Automated Software Product Line Engineering and Product Derivation

Transcription

1 Automated Software Engineering and Product Derivation Hassan Gomaa Michael E. Shin Dept. of Information and Software Engineering Dept. of Computer Science George Mason University Texas Tech University Fairfax, VA Lubbock, TX Abstract This paper describes a prototype automated software product line engineering environment, in which a multiple view model of the product line architecture and components are developed and stored in a product line repository. Automated software product derivation consists of tailoring the product line architecture given the product features and selecting the components to be included in the product. The automated environment is built on top of Rational Rose RT. Automated support is provided for developing multiple product line views, using the feature model as the unifying view, an underlying product line meta-model that provides a schema for a product line repository, support for consistency checking among the multiple views, and support for feature-based product line derivation. 1. Introduction Software product line engineering (SPL) involves developing the requirements, architecture, and component implementations for a family of systems, from which products (family members) are derived and configured. The problems of developing individual software systems are scaled upwards when developing software product lines. Automated support is a necessity for managing the complexity and variability inherent in software product lines. Software variability management is a key challenge in developing software product lines and deriving products from the product line. In order to provide an effective approach, which is capable of being automated, for variability management and product derivation in software product lines, the following is needed: a) Multiple product line views. A better understanding of software product line can be obtained by considering the different perspectives, such as requirements modeling, static modeling, and dynamic modeling, of the product line. A graphical modeling language such as UML helps in developing, understanding and communicating the different views. b) Feature model. One of the multiple views of the product line is the feature modeling view. The feature model is essential for both variability management and product derivation, because it describes the product line requirements in terms of commonality and variability, as well as defining the product line dependencies. c) Meta-model. A meta-model provides a unifying framework for the multiple views. Whereas the multiple views each need to use a different notation, a meta-model is represented in one notation. It contains the product line meta-classes and the relationships between the metaclasses, which allow consistency checking and assistance for product derivation. d) Product line repository. The meta-model is essential for tool support as it represents a schema for a product line repository, which stores the artifacts developed as a result of product line engineering. e) Consistency checking. Although a multiple view modeling approach helps in developing the product line, it is easy to introduce errors and inconsistencies in a multiple view model. It is therefore necessary to provide support for consistency checking among the multiple views. f) Product line derivation. The feature model is used to drive the process of product line derivation. By selecting a consistent set of features required for the individual product, the corresponding artifacts that realize those features are selected from the product line repository to constitute the product. This paper starts by describing multiple-view UML modeling of software product lines. It then goes on to describe how a multiple-view meta-model [1, 2] can provide a unified underlying representation for software product lines. The paper then describes a prototype software product line engineering environment tool, which is built on top of Rational Rose RT. Automated support is provided for developing multiple product line views in UML, using the feature model as the unifying view, an underlying product line meta-model that provides a schema for a product line repository, support for consistency checking among the multiple views [5, 6, 7, 15, 22, 2, 24], and support for feature-based product /07 $ IEEE 1

