Component-Based Product Line Engineering with the UML The KobrA Method Colin Atkinson, Joachim Bayer, Christian Bunse, Erik Kamsties, Oliver Laitenberger, Roland Laqua, Dirk Muthig, Barbara Paech, Jürgen Wüst, and Jörg Zettel Institut Experimentelles Software Engineering Fraunhofer IESE

Copyright © KOBRA Group Industrial Reuse Drivers Vision Assemble applications from prefabricated parts COTS component market Web Services Obstacles Current technologies (.NET, J2EE) very implementation oriented Little understanding of how to scope components Vision Capture core software assets as platform- independent models (PIMs) Automatically map PIMS to PSMs Obstacles Larges upfront investment Poor connection with regular “single- system” technology Obstacles Lack of systematic methods for creating PIMs Fixed and Ad hoc mapping techniques Vision Development activities oriented around product families manage commonalities and variabilities KobrA Component-based Development (CBD) Model-Driven Architecture (MDA) Product-Line Engineering (PLE)

Copyright © KOBRA Group The KobrA Project Supported by the German Ministry for Research and Technology (BMBF) KobrA Ko mponenten b asie r te A nwendungsentwicklung Four partners  Softlab GMBH, Munich (leaders)  PSIPENTA Software Systems, Berlin  GMD FIRST, Berlin  Fraunhofer IESE, Kaiserslautern Three year duration  January > December 2001 Products  Method, Workbench, Components Copyright © KOBRA Group KobrA Project 2Questions 3Properties 4 Existing Methods Background 5 Influences 6 Characteristics

Copyright © KOBRA Group Properties of a Good Method Simple –Minimal set of concepts –No redundancy (different words for the same thing) Systematic –Methodological, step-wise process –rigorous Prescriptive –Should try to say what you should do not what you may do Flexible –Should be useable in as wide a range of circumstances as possible Scaleable –Should be applicable in the same way to large and small systems 1KobrA Project 2Questions 3Properties 4 Existing Methods Background 5 Influences 6 Characteristics

Copyright © KOBRA Group Problems with Existing Methods Unified Process –Complicated –Limited view of components –Fundamental conflict between being “use-case driven” and “architecture centric” Catalysis –Complicated –Unfocused OPEN –Very high level –unprescriptive Fusion –“Flat” and unscaleable Cleanroom –Structured (i.e. function-oriented) 1KobrA Project 2Questions 3Properties 4 Existing Methods Background 5 Influences 6 Characteristics

Copyright © KOBRA Group Methodological Influences on KobrA Catalysis Fusion Cleanroom Copyright © KOBRA Group 2000 Product Line Engineering (PuLSE) OPEN Unified Process SELECT Perspective OMT Booch Objectory 1KobrA Project 2Questions 3Properties 4 Existing Methods Background 5 Influences 6 Characteristics

Copyright © KOBRA Group Main Characteristics of KobrA KobrA is a method for software engineering that is -  simple  systematic  prescriptive  flexible  scaleable  component-based (object-oriented)  architecture centric  iterative and Incremental  quality-oriented  product line capable  UML-based  component technology compatible Copyright © KOBRA Group KobrA Project 2Questions 3Properties 4 Existing Methods Background 5 Influences 6 Characteristics

Copyright © KOBRA Group Modeling Principles Uniformity  all behavior rich elements should be viewed as components, including (sub)systems  component assembly = component development Parsimony  minimal set of concepts (no redundancy) Locality  all models should be local to a component Encapsulation  component specifications (what) must be separated from component realizations (how)

Copyright © KOBRA Group What is a Component? There are many different definitions of “component” The three primary component implementation technologies are -  JavaBeans, COM and CORBA Common theme -  prepackaged software entities that can be plugged together - 1Components 2Locality 3Specifications & Realizations 4Frameworks 6Life Cycle Overview 5Product Lines

Copyright © KOBRA Group Traditional Client/Server Model plugs and sockets represent sets of services  plug => required services –services which a component needs to do its job –services of which the component is a client  socket => supplied services –services which a component offers to others –services for which the component is a server => Contract model  interacting components enter into a contract contract client server 1Components 2Locality 3Specifications & Realizations 4Frameworks 6Life Cycle Overview 5Product Lines

