Paper III *The PLU Toolkit Extending Telelogic DOOR and IB-Rational Rose to upport Product Line Use Case odeling agnus Eriksson 1, Henrik orast 2, Jürgen Börstler 3 and Kjell Borg 1 1 Land ystems Hägglunds AB, E-891 82 Örnsköldsvik, weden {agnuseriksson, KjellBorg}@baesystemsse 2 yntell AB, PO Box 100 22, E-100 55 tockholm, weden Henrikorast@syntellse 3 Dept of Computing cience, Umeå University, E-901 87 Umeå, weden jubo@csumuse Abstract The PLU approach (Product Line Use case modeling for ystems and oftware engineering) is a domain modeling method tailored towards the development of long lived software intensive systems PLU provides means to maintain a common and complete use case model for a whole family of systems In this paper, we describe how the commercial requirements management tool Telelogic DOOR and the UL modeling tool IB-Rational Rose can be extended and used for managing system family models in accordance with the PLU approach * Proceedings of the 20th IEEE/AC International Conference on Automated oftware Engineering, Long Beach California, AC Press, pp 300-304
Paper III The PLU Toolkit 69 1 Introduction oftware intensive defense systems, for example vehicles, are developed in short series They are always customized for specific customer needs and they are expected to have very long life spans, often 30 years or longer For a business to be competitive in a market like this it is important to achieve high levels of reuse and effective maintenance An interesting approach to address such issues is known as software product line development The basic idea of this approach is to use domain knowledge to identify common parts within a family of products and to separate them from the differences between the products The commonalties are then used to create a product platform that can be used as a common baseline for all products within the product family Due to earlier positive experiences with use cases in single system development, we aimed at a use case driven product line approach that could be applied by both our systems- and software engineering teams To address problems and issues in existing product line use case modeling approaches, we have developed a domain modeling approach that utilizes features models [7], use cases [6] and use case realizations [8] We refer to this approach as the PLU (Product Line Use case modeling for ystems and oftware engineering) approach [2] In this paper we describe a number of extensions to the commercial requirements management tool Telelogic DOOR and the UL modeling tool IB-Rational Rose aimed to better support the PLU approach For the reminder of this paper we will refer to these extensions as the PLU toolkit 2 The PLU Approach The goal of the PLU approach is to provide means for maintaining a common and complete use case model for a whole family of systems Doing so requires the proper management of variants among family members within such a model We identified four types of variants in the use case models for our product families [2] These variants regards the set of use cases included in a member of a family, the set of scenarios included in each use case, and the set of steps included in each use case scenario Furthermore, cross-cutting aspects can exist that affect several use cases on several levels in the model Our approach for managing variability in PLU is based on the work by Griss et al on FeatuREB [5] In FeatuREB a feature model is added to the 4+1 view model adopted by Jacobson et al in REB [6] Like Griss et al, we argue that feature models are better suited for domain modeling than for example UL use case diagrams and that a feature model therefore should be used as the high level view of the product family We use a feature model as a tool for structuring use cases into reusable packages for a system family We thereby provide means to manage variants among family members Product instantiation of such a family model is then done by using the feature model as a tool to choose among its variants The set of included features directly corresponds to a specific set of included use cases for a product
70 agnus Eriksson, Henrik orast, Jürgen Börstler and Kjell Borg 21 Feature odeling in PLU Kang et al first proposed using feature models in 1990 as part of Feature Oriented Domain Analysis (FODA) [7] In feature models, system features are organized into trees that represent the commonalities and variations within a family of related systems General features are located at the top of the tree and more refined features are located below Originally, FODA described andatory, Optional and Alternative features that may have requires and excludes relations to other features andatory features are available in all systems within a family Optional features may or may not be included in products Alternative features represent selections, where exactly-one-out-of-many features must be chosen A requires relationship indicates that a feature depends on some other feature to make sense in a system An excludes relationship between two features indicates that both features can not be included in the same system In PLU, FODA feature modeling is slightly extended and modified to better suit our modeling needs We have defined a new feature type called ultiple Adaptor feature to represent an at-least-one-out-of-many selection, which is missing in FODA [3] We have also chosen to rename alternative features to ingle Adaptor features, following the naming scheme proposed by annion et al for the equivalent relations in their work on reusable requirements [9] ingle and multiple adaptor features are represented by the letters and, respectively, surrounded by a circle as shown in Fig 1 In the FODA notation, an arc connects sets of alternative features Due to limitations in our tool support we removed this arc from the PLU notation Instead we imposed a modeling constraint to ensure that only one set of single adaptor and multiple adaptor features respectively may exist under the same parent feature This was necessary to avoid ambiguity in models whether a certain feature belongs to a specific set of single or multiple adaptor features If several sets are needed under the same parent, a new level must be created in the feature tree and each set is placed under a separate parent feature Domain a <<requires>> b aa ab ac ba bb bc <<excludes>> aaa aab aac aba abb bba bbb bca bcb bcc andatory Optional ingle Adaptor ultiple Adaptor Requires Excludes Fig 1: A feature model example in the PLU notation 22 Relating Features and Use Cases Gooma [4] proposed to model each feature as a use case package We have extended this idea saying that a whole set of features can compose a use case package This
Paper III The PLU Toolkit 71 enables us to also visualize variants within use case specifications using the feature model As shown in the example in Fig 2, use cases as well as use case scenarios can be mapped to features of any type to capture required variants among the members of a system family Optional Domain Optional Feature: Feature: ab ab b a aa ab aaa aab aac aba abb <<change case>> ba bb bc <<impact>> bba bbb bca bcb bcc Use Use Case: Case: <X> <X> Introduction Introduction ain uccess cenario ain uccess cenario Alternative cenarios Alternative cenarios <cenario Name 1> <cenario Name 1> <cenario Name 2> <cenario Name 2> Fig 2: An example of the relationship between features, use cases and use case scenarios We have chosen to adopt an extended version of the RUP-E Flow of Events notation [11] shown in Fig 3 for describing use case scenarios and realizations As shown in the example in Fig 4, the extension utilizes the step identifier of the original notation to capture variants as we described in [2] tep Actor Action 1 2 3 (a) The Actor The use case ends when Blackbox ystem Response The ystem Blackbox Budgeted Req It shall Whitebox Whitebox Action Budgeted Req DesignElement_1 It shall DesignElement_2 DesignElement_3 (b) Fig 3: The (a) Blackbox flow of events used for describing use case scenarios, and (b) the Whitebox flow of events used for describing use case realizations As shown in Fig 4, there is also a predefined set of feature constructs that should be mapped against each type of variant in the use case scenario notation We maintain this redundant information on purpose, since the extra information considerably improves readability Using the underlying tools, this redundancy does not pose a problem since automatic consistency checking between the models could easily be implemented We also have included use case parameters [6] in the PLU notation
72 agnus Eriksson, Henrik orast, Jürgen Börstler and Kjell Borg [2], as shown in steps 3c and 5 in Fig 4 This provides means to capture crosscutting variability in models andatory step Exactly one to be selected for a mandatory step At least one to be selected for a mandatory step Optional step At least one to be selected for an optional step Exactly one to be selected for an optional step tep Actor Action 1 The Actor 2 2 2 3a 3b 3c (4) (5)a (5)b (5)c (6) (6) (6) Blackbox ystem Response The ystem Blackbox Budgeted Req It shall @PARA_1 $PARA_2 Fig 4: An example of the relationship between features, variant use case scenario steps and use case parameters in the PLU notation 3 PLU Tool upport For software product line development to become efficient in every day practice, adequate tool support is an important factor Unfortunately, this tool support is lacking today ome experimental tools and very few commercial tools are available Furthermore, existing tools are not providing the functionality needed to support the PLU approach in a satisfying manner There are many risks associated with using tools designed for single system development in a software product line environment, like for example the following (see [1] for a detailed discussion on these issues) 1 There is a high risk that resources may be expended unnecessarily, because of lack of adequate tool support 2 There is a high risk that artifacts become inconsistent, because tools do not enable linkage or traceability between the different types of artifacts 3 There is a high risk that tools become difficult to maintain, because of the need for local modifications to enable product line development Even tough we recognize and agree with these risks, we have chosen to adapt and extend our existing single system CAE tool environment to support the PLU approach The two main arguments for this decision were: 1 Using the existing CAE tool environment will minimize the need for training of personnel 2 Using commercially available tools will minimize the amount of tool code that needs to be maintained The main tools used to support the PLU approach are the requirements management tool Telelogic DOOR and the UL modeling tool IB-Rational Rose Both tools are widely used and accepted in industry We use Telelogic DOOR to
Paper III The PLU Toolkit 73 manage our system family use case models and IB-Rational Rose for drawing feature graphs and UL diagrams We then generate appropriate reports from our domain model as Word documents, as shown in Fig 5 We have implemented a number of small extensions to these tools, which we refer to as the PLU toolkit However, to address the third risk above, our strategy is to keep these extensions as small as possible Feature odel, Use Case pecifications and Use Case Realizations DOOR Feature Graph and UL Diagrams Rose Repository of Published Reports Word Reports oftware C ystem Fig 5: Overview of the PLU toolkit 31 Telelogic DOOR Telelogic DOOR is an object database intended for requirements management Objects may be arranged in a hierarchic structure in modules Typically, node objects are used as headings and leaf objects are used for data items such as (textual) requirements Both headings and text are usually displayed in a single column in the DOOR graphical user interface This column is referred to as the main column DOOR also has a link concept enabling definitions of binary relationships between objects Links form the basis for traceability in DOOR It is possible to define attributes on both module and object level in DOOR An object attribute holds a value for each object in a module odule attributes can be used for storing additional data not related to specific objects in modules An attribute definition specifies what kind of information an attribute can store Object attributes can be displayed in columns within a module in the DOOR graphical user interface Combining this possibility with DOOR support for filtering on properties of objects, a user may define views suiting different needs These views are used when working with data and also for reporting and exporting information to other tools Views may be saved in a module for later use 32 Feature odeling in DOOR Feature models are managed in specific DOOR modules The basic idea is to use the standard DOOR object hierarchy to model the refine relation for building feature
74 agnus Eriksson, Henrik orast, Jürgen Börstler and Kjell Borg trees Each feature becomes a heading and leaf objects are used for capturing different kinds of information regarding each feature A number of attributes are defined in a feature model module: A Characteristics attribute is used for classifying each object in the module as General Information, a Feature, a Feature description, a Feature graph or a Use Case Diagram General information objects are typically used for introductory information in the domain model, such as use case actor descriptions etc A Feature Type attribute is used for classifying features in the feature hierarchy It can take the values mandatory, optional, single adaptor or multiple adaptor A Require attribute and an Exclude attribute is used to capture the requires and excludes relation between features This is realized by means of a reference holding the identity of the required or excluded feature objects A Use Case Package attribute is used when filtering out a use case model survey from the domain model Elaborating on the discussion in section 22, a sub-tree of the feature model typically corresponds to a use case package for a specific system within a system family This attribute is used for marking such sub trees in the model A Product Instances attribute is used to mark features as included or not by systems within a system family This information is managed using a multivalued enumeration attribute that can assume the names of all systems in the family as shown in Fig 6 This information is then used for filtering out product specific use case models for the different systems in the family Equivalent information can however also be captured as incoming links from higher level specifications to feature objects Which method to use, depends on the requirements for traceability to higher level specifications in the specific project Fig 6: The DOOR Domain odel View (note that project specific information is blurred)
Paper III The PLU Toolkit 75 33 Feature Graphs in Rose To be able to draw feature graphs in Rose, we utilized the UL stereotype mechanism [10] Icons for all PLU feature types were created These icons were then associated with UL Classes that had been stereotyped as the different feature types The UL Dependency relation was then stereotyped as require and the UL Association relation was stereotyped as excludes Furthermore, UL Classes are used for visualizing domain names and UL Association relations are used for visualizing the refinement relation in Rose All new elements for feature modeling have been added to the use case diagram toolbar in the graphical user interface of Rose 34 Use Case pecifications and Use Case Realizations in DOOR Each use case is managed as a separate module in the DOOR database Introductory information is captured in a traditional document structure with headings and text in the DOOR main column To capture use case scenarios and use case realizations in DOOR, we use one DOOR object to describe each scenario step To be able to do this, object attributes for all columns in the PLU notation shown in Fig 3, except the Actor Action column must be defined For the Actor Action column, the DOOR main column is used The relationship between blackbox and whitebox scenario steps (realizations) is managed using the standard DOOR object hierarchy All whitebox step objects are children to their corresponding blackbox step object This means that use case specifications and their corresponding realisation are actually different views of the same DOOR module 35 Relating Features and Use Cases in DOOR We relate features and use cases as follows in DOOR: A feature can be related to zero or more complete use cases We manage this relation in DOOR by inserting a UL use case diagram showing use cases as a leaf object under a feature object in a feature model module A feature can be related to zero or more use case scenarios We manage this relation in DOOR by creating an outgoing link from a heading object naming a scenario in a use case module, to a feature object in a feature model module using the DOOR link concept A feature can be related to zero or more scenario steps We manage this relation in DOOR by creating an outgoing link from a scenario step object in a use case module to a feature object in a feature model module, using the DOOR link concept As shown in Fig 4, we do not relate mandatory scenario steps to the feature model The same is also true for mandatory use case scenarios This is not needed since the primary purpose of the feature model is not to provide a total view of a system family, but rather to visualize variants in the family use case model
76 agnus Eriksson, Henrik orast, Jürgen Börstler and Kjell Borg 36 DOOR Extensions for the PLU Approach DOOR can be customized using its integrated scripting language DXL (DOOR extension Language) [12] DXL supports all kinds of manipulations of the DOOR database DXL can also be used to adapt and extend the standard DOOR user interface and for controlling other Windows applications that provide automation interfaces The following sections briefly describe some DXL tools that were developed as part of the PLU toolkit These tools consist of approximately 1000 lines of low complexity DXL code in total 361 Check Feature odel The purpose of the Check Feature odel tool is to help the user with basic consistency control of feature model modules The tool checks a number of rules and conditions and presents to the user any violations in the graphical user interface Currently, we have implemented the following rules/conditions: Only heading objects are marked as features All feature objects have a defined feature type No require relations exist within a set of single adaptor features Only feature objects have require or exclude relations All exclude relations are bi-directional No contradictions exist regarding exclude relations and mandatory features No exclude relations exist between ancestors and descendants in the feature hierarchy No contradictions exist regarding exclude relations and require relations 362 Check Configuration The purpose of the Check Configuration tool is to verify whether a specific product instance (configuration) of the domain model is consistent with the feature model The tool checks the following properties and presents to the user any violations in the graphical user interface All mandatory features with included parent features are included in the configuration All ancestors to included features in the feature hierarchy are included in the configuration The configuration does not violate exclude or require relations The configuration does not violate the rules of single adaptor or multiple adaptor features 363 Illustrate Feature odel Hierarchy The purpose of the Illustrate Feature odel Hierarchy tool is to illustrate a portion of the feature model hierarchy in the DOOR graphical user interface From a selected feature object in a feature model module, a feature tree with all ancestors of the selected feature is drawn in a dialog box The tool provides possibilities to
Paper III The PLU Toolkit 77 collapse and expand the nodes of the tree The tool also provides the user with an option to insert the illustration as a picture in a new DOOR object 364 Create Use Case odule The purpose of the Create Use Case odule tool is to automatically create use case modules with certain properties This has been realized by pre-creating a use case template module with predefined structure, attributes and views which is copied by the tool 365 Create Product Use Case odel urvey The purpose of the Create Product Use Case odel urvey tool is to filter out a use case model survey for a specific product instance from a feature model module The tool accomplishes this by removing, from the selected view, those objects that do not fulfil all of the following conditions: If an object is marked as General Information, it must be either a descendant of an included Feature object or marked as included by the specified product instance itself If the object is marked as a Feature, it must also be marked as included by the specified product instance and be marked as being a Use Case Package The names of these included features then become headings in the use case model hierarchy in the survey If the object is marked as a Use Case Diagram, it must be a descendant of a Feature object marked as included by the specified product instance The resulting view can then be exported into a Use Case odel urvey Report for the selected product instance using the standard DOOR Word export 366 Export Use Case The purpose of the Export Use Case tool is to export use case modules from DOOR to Word as use case specifications and use case realizations The Export Use Case tool is based on the standard DOOR Word export, which is written in DXL The basic idea of the tool is to export blackbox and whitebox scenarios as specially formatted tables (see Fig 3), and all other information as ordinary headings and text The tool distinguish between scenarios and other information using the tep attribute, which only has a defined value if an object is part of a scenario 4 ummary and Conclusions We have described how commercially available CAE tools, traditionally used in single system development, can be extended and utilized for managing system family models in accordance with the PLU approach The described PLU toolkit is currently being used in several large scale industrial development projects in the defense domain Our experience so far is quite
78 agnus Eriksson, Henrik orast, Jürgen Börstler and Kjell Borg positive An informal evaluation indicated that the toolkit allows developers to work more effectively A formal evaluation of the toolkit is currently planned References 1 Bass L, Clements P, Donohoe P, cgregor J Nortrop L: Fourth Product Line Practice Workshop Report, Technical Report CU/EI-2000-TR-002, oftware Engineering Institute, Carnegie ellon University, Pittsburgh, PA (2000) 2 Eriksson, Börstler J, Borg K: The PLU Approach Domain odeling with Features, Use Cases and Use Case Realizations,, Proceedings of the International Conference on oftware Product Lines, LNC, Vol 3714, pringer-verlag (2005) 33-44 3 Fey D, Fajta R, Boros A: Feature odeling: A eta-model to enhance Usability and Usefulness, Proceedings of the International Conference on oftware Product Lines, LNC, Vol 2371, pringer-verlag (2002) 198-216 4 Gooma H Designing oftware Product Lines with UL From Use Cases to Pattern- Based oftware Architectures, Addisson-Wesley (2004) 5 Griss, Favaro J, d Alessandro : Integrating Feature odeling with the REB, Proceedings of the Fifth International Conference on oftware Reuse, Vancouver, BC, Canada (1998) 76-85 6 Jacobson I, Griss, Jonsson P: oftware Reuse Architecture, Process and Organization for Business success, Addison-Wesley (1997) 7 Kang K Cohen, Hess J, Novak W, Peterson A: Feature Oriented Domain Analysis (FODA) Feasibility tudy, Technical Report CU/EI-90-TR-021, oftware Engineering Institute, Carnegie ellon University, Pittsburgh, PA (1990) 8 Kruchten P: The Rational Unified Process - An Introduction, econd Edition, Addison- Wesley (2000) 9 annion, Lewis O, Kaindl H, ontroni G, Wheadon J: Representing Requirements on Generic oftware in an Application Family odel, Proceedings of the International Conference on oftware Reuse ICR-6 (2000) 153-196 10 Object anagement Group: Unified odeling Language Version 20, Available at: http://wwwumlorg (2005) 11 Rational oftware: The Rational Unified Process for ystems Engineering Whitepaper, Ver 11, Available at: http://wwwrationalcom/media/whitepapers/tp165pdf (2003) 12 Telelogic AB, DXL Reference anual, DOOR 71 anual creation date: (3 ay 2004)