Chapter 11 Component Based Architecture (Component Level Design (A…
Component Based Architecture
Component-based Architecture used to
Divide a problem into sub-problems
Each sub-problem is associated with a component
Interface plays an important role
Components are highly reusable
A component encapsulates the functionality and behaviors of a software element into a reusable and self-deployable binary.
Use of COTS or developed in-house components
Increases overall reliability
Can greatly reduce development cost
A component is a deployable software package that can provide services to its client
It may require services from other components
It remains self-contained and substitutable as long as it interface is unchanged.
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, and
increased reliability with reuse of the existing components
Many standard component frameworks
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.
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?
Why use components?
Reliability and many others
Usually consists of a set of class files
Concrete Implementation Classes
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
Separation of Interface and Implementation allows changeability!
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
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.
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
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.
Starts from Use Case Diagram
May also need business concept diagram
Use case interface provider
conceptual classes modules of components
If necessary, big components can be further decomposed
Suitable for where the interface contracts between sub-systems are clear.
Suitable for loose coupling between the components and many reusable components are available
Suitable for the class library system organization. .NET class library and Java API themselves are built in component architecture
Reusability of components:
System maintenance and evolution:
Independency and flexible connectivity of components
Many OO design tools available
Sometime it is difficult to find suitable components to reuse.
Adaptation of components is always an issue.