FEATURE MODELING IN PRODUCT LINE ENGINEERING with SPARX EA

In my previous blog I discussed Use Case Modeling in Product Line Engineering. This blog contains an introduction to PLE feature modeling. This is only a brief introduction and as I said in my first blog, I highly recommend buying the book by Hassan Gomaa listed in the references.

Sparx EA Template
I have built a template in Sparx EA that I re-use on each PLE project also. It has all the stereotypes the three blogs will discuss built into it. I hope you find it useful. You can get it here.

References
Designing Software Product Lines with UML: From Use Cases to Pattern-based Software Architectures By Hassan Gomaa. ISBN: 0201775956; Published: Jul 7, 2004; Copyright 2005.

Overview
Use cases for product line engineering are the staring point for the feature modeling and analysis process. The purpose of the use cases are to capture the functional requirements and to get a clear understanding of them. The goal of feature analysis is to enable reuse.

Use cases should be grouped into use case packages. The use case packages will usually map one to one into Feature Packages. According to the author whose stereotypes we are using the packages are called feature groups. When we use the terms use case package and feature packages, we are referring to the same thing. It may not always be true that a use case package maps directly to a feature group, therefore each package must be reviewed and categorized during Feature Analysis. The feature package can include several use cases and those use cases each contain several features, however, one use case may contain several feature packages which contain several features. Use cases and features have a many to many relationship.

General Feature Modeling Guidelines

Features have five categories.





Features Categories
Features are categorized as

Default features
• Coincide with Alternative features. A default feature is the feature implemented if an alternative feature is not selected.

Common features
• Provided by all members of product line

Optional features
• Provided by some members of product line

Alternative features
• Choice of features
• One of the alternatives may be a default

Parameterized feature
• Defines a product line parameter
• Type, permitted values, default value

Feature Groups (Packages)
A feature group is a group of features with a particular constraint on their usage in a product line member








Types of feature groups:

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

How to Describe a Feature
Features will be modeled as well as described in a textual format in the Software Requirements Specification. There are two different industry standard ways to record features and requirements in a textual format. One way is too record the goals of the system, the features of the system, and the system requirements needed to implement the features. The other way, which is the way Gomaa (see references) does it, is to use feature packages and features, where features and requirements mean the same thing. In order to abstract the requirements into groups he uses feature groups, which we will also be doing.

The main goal of this document is to provide guidelines on the modeling the features. Below in the UML Stereotypes section, there are samples descriptions for modeling.

UML Stereotypes

Feature Stereotypes
• «common feature» Feature Name {prerequisite = P} {mutually includes= Feature Name}
Example: «common feature» Factory Kernel
Example: «optional feature» Clock {prerequisite=Multi-line Display}

• « optional feature» Feature Name {prerequisite = P} {mutually includes= Feature Name}
Example: «optional feature» Light, «optional feature» Beeper {mutually includes= Speaker System}

• «alternative feature» Feature Name {prerequisite = P} {mutually includes= Feature Name}
Example: «alternative feature» French, «alternative feature» Spanish

• «default feature» Feature Name {prerequisite = P} {mutually includes= Feature Name}
Example: «default feature» English

• « parameterized feature» Feature Name {type, permitted value, default value}
Example: «parameterized feature» ATM Password Length {type = integer, permitted value = 4..8, default value = 4}

Feature Group Stereotypes

Mutually exclusive features
«zero-or-one-of feature group» Feature Group Name {Alternative = A1...An, Prerequisite = P}
Example: «zero-or-one-of feature group» Roof Rack {alternative = Basic Rack, Ski Rack, Bicycle Rack}

Must select one feature
- «exactly-one-of feature group» Feature Group Name {default = D, alternative = A1...An, prerequisite = P}
Example: «exactly-one-of feature group» Display Unit {default = One-line Display, alternative = Multi-line Display}

Can select one or more features
- «at-least-one-of feature group» Feature Group Name {default = D, feature = O1, ..., On, prerequisite = P}
Example: «at-least-one-of feature group» Hotel Reservations {default =
Single Booking Reservations, feature = Block Tourist Reservations, Block Conference Reservations}

A group of optional features depend on another optional feature
- «zero-or-more-of feature group» Feature Group Name {feature = First Optional Feature Name, ..., Nth Optional Feature Name, prerequisite = Prerequisite Feature Name}
Example: «zero-or-more-of feature group» Automated Drive Control {feature = Cruise Control, Automatic Traction, prerequisite = Automatic Transmission}