UML STATIC MODELING IN PRODUCT LINE ENGINEERING (PLE) with SPARX EA

In my previous blogs I discussed Use Case Modeling and Feature Modeling in Product Line Engineering. This blog contains an introduction to PLE Static 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 TemplateI 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

As we move into the design of the individual modules we will be defining stereotypes that begin to take on the context of our application's domain. For example we may have stereotypes that build the context for our mobile device's components.

One of the hindrances we are going to have it that in UML 1.4 multiple stereotypes became supported. Sparx EA however does not support them. Product line engineering requires dual stereotypes be applied to classes. One represents its reuse categorization and the other represents its application role. We will be grouping the two stereotypes together and separating them by :: in Sparx EA. For example:

Static Modeling Guidelines

As mentioned above this document will not specify the actual stereotypes that will be used during the design of the product's components/modules until that phase of the project begins. This will be considered a living document that will need to be updated at that time. The application domain will determine the application specific parts of the stereotypes to be used. The following section outlines the Software Product Line Class Categories to be used.

Software Product Line Class Categorization

An abstract or parameterized class can be source of variability. A class that defines a variation point has vp in name of stereotype.

Top Level Product Line Class Categorization
• <> Kernel class

- Provided by every member of the Product Line (SPL)

- Used without change

• <> Optional class

- Provided by some members of the Product Line

- When used, it is used without change

• <> Variant class

- One of a set of similar classes provided by SPL

- Some identical properties, others are different

• <> Default class

- Default class among set of variant SPL classes

Abstract class reuse categories
• <> abstract kernel class

- Provided by every member of the family

- Abstract class provides standard interface for its subclasses

- SPL variability introduced through specialization

• <> abstract optional class

- Provided by some members of the Product Line

- Abstract class provides standard interface for subclasses

Parameterized class reuse categories
• <> parameterized kernel class

- Provided by every member of the family

- Configuration parameters need to be set by SPL member

- SPL variability introduced through parameterization

• <> parameterized optional class

- Provided by some members of the Product Line

- Configuration parameters need to be set by SPL member

• <<>> parameterized variant class

- One of a set of variant classes provided by SPL

- Configuration parameters need to be set by SPL member

• <> parameterized default class

- Default class among set of variant SPL classes

- Configuration parameters need to be set by SPL member

Concrete class reuse categories
• <> concrete kernel class

- Provided by every member of the family

- Class provides a standard interface for its subclasses

- SPL variability introduced through specialization

• <> concrete optional class

- Provided by some members of the Product Line

- Class provides a standard interface for its subclasses

• <<>> concrete variant class

- One of a set of variant classes provided by SPL

- SPL variability introduced through specialization

UML Stereotypes

Static Modeling Stereotypes
These are added as the Elaboration Phase and Construction Phase take place. You will need to define these as the project continues. These will be a result of application domain specific stereotypes that are defined combined with the above Software Product Line Class Categories.