Please enable JavaScript.
Coggle requires JavaScript to display documents.
Component Based Architecture - Coggle Diagram
Component Based Architecture
What is Component?
A component is a modular (cohesive), deployable (portable), replaceable (plug-and –play), and reusable set of well-defined functionalities that encapsulates its implementation and exports it as a higher-level interface.
Example
A UML component can be mapped to any target technology component
EBJ Component (.jar file)
Java Web Component (.war file)
What about MS .Net Component? - .dll file
Components Vs. OO design
A component-oriented represents a higher level of abstraction than an equivalent OO design
The component-oriented design defines components and connections between them instead of classes and connections between classes
In component-oriented design
First identify all components and their interfaces
Advantages over CO design
Reduced time in market
Lower development costs by reuse of the existing components
increased reliability with reuse of the existing components
Why use components?
-Reusability
-Productivity
-Composability
-Adaptibility
-Scalability
-Reliability and many others
Component Implementation
Usually consists of a set of class files
Abstract Interface
Concrete Implementation Classes
Note
Some IDE tools support visualization of components, e.g., VS Studio .Net Toolset
However, it does not mean that each component should have such a visual representation
Java Example
Java Counter
package counter;
interface Counter {
public void setCount(int c);
public int getCount(); public void inc();
}
Implementation File
import counter.*;
class CouterImpl implements Counter {
private int count;
public void setCount(int c){
count = c;
}
public int getCount(){
return count;
}
public void inc() {
count ++;
}
}
Why Interface & Implementation?
Separation of Interface and Implementation allows changeability!
Example 1:
CounterImpl1 myCounter = new CounterImpl1(); myCounter.inc();
Example 2:
CounterImpl2 myCounter = new CounterImpl2();
Principles of Component-Based Architecture
Figure out semantics of connections
Communication semantics important
Local: relatively easy
Remote: pay attention! many different call semantics
Think about INTERFACE, not the implementation
Component Level Design
Before the design phase, we have
Use case modeling
Business concept modeling
Use case diagrams
Describes user interactions with the system which indicate all necessary operations of the component
We can map use case diagram to the provided service interfaces of the first-cut component specification
A collaboration diagram
is an identifiable slice of functionality that describes a meaningful service involving several concepts
A collaboration diagram -> the implementation of a use case
For each use case U, there will be a collaboration diagram “encapsulated” in a component C.
Starts from Use Case Diagram
May also need business concept diagram
Mapping
Use case -> interface provider
conceptual classes -> modules of components
If necessary, big components can be further decomposed
Business concept diagram
Depicts the relationships of the business process entities in the domain
Extract business process entities that can exist independently without any associated dependency on other entities.
Recognize and discover these independent entities as new components.