This topic provides an introduction to the concept of Component-based development.
Component-based Development (CBD) is also known as Component-based Architecture (CBA) or Component-based Software Engineering (CBSE).
Fundamentally, CBD structures applications as assemblies of components. Components can deliver benefits above and beyond what objects promise to deliver in object-oriented development. CBD uses components to represent all parts and layers of a software-intensive system. Examples of these systems include the nodes in a wireless infrastructure network, the infotainment system in a vehicle, industrial control applications, aerospace, defense applications and so forth.
The benefits of CBD include increased
Modularity—components can be developed independent of the complete system.
Reuse—components can more easily be shared amongst projects.
Interoperability—component communicate using well-defined interfaces and messages.
Extensibility—component-based designs are inherently loosely-coupled, supporting easier extensibility of component and system functionality.
Efficiency—encapsulation, modularity, separation of concerns and the establishment of hierarchical component dependencies, or "layers," all contribute to reduced design and system complexity.
Productivity
Quality and Reliability—validation and testing can occur at the component- rather than system-level.
The following sections details the CBD concepts used to build systems.
A component is an independent unit of software with well-defined interfaces or ports. A component may be an assembly (an aggregation of components) or monolithic (a fully decomposed unit).
A component has a purpose—it provides a service—and it performs that purpose well. A component may need to communicate with other components to provide the service; this required communication is indicated on the interface of the component.
The interface of a component is indicated through ports that provide and require services. The ports ensure the encapsulation of the component and delegate communication. Ports receive messages for a component; the component performs its behavior and sends responses out to the environment.
When CBD refers to layers in a system, it refers to the software layers, the logical platform (or service layers), as well as the physical platform layers. Every layer provides services to the layers above and uses services from the layers below.
Layering is an often-used architectural concept that provides de-coupling between layers. De-coupling allows layers to evolve independently of one another, which is crucial in large development projects. Evolve independently here means that design, implementation, test, release and maintenance cycles can happen for one layer independently of any other layer.
The layers in a CBD design are built up as assemblies of components, each component is an independent entity and encapsulates it contents through its well-defined interface. Components can be assembled into larger entities. To this extent components are connected together through connectors. The assembled components represent another, larger component. The final assembly of components is the layer. An assembly does not limit itself to execution on a particular processor or process space.
The whole nature of an assembly is a set of communicating components. The assembly description is platform-independent by nature; deployment (allocation) of parts of the assembly to execution environments is deferred until a later part of the development cycle. This provides support for late-binding, which provides the development team with the option to delay decisions until later in the development process, when they have more information to base these decisions on. It also offers the design team the ability to revisit these decisions and make changes easily and unobtrusively.
The following sections provide more detail on the ideas and concepts introduced above.
The component interface defines the provided and required interfaces that the component uses to communicate with its environment. The component interface also defines properties. Properties are configurable parameters of the component interface. They allow the interface to be configured for a specific use. For example, if the component interface describes the interface for a phone switch, a property could describe the maximum number of calls that the component is able to handle.
Components communicate through ports, named and typed elements on the components interface that allow for receiving and sending of named messages with information. The messages on the port are defined through PortTypes. PortTypes are a set of incoming and outgoing interfaces used for communication.
Component interfaces are platform-independent by definition. The interface describes the communication that a component will be able to provide, and has no relation to the communication technology that will be used in the final implementation.
Interfaces are a grouping of cohesive operations. That is, operations that are related and are used to achieve a particular purpose. For example, a callSetup interface with addCall and removeCall operations, or a locationInformation interface with a currentLocation operation. Interfaces are uni-directional.
The operations within an interface can be synchronous or asynchronous, blocking or non-blocking, respectively.
PortTypes define a complete bi-directional collaboration between two parties through a set of incoming and outgoing interfaces. PortTypes are applied to ports.
Every PortType also has an inverse, which conjugates the incoming and outgoing interfaces. A port based on PortType X can communicate with a port based on the inverse of PortType X. PortType compatibility is defined as the fact that the receiver needs to be able to receive at least those operations that the sender is able to send.
A component interface is realized by a component realization. The realization is the modeling entity that ensures that the messages on the ports of the component interface are handled. A single component interface can be realized by one or more component realizations.
A component realization can come in the form of structure, that is, the component contains an assembly of component parts. The messages on the interface of the component are delivered to its parts for processing. The parts within the realization are defined by component interfaces, which themselves have component realizations, thereby allowing for an unlimited level of hierarchical structure.
A component realization can also come in the form of a behavioral description. This behavioral description can be code in a programming language (C, C++, Java, Ada, Perl, and so forth), but can also be a description in other modeling paradigms, for example The MathWorks Simulink or IBM Rhapsody.
Component realizations can contain a mix of behavior and structure. Some of the ports on a component interface can be implemented in structure and some of it in behavior.
The component realization can be defined through structure, an assembly of component parts connected through connectors.
A component part defines an instance of a component interface that will be present at run-time, a part is to a component interface what an attribute is to the class that defines that attribute (in C++ or Java, for example). The ports on the parts in a structure can be connected together; however, only compatible ports can be connected together.
As mentioned in the previous section, a component realization can contain behavior in source code format, either 3GL type or executable languages like executable UML. When a component realization contains behavior, then it also contains one or more implementation. The reason for the implementation is to represent the platform-specific information with relation to the code. These dependencies are settings such as compilation flags, libraries, inclusion paths and so forth. The implementation also contains code that is specific to a particular operating environment, for example code to handle device level issues if required.
Platform independence is important in embedded systems. One question to answer when striving for platform independence is what the application needs to be independent of. In CBD, the separation between Component Interface, Component Realization and Component Implementations provides this flexibility with regards to independence.
Embedded systems used to comprise a couple of threads, executing on an embedded processor. Today's embedded systems contain multiple process spaces, multiple processors, fast communication busses and so forth.
CBD recognizes this and allows the design team to express these concepts, again, in a domain-specific fashion. The logical and physical layers are model-representations of these layers. The layers are usually the responsibility of a "platforms" or "HAL" team, though this team has different names in different organizations. The model is there to represent the artifacts that this team has developed.
This layer describes the actual processing environment that the software executes on. In many domains, this is an optional layer. The physical layer is important if the design team wants to include real-time considerations in their modeling, for example, when using the MARTE standard.
Concepts in the physical platform include the processors used, for example PPC, ARM, or system-on-chip processors like the TIC6488. Systems can be as simple as a single board, or as complex as a multi-card ATCA telecom system.
The physical platform is typically abstracted through the logical platform.
The logical platform describes the places where software can be executed.
Most embedded systems use the concepts of process, thread and logical communication bus. However, depending on the domain this could be a "logical device" (SCA), CORBA bus, TIPC bus and so forth. Buses can be best-effort-based, like TCP/IP, or more deterministic: they can send data immediately for low latency, or they can send data in a buffered fashion.
All these concepts can be described in the DSL that describes this logical layer. The developer can then be presented with multiple different logical layers, one for the current hardware set and some for possible evolutions of the physical hardware sets that the product will need to support.
Deployment is a new concept introduced by CBD, it brings together the software layers with the platform layers. It models a mapping from software components and the connections between these components to the different platform layers. The deployment can be seen as a model-based representation of something that many teams call "integration."
A deployment can include a configuration. A configuration assigns values to the properties on the component interface. A PBX, for example, can have different configurations, with a maximum number of calls and with a maximum number of incoming/outgoing lines. These types of properties can be configured on the Deployment.
The deployment and configuration is the final step in integrating software on hardware. It describes which software subsystems need to be included, how to configure them and how to map them to the execution environment.
Once the deployment and configuration has been modeled we have all the information that we need to do efficient and finely-tuned code generation. The deployment is where "the rubber hits the road." The software is assigned to hardware. Any software application can be mapped to many hardware configurations in a number of different ways.
The deployment and configuration is domain-specific. For example, the SCA domain abstracts all communication through CORBA and hence mapping of connections to buses is irrelevant, while in a baseband DSP domain this is a major point of concern and optimization is critical.
Modeling of course is not a goal; it is a means to an end. Modeling is often done primarily for communication and documentation. However, the DSL approach in CBD makes the model more powerful: it can now be used to validate designs as well as transforming of designs into high-performance, executable code.
Validation of an existing model evaluates the deployment and flags problems when they are found. Problems may be entirely contained within the software layer, for example, incompatible software components that are connected—say component A provides an interface foo, where component B requires interface ba r from A. Validation will flag this and allow designers to resolve these issues.
The design team can use validation in early design days and express how they think the system will perform. These requirements are part of the model and can be refined during the development of the system. Treating these requirements as first class model entities avoids costly surprises late in the development cycle.
Validation also allows the team to explore alternative designs and receive immediate feedback on whether certain designs are feasible. The validation provides information on whether timing constraints can be met.
Transformation deals with the topic of transforming model elements into executable source code. Executable source code can be in the 3GL category (C, C++, Java), or can be other models, such as The MathWorks Simulink or IBM Rhapsody.
CBD can use both the domain-specific information as well the information in the deployment during generation. The domain-specific information provides additional information about the type of the model element; as previously mentioned, it adds additional levels of abstraction to the modeling space, abstractions that the generator understands and can use.
This deployment has the information for all of the usages of a particular entity or component and hence can optimize generation of that entity based on "global information." CBD also knows how the entity is used within the context of the logical platform and can optimize based on that.