2 line derivation. The paper concludes by evaluating the effectiveness of the prototype for SPL engineering and product derivation. 2. Multiple-View s of SPLs A multiple-view model [16] for a SPL defines the different characteristics of a software family [17], including the commonality and variability among the members of the family [4, 25]. A multiple-view model is represented using UML [, 8, 19]. The product line life cycle includes three phases described by the PLUS method [10] for: a) Requirements ing, consists of the Use Case View []. b) Analysis ing, which consists of the Static View, the Collaboration View, the Statechart View, and the Feature View [9, 10]. c) Design ing: During this phase, the software architecture of the product line is developed. Two views of the UML SPL model are described in more detail, the class model and the feature model. The static model [] is used to depict the static structural aspects of a software product line by modeling classes, their attributes and relationships between classes. Variability in class models can be addressed through abstract classes and hot spots [18]. A hot spot is a place where class adaptation takes place. Some operations of classes can be implemented or replaced by the subclasses using the inheritance mechanism. A feature model view addresses the commonality and variability of requirements for a software product line by means of features. A feature [14] is an end-user functional requirement, which is used to identify reusable requirements of a software product line [1]. A feature is categorized as a kernel, optional, or variant feature to capture commonality and variability of a software product line. Feature models [10] can evolve through dependencies among features. Each feature is supported by one or more use cases. In an evolution of the use case model, an alternative use case can extend a base use case under certain conditions. The use case dependency corresponds to a dependency between the features. Each feature is also supported by one or more classes. As a class model evolves at a hot spot, one class can be specialized from another class where the two classes support different features. This relationship between the two classes corresponds to a dependency between these two features. Fig. 1 depicts part of the feature/class dependency model for factory automation product line, depicted using Rational Rose Real-Time. The Flexible Manufacturing optional feature is supported by the composite class Flexible Manufacturing, which is composed of the classes Part Scheduler, Part Agent, Flexible Workstation Controller, and AGV Dispatcher. The SPL multiple-view model is implemented using the Rational Rose RT tool. The Rose RT executable model uses message communication between capsule (concurrent component) classes, which execute statecharts. Each transition between states on the statechart is triggered by an event when some condition is satisfied and is optionally followed by specific actions. An event is an incoming message through a port of a capsule, and the condition and action are implemented using Rose RT internal functions and C++ code. FlexibleManufacturing + / StartPart~ + / Alarm + / WorkstationData / partscheduler <<Capsule::variant, control>> FlexibleWS InputStandStatus : int = 0 OutputStandStatus : int = 0 / flexiblews + / WorkstationCommand~ + / Alarm + / WorkstationData / partagent <<Capsule::optional, PartAgent wsidx : int = 0 oldws : int = 0 ws : int[] NumberOfPart : int = 1 MAX : int = + / WorkstationCommand + / CheckWS + / MoveRequest + / StartPart~ # / log / agvdispatcher <<Capsule::optional, AGVDispatcher + / MoveRequest~ # / time <<Capsule::optional, PartScheduler ws : int[] + / CheckWS~ Fig. 1 Feature/Class dependency for Flexible Manufacturing Feature using Rose Real-Time 2

3 Initial Idle StartPart UnfinishedPart WSUnavailable PartOffOutputStand WorkstationAvailable <<Capsule::optional, control>> PartAgent PartMovingToWorkstation PartOffOutputStand PartWaitingForAGVToNextWS wsidx:int= 0 oldws:int= 0 ws: int[] NumberOfPart :int= 1 MAX int= : + /WorkstationCommand + /CheckWS + /MoveRequest + /PartComplete ~ + /StartPart ~ + /OperationRequest # / log PartArrived PartOnWorkstationInputStand PartOffInputStand ProcessingPart NextWSAvailable NextWSUnavailable PartComplete PartOnWorkstationOutputStand a) Ports of Part Agent Capsule Class b) Statechart of Part Agent Capsule Class Fig. 2. Part Agent Capsule Class Fig. 2 depicts the ports and statechart of Part Agent application capsule class (in Fig.1) in flexible manufacturing systems of a factory automation product line. As an example of its behavior, when an incoming message Part Off Input Stand arrives through the Move Request port of Part Agent capsule class, the statechart transitions from Part On Workstation Input Stand state to Processing Part state. It is important for the multiple-views of the SPL to be consistent with each other. It is also essential that as one view is modified at a variation point, the other views are also modified at their variation points so that consistency is maintained.. Multiple-View Meta- for SPLs Consistency checking between multiple views of a model is complex, one of the reasons being the different notations that are needed. An alternative approach is to consider consistency checking between multiple views at the meta-model level. The meta-model describes the modeling elements in a UML model and the relationships between them. The meta-model is described using the static modeling notation of UML and hence just uses one uniform notation instead of several. Furthermore, rules and constraints can be allocated to the relationships between modeling elements. The multiple views are formalized in the semantic multiple-view meta-model, which depicts the metaclasses, attributes of each meta-class, and relationships among meta-classes. A high level representation of the phases containing the views in this meta-model is shown in Fig., in which a phase is modeled as a composite meta-class that is composed of the views in that phase. In the meta-class model, all concepts are modeled as UML classes. However, as the meta-classes have different semantic meaning, they are assigned stereotypes corresponding to the different roles they play in the metamodel. Thus in Fig., all the meta-classes represent the different views of a UML model and are assigned the stereotype. Meta-classes representing development phases are assigned the stereotypes «phase» as they represent the different phases of the OO lifecycle, Requirements ing, Analysis ing, and Design ing. Each view in Fig. can be modeled in more detail to depict the meta-classes in that view. A view meta-class is a composite class that is composed of the meta-classes in that view. Fig. depicts underlying relationships among multiple views in development phases of a SPL. The views in each phase are: a) Requirements phase: - Use case model: This model describes the functional requirements of a software product line in terms of actors and use cases. b) Analysis phase: - Class model: This model addresses the static structural aspects of a software product line through classes and their relationships. - Statechart model: This model captures the dynamic aspects of a software product line by describing states and transitions.

