- Software Architecture & Design
- Home
- Introduction
- Key Principles
- Architecture Models
- Object-Oriented Paradigm
- Data Flow Architecture
- Data-Centered Architecture
- Hierarchical Architecture
- Interaction-Oriented Architecture
- Distributed Architecture
- Component-Based Architecture
- User Interface
- Architecture Techniques
- Useful Resources
- Quick Guide
- Useful Resources
- Discussion
Component-Based Architecture
Component-based architecture focuses on the decomposition of the design into individual functional or logical components that represent well-defined communication interfaces containing methods, events, and properties. It provides a higher level of abstraction and divides the problem into sub-problems, each associated with component partitions.
The primary objective of component-based architecture is to ensure component reusability. A component encapsulates functionality and behaviors of a software element into a reusable and self-deployable binary unit. There are many standard component frameworks such as COM/DCOM, JavaBean, EJB, CORBA, .NET, web services, and grid services. These technologies are widely used in local desktop GUI application design such as graphic JavaBean components, MS ActiveX components, and COM components which can be reused by simply drag and drop operation.
Component-oriented software design has many advantages over the traditional object-oriented approaches such as −
Reduced time in market and the development cost by reusing existing components.
Increased reliability with the reuse of the existing components.
What is a Component?
A component is a modular, portable, replaceable, and reusable set of well-defined functionality that encapsulates its implementation and exporting it as a higher-level interface.
A component is a software object, intended to interact with other components, encapsulating certain functionality or a set of functionalities. It has an obviously defined interface and conforms to a recommended behavior common to all components within an architecture.
A software component can be defined as a unit of composition with a contractually specified interface and explicit context dependencies only. That is, a software component can be deployed independently and is subject to composition by third parties.
Views of a Component
A component can have three different views − object-oriented view, conventional view, and process-related view.
Object-oriented view
A component is viewed as a set of one or more cooperating classes. Each problem domain class (analysis) and infrastructure class (design) are explained to identify all attributes and operations that apply to its implementation. It also involves defining the interfaces that enable classes to communicate and cooperate.
Conventional view
It is viewed as a functional element or a module of a program that integrates the processing logic, the internal data structures that are required to implement the processing logic and an interface that enables the component to be invoked and data to be passed to it.
Process-related view
In this view, instead of creating each component from scratch, the system is building from existing components maintained in a library. As the software architecture is formulated, components are selected from the library and used to populate the architecture.
A user interface (UI) component includes grids, buttons referred as controls, and utility components expose a specific subset of functions used in other components.
Other common types of components are those that are resource intensive, not frequently accessed, and must be activated using the just-in-time (JIT) approach.
Many components are invisible which are distributed in enterprise business applications and internet web applications such as Enterprise JavaBean (EJB), .NET components, and CORBA components.
Characteristics of Components
Reusability − Components are usually designed to be reused in different situations in different applications. However, some components may be designed for a specific task.
Replaceable − Components may be freely substituted with other similar components.
Not context specific − Components are designed to operate in different environments and contexts.
Extensible − A component can be extended from existing components to provide new behavior.
Encapsulated − A A component depicts the interfaces, which allow the caller to use its functionality, and do not expose details of the internal processes or any internal variables or state.
Independent − Components are designed to have minimal dependencies on other components.
Principles of Component−Based Design
A component-level design can be represented by using some intermediary representation (e.g. graphical, tabular, or text-based) that can be translated into source code. The design of data structures, interfaces, and algorithms should conform to well-established guidelines to help us avoid the introduction of errors.
The software system is decomposed into reusable, cohesive, and encapsulated component units.
Each component has its own interface that specifies required ports and provided ports; each component hides its detailed implementation.
A component should be extended without the need to make internal code or design modifications to the existing parts of the component.
Depend on abstractions component do not depend on other concrete components, which increase difficulty in expendability.
Connectors connected components, specifying and ruling the interaction among components. The interaction type is specified by the interfaces of the components.
Components interaction can take the form of method invocations, asynchronous invocations, broadcasting, message driven interactions, data stream communications, and other protocol specific interactions.
For a server class, specialized interfaces should be created to serve major categories of clients. Only those operations that are relevant to a particular category of clients should be specified in the interface.
A component can extend to other components and still offer its own extension points. It is the concept of plug-in based architecture. This allows a plugin to offer another plugin API.
Component-Level Design Guidelines
Creates a naming conventions for components that are specified as part of the architectural model and then refines or elaborates as part of the component-level model.
Attains architectural component names from the problem domain and ensures that they have meaning to all stakeholders who view the architectural model.
Extracts the business process entities that can exist independently without any associated dependency on other entities.
Recognizes and discover these independent entities as new components.
Uses infrastructure component names that reflect their implementation-specific meaning.
Models any dependencies from left to right and inheritance from top (base class) to bottom (derived classes).
Model any component dependencies as interfaces rather than representing them as a direct component-to-component dependency.
Conducting Component-Level Design
Recognizes all design classes that correspond to the problem domain as defined in the analysis model and architectural model.
Recognizes all design classes that correspond to the infrastructure domain.
Describes all design classes that are not acquired as reusable components, and specifies message details.
Identifies appropriate interfaces for each component and elaborates attributes and defines data types and data structures required to implement them.
Describes processing flow within each operation in detail by means of pseudo code or UML activity diagrams.
Describes persistent data sources (databases and files) and identifies the classes required to manage them.
Develop and elaborates behavioral representations for a class or component. This can be done by elaborating the UML state diagrams created for the analysis model and by examining all use cases that are relevant to the design class.
Elaborates deployment diagrams to provide additional implementation detail.
Demonstrates the location of key packages or classes of components in a system by using class instances and designating specific hardware and operating system environment.
The final decision can be made by using established design principles and guidelines. Experienced designers consider all (or most) of the alternative design solutions before settling on the final design model.
Advantages
Ease of deployment − As new compatible versions become available, it is easier to replace existing versions with no impact on the other components or the system as a whole.
Reduced cost − The use of third-party components allows you to spread the cost of development and maintenance.
Ease of development − Components implement well-known interfaces to provide defined functionality, allowing development without impacting other parts of the system.
Reusable − The use of reusable components means that they can be used to spread the development and maintenance cost across several applications or systems.
Modification of technical complexity − A component modifies the complexity through the use of a component container and its services.
Reliability − The overall system reliability increases since the reliability of each individual component enhances the reliability of the whole system via reuse.
System maintenance and evolution − Easy to change and update the implementation without affecting the rest of the system.
Independent − Independency and flexible connectivity of components. Independent development of components by different group in parallel. Productivity for the software development and future software development.