Copyright © KOBRA Group Tree-Based Development In general, the client/server model leads to a network (graph) of interconnected components BUT, an arbitrary graph has numerous shortcomings  no model of composition  no obvious development order Cleanroom shows that a tree based software structure has many advantages  natural model of composition  obvious development sequences  recursive definitions and activities  systematic  improved quality 1Components 2Locality 3Specifications & Realizations 4Frameworks 6Life Cycle Overview 5Product Lines

Copyright © KOBRA Group A System = A Component Many approaches view component development and component assembly as different activities  development with components  development of components  In KobrA component development and assembly are the same thing  a system = a component + = + = 1Components 2Locality 3Specifications & Realizations 4Frameworks 6Life Cycle Overview 5Product Lines

Copyright © KOBRA Group Creation as the basis for Composition The basic composition concept does not yield a tree  many shades of aggregation  an entity can be a component of several things simultaneously How can trees be crystallized from client/server graphs? Solution is the “creation” relationship  every software entity must be created by exactly one other entity  every object-oriented system running today contains a creation tree  an entity normally creates the things to which it has a strong composition relationship 1Components 2Locality 3Specifications & Realizations 4Frameworks 6Life Cycle Overview 5Product Lines

Copyright © KOBRA Group creates imports Run-time Composition Tree A B C D E F G H I1I1 I2I2 1Components 2Locality 3Specifications & Realizations 4Frameworks 6Life Cycle Overview 5Product Lines

Copyright © KOBRA Group The Principle of Locality Run-time composition structures are traditionally described within global models  inhibits reuse  non-component oriented The principle of locality states that -  content and organization of software artifacts should be relative to a single component Global artifacts  should be used as little as possible  should be generated recursively 1Components 2Locality 3Specifications & Realizations 4Frameworks 6Life Cycle Overview 5Product Lines

Copyright © KOBRA Group Applying the Principle of Locality Run-time Hierarchy set of models defines Traditional approaches Development Time Description “component of” relationship 1Components 2Locality 3Specifications & Realizations 4Frameworks 6Life Cycle Overview 5Product Lines

Copyright © KOBRA Group Internal versus External Views The properties of a component can be seen from two viewpoint points -  external view –properties of a component visible from, or controlled by, the “outside” –in KobrA, described by the specification  internal view –properties of a component visible from the “inside” –includes the properties visible from outside –in KobrA, described by the realization External view point Internal view point Component Realization Specification 1Components 2Locality 3Specifications & Realizations 4Frameworks 6Life Cycle Overview 5Product Lines

Copyright © KOBRA Group Component Specification Describes a component’s externally visible properties Structural Model (UML class/object diagrams) Functional Model (operation specifications) Behavior Model (UML statechart diagram) Component Specification 1Components 2Locality 3Specifications & Realizations 4Frameworks 6Life Cycle Overview 5Product Lines

Copyright © KOBRA Group Component Realization Describes a component’s realization properties Structural Model (UML class/object diagrams) Interaction Model (UML collaboration diagrams) Activity Model (UML activity diagrams) Component Realization 1Components 2Locality 3Specifications & Realizations 4Frameworks 6Life Cycle Overview 5Product Lines

Copyright © KOBRA Group Component Model Suite Structural Model (UML class/object diagrams) Functional Model (operation specifications) Structural Model (UML class/object diagrams) Interaction Model (UML collaboration diagrams) Activity Model (UML activity diagrams) Behavior Model (UMLstatechart diagram) Komponent Specification Realization 1Components 2Locality 3Specifications & Realizations 4Frameworks 6Life Cycle Overview 5Product Lines

Copyright © KOBRA Group Framework Correctness Rules A B Consistency relationships Refinement relationships Contract relationship 1Components 2Locality 3Specifications & Realizations 4Frameworks 6Life Cycle Overview 5Product Lines

Copyright © KOBRA Group Containment Trees Clientship rules Clientship + Containment rules Clientship + Containment rules Clientship + Containment rules Cliensthip rules Clientship rules

Copyright © KOBRA Group Framework Engineering Specification Realization Cpt A Cpt B Cpt D Cpt C Component Reuse COTS Component 1Components 2Locality 3Specifications & Realizations 4Frameworks 6Life Cycle Overview 5Product Lines

Copyright © KOBRA Group Context Realization Represents a description of the environment of the system  can be thought of as a realization without a specification (i.e. a component without a “top”)  involves “front end” activities akin to requirements analysis Structural Model (UML class/object diagrams) Interaction Model (UML collaboration diagrams) Activity Model (UML activity diagrams) Realization 1Components 2Locality 3Specifications & Realizations 4Frameworks 6Life Cycle Overview 5Product Lines