4 - Collaboration model: This model addresses the dynamic aspects of a software product line by describing objects and their message communication. - Feature model: This model captures the commonality and variability of a software product line by means of features and their dependencies. c) Design phase [8]: - Consolidated collaboration model: This model synthesizes all the collaboration diagrams developed for the use cases. - Subsystem architecture model: Based on the consolidated collaboration model, this model addresses the structural relationships between subsystems. - Task architecture model: This model addresses the subsystems decomposition into tasks (active objects) and passive objects. - Refined class model: This model addresses the design of classes by determining the operations and attributes of each class. «phase» Requirements ing «phase» Analysis ing Feature «phase» Design ing Refined Class Supported by Maps to Supported by Maps to Refined to Instantiates objects for Class Task Architecture Use Case Statechart Decomposed into Realized by Equivalent to Behavior described by Instantiated from Generates actions and activities for Generates events for Subsystem Architecture Mapped to Behavior described by Abstracted into Collaboration Integrated into Consolidated Collaboration Fig.. High-level relationships between multiple views for a software product line 4. Tool Support for Multiple-View s To support the multiple-view model of SPLs, the UML Based Software Engineering Environment (PLUSEE) has been developed using Rational Rose RT. The scope of PLUSEE includes the product line engineering and product derivation phases (Fig. 4). a) Product line Engineering. A product line multiple-view model, which addresses the multiple views of a software product line, is modeled and checked for consistency between the multiple views. The product line multiple-view model and architecture is captured and stored in the product line reuse library. b)product derivation. A target system multiple view model is configured from the product line multipleview model. The user selects the desired features for the product line member (referred to as target system) and the tool configures the target system architecture. PLUSEE represents second generation SPL engineering tools which build on experience gained in previous research [11, 12]. The design decisions affecting the development of PLUSEE are as follows: a) Both Rose and Rose RT Commercial CASE Tools are used as the interface to this prototype. Rose supports the standard UML, but it does not generate an executable architecture from the product line multipleview model. On the other hand, Rose RT generates an executable architecture from the product line multiple view model and simulates the product line architecture although it does not fully support standard UML. To take advantages of Rose and Rose RT, two separate versions of PLUSEE, which are very similar to each other, were developed. b) The Knowledge Based Requirement Elicitation tool (KBRET) [11] and GUI developed in previous research are used without change. Requirements Engineering Requirements Multiple-View, Architecture, Reusable Component Types Reuse Library Product Derivation Unsatisfied Requirements, Errors, Adaptations Fig. 4. Overview of PLUSEE Fig. 5 presents an overview of the SPL engineering tools. A SPL engineer captures a SPL multiple-view model consisting of use case, collaboration, class, statechart, and feature models through the Rose tools, which save the model information in a Rose MDL file. From this MDL file, the product line relations extractor extracts product line relations, which correspond to the meta-classes in the meta-model, and hcnce maps the multiple-view model to SPL model relational tables. These tables are used by the consistency checker to check for consistency of the multiple-view model by executing the consistency checking rules defined by the PLUS method [10]. After the SPL engineer has produced a 4

