Component-based software engineering Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 19 Slide 1 CBSE essentials Independent components gespecificeerd door hun interfaces. Component standards om integratie van componenten te vereenvoudigen. Middleware voorziet ondersteuning voor de onderlinge samenwerking van de componenten. A development process dat geriht is op hergebruik. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 19 Slide 2
CBSE and design principles Los van de voordelen van hergebruik, is CBSE gesteund op: Componenten zijn onafhankelijk dus geen onderlinge interferentie; De implementatie van de componenten is verborgen; Communicatie gebeurt via goed gedefinieerde interfaces; Component platforms zijn shared en reduceren de ontwikkelingskosten. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 19 Slide 3 Components Componenten bieden een service zonder vraag waar de component wordt uitgevoerd of zijn programmeertaal Een component is een onafhankelijk uitvoerbare entiteit die kan opgebouwd zijn uit meerdere uitvoerbare objecten; De component interface is publiek en alle interacties gaan via de publieke interface; Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 19 Slide 4
Component characteristics 1 Standardised Independen t Composable Component standardisation means that a component that is used in a CBSE process has to conform to some standardised component model. This model may define component interfaces, component meta-data, documentation, composition and deployment. A component should be independen t Š it should be possible to compose and deploy it without having to use other specific components. In situations where the component needs externally provided services, these should be explicitly set out in a ŌrequiresÕ interface specification. For a component to be composable, all external interactions must take place through publicly defined interfaces. In addition, it must provide external access to information about itself such as its methods and attributes. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 19 Slide 5 Component characteristics 2 Deployable Documented To be deployable, a component has to be se lf-contained and must be able to operate as a stand-alone entity on some component platform that implements the component model. This usually means that the component is a binary component that does not have to be compiled before it is deployed. Components have to be fully documented so that potential users of the component can decide whether or not they meet their needs. The syntax and, ideally, the semantics of all component interfaces have to be specified. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 19 Slide 6
Component interfaces Provides interface Definieert de services die door de component worden geboden aan andere componenten. Requires interface Definieert de services die specificeren welke services moeten beschikbaar worden gesteld aan de component opdat hij zou werken zoals voorzien. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 19 Slide 7 Component interfaces Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 19 Slide 8
A data collector component Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 19 Slide 9 Components and objects Componenten zijn entiteiten georganiseerd voor effectief gebruik. Components definieren geen types. Component implementaties zijn ondoorzichtig. Componenten zijn taal-onafhankelijk. Componenten zijn gestandaardiseerd. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 19 Slide 10
Component models Een component model is een definitie van een standdard van een component implementatie, documentatie en verspreiding. Voorbeelden van component models EJB model (Enterprise Java Beans) COM+ model (.NET model) Corba Component Model Het component model specificeert hoe interfaces moeten worden gedefinieerd en specificeert de elementen die moeten worden opgenomen in een interface definitie. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 19 Slide 11 Elements of a component model Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 19 Slide 12
Middleware support Component models zijn de basis voor middleware die ondersteuning biedt voor het uitvoeren van componenten. Component model implementaties bieden: Platform services die de componenten laten communiceren; Horizontale services: applicatie-onafhankelijke services gebruikt door verschillende componenten.. Om van de services voorzien door een model gebruik te kunnen maken, worden componenten verspreid in een container. Dit is een set van interfaces die worden gebruikt om toegang te krijgen tot de service implementaties. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 19 Slide 13 Component model services Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 19 Slide 14
Component development for reuse Componenten ontwikkeld voor een specifieke applicatie moeten meestal worden veralgemeend om ze herbruikbaar e maken. Een component is meestal herbruikbaar als het geassocieerd is met een stabiele domain abstraction (business object). Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 19 Slide 15 The CBSE process Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 19 Slide 16
The component identification process Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 19 Slide 17 Component composition Het proces van het assembleren van componenten om een systeem te creëren. Compositie houdt in: Integratie van componenten met mekaar en met de component infrastructure. Normaliter moet glue code worden geschreven om componenten te integreren. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 19 Slide 18
Types of composition Sequential composition waar de samengestelde componenten uitgevoerd worden in sequentiele volgorde. Hierarchical composition waarbij een component beroep doet op de services van een andere. De provides interface van de ene component is samengevoegd met de requires interface van de andere. Additive composition waar de interfaces van twee componenten worden samengevoegd om een nieuwe component te creëren. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 19 Slide 19 Types of composition Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 19 Slide 20
Interface incompatibility Parameter incompatibility waar operaties dezelfde naam hebben maar van verschillende types zijn. Operation incompatibility waar de namen van de operaties in de provides interface en de requires interfaces verschillend zijn. Operation incompleteness waar de provides interface van de ene component een subset is van de requires interface van een ander. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 19 Slide 21 Incompatible components Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 19 Slide 22
Adaptor components Een probleem van incompatibiliteit wordt in elk geval opgelost door het schrijven van een ADAPTOR component. De interfaces van de samen te stellen componenten worden compatible gemaakt. De types van adaptor kunnen van verschillende types zijn. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 19 Slide 23 Composition through an adaptor De component postcodestripper is de adaptor die de sequentiele compositie van addressfinder en mapper componenten mogelijk maakt. address = addressfinder.location (phonenumber) ; postcode = postcodestripper.getpostcode (address) ; mapper.displaymap(postcode, 10000) Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 19 Slide 24
Adaptor for data collector Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 19 Slide 25 Photo library composition Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 19 Slide 26
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? Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 19 Slide 27 The Object Constraint Language De Object Constraint Language (OCL) werd ontworpen om constraints te definieren geassocieerd met UML models. Ze is gesteund op de notatie van de pre en post conditie specificatie. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 19 Slide 28
Formal description of photo library -- The context keyword names the component to which the conditions apply context additem -- 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 Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 19 Slide 29 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. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 19 Slide 30
Data collection and report generation Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 19 Slide 31