Copyright © KOBRA Group Implementation and Building Mapping component realizations into an executable form represents a separate dimension  executable images can be created after each realization  incremental development Cpt A Cpt B Cpt C 1Components 2Locality 3Specifications & Realizations 4Frameworks 6Life Cycle Overview 5Product Lines

Copyright © KOBRA Group Product Line Engineering Most software development organizations develop a line of similar but slightly different products KobrA describes a family of similar systems (i.e. components) by modeling  variabilities  decisions A component (class) with (non-empty) decision models (i.e. optional features) is known as a generic component A tree of generic components represents a generic framework  decision models are related hierarchically  decision model resolution implies the resolution of all lower decision models => Incremental introduction of product lines 1Components 2Locality 3Specifications & Realizations 4Frameworks 6Life Cycle Overview 5Product Lines

Copyright © KOBRA Group Generic Component Models Structural Model (UML class/object diagrams) Functional Model (operation schemata) Structural Model (UML class/object diagrams) Interaction Model (UML collaboration diagrams) Activity Model (UML activity diagrams) Behavior Model (UMLstatechart diagram) Decision Model (textual) Komponent Decision Model (textual) Specification Realization 1Components 2Locality 3Specifications & Realizations 4Frameworks 6Life Cycle Overview 5Product Lines

Copyright © KOBRA Group High-Level KobrA Life Cycle Development Maintenance Framework Engineering Application Engineering … Phase #1 … Framework Engineering Application Engineering Phase #2 … Framework Engineering Application Engineering 1Components 2Locality 3Specifications & Realizations 4Frameworks 6Life Cycle Overview 5Product Lines

Copyright © KOBRA Group Method Prescriptiveness FrameworkApplication ImplementationExecutableDeployedSystem 0% 100% Prescriptiveness KobrA Method Other technologies 1Components 2Locality 3Specifications & Realizations 4Frameworks 6Life Cycle Overview 5Product Lines

Copyright © KOBRA Group Separation of Concerns Abstraction Composition Specificity Instantiation Framework Engineering Implementation Framework Application Implementation 1Components 2Locality 3Specifications & Realizations 4Frameworks 6Life Cycle Overview 5Product Lines

Copyright © KOBRA Group Summary of Key Features  Strict separation of concerns –Genericity, composition, abstraction  Strict separation of product and process  Uniform treatment of systems and components –component assembly = component creation –Fractal-like product, Recursive process  Incremental support for product lines –Incremental addition/resolution of decision models  Integrated Quality assurance –Inspections, testing, quality modeling  Flexible Implementation Approach –Separation of refinement and translation –Refinement and translation patterns –Compatible with most implementation technologies (including JavaBeans, CORBA, COM) 1Components 2Locality 3Specifications & Realizations 4Frameworks 6Life Cycle Overview 5Product Lines

Copyright © KOBRA Group Single-System versus Product-line Development  An application = a framework with no decisions models (i.e. no variabilities)  Single-system development is a special case of product line engineering with no variabilities –framework engineering + implementation – variabilities Framework Engineering Application Engineering Implementation Single-System Product-Line  (no variabilities)   ( variabilities ) 1Main Activities 2Example 3Context Realization 4Specification 6Component Hierarchy Single System Development 5Realization 7Reuse

Copyright © KOBRA Group Primary Framework Engineering Activities Context Realization  produces a set of realization models for the environment of the system Component Specification  produces a specification of a component in relationship to a given realization Component Realization  produces a realization of a component in relationship to a given specification Component Reuse  matches the needs of a given realization to the capabilities of a preexisting component (I.e. a COTS component) via a mutually agreed specification Quality Assurance  ensure the quality of the KobrA models using inspections, testing and quality modeling 1Main Activities 2Example 3Context Realization 4Specification 6Component Hierarchy Single System Development 5Realization 7Reuse

Copyright © KOBRA Group Simple International Banking System The Simple International Banking (SIB) System provides very simple banking services to customers. These fall into two categories,  Creation and management of simple accounts  Simple currency exchange calculations Customers are able to open simple accounts in some denomination, but must do so with a minimum balance of 50 EUR. Once opened, money can be deposited into and withdrawn from an account in any denomination. The current state of the account can also be viewed by Banks Clerks. The bank maintains a set of exchange rates between Euros and other currencies. Customers can request for amounts in foreign currencies to be converted to and from Euros. Bank Clerks can enter exchange rates at any time. 1Main Activities 2Example 3Context Realization 4Specification 6Component Hierarchy Single System Development 5Realization 7Reuse

