Developing Component-Based Systems

1. Developing Component-Based Systems TIP This chapter discusses the techniques to develop component-based systems, i.e., architecture design, components and interface, component assembly, and testing. X LIU, School of Computing, Napier University

2. What is architecture • The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them.

3. What is architecture • The architecture is not the operational software, rather, it is a representation that enables a software engineer to • Analyze the effectiveness of the design in meeting its stated requirements • Consider architectural alternatives at a stage when making design changes is still relatively easy • Reducing the risks associated with the construction of the software

4. Why is architecture important • Representations of software architecture are an enabler for communication between all parties interested in the development of a computer-based system • The architecture highlights early design decisions that will have a profound impact of all software engineering work that follows, and as important, on the ultimate success of the system as an operational entity • Architecture constitutes a relatively small, intellectually graspable model of how the system is structured and how its components work together

5. Components and architecture • A component system architecture consists of • a set of platform decisions • a set of component frameworks • an interoperation design for the component frameworks.

6. Platform • A platform is the substrate that allows for installation of components and component frameworks, such that these can be instantiated and activated. • A platform can be concrete or virtual. • Concrete platforms provide direct physical support, that is implement their services in hardware • Virtual platforms, also called platform abstractions or platform shields, emulate a platform on top of another, introducing a cost-flexibility trade-off. • In practice, all platforms are virtual to some degree, and a sharp distinction is academic.

7. Component Framework • A component framework is a dedicated and focused architecture, usually around a few key mechanisms, and a fixed set of policies for mechanisms at the component level. • Component frameworks often implement protocols to connect participating components and enforce some of the polices set by the framework. • The polices governing the use of the mechanisms that are used by the framework itself are not necessarily fixed, instead, they can be left to higher-level architectures.

8. Interoperation Design • A interoperation design for component frameworks comprises the rules of interoperation among all the frameworks joined by the system architecture

9. The Structure of a Component • A component is a set of normally simultaneously deployed atomic components. • The distinction between components and atomic components caters for the fact that most atomic components will never de deployed individually, although they could. • Instead, most atomic components belong to a family of components and a typical deployment will cover the entire family.

10. The Structure of a Component • An atomic component is a module and a set of resources • Atomic components are the elementary units of deployments, versioning and replacement. Although usually deployed in groups, individual deployment is possible. • A module is a set of classes and possible non-object-oriented constructs, such as procedures or functions.

11. Architectural styles • Any software system is based on certain architectural style. • Each style describes a system category that encompasses: • A set of components that perform a function required by a system • A set of connectors that enable communication, coordinations and cooperation among components

12. Architectural styles • Constrains that define how components can be integrated to form the system • Semantic models that enable a designer to understand the overall properties of a system by analyzing the known properties of its constituent parts.

13. Architectural styles • Data centered architectures • Data flow architectures • Call and return architectures • Object-oriented architectures • Layered architectures • Tiered component architecture

14. Data centered architectures

15. Data centered architectures • Client software accesses a central repository. • In some cases, the data repository is passive, i.e., client software accesses the data independent to any changes to the data or the actions of other client software. • A variation on this approach transforms the repository into a blackboard that sends notifications to client software when data of interest to the client changes.

16. Data centered architectures • Data centered architectures promote integrability. Existing components can be changed or new client components can be added to the architecture without concern about other clients because the components operate independently. • In addition, data can be passed among clients using the blackboard mechanism, i.e., the blackboard component serves to coordinate the transfer of information between clients. • Client components are independently executing processes.

17. Data flow architectures

18. Data flow architectures • A pipe and filter pattern has a set of components, called filters, connected by pipes that transmit data from one component to the next. • Each filter works independently of those components upstream and down stream; is designed to expect data input of a certain form, and produces data output to the next filter of a specified form.

19. Data flow architectures • However, the filter does not require knowledge of the working of its neighboring filters. • If data flow degenerates into a single line of transform, it is termed batch sequential. This pattern accepts a batch of data and then applies a series of sequential components to transform it.