Designing Software Product Lines with UML

Designing Software Product
Lines
with UML
Hassan Gomaa
Department of Information and Software
Engineering
George Mason University
Fairfax, Virginia 22030-4444
Phone: (703) 993-1652
Email: [email protected]
Software Engineering Workshop Tutorial
April 2005
Copyright © 2005 Hassan Gomaa
All rights reserved. No part of this document may be
reproduced in any form or by any means, without the prior
written permission of the author.
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
GOMAA: Preface
DESIGNING SOFTWARE PRODUCT LINES
WITH UML
Hassan Gomaa
Department of Information and Software Engineering
George Mason University
Fairfax, Virginia 22030-4444
(703) 993 1652
Fax: (703) 993 1638
Email: [email protected]
Preface
June 2004
Overview
This book describes an evolutionary software engineering process for the development of
software product lines, which uses the Unified Modeling Language (UML) notation. A software
product line (or product family) consists of a family of software systems that have some common
functionality and some variable functionality. The interest in software product lines emerged
from the field of software reuse when developers and managers realized that they could obtain
much greater reuse benefits by reusing software architectures instead of reusing individual
software components. The field of software product lines is increasingly recognized in industry
and government as being of great strategic importance for software development. Studies indicate
that if three or more systems with a degree of common functionality are to be developed, then
developing a product line is significantly more cost-effective than developing each system from
scratch.
The traditional mode of software development is to develop single systems—that is, to
develop each system individually. For software product lines, the development approach is
broadened to consider a family of software systems. This approach involves analyzing what
features (functional requirements) of the software family are common, what features are optional,
and what features are alternatives. After the feature analysis, the goal is to design a software
architecture for the product line, which has common components (required by all members of the
family), optional components (required by only some members of the family), and variant
components (different versions of which are required by different members of the family). Instead
of starting from square one, the developer creates applications by adapting and configuring the
product line architecture.
To model and design families of systems, the analysis and design concepts for single
product systems need to be extended to support software product lines. This book is intended to
appeal to readers who are familiar with modeling and designing single systems, but who wish to
extend their knowledge to modeling and designing software product lines. It is also intended to
appeal to readers who are familiar with applying UML to the modeling and design of single
systems but not with developing software product lines.
Pref-1
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
GOMAA: Preface
What This Book Provides
Several textbooks on the market describe object-oriented concepts and methods, which are
intended for single systems. Very few books address software families or product lines; and of
those that do, even fewer use UML.
This book provides a comprehensive treatment of the application of UML-based objectoriented concepts to the analysis and design of software product lines. In particular, it does the
following:
x Describes fundamental concepts and technologies in the design of software product lines.
x
Describes, in considerable detail, a UML-based object-oriented analysis and design
method for software product lines. It examines how each of the UML modeling views—
use case modeling, static modeling, dynamic state machine modeling, and dynamic
interaction modeling—is extended to address software product lines. Each UML
modeling view is extended to reflect the commonality and variability of the product line.
A new view, the feature modeling view, is added to explicitly model the commonality
and variability of software requirements.
x
Uses the Object Management Group (OMG) concept of model-driven architecture to
develop a component-based software architecture for a product line. The product line
architecture is expressed as a UML platform-independent model, which can then be
mapped to a platform-specific model.
x
Describes how architectures for software product lines are developed through the
consideration of software architectural patterns in relation to the characteristics of the
product line. The product line architecture is component-based and explicitly models the
commonality and variability of the product line.
x
Presents three case studies illustrating how a software product line architecture is
developed, starting with use cases and feature modeling in the requirements modeling
phase, static and dynamic modeling in the analysis modeling phase, and the development
of the component-based software architecture in the design modeling phase. The case
studies focus on a microwave oven product line, an electronic commerce product line,
and a factory automation product line.
x
Includes a glossary, a bibliography, and two appendices, which provide (1) an overview
of UML 2 notation and (2) a catalog of software architectural patterns for product lines.
The PLUS Advantage
The UML-based software design method for software product lines described in this book is
called PLUS (Product Line UML-Based Software Engineering). The PLUS method extends the
UML-based modeling methods that are used for single systems to address software product lines.
With PLUS, the objective is to explicitly model the commonality and variability in a software
product line. PLUS provides a set of concepts and techniques to extend UML-based design
methods and processes for single systems to handle software product lines. In particular, for
modeling software product lines, PLUS provides the following additions to the process of
modeling single systems:
Pref-2
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
GOMAA: Preface
Software Product Line Requirements Modeling
x
Use case modeling. Model commonality and variability in the use case model. For this
purpose, PLUS provides an approach to modeling kernel, optional, and alternative use
cases, as well as an approach to modeling variation points in use cases.
x
Feature modeling. Model product line features. Feature modeling is a key concept in
software product lines. PLUS provides an approach for modeling common, optional, and
alternative features, an approach for deriving the feature model from the use case model,
and an approach for representing features with the UML notation.
Software Product Line Analysis Modeling
x
Static modeling. Develop a product line context model for the product line boundary.
Determine kernel, optional, and alternative external classes. Develop a product line
information (entity class) model: determine kernel, optional, and alternative entity
classes.
x
Dynamic interaction modeling. Develop interaction diagrams to realize kernel, optional,
and alternative use cases. Use evolutionary development: the kernel first approach is
applied to determine product line commonality, followed by product line evolution to
determine variability.
x
Dynamic state machine modeling. Develop kernel, optional, and alternative statecharts.
Manage state machine variability through inheritance and parameterization.
x
Feature/class dependency modeling. Determine the dependency that common, optional,
and alternative features have with kernel, optional, and variant classes.
Software Product Line Design Modeling
x
Software architectural patterns. Determine the software architectural structure and
communication patterns that are most appropriate for the product line, given the catalog
of architectural patterns.
x
Component-based software design. Develop a component-based software design for the
product line, which models kernel, optional, and variant components, as well as their
ports and provided and required interfaces. Design the component-based architecture that
explicitly models the components and their interconnections.
Software Application Engineering
Develop a software application that is a member of the product line, by using the feature model to
derive the application from the product line architecture and components.
Pref-3
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
GOMAA: Preface
Annotated Table of Contents
Chapter 1: Introduction
This chapter presents an introduction to software product lines, a discussion of software reuse
issues, and an overview of object-oriented analysis and design with UML.
Chapter 2: Design Concepts for Software Product Lines
This chapter discusses and presents an overview of key design concepts and technologies for
software product lines, including object-oriented technology, software architecture, and the
software component technology.
Chapter 3: Software Product Line Engineering
This chapter introduces the software product line design method, which is described in much
greater detail in subsequent chapters. One of the goals of this method is to be capable of
extending other design methods, such as the author’s COMET method (Concurrent Object
Modeling and Architectural Design Method) to model and design software product lines. The
acronym for the method is PLUS (Product Line UML-Based Software Engineering). However,
the term PLUS is also intended to mean that other methods can be extended to support product
lines such as COMET, ROPES, or RUP/USDP.
There are two main strategies for developing a software product line, referred to as
forward evolutionary engineering and reverse evolutionary engineering. Forward evolutionary
engineering is best used when a new product line is being developed with no previous systems to
guide the development. Reverse evolutionary engineering is best used when the product line
development begins with existing systems that are candidates for modernization and inclusion in
a project to develop a product line.
Chapter 4: Use Case Modeling for Software Product Lines
This chapter describes how use case modeling concepts are extended to address software product
lines—in particular, how the common and variable functionality of the product line is modeled
with kernel, optional, and alternative use cases, and how variation points are used to model
variability.
Chapter 5: Feature Modeling for Software Product Lines
This chapter describes feature modeling—a concept used widely in software product lines but not
addressed by UML. The discussion covers how feature modeling concepts can be incorporated
into the UML and how features can be determined from use cases.
Chapter 6: Static Modeling in Software Product Lines
This chapter describes how static modeling concepts are extended to address software product
lines—in particular, to address modeling the boundary of the software product line and modeling
entity classes, which are information-intensive classes. Also discussed is the categorization of
application classes from two perspectives: the role the class plays in the application, and the reuse
characteristic of the class.
Pref-4
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
GOMAA: Preface
Chapter 7: Dynamic Interaction Modeling for Software Product Lines
This chapter describes how dynamic interaction modeling concepts are extended to address
software product lines. Communication diagrams are developed for each kernel, optional, and
alternative use case. Dynamic interaction modeling to address use case variation points is also
covered. The kernel first approach is used for dynamic modeling, followed by the product line
evolution approach.
Chapter 8: Finite State Machines and Statecharts for Software
Product Lines
This chapter describes how finite state machine and statechart modeling concepts are extended to
address software product lines. In particular, each state-dependent control class—whether kernel,
optional, or variant—needs to be modeled with a finite state machine and depicted as a statechart.
It is also possible to model variability using inherited state machines and parameterized state
machines.
Chapter 9: Feature/Class Dependency Modeling for Software Product
Lines
This chapter describes how to determine which classes from the analysis model are needed to
support the features from the feature model. Product line classes are categorized as kernel,
optional, and variant classes. Modeling class variability using both inheritance and
parameterization is described. Feature-based dynamic modeling and static modeling are also
covered.
Chapter 10: Architectural Patterns for Software Product Lines
This chapter describes a range of software architectural patterns that are particularly useful in the
design of software product line architectures. Both architectural structure and communication
patterns are described. Architectural structure patterns address the overall structure of the
software architecture. Architectural communication patterns address the ways in which
distributed components can communicate with each other. This chapter also describes how
product line architectures can be built from these patterns.
Chapter 11: Software Product Line Architectural Design: ComponentBased Design
This chapter describes how a product line architecture is designed as a component-based
architecture. Separation of concerns in component design is an important issue. Components are
categorized according to their roles in the software architecture. The design of component
interfaces is described. The chapter also discusses how component-based software architectures
can be depicted with the structured class and composite structure diagram notation introduced in
UML 2, which allows components, ports, connectors, and provided and required interfaces to be
depicted.
Chapter 12: Software Application Engineering
This chapter describes the process for deriving a member of the software product line from the
product line architecture and components. This is a tailoring process involving selection of the
Pref-5
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
GOMAA: Preface
appropriate components and setting of the parameter values for individual components to include
in the product line member. The chapter covers how the feature model is used to help in this
process.
Chapter 13: Microwave Oven Software Product Line Case Study
This chapter describes how the PLUS software product line method is applied to the design of a
microwave oven software product line. Because this is a new product line, the forward
evolutionary engineering product line development strategy is used, in which an iterative
approach is used to determine the kernel functionality of the product line before the variable
functionality is modeled.
Chapter 14: Electronic Commerce Software Product Line Case Study
This chapter describes how the PLUS software product line method is applied to the design of an
e-commerce application product line. Because there are two main systems—business-to-business
(B2B) and business-to-consumer (B2C)—in the electronic commerce product line, the reverse
evolutionary engineering product line development strategy is applied first to each type of
system, from which the product line commonality is determined first, followed by the product
line variability.
Chapter 15: Factory Automation Software Product Line Case Study
This chapter describes how the PLUS software product line method is applied to the design of a
factory automation product line. Because this product line starts with existing factory automation
systems that are candidates for modernization and inclusion in the product line, the reverse
evolutionary engineering product line development strategy is applied.
Appendix A: Overview of the UML Notation
This appendix provides an overview of the different UML 2.0 diagrams used by the PLUS
method. The differences between the UML 2.0 notation and UML 1.x notation are also explained,
as are the conventions used in this book.
Appendix B: Catalog of Software Architectural Patterns
In this appendix the software architectural structure and communication patterns, originally
described in Chapter 10, are documented alphabetically in a common template for easy reference.
Pref-6
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
Hassan Gomaa
Biosketch
Hassan Gomaa is Chair and Full Professor in the Department of Information and Software
Engineering at George Mason University, Fairfax, Virginia. He received a B.Sc.(Eng.) with First
Class Honors in Electrical Engineering from University College, London University, and the
DIC and Ph.D. in Computer Science from Imperial College of Science and Technology, London
University.
He has over 30 years experience in software engineering, both in industry and academia, and has
published over 130 technical papers and 3 textbooks. His book, "Software Design Methods for
Concurrent and Real-Time Systems", is published by Addison Wesley as part of the SEI Series
on Software Engineering, had its fourth printing in 1999, and was translated into Chinese in
2003. His second book, entitled “Designing Concurrent, Distributed, and Real-Time
Applications with UML”, was published by Addison Wesley in 2000, had its fourth printing in
2004, and was translated into Chinese in 2004. His latest textbook entitled “Designing Software
Product Lines with UML” was published by Addison Wesley in July 2004.
His current research interests include object-oriented analysis and design for concurrent, realtime, and distributed systems, software architecture, software product lines, software reuse,
software performance engineering, intelligent software agents, software engineering
environments, and software process models. His research has been funded by the National
Science Foundation, NASA, DARPA, Hughes Applied Information Systems, Siemens, Software
Productivity Consortium, Virginia Center of Innovative Technology, Virginia Center of
Excellence in Software Reuse, CTA, American Management Systems, and Grumman. He is the
developer of the DARTS, ADARTS, CODARTS, COMET, and PLUS software design methods.
He has taught several short courses for industry and academia He also consults in both the
technical and management aspects of software engineering.
Previously, he held faculty positions at the Wang Institute of Graduate Studies, where he was
Professor of Information Technology, and at Imperial College of Science and Technology,
London University, where he was a lecturer (equivalent to Assistant Professor in North America)
in the Department of Computing. He also has several years industrial experience, most recently
at General Electric.
1
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
Designing Software Product Lines with UML
Hassan Gomaa
Department of Information and Software Engineering
George Mason University
Fairfax, Virginia 22030-4444
Phone: (703) 993-1652
Email: [email protected]
Software Engineering Workshop Tutorial
April 2005
Copyright © 2005 Hassan Gomaa
All rights reserved. No part of this document may be reproduced in any form
or by any means, without the prior written permission of the author.
Copyright 2005 H. Gomaa
SPL-1
Introduction
•
•
•
•
Software Product Line
– Family of products / systems
– Some common components, some optional, some variant
Designing Software Product Lines
– Object Oriented Analysis and Design of Software Product Lines
– Emphasis on modeling commonality and variability in software
product lines
Unified Modeling Language (UML)
– Standardized notation for object-oriented development
– UML notation extended to model software product lines
– Use UML standard extension mechanisms
• Stereotypes
• Constraints
• Tagged values
UML 2.0
– New concepts for depicting software architectures and components
Copyright 2005 H. Gomaa
SPL-2
1
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
UML and COMET
• Unified Modeling Language (UML)
– OMG Standardized notation for describing design
– Methodology independent
• Concurrent Object Modeling and architectural design
mEThod (COMET)
– Object Oriented Analysis and Design Method
– Targeted for concurrent, distributed, and real-time
applications
– Uses UML notation
• COMET = UML + Method
•
H. Gomaa, “Designing Concurrent, Distributed, and Real-Time
Applications with UML”, Addison Wesley Object Technology Series,
2000
Copyright 2005 H. Gomaa
SPL-3
Software Reuse
• Traditional Software Reuse
– Library of reusable code components
– Emphasis on code reuse
• Architecture Reuse
– Focuses on requirements and design reuse
– Much greater potential than code reuse
• Software Product line engineering
– Software engineering for family of products
– Reuse of requirements and architecture
• Application engineering
– Software engineering for one member of family
• Architecture for Software Product Lines
– Captures similarities and variations of product family
Copyright 2005 H. Gomaa
SPL-4
2
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
Object-Oriented Analysis and Design (OOAD)
for Software Product Lines
• Unified Modeling Language (UML)
– Standard notation for describing a software design
– Needs to be used with an analysis and design method
• UML notation for OOAD method for single systems
– H. Gomaa, “Designing Concurrent, Distributed, and
Real-Time Applications with UML”, Addison Wesley
Object Technology Series, 2000.
• UML notation for OOAD Method for modeling software
product lines
– H. Gomaa, “Designing Software Product Lines with
UML”, Addison Wesley Object Technology Series,
July 2004
Copyright 2005 H. Gomaa
SPL-5
Evolutionary Process Model
for Software Product Lines
Product Line
Requirements
Product Line
Engineering
Product Line Requirements and
Analysis Models,
Product Line Architecture,
Reusable Components
Product
Line
Reuse
Library
Application
Requirements
Application
Engineering
Application
Unsatisfied Requirements, Errors, Adaptations
Copyright 2005 H. Gomaa
SPL-6
3
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
Product Line Engineering
Copyright 2005 H. Gomaa
SPL-7
Requirements Modeling
What should SPL Design Method provide?
• Support variability in use case
modeling
• Integrate feature modeling with
other UML views
Copyright 2005 H. Gomaa
SPL-8
4
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
UML Modeling for Single Systems
• Use Case Model
– Use case diagram
• Static Model
– Class diagram
• Dynamic Model
– State Machine Model
• Statechart
– Interaction Model
• Communication (collaboration) or sequence diagram
Copyright 2005 H. Gomaa
SPL-9
UML Modeling for Software Product Lines
• Use Case Model
– Model kernel, optional, and alternative use cases
– Model variation points in use cases
• Static Model
– Model kernel, optional, variant classes and relationships
• Dynamic State Machine Model
– Statechart for each state dependent object
• Dynamic Interaction Model
– Communication diagram for each use case
– Communication diagrams depend on objects in
prerequisite use cases
• Feature modeling
– Model product line variability in software requirements
Copyright 2005 H. Gomaa
SPL-10
5
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
Use Case Modeling for
Software Product Lines
• Use Case Model
– Defines functional requirements in terms of use cases
and actors
– Use case describes sequence of interactions between
actor and system
• Single Systems
– All use cases required
– All actors required
• Software product lines
– Kernel use cases
– Optional use cases
– Alternative use cases
– Some actors may be optional
Copyright 2005 H. Gomaa
SPL-11
Variation Points in a Use Case Model
• Variation Point
– Location in a use case where a change can take place
• Variation Point can be handled by
– Variation Point within use case
• Identify line # in use case where variability can be
introduced
– Conditional use case relationship
• Extend relationship
– Extend use case if product line condition is True
• Include relationship
– Include use case if product line condition is True
Copyright 2005 H. Gomaa
SPL-12
6
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
Developing Use Case Model for
Software Product Lines
• Kernel First Approach
– Develop use cases that are common to all members of
the software product line
• Kernel use cases
• Product Line Evolution Approach
– Start with kernel use case model
– Develop optional and alternative use cases
Copyright 2005 H. Gomaa
SPL-13
Developing Use Case Model for Software Product Lines Kernel First Approach
• Kernel First Approach
– Develop kernel use cases initially
• Example of Kernel First Approach
– Kernel use case in Microwave Product Line
• Cook Food
• Product Line Evolution Approach
– Address Product Line use case variability
– Cook Food kernel use case
• Several variation points
– Optional use cases in Microwave Product Line
• Set Time of Day
• Display Time of Day
Copyright 2005 H. Gomaa • Cook Food with Recipe
SPL-14
7
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
Use Case Model for Microwave Oven System
Cook Food
User
Timer
• Example of Timing Requirement
- When timer expires, system must
switch off heater within 100 msecs
Copyright 2005 H. Gomaa
SPL-15
Use Case Model for Microwave Oven Product Line
Categorize use cases
using UML
stereotypes
<<kernel>>
Cook Food
<<optional>>
Set Time of Day
Timer
User
<<optional>>
Display Time of Day
<<optional>>
Cook Food with Recipe
Copyright 2005 H. Gomaa
SPL-16
8
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
Use Case Model for Microwave Oven SPL
Use case name: Cook Food
Reuse category: Kernel
Summary: User puts food in oven, and microwave oven cooks food.
Actors: User (primary), Timer (secondary).
Precondition: Microwave oven is idle.
Description:
1. User opens the door, puts food in the oven, and closes the door.
2. User presses the Cooking Time button.
3. System prompts for cooking time.
4. User enters the cooking time on the numeric keypad and presses the Start Button.
5. System starts cooking the food.
6. System continually displays the cooking time remaining.
7. The timer elapses and notifies the system.
8. System stops cooking the food and displays the end message.
9. User opens the door, removes food from the oven, and closes the door.
10. System clears the display.
Alternatives:
Line 1: Uses presses Start when the door is open. System does not start cooking.
…..
Postcondition: Microwave oven has cooked the food.
Copyright 2005 H. Gomaa
SPL-17
Cook Food Use Case - Variation Points
• Lines 3,8: Display Language – Mandatory alternative
– Default = English
– Alternatives = French, Spanish, German, Italian
• Line 1: Weight Sensor – Mandatory alternative
– Default = Boolean weight
– Alternative = Analog weight
• Line 1: Heating Element – Mandatory alternative
– Default = One-level Heating Element
– Alternative = Multi-level Heating Element
• Line 2: Power level – Optional
– Power level buttons = high, medium, or low.
Copyright 2005 H. Gomaa
SPL-18
9
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
Cook Food Use Case - Variation Points
• Lines 3,4,6,8,10: Display Unit - Mandatory alternative
– Default = one-line display
– Alternative = multi-line display
• Lines 2, 6: Minute plus. Optional
– Add one to cooking time.
– Start cooking if not yet cooking.
• Lines 1,5,8,9: Light – Optional
– Lamp switched on when cooking & when door is open.
• Lines 5,8: Turntable – Optional
– Turntable rotates for duration of cooking
• Line 8: Beeper – Optional
– Switch Beeper on when cooking stops
Copyright 2005 H. Gomaa
SPL-19
Use Case Model for Microwave Oven SPL
Use case name: Set Time of Day
Reuse category: Optional
Dependency: Variation point in Cook Food use case: at Display Unit variation point,
select Multi-Line Display
Summary: User sets Time of Day clock
Actor: User
Precondition: Microwave oven is idle
Description:
1. User presses Time of Day (TOD) Button
2. System prompts for Time of Day.
3. User enters the Time of Day by pressing the numeric keypad.
4. System displays the entered Time of Day.
5. User presses start.
6. System starts the Time of Day timer.
7. System increments the Time of Day each second.
Alternatives:
Variation Points
Line 4: 12/24 hour Clock – Mandatory alternative
TOD display is either 12 hour clock or 24 hour clock
Postcondition: TOD clock has been set
Copyright 2005 H. Gomaa
SPL-20
10
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
Use Case Model for
Software Product Lines
- View Integration Approach
• Specify use cases for each member of product line
• Compare use cases for different members
• Determine kernel, optional, and alternative use cases
– Kernel use cases needed by all Product Line members
– Optional use cases needed by some Product Line
members
– Alternative use cases are mutually exclusive
Copyright 2005 H. Gomaa
SPL-21
Figure 4.13 E-commerce: Example of Reverse Engineering Approach:
Supplier use cases in B2C systems
Supplier
Process
Delivery Order
Confirm
Shipment
Bill Customer
Copyright 2005 H. Gomaa
SPL-22
11
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
Figure 4.14 E-commerce: Example of Reverse Engineering Approach:
Supplier use cases in B2B systems
Supplier
Process
Delivery Order
Confirm
Shipment
Send Invoice
Copyright 2005 H. Gomaa
SPL-23
Figure 4.15 E-commerce: Example of Reverse Engineering Approach:
Supplier use cases in E-Commerce product line
«kernel»
Process Delivery
Order
Supplier
«kernel»
Confirm
Shipment
«alternative»
Send Invoice
«alternative»
Bill Customer
Copyright 2005 H. Gomaa
SPL-24
12
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
Feature Modeling for
Software Product Lines
• Feature (Kang, SEI)
– Function or characteristic that differentiates between
members of the software product line
• Feature modeling
– Very important for SPLs
– PLUS integrates feature modeling with other UML
modeling views
Copyright 2005 H. Gomaa
SPL-25
Feature Modeling
• Feature
– Function or characteristic that differentiates between
members of the software product line
• Features are categorized as
– Common features
• Required by all members of product line
– Optional features
• Required by some members of product line
– Alternative features
• Choice of features
• One of the alternatives may be a default feature
– Parameterized feature
• Type, permitted values, default value
Copyright 2005 H. Gomaa
SPL-26
13
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
Feature Modeling in UML
• Model feature as a use case
– Can use when a feature is modeled as a use case
• Model feature as a use case package
– Can use when a feature is a grouping of use cases
• Model feature as a class
– Using UML static modeling to model meta-classes
• Feature / use case dependency
– Tabular representation
Copyright 2005 H. Gomaa
SPL-27
Figure 5.1 Optional Feature as Use Case Package
«optional feature»
TOD Clock
«optional»
Set Time Of Day
User
«optional»
Display Time Of Day
Copyright 2005 H. Gomaa
Timer
SPL-28
14
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
Feature Modeling
• Feature Dependencies
– One feature depends on another
– Dependency on common features is implicit
– Dependency on optional features is explicitly specified
• Feature Relationships
– Mutually exclusive features
• Zero or One out of a group of features
– Exactly one of a group of features
• One and only one out of a group of features
– One or more of a group of features
• One or more out of a group of features
– Mutually inclusive
• If one feature is picked, the other must be picked
Copyright 2005 H. Gomaa
SPL-29
Feature Modeling with UML
• Derive features from use cases and variation points
– Concentrate on modeling variability
• Use static modeling meta-class notation
– Classes depict features and feature groups
• Features are categorized using UML stereotypes
– <<common feature>>
– <<optional feature>>
– <<alternative feature>>
– <<default feature>>
– <<parameterized feature>>
• Model Feature Dependencies and Feature Relationships
Copyright 2005 H. Gomaa
SPL-30
15
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
Feature Notation
• Uses extension mechanisms of UML
– Stereotypes, tagged values, constraints
• «common feature» Feature Name,
– «common feature» Factory Kernel
• « optional feature» Feature Name {prerequisite = P}
– «optional feature» Light, «optional feature» Beeper
• «alternative feature» Feature Name {prerequisite = P}
– «alternative feature» French, «alternative feature» Spanish
• «default feature» Feature Name {prerequisite = P}
– «default feature» English
• « parameterized feature» Feature Name
– «parameterized feature» ATM Password Length
{type = integer, permitted value = 4..8, default value = 4}
Copyright 2005 H. Gomaa
SPL-31
Feature Notation
• «zero-or-one-of feature group» Feature Group Name
{Alternative = A1…An, Prerequisite = P}
– «zero-or-one-of feature group» Roof Rack {alternative
= Basic Rack, Ski Rack, Bicycle Rack}
• «exactly-one-of feature group» Feature Group Name
{default = D, alternative = A1…An, prerequisite = P}
– «exactly-one-of feature group» Display Unit {default =
One-line Display, alternative = Multi-line Display}
• «at-least-one-of feature group» Feature Group Name
{default = D, feature = O1, …, On, prerequisite = P}
– «at-least-one-of feature group» Hotel Reservations
{default = Single Booking Reservations, feature =
Block Tourist Reservations, Block Conference
Reservations}
Copyright 2005 H. Gomaa
SPL-32
16
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
Figure 5.8 Features and Feature Groups in UML
«at-least-one-of
feature group»
Hotel
Reservations
«default feature»
Single Booking
Reservations
«optional
feature»
Block Tourist
Reservations
«optional feature»
Block Conference
Reservations
«exactly-one-of
feature group»
Display Unit
«zero-or-one-of
feature group»
Roof Rack
{mutually exclusive feature}
{mutually exclusive feature}
«alternative
feature»
Basic Rack
«alternative
feature»
Ski Rack
«alternative
feature»
Bicycle Rack
«default
feature»
One-line
Display
«alternative
feature»
Multi-line
Display
Copyright 2005 H. Gomaa
SPL-33
Use Cases and Features in Software Product Lines
• Use Cases
– Define functional requirements of system or SPL
• Features
– Identify reusable requirements
• Use cases
– Basis to determine features in Software Product Lines
• Functional feature modeled as
– One or more use cases reused together
• Feature modeled as use case or use case package
• Use Case Variation Point as feature
– Optional functional requirement within a use case
– Alternative functional requirement within a use case
• Feature / use case dependency
– Can use tabular representation
Copyright 2005 H. Gomaa
SPL-34
17
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
Microwave Oven Feature Model
Copyright 2005 H. Gomaa
SPL-35
Table 5.1 Feature/use case relationships: microwave oven SPL
Feature Name
Feature
Category
Use Case Name
Use Case Category/
Variation Point (vp)
Variation Point
Name
Microwave Oven Kernel
common
Cook Food
kernel
Light
optional
Cook Food
vp
Turntable
optional
Cook Food
vp
Turntable
Beeper
optional
Cook Food
vp
Beeper
Minute Plus
optional
Cook Food
vp
Minute Plus
One-line Display
default
Cook Food
vp
Display Unit
Multi-line Display
alternative
Cook Food
vp
Display Unit
English
default
Cook Food
vp
Display Language
Light
French
alternative
Cook Food
vp
Display Language
Spanish
alternative
Cook Food
vp
Display Language
German
alternative
Cook Food
vp
Display Language
Italian
alternative
Cook Food
vp
Display Language
Boolean Weight
default
Cook Food
vp
Weight Sensor
Analog Weight
alternative
Cook Food
vp
Weight Sensor
One-level Heating
default
Cook Food
vp
Heating Element
Multi-level Heating
alternative
Cook Food
vp
Heating Element
Power Level
optional
Cook Food
vp
Power Level
TOD Clock
optional
Set Time of Day
Display Time of Day
optional
optional
12/24 Hour Clock
parameterized
Set Time of Day
Display Time of Day
vp
optional
Cook Food with Recipe
optional
Recipe
Copyright 2005 H. Gomaa
12/24 Hour Clock
SPL-36
18
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
Product Line Engineering
- Analysis Modeling
Copyright 2005 H. Gomaa
SPL-37
Analysis Modeling
What should SPL Design Method provide?
• For product lines
– Support variability
• Static Modeling
• Dynamic Modeling
Copyright 2005 H. Gomaa
SPL-38
19
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
Static Modeling for Software Product Lines
•
•
•
•
Static Model
– Define structural relationships between classes
– Depict classes and their relationships on class diagrams
Static Modeling for software product lines
Depict class categorization using UML stereotypes
– Stereotype defines a new building block that is derived from an
existing UML modeling element but is tailored to the modeler’s
problem
– Depicted using guillemets
• «entity», «interface», «control»
UML 1.4 upwards supports multiple stereotypes for class
– Use UML stereotypes to depict reuse category
– Use UML stereotypes to depict application role category
Copyright 2005 H. Gomaa
SPL-39
Static Modeling for Single Systems
• UML 1.4 upwards supports multiple
stereotypes for a modeling element
• Single systems (COMET)
– Categorize each class by
application role using stereotype
– «control», «entity», «interface»
Copyright 2005 H. Gomaa
SPL-40
20
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
Static Modeling for
Software Product Lines
•
•
UML 1.4 upwards supports multiple
stereotypes for a modeling element
Single systems
– Categorize each class by application role
using stereotype
– «control», «entity», «interface»
• Software Product Lines (PLUS)
– Second UML stereotype depicts
reuse category
– «kernel», «optional», «variant»
Copyright 2005 H. Gomaa
SPL-41
Software Product Line Context Model
• Defines boundary between software product line and
external environment
– Depicted on UML product line context class diagram
• Software product line system
– Consider as one aggregate class
• Application role categories of external classes
– «external I/O device», «external user», «external
system», «external timer»
• Reuse categories of external classes
• Develop using:
– Kernel First Approach or
– View Integration Approach
Copyright 2005 H. Gomaa
SPL-42
21
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
Microwave Oven product line
Kernel System context class diagram
Copyright 2005 H. Gomaa
SPL-43
Figure 6.6 Microwave Oven product line context
class diagram
Copyright 2005 H. Gomaa
SPL-44
22
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
Dynamic Interaction Modeling for Software Product Lines
• Object interaction model
– Defines how objects participate in use cases
– Use communication (collaboration) diagrams or
sequence diagrams
• Software Product Line Interaction model
– Determine objects that participate in each use case
– Determine sequence of messages sent between objects
– Develop at least 1 interaction diagram for each use case
• Kernel communication diagrams
• Optional communication diagrams
• Alternative communication diagrams
Copyright 2005 H. Gomaa
SPL-45
Dynamic Analysis
for Software Product Lines
• Kernel First Approach
– Collaboration diagrams for kernel system are similar to
collaboration diagrams for single system
– Only kernel objects participate in kernel collaboration
diagrams
– Kernel system may or may not be a member of product
line
• Software Product Line Evolution
– Start with kernel collaboration diagrams
– Consider optional and alternative collaboration
diagrams
Copyright 2005 H. Gomaa
SPL-46
23
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
Communication diagram for Cook Food use case
«external input device»
: Keypad
«product line system»
: MicrowaveOvenSystem
«external timer»
: Clock
8: Timer Event
6: Start Key Input
«input device interface»
: KeypadInterface
6.1: Start
«state dependent control»
: MicrowaveOvenControl
8.4 : Stop Cooking
6.3: Start Cooking Output
8.5 : Stop Cooking Output
«external output device»
: One-levelHeatingElement
«timer»
: OvenTimer
8.2:
Finished
«entity»
: OvenData
6.2: Start Cooking
«output device interface»
: One-levelHeatingElement
Interface
8.1:
Decrement
Cooking
Time
«output device
interface»
: One-lineDisplay
Interface
6.2a: Start Timer
8.3: Timer
Expired
8.3a: Display
End prompt
8.3a.3: End
Prompt
«external output
device»
: One-lineDisplay
Copyright 2005 H. Gomaa
SPL-47
Statechart for Microwave Oven Control
• Incoming message to object-> input event on statechart
• Output event on statechart -> outgoing message from object
Copyright 2005 H. Gomaa
SPL-48
24
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
Communication diagram for Cook Food use case
«external input device»
: Keypad
«product line system»
: MicrowaveOvenSystem
«external timer»
: Clock
8: Timer Event
6: Start Key Input
«input device interface»
: KeypadInterface
6.1: Start
«state dependent control»
: MicrowaveOvenControl
8.2:
Finished
«entity»
: OvenData
6.2: Start Cooking
8.4 : Stop Cooking
«output device
interface»
: One-lineDisplay
Interface
«output device interface»
: One-levelHeatingElement
Interface
«timer»
: OvenTimer
8.1:
Decrement
Cooking
Time
6.2a: Start Timer
8.3: Timer
Expired
8.3a: Display
End prompt
8.3a.3: End
Prompt
6.3: Start Cooking Output
8.5 : Stop Cooking Output
«external output
device»
: One-lineDisplay
«external output device»
: One-levelHeatingElement
Copyright 2005 H. Gomaa
SPL-49
Communication diagram for Cook Food use case
«external input device»
: Keypad
«product line system»
: MicrowaveOvenSystem
«external timer»
: Clock
8: Timer Event
6: Start Key Input
«input device interface»
: KeypadInterface
6.1: Start
«state dependent control»
: MicrowaveOvenControl
6.2a: Start Timer
8.4 : Stop Cooking
6.3: Start Cooking Output
8.5 : Stop Cooking Output
«external output device»
: One-levelHeatingElement
8.2:
Finished
«entity»
: OvenData
6.2: Start Cooking
«output device interface»
: One-levelHeatingElement
Interface
«timer»
: OvenTimer
8.1:
Decrement
Cooking
Time
«output device
interface»
: One-lineDisplay
Interface
8.3: Timer
Expired
8.3a: Display
End prompt
8.3a.3: End
Prompt
«external output
device»
: One-lineDisplay
Copyright 2005 H. Gomaa
SPL-50
25
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
Statechart for Microwave Oven Control
• Incoming message to object-> input event on statechart
• Output event on statechart -> outgoing message from object
Copyright 2005 H. Gomaa
SPL-51
Communication diagram for Cook Food use case
«external input device»
: Keypad
«product line system»
: MicrowaveOvenSystem
«external timer»
: Clock
8: Timer Event
6: Start Key Input
«input device interface»
: KeypadInterface
6.1: Start
«state dependent control»
: MicrowaveOvenControl
6.3: Start Cooking Output
8.5 : Stop Cooking Output
«external output device»
: One-levelHeatingElement
«timer»
: OvenTimer
8.2:
Finished
«entity»
: OvenData
6.2: Start Cooking
8.4 : Stop Cooking
«output device interface»
: One-levelHeatingElement
Interface
8.1:
Decrement
Cooking
Time
«output device
interface»
: One-lineDisplay
Interface
6.2a: Start Timer
8.3: Timer
Expired
8.3a: Display
End prompt
8.3a.3: End
Prompt
«external output
device»
: One-lineDisplay
Copyright 2005 H. Gomaa
SPL-52
26
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
Figure 7.6 Communication diagram for kernel use case: Cook Food
«external input device»
: DoorSensor
«external input device»
: BooleanWeightSensor
1,9: Door Opened Input
3:Door Closed Input
«product line system»
: MicrowaveOvenSystem
«external input device»
: Keypad
4: Cooking Time Key
Input
5*: Numeric Key Input
6: Start Key Input
2,10: Weight
Input
«input device interface»
: BooleanWeightSensor
Interface
«input device interface»
: DoorSensorInterface
7*,8: Timer Event
«input device interface»
: KeypadInterface
«timer»
: OvenTimer
7.1,8.1:
4.1: Cooking Time Selected Decrement
5.1: Cooking Time Entered Cooking
Time
6.1: Start
2.1 : Item Placed
10.1 : Item
Removed
1.1,9.1: Door
Opened
3.1: Door Closed
«external timer»
: Clock
7.2: Time left
8.2: Finished
5.2a: Update
Cooking
Time
«state dependent control»
: MicrowaveOvenControl
6.2: Start Cooking
8.4 : Stop Cooking
«entity»
: OvenData
4.2: Prompt for Time
5.2: Display Cooking Time
8.3: Timer Expired
7.3: Update Cooking time Display
8.3a: Display End Prompt
«output device
interface»
: One-lineDisplay
Interface
«output device interface»
: One-levelHeatingElement
Interface
6.2a: Start Timer
4.3,8.3a.1: Read
«entity»
: EnglishDisplay
Prompts
4.4,8.3a.2:
Prompt
6.3: Start Cooking Output
8.5 : Stop Cooking
Output
Copyright 2005 H. Gomaa
4.5: Time Prompt
5.3,7.4: Display Time
8.3a.3: End Prompt
«external output device»
: One-lineDisplay
«external output device»
: One-levelHeating
Element
SPL-53
Figure 7.12 Communication Diagram for optional
TOD feature
«external input device»
: Keypad
«product line system»
: MicrowaveOvenSystem
«external timer»
: Clock
C1: TOD Clock Key Input
C2*: Numeric Key Input
C3: Start Key Input
T1*: Timer Event
«timer»
: TODTimer
«input device interface»
: KeypadInterface
C1.1: TOD Clock Selected
C2.1: Time Entered
C3.1: Start
«state dependent control»
: MicrowaveOvenControl
T1.1: Increment
TOD Clock
Time
T1.2:
TOD
C2.2a: Update
TOD
C1.2b: Clear TOD
«entity»
: OvenData
C1.2a Stop TOD
C1.2: Prompt For
TOD
C2.2: Display TOD
C3.2: Start TOD
Timer
«output device
interface»
: Multi-lineDisplay
Interface
T1.3: Update TOD Display
C1.3: Read
C1.4: Prompt
C1.5: Enter TOD Prompt
C2.3,T1.4: Display TOD
«entity»
: EnglishDisplay
Prompts
«external output device»
: Multi-lineDisplay
Copyright 2005 H. Gomaa
SPL-54
27
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
State Machine Models for SPLs
• Design statechart for each state dependent class
• Model state machine variability
– Inherited vs Parameterized State Machines
• Inherited State Machine
– Different statechart for each alternative or optional feature
• Disadvantage:
– Each feature & feature combination needs an inherited state
machine
– Leads to combinatorial explosion of inherited state
machines
• Often better to design parameterized state machine
Copyright 2005 H. Gomaa
SPL-55
Parameterized State Machine Models
• Design one state machine with states, transitions, events,
actions, corresponding to all features
• Feature dependent transition
– Use feature condition as guard on transition
• Event [Feature Condition]
– Feature condition is
• True if feature Selected
• False if feature not selected
• E.g., Minute Pressed [minuteplus]
Copyright 2005 H. Gomaa
SPL-56
28
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
Parameterized Statechart for Microwave Oven Control
(all features)
Feature dependent transition: Minute Pressed [minuteplus]
Copyright 2005 H. Gomaa
SPL-57
Parameterized State Machine Models
• Feature dependent action
• Action is only executed if Feature Condition is True
– Action [Feature Condition]
• Switch On [light], Switch Off [light]
Copyright 2005 H. Gomaa
SPL-58
29
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
Parameterized Statechart for Microwave Oven Control
(all features)
Feature dependent actions: [light], [beeper]
Copyright 2005 H. Gomaa
SPL-59
Parameterized State Machine Models
• Feature dependent state identified by UML constraint
• State can only be entered if Feature is selected
– {feature = recipe} Recipe State
• Transition into state is guarded
Copyright 2005 H. Gomaa
SPL-60
30
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
Parameterized Statechart for Microwave Oven Control
(all features)
Feature dependent state (Recipe state)
Copyright 2005 H. Gomaa
SPL-61
Figure 8.1 Statechart for Microwave Oven Control (kernel functionality)
1.1: Door Opened
Door Shut
Door Open
Door Closed
2.1: Item Placed
Cancel/Cancel
Timer
10.1: Item Removed
Door Closed [Time Remaining]
Door Open
With Item
Door Opened/
Stop Timer
3.1: Door Closed [Zero Time]
Door Opened
9.1: Door Opened
Cooking
8.3: Timer Expired
entry/6.2: Start Cooking
Door Shut
With Item
Cancel/
Stop Timer
exit/8.4: Stop Cooking
6.1: Start/
6.2a: Start Timer
5.1: Cooking Time Entered/
5.2: Display Cooking Time,
5.2a: Update Cooking Time
Cancel/
Cancel Timer
Ready To Cook
Copyright 2005 H. Gomaa
Cooking Time Entered/ Display
Cooking Time,
Update Cooking Time
SPL-62
31
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
Figure 8.12 Parameterized Statechart for Microwave Oven Control (all features)
Item Removed/
Cancel Recipe,
Display Recipe
Cancelled
1.1: Door Opened / 1.2: Switch On[light]
Door Shut
Door Open
Door Closed / Switch Off [light]
Cancel/
Cancel Timer
Door Closed [Time Remaining]/
Switch Off [light]
Door Open
With Item
Door Opened/
Stop Timer
Door Opened/
Switch On [light]
3.1: Door Closed [Zero Time]/
3.2: Switch Off [light]
Cooking
9.1: Door Opened/
9.2: Switch On [light]
8.3: Timer Expired/
8.4d: Clear Power Level [power],8.4b:
Switch Off [light]
6.11: Minute
Plus[minuteplus]/
6.12: Add Minute
entry/
4M.2a,6.2: Start Cooking,
6.2c: Start Turning [turn],
6.2b: Switch On [light],
exit/
8.4: Stop Cooking,
8.4a: Beep [beeper],
8.4c: Stop Turning [turn]
Cancel/
Stop Timer,
Switch Off [light]
R4.1: Recipe Entered
[recipe]
Door Shut
With Item
4M.1: Minute Plus[minuteplus]/
4M.2: Start Minute
Cancel
{feature =
recipe}
Recipe
R8.3: Timer
Expired
5.1: Cooking Time Entered/
5.2: Display Cooking,
5.2a: Update Cooking Time
6.1: Start/
6.2a: Start Timer
Copyright 2005 H. Gomaa
10.1: Item Removed
2.1: Item Placed
Cancel/
Cancel Timer
Ready To Cook
Cooking Time Entered/ Display
Cooking Time,
Update Cooking Time
SPL-63
Feature Based Impact Analysis
• Kernel First Approach
– Develop kernel communication diagrams
• Product Line evolution approach
– Consider impact of optional and alternative features on
kernel communication diagrams
• Analyze impact of each feature on kernel communication
diagrams
– Consider optional objects that need to be added
– Consider replacement of default objects with variant
objects
– Consider impact on existing kernel objects that
communicate with optional / variant objects
Copyright 2005 H. Gomaa
SPL-64
32
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
Feature Based Impact Analysis
• Kernel First Approach
– Develop kernel interaction diagrams to realize kernel
use cases
• Product Line evolution approach
– Consider impact of optional and alternative features on
kernel
• Analyze impact of each feature
– Optional object(s) can be added
– Variant object can replace default object
– Determine impact on existing kernel objects
• Communicate with optional / variant objects
Copyright 2005 H. Gomaa
SPL-65
Communication Diagram For Microwave Oven SPL
- Impact Of Beeper and Light Features
• Optional objects added
• Impact on kernel control object
•Feature dependent messages
Copyright 2005 H. Gomaa
SPL-66
33
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
Variation Points in Static Modeling
• A variation point identifies a location at which change will
occur in a software product line
• The variation point also identifies the mechanism for a
reuser to make the change
• Variation point mechanisms
– Abstract classes and inheritance
• Abstract superclass
• Specialized differently for various members of SPL
– Parameterization
• Configuration Parameters
• Different values for different members of SPL
Copyright 2005 H. Gomaa
SPL-67
Abstract Classes in Software Product Lines
• Abstract Class
– Defines common interface for subclasses
– Defers implementation of operation(s) to subclasses
– Captures common properties for all related classes
– Often represents kernel class
– Could also be optional
• Subclasses are variant classes
– Inherit common properties from abstract superclass
– Extend with variant properties
• New attributes
• New operations
• Alternative implementations of abstract operations
Copyright 2005 H. Gomaa
SPL-68
34
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
Figure 9.1 Example of abstract superclass and subclasses
«kernel-abstract-vp»
«entity»
Account
# accountNumber : Integer
# balance : Real = 0
+ open (accountNumber : Integer)
# credit (amount : Real)
# debit (amount : Real)
+ readBalance () : Real
+ close ()
«default»
«entity»
CheckingAccount
- lastDepositAmount : Real = 0
+ credit (amount : Real)
+ debit (amount : Real)
+ readLastDepositAmount() : Real
«variant»
«entity»
SavingsAccount
- cumulativeInterest : Real = 0
- debitCount : Integer = 0
- maxFreeDebits : Integer = 3
- bankCharge : Real = 2.50
+ credit (amount : Real)
+ debit (amount : Real)
+ clearDebitCount()
+ addInterest (interestRate : Real)
+ readCumulativeInterest () : Real
Copyright 2005 H. Gomaa
SPL-69
Variant vs. Parameterized Classes
• Abstract superclass and variant subclasses
– Advantage
• Isolates each variation in one variant class
• A variant class is impacted by only one feature
– Disadvantage
• Could lead to combinatorial explosion of variant classes
• Parameterized Classes
– Advantage
• One parameterized class instead of many variant classes
– Disadvantage
• A parameterized class can be impacted by more than one
feature
Copyright 2005 H. Gomaa
SPL-70
35
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
Figure 9.2 Example of parameterized class
«kernel-param-vp»
«entity»
OvenData
- cookingTime : Integer = 0 {range >=0}
- selectedPowerLevel : powerType = High {Range = High, Medium, Low} {feature = Power Level}
- itemWeight : Real = 0.0 {range > 0} {feature = Analog Weight}
- selectedRecipe : Integer = 0 {range > 0}{feature = Recipe}
- TODvalue : Time = 12:00 {feature = TOD Clock}
- TODmaxHour : Time = 12:00 {permitted value = 12:00, 24:00} {feature = TOD Clock}
Copyright 2005 H. Gomaa
SPL-71
Feature / Class Dependencies
• For each optional or alternative feature, define
– Optional and/or variant classes required to support feature
– If feature has prerequisite features
• Classes in feature may use classes in prerequisite features
– Features determine which classes can co-exist in same
system
• Some variants are mutually exclusive
– Used by different members of product line
– E.g., High Volume Workstation Controller, Flexible
Workstation Controller, Monitoring Workstation Controller
• Some variants co-exist in same system
– E.g., High Volume Workstation Controller, Receiving
Workstation Controller, Shipping Workstation Controller
Copyright 2005 H. Gomaa
SPL-72
36
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
Table 9.1 Feature/class dependencies: microwave oven SPL
Feature Name
Copyright 2005 H. Gomaa
Feature
Category
Class Name
Class Reuse
Category
Class Parameter
Microwave Oven
Kernel
common
Door Sensor Interface
Weight Sensor Interface
Keypad Interface
Heating Element Interface
Display Interface
Microwave Oven Control
Oven Timer
Oven Data
Display Prompts
kernel
kernel-abstract-vp
kernel-param-vp
kernel-abstract-vp
kernel-abstract-vp
kernel-param-vp
kernel-param-vp
kernel-param-vp
kernel-abstract-vp
Light
optional
Lamp Interface
Microwave Oven Control
optional
kernel-param-vp
light : Boolean
Turntable
optional
Turntable Interface
Microwave Oven Control
optional
kernel-param-vp
turntable : Boolean
Beeper
optional
Beeper Interface
Microwave Oven Control
optional
kernel-param-vp
beeper : Boolean
Minute Plus
optional
Keypad Interface
Microwave Oven Control
Oven Timer
kernel-param-vp
kernel-param-vp
kernel-param-vp
minuteplus : Boolean
minuteplus : Boolean
minuteplus : Boolean
One-line Display
default
One-line Display Interface
default
Multi-line Display
alternative
Multi-line Display
Interface
variant
English
default
English Display Prompts
default
French
alternative
French Display Prompts
variant
Spanish
alternative
Spanish Display Prompts
variant
German
alternative
German Display Prompts
variant
Italian
alternative
Italian Display Prompts
variant
SPL-73
Product Line Engineering
– Design Modeling
Copyright 2005 H. Gomaa
SPL-74
37
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
Component-based Distributed Software
Architecture
• Executes on multiple nodes in distributed configuration
– Consists of distributed components
• Distributed component
– Well-defined provided and required interfaces
– Concurrent object
– Logical unit of distribution and deployment
– Communicates with other components using messages
– Structure
• Composite object consisting of other objects
• Simple object
– Capable of being reused
Copyright 2005 H. Gomaa
SPL-75
Modeling Components in UML 2.0
• Components
– Modeled as UML 2.0 structured classes
– Depicted on UML 2.0 composite structure diagrams
• Components
– Communicate with each other through ports
• Port
– Consists of provided and/or required interfaces
• Connector
– Joins required port of one component to provided port of
another component
Copyright 2005 H. Gomaa
SPL-76
38
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
Design of individual components
Copyright 2005 H. Gomaa
SPL-77
Design of “plug compatible” components
• Connector
• Joins required port of
one component to
provided port of another
component
• Microwave Control
can be connected to
either version of
Microwave Display
– Less variability
Copyright 2005 H. Gomaa
SPL-78
39
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
Design of Composite Component
Copyright 2005 H. Gomaa
SPL-79
Software Design and Architectural Patterns
• Design Patterns
– Small group of collaborating objects
– Gang of Four (Gamma, Helms, Johnson, Vlissides)
• Software Architectural Patterns
– Recurring architectures used in various software
applications
– Buschmann, etc. at Siemens
• Architectural Structure Patterns
– Address structure of major subsystems of system or PL
• Architectural Communication Patterns
– Reusable interaction sequences between components
Copyright 2005 H. Gomaa
SPL-80
40
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
Architectural Structure Patterns
for Software Product Lines
• Layered patterns very important in SPLs
– Layers of Abstraction
– Kernel
• Client/Server patterns
– Basic Client/Server
– Client/Broker/Server
– Client/Agent/Server
• Control Patterns very important in RT Design
– Centralized Control
– Distributed Control
– Hierarchical Control
Copyright 2005 H. Gomaa
SPL-81
Architectural Structure Patterns
for Software Product Lines
• Layers of Abstraction
– Structure product line into hierarchical levels
– Each layer provides services for higher layers
• Layers of Abstraction in Product Lines
– Allows use of subsets and extensions
– Lower layers do not depend on upper layers
• Kernel components at lowest layer
– Higher layers depend on lower layers
• Optional and variant components at higher layers
• Kernel Pattern in Software Product Lines
– Kernel of product line is at lowest layer of hierarchy
– Optional and variant components at higher layers
depend on kernel components in kernel layer
Copyright 2005 H. Gomaa
SPL-82
41
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
Figure 10.1 Example of layers of abstraction pattern
- ISO open systems interconnection reference model
Layer 7
Application Layer
Layer 6
Presentation Layer
Layer 5
Session Layer
Layer 4
Transport Layer
Layer 3
Network Layer
Layer 2
Data Link Layer
Layer 1
Physical Layer
Copyright 2005 H. Gomaa
SPL-83
Centralized Control Pattern
E.g., Microwave Oven Control
«kernel»
«input component»
DoorComponent
• Centralized Control Pattern
– One control component
• Executes statechart
– Receives sensor input
from input components
– Controls external
environment via output
components
«variant»
«input component»
WeightComponent
«kernel-param-vp»
«input component»
KeypadComponent
«kernel»
«control component»
MicrowaveControl
«variant»
«output component»
HeatingElementComponent
Copyright 2005 H. Gomaa
«variant»
«output
component»
MicrowaveDisplay
SPL-84
42
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
Architectural Communication Patterns for Software
Product Lines
• Peer-to-Peer Communication Patterns
– Asynchronous communication
– Bi-directional asynchronous communication
• Client/Server Communication Patterns
– Synchronous communication with reply
– Synchronous communication with Callback
• Very important for evolutionary design:
• Broker Communication Patterns
– Broker forwarding
– Broker handle
– Discovery
• Group Communication Patterns
– Broadcast
– Subscription/notification (Multicast)
Copyright 2005 H. Gomaa
SPL-85
Software Architecture for Microwave Oven - asynchronous
communication Pattern
Copyright 2005 H. Gomaa
SPL-86
43
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
Evolutionary Process Model
for Software Product Lines
Product Line
Requirements
Product Line
Engineering
Product Line Requirements and
Analysis Models,
Product Line Architecture,
Reusable Components
Product
Line
Reuse
Library
Application
Requirements
Application
Engineering
Application
Unsatisfied Requirements, Errors, Adaptations
Copyright 2005 H. Gomaa
SPL-87
Software Application Engineering
• Software Application
– Member of software product line
• Software Application Engineering
– Derive application architecture from SPL architecture
• Select application features subject to
– Feature dependencies and relationships
• Derive software application architecture
– Kernel components always selected
– Optional and variant components correspond to features
selected
Copyright 2005 H. Gomaa
SPL-88
44
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
Microwave Oven Application
Feature Model
«optional
feature»
MinutePlus
requires
requires
«common
feature»
Microwave
Kernel
requires
«optional
feature»
Light
«exactly-one-of
feature group»
DisplayUnit
«alternative
feature»
Multi-lineDisplay
«optional
feature»
Turntable
«optional
feature»
Beeper
requires
requires
requires
«default
feature»
One-lineDisplay
«exactly-one-of
feature group»
HeatingElement
«default feature»
OnelevelHeating
«alternative
feature»
Multi-levelHeating
mutually
includes
«optional
feature»
TODClock
Copyright 2005 H. Gomaa
SPL-89
Figure 12.7 Use Case model for Microwave Application
«kernel»
Cook Food
«optional»
Set Time of Day
Timer
User
«optional»
Update Time of Day
«optional»
Cook Food with Recipe
Copyright 2005 H. Gomaa
SPL-90
45
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
Table 12.1 Microwave oven application:
feature/use case dependencies
Feature Name
Feature
Category
Use Case Name
Use Case
Category/
Variation
Point (vp)
Microwave Oven Kernel
common
Cook Food
kernel
Light
optional
Cook Food
vp
Beeper
optional
Cook Food
vp
Beeper
Multi-line Display
alternative
Cook Food
vp
Display Unit
French
alternative
Cook Food
vp
Display Language
Boolean Weight
default
Cook Food
vp
Weight Sensor
One-level Heating
default
Cook Food
vp
Heating Element
TOD Clock
optional
Set Time of Day
Display Time of Day
optional
optional
12/24 Hour Clock
parameterized
Set Time of Day
Display Time of Day
optional
Variation Point
Light
12/24 Hour Clock
Copyright 2005 H. Gomaa
SPL-91
Figure 12.8 Microwave Oven Application context class
diagram
«kernel»
«external input device»
1
1
Outputs
To
DoorSensor
Inputs
To
1
Inputs
To
1
BooleanWeightSensor
1
Inputs
To
«kernel»
«external input device»
1
«product line system»
1
MicrowaveOven
Application
1
0..1
«variant»
«external output device»
«optional»
«external output device»
Outputs
To
1
Clock
1
Outputs
To
1
Turntable
Outputs
To
1
1
«kernel»
«external timer»
Outputs
To
Multi-lineDisplay
1
1
Awakens
Keypad
Beeper
1
1
«variant»
«external input device»
«optional»
«external output device»
«variant»
«external output device»
OneLevelHeating
Element
«optional»
«external output device»
Copyright 2005 H. Gomaa
Lamp
SPL-92
46
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
Table 12.2 Microwave oven application: feature/class dependencies
Feature Name
Feature
Category
Class Name
Class Reuse
Category
Class Parameter
Microwave Oven
Kernel
common
Door Sensor Interface
Weight Sensor Interface
Keypad Interface
Heating Element Interface
Display Interface
Microwave Oven Control
Oven Timer
Oven Data
Display Prompts
kernel
kernel-abstract-vp
kernel-param-vp
kernel-abstract-vp
kernel-abstract-vp
kernel-param-vp
kernel-param-vp
kernel-param-vp
kernel-abstract-vp
Light
optional
Lamp Interface
Microwave Oven Control
optional
kernel-param-vp
light : Boolean
Beeper
optional
Beeper Interface
Microwave Oven Control
optional
kernel-param-vp
beeper : Boolean
Multi-line Display
alternative
Multi-line Display Interface
variant
French
alternative
French Display Prompts
variant
Boolean Weight
default
Boolean Weight Sensor
Interface
default
One-level Heating
default
One-level Heating Element
Interface
default
TOD Clock
optional
TOD Timer
Keypad Interface
Microwave Oven Control
Oven Data
optional
kernel-param-vp
kernel-param-vp
kernel-param-vp
TODClock : Boolean
TODClock : Boolean
TODvalue : Real
Oven Data
kernel-param-vp
TODmaxHour : Integer
12/24 Hour Clock
Parameterized
Copyright 2005 H. Gomaa
SPL-93
Software Architecture for Microwave Oven Application - Component
Structuring
Copyright 2005 H. Gomaa
SPL-94
47
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
Figure 12.14 Software architecture for Microwave Oven
Application - message communication
«kernel»
«external timer»
: Clock
Timer
Event
«kernel»
«external input device»
: DoorSensor
«kernel»
«external input device»
: Keypad
«variant»
«external input device»
: BooleanWeightSensor
Weight Input
Door Input
Keypad Input
«product line system»
: MicrowaveOvenSystem
«kernel»
«input component»
: DoorComponent
sendControlRequest (doorEvent)
«default»
«input component»
: BooleanWeightComponent
«kernel-param-vp»
«input component»
: KeypadComponent
sendControlRequest (weightEvent)
sendControlRequest (keypadEvent)
«kernel»
«control component»
: MicrowaveControl
startCooking (level)
stopCooking ()
«default»
«output component»
: One-levelHeatingElementComponent
Heating Element Output
Copyright 2005 H. Gomaa
«variant»
«external output device»
: One-levelHeatingElement
displayPrompt (promptId)
displayTime (time)
displayTOD (TOD)
beep ()
switchOn ()
switchOff ()
«optional»
«output component»
: LampComponent
Lamp Output
«optional»
«external output device»
: Lamp
«optional»
«output component»
: BeeperComponent
Beeper
Output
«optional»
«external output device»
: Beeper
«variant»
«output component»
: Multi-lineMicrowaveDisplay
Display Output
«variant»
«external output device»
: Multi-lineDisplay
SPL-95
Microwave Oven Application architecture
Copyright 2005 H. Gomaa
SPL-96
48
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.
Figure 12.16 Distributed Application Configuration
DoorComponent
{1 node}
BooleanWeightComponent
{1 node}
KeypadComponent
{1 node}
«high speed bus»
MicrowaveControl
{1 node}
One-levelHeatingElementComponent
{1 node}
LampComponent
{1 node}
BeeperComponent
{1 node}
Multi-lineMicrowaveDisplay
{1 node}
Copyright 2005 H. Gomaa
SPL-97
Review
•
•
•
Software Product Line
– Family of products / systems
– Some common components, some optional, some variant
Designing Software Product Lines
– Object Oriented Analysis and Design of Software Product Lines
– Emphasis on modeling commonality and variability in software
product lines
Unified Modeling Language (UML)
– Standardized notation for object-oriented development
– UML notation extended to model software product lines
– H. Gomaa, “Designing Software Product Lines with UML: From
Use Cases to Pattern-based Software Architectures”, Addison
Wesley Object Technology Series, July 2004
Copyright 2005 H. Gomaa
SPL-98
49
Authorized licensed use limited to: IEEE Xplore. Downloaded on April 26, 2009 at 19:41 from IEEE Xplore. Restrictions apply.