Copyright © KOBRA Group Context Realization  Starting Point for Development  Describes the Context of the Software System  Provides Realization Models for the Root Komponent Usage Software Business 1Main Activities 2Example 3Context Realization 4Specification 6Component Hierarchy Single System Development 5Realization 7Reuse

Copyright © KOBRA Group Primary Realization Models (The Output) Structural model  describes the data and components needed by the component in order to fulfill is contract –one or more class diagrams –zero or more object diagrams Activity model  describes the algorithms used to realize the operations of the component –zero or more activity diagrams Interaction model  describes how operations of the component are realized in terms of interactions –zero or more interaction diagrams (per operation) 1Main Activities 2Example 3Context Realization 4Specification 6Component Hierarchy Single System Development 5Realization 7Reuse

Copyright © KOBRA Group Types of Activities Any separately identifiable unit of behaviour (functionality) is called an activity in KobrA Three kinds of activities are recognized  free: a separate chunk of behaviour, charaterized by its input and output –depicted as an activity diagram without swimlanes  associated: an activity assigned to an object, but not yet identified as an operation –depicted as an activity diagram with swimlanes  operation: an activity that is identified as an operation of a component –such an activity is said to be allocated –depicted by an activity diagram or interaction diagram 1Main Activities 2Example 3Context Realization 4Specification 6Component Hierarchy Single System Development 5Realization 7Reuse

Copyright © KOBRA Group Context Realization Activities Data Activities Data Modeling Business Process Modeling Realization Interaction Modeling Usage Modeling 1Main Activities 2Example 3Context Realization 4Specification 6Component Hierarchy Single System Development 5Realization 7Reuse

Copyright © KOBRA Group Context Realization Activities (Continued) Business process modeling –who does what to what and when –actors, activities, data and rules –described at “business” level of abstraction Data modeling  identify organizational and technological data  identify information and material data Usage modeling  activity modeling –decompose activities that involve the “system”  interface design –screen templates, dialogues etc. Interaction modeling  integrate actors, activities, data and rules 1Main Activities 2Example 3Context Realization 4Specification 6Component Hierarchy Single System Development 5Realization 7Reuse

Copyright © KOBRA Group SIB Context Structural Model Bank 1 Account Clerk Customer name ID Balance denomination * * 1 * * * 1 Bank Context Bank Context Class Diagram

Copyright © KOBRA Group openNewAccount activity diagram SIB Context Activity Model DecideStarting Balance :Customer :Clerk :Bank Balance  50 EUR Balance < 50 EUR CheckStarting Balance CreateAccount Deposit Balance Bank Context

Copyright © KOBRA Group SIB Context Interaction Model OpenNewAccount sequence diagram :Bank :Customer:Clerk OpenNewAccount (bal, curr, name) [bal < 50 EUR] InsufficentMessage() [bal  50 EUR]CreateAccount (name, curr) : ID Deposit (ID, bal, curr) Bank Context

Copyright © KOBRA Group The Role of Use Cases Traditional use-case modelling roughly covers the concerns addressed by usage and interaction modelling  use case modelling = usage modelling + interaction modelling A use case corresponds to an activity asociated with the software system  use case = activity associated with the software system  a use case diagram can be used to document such activities The system is one of the actors or data items identified in the “to be“ business process models 1Main Activities 2Example 3Context Realization 4Specification 6Component Hierarchy Single System Development 5Realization 7Reuse

Copyright © KOBRA Group Use Cases within Context Realization Data Activities Data Modeling Business Process Modeling Realization Use Case Modeling 1Main Activities 2Example 3Context Realization 4Specification 6Component Hierarchy Single System Development 5Realization 7Reuse

Copyright © KOBRA Group SIB Use Case Model OpenNewAccount Deposit ViewAccount SetRate Withdraw Convert Bank Customer Clerk CloseAccount «uses» 1Main Activities 2Example 3Context Realization 4Specification 6Component Hierarchy Single System Development 5Realization 7Reuse

Copyright © KOBRA Group Component Specification To describe the externally visible properties of a component Defines a component’s  supplied services (supplied interface)  imported services (components)  exported services (components) provides the basis for the contract between the component and its clients Is defined in the context of the parent component’s realization (or the context realization if the root) 1Main Activities 2Example 3Context Realization 4Specification 6Component Hierarchy Single System Development 5Realization 7Reuse

