Comparison of System Family (Product Line) Modeling Approaches
advertisement
Comparison of System Family (Product Line) Modeling Approaches University of Oslo Jon Oldevik SINTEF SPLC - 2005 Øystein Haugen, Birger Møller-Pedersen Towards ... A reference model for comparing approaches to the modeling of system families What should such a reference model do? Analyzability (can system (family) be analyzed?) Support for iterative development (partial models)? Maintenance, evolution (what about not-foreseen features?) SPLC - 2005 – Obviously tell how a specific modeling approach handles variations, – but, equally important, how the modeling approach cover commonalities and requirements to systems development in general, e.g. Reference Model SPLC - 2005 Comparison issues How commonalities and variabilities are handled SPLC - 2005 Can system family models be analyzed? Partial system family models? How the production of actual systems is performed. Not-foreseen features? Simple example Watch with display, a number of buttons and a speaker Speaker may be plain speaker or polyphonic speaker SPLC - 2005 Framework/Configuration Approach = Requirements Model influence = Modeling by means of Specialization/ Composition/ Configuration SPLC - 2005 = Generic system and Framework & Library = Requirements resolution Generic Specific Speaker PolyphonicSpeaker PlainSpeaker Based on mechanisms of standard languages (composition, specialization, generic mechanisms) SPLC - 2005 Commonalities captured by system family model as a framework with default architecture and default behavior Family-as-the-union-of-all-systems Approach feature variation point = Generation SPLC - 2005 = Union of all systems Generic Specific Commonalities captured by union of mandatory elements Variation model elements marked by annotations SPLC - 2005 System family model contains all possible variants Domain Specific Languages Approach = Domain knowledge influence = Modeling in Domain Specific Language SPLC - 2005 = Domain Specific Language = System specific requirements Generic Specific General purpose language elements No system family model, but commonalities captured by elements of the language Variations captured by different language elements SPLC - 2005 Domain specific language elements How are variabilities modeled? Framework/ Configuration Family-as-theunion-of-all-systems Domain Specific Languages By generic mechanisms of a (standard) language As annotations to a (standard) language By specific language mechanisms SPLC - 2005 How are commonalities modeled? Framework/ Configuration Family-as-theunion-of-all-systems Implicitly defined This model is also a valid system model (with default architecture and behavior). The system family model is not necessarily a valid system model. As there is no system family model, commonalities are defined by elements of the DSL SPLC - 2005 The system family model is a model of the common properties of all systems. Domain Specific Languages Are systems modeled or are they generated ? Family-as-theunion-of-all-systems Domain Specific Languages Modeled Generated Modeled Model elements may be added. Model elements should not be added. Model elements may be added. Standard code generator may be used. Standard code generator may be used. Tailored code generator must be used. SPLC - 2005 Framework/ Configuration Can the system family model be analyzed? Framework/ Configuration Family-as-theunion-of-all-systems Domain Specific Languages Yes No No as the family model with all variations and all model annotations is not necessarily a valid system model as there is no system family model, however, the language may be analyzed SPLC - 2005 as the family model is a valid system model with default structure and behavior specified Are partial system family models supported? Family-as-theunion-of-all-systems Domain Specific Languages Yes Yes No as a new system family model (a copy), in which some variabilities have been resolved since there is no system family model. as specializations and extensions of the system family model. SPLC - 2005 Framework/ Configuration How are unforeseen features handled? Framework/ Configuration Just added to the model, by specialization or composition Family-as-theunion-of-all-systems If they can be expressed in the DSL, express them there. If not expressible, make a new language SPLC - 2005 The system family model has to be changed, or one shall allow additions to the (automatically) generated system model Domain Specific Languages Conclusion No approach have all the nice properties that one would like to have!! What about combining approaches? SPLC - 2005 Obvious combinations Frameworks/configuration and annotations – E.g. for different kinds of variations Doing DSL in a standard language? – This is called profiling (at least for UML within OMG) SPLC - 2005 Not-so-obvious combinations Doing Framework/Configuration in a DSL? – The DSL will then be very general purpose – and large Doing annotations in a DSL? – Same as above: these will just be general purpose mechanisms SPLC - 2005 Requires that it is possible to define DSLs as specializations of a general purpose language Summary Framework/ Configuration variability Family-as-unionof-all-systems By generic As annotations to a mechanisms of a standard language standard language commona The system family lity model is a model Domain Specific Languages By specific language mechanisms Implicitly defined there is no system family model Modeled Generated Modeled analysis Yes No No unforeseen Just added system family If not expressible, model must change make a new language SPLC - 2005 modeled ?
