Architectural Description of Object Oriented Frameworks: An Approach

1. Architectural Description of Object Oriented Frameworks: An Approach Gabriela Arévalo LIFIA (UNLP - Argentina), EMN (France) Isabelle Borne EMN (France)

2. Composition Association A provides services to B ? Hierarchy Motivation • The documentation provided to understand an object oriented framework: overall design, variation points, architecture reuse and possible integrations • Trends: informal and semi-formal techniques

3. Work Approach • Problem: Documentation has limitations to represent the semantics of the different parts of the frameworks • Proposal: use of a formal architectural description language (ADL) • Objectives: • Evaluate the expressive power of the approach • Consider the complementarity and flexibility regarding other approaches

4. Context and Tools Wright ADL (Formal Theory: CSP) ARCHITECTURAL DESCRIPTION Object Oriented Frameworks OO frameworks: set of abstract classes and way objects in those classes collaborate(Johnson & Foote, 1988) analysis, design and code reuse; frozen spots; hotspots Software architecture: the structure of the components of a system, their interrelationships, and principles and guidelines governing their design and evolution over time (Shaw & Garlan, 1996) ADLs, architectural styles

5. Architectural Description of Frameworks Issues of using Wright: • definition of components and connectors • protocols of elements in terms of CSP • internal state of components (use of Abstract Machines B) Nowack Work (1998): 3 levels

6. Measrmt Item Item Factory Measrmt Values A Case Study Measurements System Framework (Bosch, 1999) Sensor 2 Item Factory 3 Measurement Item 4 1 5 Actuator 6 Trigger Class Diagram 1 .. n

7. Component A Connector AB Component B Class A Class B Class B Inst variables x, y, z Method m3: p1 Class A Method m1 Method m2: p1 x: p2 Components and Connectors Architectural Component Software Component Class

8. Components and Connectors - Example Component ItemFactory Port MItem= (events to MItem) Computation = .... Component MValues Port MItem = (events from IFactory) Computation = .... Component MItem Port IFactory = (events from IFactory) Port MValues = (events to MValues) Computation = .... Connector Distributn (nMV: 1..n) Role MItem = (events from IFactory) Role MValues1..nMV = (events to MValues) Glue = ....

9. Protocols in terms of CSP Rule: Classes Creation B new or B new with:p1 .... with: pn create -->  x [] 1..n; asParameter! px (ox1, …. oxn ) Rule: If-expression (condition) ifTrue:[actionTrue] ifFalse:[actionFalse] actionTrue (or  x 1..n; actionTruex)  actionFalse (or  x 1..n; actionFalsex)

10. Protocols - Example (1) Class: Item Factory trigger “Start an item” mi:=prototype copy. (inCalibration) ifTrue:[(calib. mode)] ifFalse: [(normal mode)] mi.start ^mi Port MItem{ItemFactory side}= copy (<calibration mode>  <normal mode>) start Glue {Connector} = IFactory.copy Mitem.copy [] ... Port ItemFactory {Mitem side}= copy (<calibration mode> [] <normal mode>) start

11. Protocols - Example (2) Class: Measurement Item performCalculation measurementValues do:[:each | each performCalculation] Port MValues{MItem side}= performCalculation MValues Glue {Conn. Distribution} = MItem. performCalculation x:1..nMVs; MValuesx.performCalculation Port MItem {Mitem side}= performCalculation <gets the real measrmts>

12. Tests of a Wright Description Completeness & Consistency Component ItemFactory Component MItem Component MValues Connector IF_to_MI Connector MI_to_MV Architectural Description based on an ADL • Raise the level of abstraction • Model without implementation details • Description used as documentation

13. Aspects of the Algorithm Levels of Description: Structural Relationships Hierarchical Component A Component A Connector AC Connector AB Component C Component B Class E Class A Class B Class C Class F Class A Method m1 Method m2: p1 x: p2 Class C ( superclass: B ) Instances variables x, y, z Method m3: p1

14. Approach: Discussion • Case Studies: Measurements System and Coordination Component Frameworks (approx. 20-25 classes) • Graph of Connectors & Components Tests of Completeness and Consistency Definition an Architectural Style Frozen Spots Framework Architecture • Levels of Description • Architectural Views (Behavioural, Growth views) • Lack of expressiveness of structural and timing issues • Lack of expressiveness in dynamic binding and creation/destruction of components

15. Conclusions (1) GENERAL ASPECTS • Architectural Style characterizes all the applications resulting from the framework instantiation • “Language-independent” mapping (code to CSP notation) • Complementariness with other techniques • Ex: UML class diagrams to express class hierarchies

16. Conclusions (2) ARCHITECTURAL MODELLING • Semantic Structure: how the classes were structured and how they collaborate with other objects. • Two models: units of computation (components) & units of communication (connectors)

17. Future Research • An automatic tool to build the Wright description and to validate the approach • Study of inferred information in terms of formal properties • Study of the representation of frameworks as one architectural component. • Solutions with another ADLs to the presented problems