Component-Based Software Engineering Module 1 Part 4 Component Composition

1. Component-Based Software EngineeringModule 1 Part 4Component Composition Dr. Eman M. Saleh Al-Maghary Email: e_saleh@asu.edu.jo – Ext. 1269 SE Department Faculty of Information Technology http://fit.asu.edu.jo – http://OpenCourse.asu.edu.jo

2. Component-Based Software Engineering 1302481 • Prerequisite: 1302386 • Text Books: • “Software Engineering, Ian Sommerville, 9th Ed., 2012.

3. Lecture Contents • Different types of component composition • Adapter components • Composition adapters and emergent properties

4. Chapter 17 Software reuse Component composition • The process of assembling components to create a system. • Composition involves integrating components with each other and with the component infrastructure. • Normally you have to write ‘glue code’ to integrate components.

5. Chapter 17 Software reuse Types of composition • Sequential composition where the composed components are executed in sequence. This involves composing the provides interfaces of each component. • Hierarchical composition where one component calls on the services of another. The provides interface of one component is composed with the requires interface of another. • Additive composition where the interfaces of two components are put together to create a new component. Provides and requires interfaces of integrated component is a combination of interfaces of constituent components.

6. Chapter 17 Types of component composition

7. Examples

8. Sequential composition • the components are executed in sequence to provide some required effect • The outputs from the ‘provides’ interface from the first component executed become the inputs for the provides interface for the 2nd unit called. Example: Simple Connect Component and the Chat Component Executed First Simple Connect Application/Server Address +User name Chat

9. Hierarchical composition • In this case, one component (defined in the requires interface) is called directly from within the body of the other component. • The calling component must know the name and the signature of the called component. Calling Chat myButton.label = “Send” Called Button

10. Additive composition • In this case, we put two components together so that the provides interface includes operations that come from both of the composed components. Chatting Room Video Audio Record session life streaming

11. Interface incompatibility • Parameter incompatibility where operations have the same name but are of different types. • Operation incompatibility where the names of operations in the composed interfaces are different. • Operation incompleteness where the provides interface of one component is a subset of the requires interface of another. Chapter 17

12. Interface incompatibility • Possible solutions: • Write wrapping code which bridges the gaps OR • Use an adaptor component to bridge the gap Chapter 17

13. Adaptor components • Address the problem of component incompatibility by reconciling the interfaces of the components that are composed. • Different types of adaptor are required depending on the type of composition. • An addressFinder and a mapper component may be composed through an adaptor that strips the postal code from an address and passes this to the mapper component. Chapter 17

14. Component adaptation-wrapping • white-box wrapping is applied : When a software team has full access to the internal design and code for a component, white-box wrapping is applied. This wrapping examines the internal processing details and makes code-level modifications to remove any conflicts. • Grey-box wrapping is applied when the component library provides a component extension language or API that enables conflicts in interfaces to be removed or masked. • Black-box wrapping: Write “glue code” which bridges the gaps

15. Components with incompatible interfaces • The component addressFinder through its location method produces a string which is the address of the property, including street number and name and town • The component mapper through its displayMap method, expects a string which is a postcode only (not a complete address)

16. Composition through an adaptor • The component postCodeStripper is the adaptor that facilitates the sequential composition of addressFinder and mapper components. Chapter 17

17. The component postCodeStripper is the adaptor that facilitates the sequential composition of addressFinder and mapper components. Adapter component - Wrapping Code

18. An adaptorlinking a data collector and a sensor An adaptor component may be used is in hierarchical composition Chapter 17

19. Photolibrary composition Chapter 17

20. Interface semantics • You have to rely on component documentation to decide if interfaces that are syntactically compatible are actually compatible. • Consider an interface for a PhotoLibrary component: Chapter 17

21. Photo Library documentation “This method adds a photograph to the library and associates the photograph identifier and catalogue descriptor with the photograph.” “what happens if the photograph identifier is already associated with a photograph in the library?” “is the photograph descriptor associated with the catalogue entry as well as the photograph i.e. if I delete the photograph, do I also delete the catalogue information?”

22. Chapter 17 The Object Constraint Language • The Object Constraint Language (OCL) has been designed to define constraints that are associated with UML models. • It is based around the notion of pre and post condition specification – common to many formal methods.

23. The OCL description of the Photo Library interface • -- The context keyword names the component to which the conditions apply • contextaddItem • -- The preconditions specify what must be true before execution of addItem • pre: PhotoLibrary.libSize() > 0 • PhotoLibrary.retrieve(pid) = null • -- The postconditions specify what is true after execution • post:libSize () = libSize()@pre + 1 • PhotoLibrary.retrieve(pid) = p • PhotoLibrary.catEntry(pid) = photodesc • context delete • pre: PhotoLibrary.retrieve(pid) <> null ; • post: PhotoLibrary.retrieve(pid) = null • PhotoLibrary.catEntry(pid) = PhotoLibrary.catEntry(pid)@pre • PhotoLibrary.libSize() = libSize()@pre—1

24. Chapter 17 Software reuse Photo library conditions • As specified, the OCL associated with the Photo Library component states that: • There must not be a photograph in the library with the same identifier as the photograph to be entered; • The library must exist - assume that creating a library adds a single item to it; • Each new entry increases the size of the library by 1; • If you retrieve using the same identifier then you get back the photo that you added; • If you look up the catalogue using that identifier, then you get back the catalogue entry that you made.

25. Composition trade-offs • When composing components, you may find conflicts between functional and non-functional requirements, and conflicts between the need for rapid delivery and system evolution. • You need to make decisions such as: • What composition of components is effective for delivering the functional requirements? • What composition of components allows for future change? • What will be the emergent properties of the composed system? Chapter 17

26. Data collection and report generation components Chapter 17

27. Composition trade-offs • There are many situations where the solutions to the composition problems are mutually conflicting. • In a): many reports may be needed and cannot be generated both data management and report generator can be replaced • In b): - Faster coz no component communication overheads. - Data integrity that apply to the database also apply to reports (no errors in reports) Chapter 17

28. Customization • We define component customization as the ability of a consumer to adapt a component prior to its installation or use. • Since components are generally treated in black-box fashion, revealing as little as possible of their implementation, components can only be customized using clearly defined customization interfaces. • A customization interface enables customization and deployment tools to modify simple properties by providing instances of other components as parameters to customization functions. • Other option is through the component provider (cost) or open source (free)

29. Packaging and Deployment • Fast Internet connections will allow component consumers to conveniently download packaged components with documentation to develop comprehensive software systems. • A component model must describe how components are packaged so they can be independently deployed. • The component must be packaged with anything that the component producer expects will not exist in the component infrastructure. • This may include the program source code, configuration data, help files, other depending components, and additional resources. • A deployment description provides information about the contents of a package and other information that is necessary for the deployment process.

30. Evolution Support • Component-based systems require support for system evolution. • Components acting as a server for other components might have to be replaced by newer versions providing new or improved functionality. • A new version may not only have a different implementation but may provide modified or new interfaces. • Existing clients of such components should, ideally, not be affected or should be affected as little as possible. • As a general rule of thumb for engineers substituting components, component B can immediately replace component A, if component B provides at least what component A provided,. • In addition, old and new versions of a component might need to co-exist in the same system.

31. Chapter 17 Key points • During the CBSE process, the processes of requirements engineering and system design are interleaved. • Component composition is the process of ‘wiring’ components together to create a system. • When composing reusable components, you normally have to write adaptors to reconcile different component interfaces. • When choosing compositions, you have to consider required functionality, non-functional requirements and system evolution.