Copyright © KOBRA Group Primary Specification Models Structural model  data manipulated by the component, its environment, and any externally visible structure –one or more class diagrams –zero or more object diagrams Functional model  computations performed by the component –one operation specification for each operation Behavioral model  states exhibited by the component and the events that change them –zero or more statechart diagrams –zero or more event maps 1Main Activities 2Example 3Context Realization 4Specification 6Component Hierarchy Single System Development 5Realization 7Reuse

Copyright © KOBRA Group Auxiliary Specification Artifacts Non-functional requirements specification  desired quality characteristics Quality Measures  desired quality thresholds and the related quality factors Dictionary  tables of model entities and their role Test Cases  test cases to support functional testing Decision Model  variable features and related user decisions 1Main Activities 2Example 3Context Realization 4Specification 6Component Hierarchy Single System Development 5Realization 7Reuse

Copyright © KOBRA Group Bank Specification Structural Model createAccount deposit viewAccount withdraw closeAccount setRate convertToEuro convertFromEuro Bank noOfAccounts : Integer := 0 Account accountID : String balance : Float Denom : String manages 1 * Bank Bank Specification Class Diagram

Copyright © KOBRA Group Bank Specification Functional Model Bank createAccount Operation Specification

Copyright © KOBRA Group Bank Specification Functional Model (Contd) Bank withdraw operation specification

Copyright © KOBRA Group Bank Specification Behavioral Model Empty AccountsButNoRates RatesButNoAccounts AccountAandRates createAccount/ deposit/ viewAccount/ withdraw / closeAccount [noOfAccounts > 2]/ noOfAccounts : Integer createAccount/ deposit/ viewAccount/ withdraw/ closeAccount [noOfAccounts > 2]/ setRate/ convertToEuro/ convertFromEuro/ noOfAccounts : Integer := 0 setRate/ convertToEuro/ convertFromEuro/ createAccount setRate closeAccount [noOFAccounts = 1 ] createAccount closeAccount [noOFAccounts = 1 ] {crateAccount, deposit, withdraw, viewAccount must all be in Euro} Bank

Copyright © KOBRA Group Role of a Component Realization To describe the way in which a component realizes the services specified in the specification Defines a component’s  private subcomponents  architecture and design Is defined in the context of the component’s specification  the realization models expand upon the information in the specification models 1Main Activities 2Example 3Context Realization 4Specification 6Component Hierarchy Single System Development 5Realization 7Reuse

Copyright © KOBRA Group Primary Realization Models Structural model  describes the data and components needed by the component in order to fulfill its contract –one or more class diagrams –zero or more object diagrams Activity model  describes the algorithms used to realize the operations of the component –zero or more activity diagrams Interaction model  describes how operations of the component are realized in terms of interactions –zero or more interaction diagrams (per operation) 1Main Activities 2Example 3Context Realization 4Specification 6Component Hierarchy Single System Development 5Realization 7Reuse

Copyright © KOBRA Group Auxiliary Realization Artifacts Quality Measures  Measures of relevant Quality Factors Dictionary  tables of model entities and their role Test Suite  Test Cases for Structural Testing Decision Model  variable features and related user decisions 1Main Activities 2Example 3Context Realization 4Specification 6Component Hierarchy Single System Development 5Realization 7Reuse

Copyright © KOBRA Group Auxiliary Realization Artifacts Quality Measures  Measures of relevant Quality Factors Dictionary  tables of model entities and their role Test Suite  Test Cases for Structural Testing Decision Model  variable features and related user decisions 1Main Activities 2Example 3Context Realization 4Specification 6Component Hierarchy Single System Development 5Realization 7Reuse

Copyright © KOBRA Group Role of Realization Activities Data Activities Structural Modeling Interaction Modeling Activity Modeling 1Main Activities 2Example 3Context Realization 4Specification 6Component Hierarchy Single System Development 5Realization 7Reuse

Copyright © KOBRA Group The DNA (Data aNd Activity) Model Data Activities Specification Realization/ Specifications Object-oriented 1Main Activities 2Example 3Context Realization 4Specification 6Component Hierarchy Single System Development 5Realization 7Reuse

Copyright © KOBRA Group The DNA Spiral ActivitiesData Realization Context Realization Specification 1Main Activities 2Example 3Context Realization 4Specification 6Component Hierarchy Single System Development 5Realization 7Reuse