5 consistent multiple-view model, an executable SPL model is developed using Rose RT. The SPL executable model is based on message communication between active objects, which execute statecharts [20]. Next, the product line dependent knowledge base is extracted by the Product line Dependent Knowledge Base Generator for configuring target systems from the SPL multiple-view model. In the target system configuration phase of PLUSEE (Fig. 6), a Knowledge Based Requirement Elicitation tool (KBRET) is used to assist the human target system requirements engineer to select the optional features for the target system [11]. Once the features are selected, KBRET reasons about the feature/feature dependencies to ensure that a consistent set of target system features are selected from the feature model. Using the target system features, the Relations Extractor extracts target system relations from the SPL model database. The Rose MDL File Generator uses the target system relations to generate a target system Rose MDL file, which is then used to configure an executable target system. A Rose Real-Time target system executable model is a simulation of the target system, which is then executed and tested to determine whether the multiple-view model performs in accordance with the requirements. More details on the tools are given in the next section. Use Case Use Case Collaboration Object1 Object2 Message Product Line Engineer Multiple-View Consistency Checker Class Class1 1 * Class2 Statechart State1 State2 Event/ Action Rational Rose S/W Rose MDL File for Domain Multiple-View Relations Extractor Multiple-View Relations Classes Aggregate Class Dependent Knowledge Base Generator Feature - Use Case Feature2 Feature2 Multiple-View Executable Components (Rose RT only) Dependent Knowledge Base (PLDKB) Fig. 5. Engineering Tools for PLUSEE Rose MDL File for Domain Domain Relations Classes Aggregate Class - Use Case User Domain Dependent Knowledge Base (DDKB) KBRET GUI Knowledge- Based Requirements Elicitation Tool (KBRET) Rose MDL File for Target System Target System Rose MDL Generator Relations Relations Extractor Feature Set Rational Rose S/W User Use Case Use Case Collaboration Object1 Object2 Message Class Class1 1 * Class2 Statechart State1 State2 Event/ Action Executable Component (Rose RT only) Fig. 6. Configuration Tools for PLUSEE 5

6 5. Software Engineering 5.1 Multiple-View SPL Relations Extractor The multiple-view product line relations extractor generates product line relations from the multiple-view product line model. Rose and Rose RT save a multipleview product line model in ASCII MDL and RTMDL files, respectively. In these files, information about the multiple-view model is stored with keywords. These keywords are used for extracting the information relevant to the multiple views of a software product line from the Rose MDL and Rose RTMDL files. The product line relations extracted are stored in an underlying tabular representation of the multiple views, which are later used for consistency checking and target system configuration. The product line relations are tool independent. 5.2 Consistency Checker The product line model consistency checker identifies inconsistencies between multiple views in the same phase or different phases. The rules for consistency checking between multiple views are checked against the product line relations extracted from the product line meta-model. For example, the consistency checking rule, each optional class in the class model must support only one optional feature, is checked by the consistency checker using Optional Class relation ((a) of Fig.7) and Optional Feature Class Dependency relation ((b) of Fig. 7), which are derived from the multiple-view model in Fig.1. The Optional Class relation contains optional classes derived from the product line static model. The Optional Feature Class Dependency relation defines a dependency between an optional feature and an optional class supporting the feature. To check the rule, the consistency checker confirms that each optional class in the Optional Class relation supports only one optional feature in the Optional Feature Class Dependency relation. For example, if the consistency checker finds an optional class that supports more than one optional feature, a kernel feature, or no feature at all, it generates a consistency error message for this rule. 5. Dependent Knowledge Base Generator The product line dependent knowledge base generator generates the product line dependent knowledge base from the product line relations. The product line dependent knowledge base contains information about classes, optional features, feature/feature dependency, feature/class dependency, generalization/specialization relations among classes), aggregation relations among classes), and feature sets. The product line dependent knowledge base is used by KBRET to select target system features from the available optional features. Part Scheduler Part Agent AGV Dispatcher Flexible Workstation Controller Optional Feature Flexible Manufacturing Flexible Manufacturing Flexible Manufacturing Flexible Manufacturing Optional Class (a) Optional Class relation Optional Class Part Scheduler Part Agent AGV Dispatcher Flexible Workstation Controller (b) Optional Feature Class Dependency relation Fig. 7. Product line relations for consistency checker 5.4 Knowledge Based Requirements Elicitation The Knowledge Based Requirement Elicitation Tool (KBRET) is used to assist a user to select optional features of each target system. KBRET, which was developed in previous research [11], conducts a dialog with a human target system requirements engineer, presenting the user with the optional features available for selecting a target system. The user selects the features that will belong to the target system; KBRET reasons about feature/feature dependencies and then checks for feature set constraints such as mutually exclusive feature sets, exactly one-of feature sets, and one-or-more feature sets to resolve conflicts among features. Based on the selected features, KBRET determines the kernel, optional and variant classes to be included in this target system. 6. Software Product Derivation 6.1 Relations Extractor The target system relations extractor creates relations for a target system from the multiple-view product line relations. The goal is to tailor the product line multiple view model so as to configure a target system corresponding to the features selected for the target system. To extract target system relations, the extractor uses the optional and variant features that a user has selected through KBRET, as well as kernel features that are automatically selected for all product line members. The target system relation extractor determines the relations for a target system sequentially. To extract target use cases, it first reads the feature/use case dependency relation to determine whether each use case is a constituent of a feature that is selected for a target system. In this prototype tool, a use case is realized by one collaboration diagram in which the name of the 6

