Download presentation
Presentation is loading. Please wait.
Published byHillary Hunt Modified over 8 years ago
1
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
2
Copyright © KOBRA Group 2000 - 2 - 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) 1 2 3 Product-Line Engineering (PLE)
3
Copyright © KOBRA Group 2000 - 3 - 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 1999 -> December 2001 Products Method, Workbench, Components Copyright © KOBRA Group 2000 1KobrA Project 2Questions 3Properties 4 Existing Methods Background 5 Influences 6 Characteristics
4
Copyright © KOBRA Group 2000 - 4 - 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
5
Copyright © KOBRA Group 2000 - 5 - 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
6
Copyright © KOBRA Group 2000 - 6 - 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
7
Copyright © KOBRA Group 2000 - 7 - 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 2000 1KobrA Project 2Questions 3Properties 4 Existing Methods Background 5 Influences 6 Characteristics
8
Copyright © KOBRA Group 2000 - 8 - 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)
9
Copyright © KOBRA Group 2000 - 9 - 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
10
Copyright © KOBRA Group 2000 - 10 - 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
11
Copyright © KOBRA Group 2000 - 11 - 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
12
Copyright © KOBRA Group 2000 - 12 - 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
13
Copyright © KOBRA Group 2000 - 13 - 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
14
Copyright © KOBRA Group 2000 - 14 - 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
15
Copyright © KOBRA Group 2000 - 15 - 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
16
Copyright © KOBRA Group 2000 - 16 - 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
17
Copyright © KOBRA Group 2000 - 17 - 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
18
Copyright © KOBRA Group 2000 - 18 - 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
19
Copyright © KOBRA Group 2000 - 19 - 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
20
Copyright © KOBRA Group 2000 - 20 - 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
21
Copyright © KOBRA Group 2000 - 21 - Framework Correctness Rules A B Consistency relationships Refinement relationships Contract relationship 1Components 2Locality 3Specifications & Realizations 4Frameworks 6Life Cycle Overview 5Product Lines
22
Copyright © KOBRA Group 2000 - 22 - Containment Trees Clientship rules Clientship + Containment rules Clientship + Containment rules Clientship + Containment rules Cliensthip rules Clientship rules
23
Copyright © KOBRA Group 2000 - 23 - 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
24
Copyright © KOBRA Group 2000 - 24 - 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
25
Copyright © KOBRA Group 2000 - 25 - 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
26
Copyright © KOBRA Group 2000 - 26 - 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
27
Copyright © KOBRA Group 2000 - 27 - 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
28
Copyright © KOBRA Group 2000 - 28 - 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
29
Copyright © KOBRA Group 2000 - 29 - Method Prescriptiveness FrameworkApplication ImplementationExecutableDeployedSystem 0% 100% Prescriptiveness KobrA Method Other technologies 1Components 2Locality 3Specifications & Realizations 4Frameworks 6Life Cycle Overview 5Product Lines
30
Copyright © KOBRA Group 2000 - 30 - Separation of Concerns Abstraction Composition Specificity Instantiation Framework Engineering Implementation Framework Application Implementation 1Components 2Locality 3Specifications & Realizations 4Frameworks 6Life Cycle Overview 5Product Lines
31
Copyright © KOBRA Group 2000 - 31 - 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
32
Copyright © KOBRA Group 2000 - 32 - 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
33
Copyright © KOBRA Group 2000 - 33 - 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
34
Copyright © KOBRA Group 2000 - 34 - 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
35
Copyright © KOBRA Group 2000 - 35 - 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
36
Copyright © KOBRA Group 2000 - 36 - 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
37
Copyright © KOBRA Group 2000 - 37 - 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
38
Copyright © KOBRA Group 2000 - 38 - 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
39
Copyright © KOBRA Group 2000 - 39 - 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
40
Copyright © KOBRA Group 2000 - 40 - SIB Context Structural Model Bank 1 Account Clerk Customer name ID Balance denomination * * 1 * * * 1 Bank Context Bank Context Class Diagram
41
Copyright © KOBRA Group 2000 - 41 - 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
42
Copyright © KOBRA Group 2000 - 42 - 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
43
Copyright © KOBRA Group 2000 - 43 - 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
44
Copyright © KOBRA Group 2000 - 44 - 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
45
Copyright © KOBRA Group 2000 - 45 - 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
46
Copyright © KOBRA Group 2000 - 46 - 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
47
Copyright © KOBRA Group 2000 - 47 - 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
48
Copyright © KOBRA Group 2000 - 48 - 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
49
Copyright © KOBRA Group 2000 - 49 - 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
50
Copyright © KOBRA Group 2000 - 50 - Bank Specification Functional Model Bank createAccount Operation Specification
51
Copyright © KOBRA Group 2000 - 51 - Bank Specification Functional Model (Contd) Bank withdraw operation specification
52
Copyright © KOBRA Group 2000 - 52 - 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
53
Copyright © KOBRA Group 2000 - 53 - 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
54
Copyright © KOBRA Group 2000 - 54 - 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
55
Copyright © KOBRA Group 2000 - 55 - 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
56
Copyright © KOBRA Group 2000 - 56 - 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
57
Copyright © KOBRA Group 2000 - 57 - 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
58
Copyright © KOBRA Group 2000 - 58 - 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
59
Copyright © KOBRA Group 2000 - 59 - The DNA Spiral ActivitiesData Realization Context Realization Specification 1Main Activities 2Example 3Context Realization 4Specification 6Component Hierarchy Single System Development 5Realization 7Reuse
60
Copyright © KOBRA Group 2000 - 60 - Bank Realization Structural Model Bank Converter 1 1 PersistentAccount 1 1 1 * * setRate convertToEuro convertFromEuro createAccount getAccount closeAccount Teller accesses creates Account deposit withdraw * 1 Bank
61
Copyright © KOBRA Group 2000 - 61 - Bank Realization Structural Model (Contd.) :Bank :Converter :Teller PersistentAccount Bank Bank Realization Object Diagram
62
Copyright © KOBRA Group 2000 - 62 - Bank Realization Interaction Model :Bank :Teller createAccount (name, curr) : ID 1: createAccount (name, curr) : ID Bank createAccount Collaboration Diagram
63
Copyright © KOBRA Group 2000 - 63 - 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
64
Copyright © KOBRA Group 2000 - 64 - Bank Realization Activity Model getAccount GetBalance evaluateRequest WidthrawCashreturn False return True :Teller:Account:Bank Balance Request Balance < Request :Converter ConvertRequest Bank
65
Copyright © KOBRA Group 2000 - 65 - SIB Component Hierarchy Bank TellerConverter Association Account Dictionary 1 1 * * «owns» 1 creates
66
Copyright © KOBRA Group 2000 - 66 - 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
67
Copyright © KOBRA Group 2000 - 67 - Teller Specification Functional Model Teller createAccount operation specification
68
Copyright © KOBRA Group 2000 - 68 - Teller Specification Behavioral Model Teller Empty HasAccounts createAccount/ getAccount/ closeAccount [noOfAccounts > 2]/ noOfAccounts : Integer := 0 createAccount closeAccount [noOFAccounts = 1 ] Teller Statechart diagram
69
Copyright © KOBRA Group 2000 - 69 - Teller Realization Structural Model Teller Dictionary PersistentAccount Object 1 1 * * Teller Teller Realization Class Diagram
70
Copyright © KOBRA Group 2000 - 70 - 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
71
Copyright © KOBRA Group 2000 - 71 - Dictionary Specification Structural Model Dictionary PersistentObject * Store retrieve remove Dictionary noOfEntries : Integer := 0 Dictionary Specification Class Diagram
72
Copyright © KOBRA Group 2000 - 72 - Dictionary Realization Structural Model Dictionary PersistentObject * Dictionary Association Dictionary Realization Class Diagram
73
Copyright © KOBRA Group 2000 - 73 - 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
74
Copyright © KOBRA Group 2000 - 74 - 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
75
Copyright © KOBRA Group 2000 - 75 - Further Information Web Pages www.iese.fhg.de/KobrA www.kobra-project.org 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. 2000 Contact Person Dr. Oliver Laitenberger +49 6301 707 223, Oliver.Laitenberger@iese.fhg.de 1Product Families 2Commonalites & Variabilities 3Decision Models 4Application Engineering 6Refinement v Translation Product Line Development 5Implementation 7Conclusion
Similar presentations
© 2024 SlidePlayer.com Inc.
All rights reserved.