Copyright © KOBRA Group Bank Realization Structural Model Bank Converter 1 1 PersistentAccount * * setRate convertToEuro convertFromEuro createAccount getAccount closeAccount Teller accesses creates Account deposit withdraw * 1 Bank

Copyright © KOBRA Group Bank Realization Structural Model (Contd.) :Bank :Converter :Teller PersistentAccount Bank Bank Realization Object Diagram

Copyright © KOBRA Group Bank Realization Interaction Model :Bank :Teller createAccount (name, curr) : ID 1: createAccount (name, curr) : ID Bank createAccount Collaboration Diagram

Copyright © KOBRA Group Bank Realization Interaction Model (Contd) :Bank :Converter withdraw (ID, curr, am) : res 4 : [bal > euro] withdraw (euro) : res a : PersistentAccount 1: getAccount(ID) : a :Teller 2: convertToEuro (curr, am) : euro 3 :getBalance() :bal Bank withdraw Collaboration Diagram

Copyright © KOBRA Group Bank Realization Activity Model getAccount GetBalance evaluateRequest WidthrawCashreturn False return True :Teller:Account:Bank Balance  Request Balance < Request :Converter ConvertRequest Bank

Copyright © KOBRA Group SIB Component Hierarchy Bank TellerConverter Association Account Dictionary 1 1 * * «owns» 1 creates

Copyright © KOBRA Group Teller Specification Structural Model Teller createAccount getAccount closeAccount Teller noOfAccounts : Integer := 0 creates * PersistentAccount accountID : String balance : Float Denom : String 1 Teller Specification Class Diagram

Copyright © KOBRA Group Teller Specification Functional Model Teller createAccount operation specification

Copyright © KOBRA Group Teller Specification Behavioral Model Teller Empty HasAccounts createAccount/ getAccount/ closeAccount [noOfAccounts > 2]/ noOfAccounts : Integer := 0 createAccount closeAccount [noOFAccounts = 1 ] Teller Statechart diagram

Copyright © KOBRA Group Teller Realization Structural Model Teller Dictionary PersistentAccount Object 1 1 * * Teller Teller Realization Class Diagram

Copyright © KOBRA Group Teller Realization Interaction Model Teller :Teller :Dictionary createAccount (name, curr) : ID 2: store (ID, a) a : PersistentAccount 1: create (name, curr) : ID createAccount Collaboration Diagram

Copyright © KOBRA Group Dictionary Specification Structural Model Dictionary PersistentObject * Store retrieve remove Dictionary noOfEntries : Integer := 0 Dictionary Specification Class Diagram

Copyright © KOBRA Group Dictionary Realization Structural Model Dictionary PersistentObject * Dictionary Association Dictionary Realization Class Diagram

Copyright © KOBRA Group Contract View of Component Reuse KobrA component Specification (Requirements on Reused Component) Contract Consumer Supplier KobrA Specification of Reused Component Conformance Map Reused Component (Non-KobrA) Specification of Reused Component 1Main Activities 2Example 3Context Realization 4Specification 6Component Hierarchy Single System Development 5Realization 7Reuse

Copyright © KOBRA Group What does KobrA Offer? KobrA helps answer the following basic questions -  What UML models should I build and how should I organize them?  What information should be in the models?  How do I start?  How can I check that my models are correct or “good enough”?  How can I capture the different variants of my systems?  How can I incorporate my existing software, or software that I can buy?  How should I go about changing my system once I’ve finished the first version?  How do I know what do do next ? 1Product Families 2Commonalites & Variabilities 3Decision Models 4Application Engineering 6Refinement v Translation Product Line Development 5Implementation 7Conclusion

Copyright © KOBRA Group Further Information Web Pages   Book  Atkinson et. al., Component-Based Product Line Engineering with the UML, Addison-Wesley, 2001 Papers –C. Atkinson, J. Bayer, O. Laitenberger and J. Zettel, Component- Based Software Engineering: The KobrA Approach, ICSE’200, Limerick, Ireland. 200 –C. Atkinson, J. Bayer and D. Muthig, "Component-Based Product Line Development: The KobrA Approach," SPLC1, Pittsburgh, August Contact Person  Dr. Oliver Laitenberger  , 1Product Families 2Commonalites & Variabilities 3Decision Models 4Application Engineering 6Refinement v Translation Product Line Development 5Implementation 7Conclusion