7 collaboration diagram is the same as the name of the use case. Using this relationship between a use case and its corresponding collaboration diagram, the extractor creates relations associated with the target system collaboration model. Then the target system relations extractor reads the feature/class relation table to determine whether each class supports a feature in the target system. Next, the extractor derives relations concerning the statechart model. The behavior of a control class is described by a statechart. In this tool, a statechart name has the name as a control class. To extract the target system relations for the statechart model, the extractor find all statecharts that have the same names as the target system classes, and then creates target system relations for these statecharts. For each product line relational table, the extractor stores the extracted relations in the equivalent target system relational table. These target system relations are represented in a relational tabular form similar to product line relations. 6.2 MDL Generator The target system MDL generator was developed to create the Rose MDL file for a target system. Using the target system relations, the target system Rose MDL generator generates a Rose MDL file for a target system by changing the color of the modeling elements in the target system. A target MDL file for a target system is generated by changing the colors of target classes in the class model, target use cases in the use case diagram, target objects in the collaboration model, and target states in the statechart model. The changed color of target system multiple-view models (for example, yellow) is distinguished from the color of the original product line multiple-view model (for example, white). 7. Mapping of Multiple Views to Rose RT The product line multiple-view model is mapped to the Rose RT model, which provides a basis for composing an executable target system. A feature in the feature model and its supporting classes are mapped to capsule classes. As a feature is supported by one or more classes in the feature model, a feature capsule class is a composite class containing one or more capsule classes corresponding to classes supporting the feature. A feature is mapped to a feature capsule class in Rose Real-Time, while a class supporting a feature is mapped to an application capsule class. A dependency between a feature and classes in the product line multiple-view model is represented by means of a composition hierarchy between a feature capsule class and application capsule classes. A capsule class is a basic element of composition for an executable target system. A class diagram of Rose Real-Time is depicted in Fig.1, which is mapped from the feature/class dependency for Flexible Manufacturing feature in Factory Automation product line. The Flexible Manufacturing feature in the product line multiple-view model is mapped to a Flexible Manufacturing capsule class in Rose Real-Time, whereas Part Agent, Part Scheduler, Flexible Workstation, and AGV Dispatcher classes supporting Flexible Manufacturing feature are mapped to their corresponding application capsule classes. A dependency between a Flexible Manufacturing feature and its application classes in the Factory Automation product line multiple-view model is represented by means of a composition hierarchy between the feature capsule class and application capsule classes. A feature capsule has its structure diagram that shows binding between application capsule classes encapsulated in the feature capsule. To bind two ports, one needs to be conjugated with respect to the other. An unconjugated port sends the outgoing messages defined by the protocol and receives the incoming ones, while a conjugated port receives the outgoing messages and sends the incoming ones. On the structure diagrams in Rose Real-Time, unconjugated ports are shown with small black squares (Fig.8), while conjugated ports are shown with small white squares. The bindings between application capsule classes in a feature capsule class are derived from the collaboration diagram of the product line multiple-view model. An incoming message to an object in the collaboration diagram is transformed into a conjugate port of the capsule class (from which the object is instantiated), whereas an outgoing message from an object is transformed to an unconjugated port. The structure diagram of Flexible Manufacturing feature capsule class is depicted in Fig. 8, where Part Agent, Part Scheduler, Flexible Workstation, and AGV Dispatcher capsule objects are bound via conjugated and unconjugated ports. For example, the Workstation Check port in Part Agent capsule object, which is an unconjugated port, is bound to the conjugated port in the Part Scheduler capsule object. 8. Composition of Executable Executable target systems are manually configured by developing a composition diagram and its structure diagram for each target system based upon the target feature set derived by the KBRET. A class composition diagram depicts feature capsule classes supporting the target system and external system capsule classes involved in the system [20]. A target system is represented by a target system capsule class in Rose RT, 7

