Architectural Modelling in Product Family Context

Transcription

1 Architectural Modelling in Product Family Context Rodrigo Cerón, José L. Arciniegas, José L. Ruiz, Juan C. Dueñas (Universidad Politécnica de Madrid) Jesús Bermejo (Telvent) Rafael Capilla (Universidad Rey Juan Carlos) SPAIN

2 Contents System family engineering The role of architecture Architectural processes Examples and tool support Conclusions and further work 2

3 System Family Engineering 3

4 The role of models in SFE Traceability Conflicts Test model dependency with the conflict package is not straight; the dependency is based on the design in the implementation phase. Requirement Models Architectural Models Test Models Decision Test model dependency with the decision package is not straight; the dependency is based on the design in the implementation phase. 4

5 Architectural models SSPF A rc h it e c tu ra l C on f l ic t 0..* Stakeholder 2..* takes part in 0..*..* identif ies..* is im portant to..*..* affects to 0..* A rc hitec tural D ec is ion are taken in selects Variants used to cover is a d dr es s e d t o Decision Model Template is based on Decision Model consists of has..* C oncern.. * Viewpoint has source 0.. Library Viewpoint established m ethods f or.. * consists of 0..*..* belongs to has.. * V ar ia b il it y p o in t identifies..* conf orm s to participates in Model..* consists of..* Common Parts SSPF Architectural Description selects..*..* SSPF View consists of..*..* participates in described by organized by..*..* Asset consists of..*..* provides R ationale participates in is defined by Expression..*..*..* Elem ent C onnector affects to 5

6 SFE Modelling Aids UML as modelling language Variation point: a scattered region in the model where decision must be made to obtain specific products. Variant: each different asset that can be chosen at variation points. No explicit representation of variation point inside the reference architecture model. Each variant in the reference architecture must be labelled. Reference architecture should ideally provide an orthogonal space of decision. 6

7 Core reference architecture Core Reference Start Domain Scoping [Initial] Product scoping [Initial] Product architectural Scoping Product scoping assessment Domain Scoping [Refined] Product scoping [Refined] Product out PF Discard product from PF Product can be in PF PF Requirements Choose architectural style Common Requirements Assessment Not fullfil for all Products Fullfil for all products Engineering Assets Repository Develop core Reference architecture Core Reference [Draft] Core Reference Stop 7

8 Refinement and population Refinement and architectural population start Core Reference [Draft] Refine core reference architecture Core Reference [Draft] Platform Repository Enrich core reference architecture Core Reference [Initial] Engineering Assets Repository Incoherent Provide Variation Points Coherent PF Reference [Draft] Product Specific Requirements Identify variation points relationship Architectural Requirements assessment PF Reference [Provisioned] PF Reference [assessed] Not fulfill Requirements Identify ranges for variations points Fulfill Requirements PF Reference [Initial] Refinement and architectural population stop 8

9 Functional derivation Functional Derivation Start PF Reference [Initial] Product Specific Requirements Select functional-based decisions Select Variants Component Repository Match component Repository Functional Product [Draft] No match All match Remove incompatible variants No posible remove Complete Check architectural requirements Functional Product [Initial] No fulfill Arch. Req. fufill Architectural Requirements Functional Derivation Stop 9

10 Non functional derivation Non-functional derivation start Functional Product [Initial] Select non-funcional-based decisions Product Specific Requirements Select Variants Match component Repository Specific Product [Draft] Component Repository No match All Match PF Requirements Check completeness Incomplete and no possible to defer Complete or incomplete but possible defer Package product specific architecture Specific Product [packaged] Quality Model Quality assess model Specific Product [Initial] No fulfil Quality model Fulfil Quality model Non-functional derivation stop 0

11 Reference architecture - Example ProfileManager {Variant} BindList {Variant} (from graphics) BindJ2MEListener {Variant} (from graphics) Controller (from logic) manageprofileclient {Variant} * * useprofileclient {Variant}..n addprofile() deleteprofile() MovementTechnique {Variant} Profile {Variant} completeorder() manageprofileserver {Variant} useprofileserver {Variant} DeviceController DeviceDriver BindEngine {Variant} BindEngine2 {Variant} BindFrame {Variant} (from graphics) BindJ2SEListener {Variant} (from graphics) LinkConnection (f rom Ne two rk) LinkManager {Variant} (from Network) MIDLinkManager {Variant} (from Network) ServletFrontEnd Console GUI

12 Variation points VP: possibility of using J2ME or J2SE classes for the GUI of the client. VP = (BindList AND BindJ2MEListener) XOR (BindFrame AND BindJ2SEListener) VP2: possibility of using J2ME or J2SE network classes to build the network implementation of the client. VP2 = LinkManager XOR MIDLinkManager VP3: possibility of controlling different types of electronic binds. Different engines are different device drivers for each of these. VP3 = BindEngine XOR BindEngine2 VP4: optional functionality. The system may or may not store profiles for the automatic adaptation of the light in the room to the user needs. VP4 = OPT (ProfileManager AND MovementTechnique AND Profile) VP5: possibility of associating optional components in VP4 to the server or to the client. If a profile manager is included, it can be allocated to the client or to the server. A decision about the quality of the system must be taken whose results are to put this function in either of those places. VP5 = VP4 AND ((manageprofileclient AND useprofileclient) XOR (manageprofileserver AND useprofileserver)) 2

13 Decisions for derivation Decision = BindList, BindJ2MEListener Decision 2 = MIDLinkManager Decision 3 = BindEngine Decision 4 = TRUE Decision 5 = manageprofileserver, useprofileserver. 3

14 Product architecture - Example BindList (from graphics) Contr oller (from logic) Pr ofile + completeorder() MovementTechnique DeviceController Pr ofilemanager + addprofile() + deleteprofile() BindJ2MEListener (from graphics) LinkConnection (from Network) MIDLinkManager (from Network) ServletFrontEnd DeviceDriver (from Server Class es) BindEngine Console GUI 4

15 Validation A complete logical language has been defined (including the not, or, xor, and operators) and a prototype of tool for execution of the derivation process has been developed. The largest experiment so far: 55 classes, 6 interfaces, 25 inheritance associations, 20 composition associations, 20 implementation associations, 60 attributes and 20 methods 28,474,976,70,656 possible product architectures. applying decisions iteratively a satisfactory solution can be found in seconds. 5

16 Conclusions The variability of functional elements must be represented. Unconnected regions of models can be part of the variation point; other approaches link each of the possible variants to a single point in the architecture. Different rules for relations are included, not only the selection (xor), but mandatory and optionality. Associations between elements in the model can also be affected by the variability points and henceforth they can be affected by the rules and decisions. Non-functional issues, such as quality crosscutting or adaptations to different deployment settings, must be dealt with in the variability representation (for example, the allocation to the client or the server of a certain functionality). 6

17 Future work Review of the work under UML 2.0 Semantic checking between UML models and views Application of variation points to other elements in models than packages or classes Methodological support for the management of decisions Support for traceability among common parts in domain analysis, architecture and implementation 7