8 which has its corresponding structure diagram. A structure diagram for a target system capsule class describes the composite structure of its constituent feature capsule objects (which are instantiated from capsule classes), ports, and connections between the objects. To complete a structure diagram for a target system, connections between feature capsule objects through their ports are needed to communicate between capsule objects. + / StartPart~ + / StartPart~ / partscheduler / partagent : PartAgent : PartScheduler + / CheckWS + / CheckWS~ + / WorkstationCommand + / MoveRequest + / WorkstationCommand~ / flexiblews : FlexibleWS + / WorkstationData+ / Alarm + / WorkstationData + / Alarm + / MoveRequest~ / agvdispatcher : AGVDispatcher Fig. 8. Structure Diagram of Flexible Manufacturing Feature Fig. 9 shows a class composition diagram for a flexible manufacturing target system. This target system consists of several features: Factory Kernel, Flexible Manufacturing, Work Order User, Process Management, Work Order Management, Process Planning User, and Factory Operations User. In addition, it involves two external systems, that is, Pick-and-Place Robot and Assembly Robot. Each feature is supported by one or more capsule classes, which are defined in the implementation of the multiple-view model. The structure diagram of a flexible manufacturing target system in Fig. 10 shows how the feature capsule objects (instantiated from feature capsule classes) and external systems (instantiated from external system capsule classes) are connected to communicate with each other. For a given target system, a specific number of instances of those capsules is defined. The executable target system is used to validate the specifications configured from PLUSEE tool. With the information of the structure diagram for a target system, Rose RT integrates the components associated with target features. Rose RT checks message types and then generates the executable C++ code corresponding to components in the structure diagram. The executable target system is checked against the requirements of the target system use case model. <<Capsule::kernel feature>> / factorykernel FactoryKernel + / AlarmRequest~ + / WorkstationRequest~ + / Alarm~ + / WorkstationData~ WorkOrderUser + / WorkOrder + / ProcessPlanRequest + / StartPart + / PartComplete <<Capsule::external system>> PickAndPlaceRobot idx : int = 0 ~ # / time / workorderuser / pickandplacerobot <<Capsule::target system>> FlexibleManufacturingSystem / flexiblemanufacturing / processmanagement FlexibleManufacturing + / StartPart~ + / Alarm + / WorkstationData / assemblyrobot ProcessManagement + / ProcessPlanRequest~ ~ / processplanninguser / factoryoperationsuser / workordermanagement <<Capsule::external system>> AssemblyRobot idx : int = 0 ProcessPlanningUser + / ProcessPlanRequest WorkOrderManagement + / WorkOrder~ ~ # / log # / time FactoryOperationsUser + / AlarmRequest + / WorkstationRequest Fig. 9. Class Composition Diagram for a Flexible Manufacturing System 8

9 / factoryoperationsuser : FactoryOperationsUser + / WorkstationRequest + / AlarmRequest + / WorkstationRequest~ + / AlarmRequest~ / workordermanagement : WorkOrderManagement / factorykernel : FactoryKernel + / WorkstationData~ + / Alarm~ + / WorkOrder~ + / WorkOrder + / StartPart / workorderuser + / StartPart~ + / WorkstationData + / Alarm : WorkOrderUser / flexiblemanufacturing : FlexibleManufacturing + / PartComplete + / ProcessPlanRequest + / ProcessPlanRequest~ ~ / processmanagement ~~ : ProcessManagement / assemblyrobot / pickandplacerobot : AssemblyRobot : PickAndPlaceRobot + / ProcessPlanRequest / processplanninguser : ProcessPlanningUser 9. Evaluation of Prototype To evaluate this approach, the PLUSEE has been used in two case studies [21], a factory automation product line and an electronic commerce product line. The evaluation of the PLUSEE is conducted through the following validation procedure, which also identifies the activities performed by the human product line developer and the PLUSEE tool: a) Develop a multiple-view model of a software product line (Human). b) Map the multiple-view model to multiple-view model relations (Tool). c) Perform consistency checking of the multiple-view model relations (Tool). d) Implement multiple views using Rose Real-Time (Human). e) Configure target systems from the software product line (Tool and Human). f) Test target system using conventional software testing techniques (Human). The following objectives were achieved: a) Provide tool support for representing the multiple graphical views supported by the product line modeling method. This was achieved using the Rose graphical editors to support the multiple views. Rose was used to capture the multiple views; the underlying representation of each view was then extracted by our tools and mapped to the product line repository. b) Provide a capability for consistency checking between the multiple views. We developed a multiple view consistency checking tool for this purpose, which reported any inconsistencies among the views to the user. Fig. 10. Structure Diagram of a Flexible Manufacturing System c) Provide a capability for mapping the multiple views to a product line repository. This was achieved by first using the open architecture provided by Rose to extract the information in the multiple views, mapping these views to an integrated set of data base relations that supported the multiple views, and then mapping these relations to a knowledge base repository. This was achieved using tools we developed for PLUSEE. d) Provide automated support for product derivation from the product line repository. This was achieved by developing the knowledge based requirements elicitation tool (KBRET) for this purpose. KBRET interacts with the product requirements engineer to derive the product from the product line repository. e) Provide a product line independent environment. Thus the prototype should be capable of being used with multiple product line models. Product line independence is achieved by treating all product line specific information as data and facts to be manipulated by the product line independent tools. To demonstrate product line independence, several different product lines have been modeled and products derived from them. f) Use existing software tools where possible. Both Rational Rose and Rational Rose RT were used for this research. g) Provided an environment that is capable of evolving with new CASE tools. The SPL repository is CASE tool independent. To support a different UML modeling tool, it is necessary to develop a new version of the SPL multiple view relations extractor. In this research, we developed two versions of the extractor, one for Rose and the other for Rose RT. 9

10 10. Conclusions This paper has described a research prototype for an automated software product line engineering environment, in which a multiple view model of the product line architecture and components are developed and stored in a product line repository. Automated software product derivation consists of tailoring the product line architecture given the product features and selecting the components to be included in the product. The automated environment was built on top of Rational Rose RT. Automated support is provided for developing multiple product line views, using the feature model as the unifying view, an underlying product line meta-model that provides a schema for a product line repository, support for consistency checking among the multiple views, and support for feature-based product line derivation. This research has demonstrated the viability of using UML-based methods and tools for software product line engineering and automated product derivation. References [1] Reda Bendraou, Marie-Pierre Gervals, and Xavier Blanc, UML4SPM: A UML2.0-Based Metamodel for Software Process ing, ACM/IEEE 8th International Conference on Driven Engineering Languages and Systems, UML 2005, Montego Bay, Jamaica, October 2-7, [2] Xavier Blanc, Franklin Ramalho, and Jacques Robin, Metamodel Reuse with MOF, ACM/IEEE 8th International Conference on Driven Engineering Languages and Systems, UML 2005, Montego Bay, Jamaica, October 2-7, [] G. Booch, J. Rumbaugh, I. Jacobson, The Unified ing Language User Guide, Second Edition, Addison Wesley, Reading MA, [4] P. Clements and L. Northrop, Software s: Practices and Patterns, Addison Wesley, [5] S.teve Easterbrook and B.ashar Nuseibeh." Using Viewpoints for Inconsistency Management". BCS/IEE Software Engineering Journal, January [6] Alexander Egyed. "Automating Architectural View Integration in UML". Proc. ESEC/FSE [7] Gregor. Engels, R.eiko Heckel, and Jochen M. Küster, The Consistency Workbench: A Tool for Consistency Management in UML-Based Development, Proc. UML Conference, San Francisco, CA, Oct [8] H. Gomaa, Designing Concurrent, Distributed, and Real- Time Applications with UML, Addison-Wesley, [9] Hassan Gomaa and Michael E. Shin, Multiple-View Meta- ing of Software s the Eighth IEEE Intlernational Conference on Engineering of Complex Computer Systems (ICECCS 2002), Maryland, December, [10] H. Gomaa, H. Designing Software s with UML: From Use Cases to Pattern-based Software Architectures, Addison-Wesley Object Technology Series, [11] H. Gomaa, L. Kerschberg, V. Sugumaran, C. Bosch, and I Tavakoli, "A Knowledge-Based Software Engineering Environment for Reusable Software Requirements and Architectures," J. Automated Software Engineering, Vol., Nos. /4, August [12] H. Gomaa and G.A. Farrukh, Methods and Tools for the Automated Configuration of Distributed Applications from Reusable Software Architectures and Components, IEE Proceedings Software, Vol. 146, No. 6, December [1] M. Griss, J. Favaro, M. D Alessandro, Integrating Feature ing with the RSEB, Proc. International Conference on Software Reuse, Victoria, June [14] K. C. Kang et. al., Feature-Oriented Domain Analysis, Technical Report No. CMU/SEI-90-TR-21, Software Engineering Institute, November [15] McUmber W. E. and Cheng, B. A General Framework for Formalizing UML with Formal languages 2 rd International Conference on Software Engineering, pp [16] B. Nuseibeh, J. Kramer and A. Finkelstein, "A Framework for Expressing the Relationships Between Multiple Views in Requirements Specification ", IEEE Transactions on Software Engineering, 20(10): , [17] Parnas D., "Designing Software for Ease of Extension and Contraction", IEEE Transactions on Software Engineering, March [18] Wolfgang Pree, Design Patterns for Object-Oriented Software Development, Addison-Wesley, [19] J. Rumbaugh, G. Booch, I. Jacobson, The Unified ing Language Reference Manual, Second Edition, Addison Wesley, Reading MA, [20] B. Selic, G. Gullekson, and P. T. Ward, Real-Time Object-Oriented ing, John Wiley & Sons, [21] Michael E. Shin, Evolution in Multiple-View s in Software Product Families, Ph.D. dissertation, George Mason University, Fairfax, VA, [22] Ragnhild Van Der Straeten, Tom Mens, Jocelyn Simmonds, and Viviane Joncherset. al, Using Description Logic to Maintain Consistency between UML s, Proc. UML Conference, San Francisco, CA, Oct [2] Thanwadee T. Sunetnanta and Anthony Finkelsteing, Automated Consistency Checking for Multiperspective Software Specifications Workshop on Advanced Separation of Concerns, The 2 rd Intlernational Conference on Software Engineering (ICSE2001), Toronto, Ontario, Canada, May [24] A. Tsiolakis and H. Ehrig Consistency Analysis of UML Class and of Sequence Diagrams using Attribute Graph Grammers, Tech Rep No Technical University of Berlin. At April [25] David M Weiss and Chi Tau Robert Lai, Software Product-Line Engineering: A Family-Based Software Development Process, Addison Wesley,