Product Line Engineering (PLE) UML Modeling Profile in Sparx Enterprise Architect (EA)
Product Line Engineering is at the heart of Microsoft's Software Factory movement. Although we have benefited greatly from the release of the Mobile Client Software Factory, the Smart Client Software Factory, the Web Client Software Factory, and the Web Service Software Factory, we still do not have any new tools to create our own. I am still defaulting to the UML Profile that has served me well in the past.
I have implemented three PLE processes in the past. Two of the product lines were implemented, one was not. At the one that didn't the company went broke because of other issues, but the product line project was the project that was axed. PLE is a process that takes time and money to pull off. I have been a lot of places that think process just happens. It doesn't, it takes time, money, experience, and management support. The company that dropped the project didn't have a complete understanding of that.
This series of blogs isn't about company's lack of knowledge in what it takes to implement a process. I will save those soapbox rants for another day. This blog is the first in a series of 3. They all deal with PLE UML modeling. On every PLE project I have been on I have used the UML profile Hassan Gomma published in his book Designing Software Product Lines with UML: From Use Cases to Pattern-based Software Architectures.
Each of the blogs will include a section of some of the specifications I re-use on each project. I created my own generic specifications that I then tailor for each new client. Keep in mind I also provide many other templates that might be referred to in the blog. For example the Use Case specification I provide.
The three blog topics are Use Case Modeling, Feature Modeling, and Static Modeling. I recommend that if you find this information useful, you buy the book Designing Software Product Lines with UML: From Use Cases to Pattern-based Software Architectures By Hassan Gomaa. I do not go nearly into the detail he does in the book. He provides a ton of examples that can help with the understanding of the stereotypes. The information I am providing is simply part of a specification I use. If you own the book, or have previous UML experience, you will most likely be able to use the Sparx EA template I provide right off the bat, others will need to buy the book or do a little more research.
Sparx EA Template
I have built a template in Sparx EA that I re-use on each PLE project I do. 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.
Links
Software Engineering Institute Framework for Product Line Practices Site
Software Product Lines Discussion Board
PLEES
Software Product Lines
Suggested Reading
USE CASE MODELING IN PRODUCT LINE ENGINEERING
OverviewUse cases for product line engineering are different than use cases written for single applications. When gathering requirements for single system all the functional requirements are captured by the use cases and all the use cases are implemented in the system. In a product line engineering environment, the use cases for a given instance of the product line are implemented, but that instance may not use all the use cases that are captured during the process for a product line family of systems.
Use cases should be grouped into use case packages. The use case packages will usually map one to one into Feature Packages. This may not always be true; therefore each package must be reviewed and categorized during Feature Analysis. The feature package will usually include several use cases and those use cases each contain several features.
General Use Case Modeling Guidelines
There are three types of use cases that are involved with product lines.
Kernel use cases define use cases required by all members of the family.
Optional use cases define use cases required by some but not all members of the family. This distinction is given by a specific condition associated with optional use cases.
Variant use cases define use cases with different versions which are required by different members of the family.
- To model variation points, the extension points and the extend relationship are used.
UML stereotypes «kernel», «optional», and «variant» are used to distinguish kernel, optional, and variant use cases.
Use Cases should be grouped by packages. The use case packages later become feature packages during the feature modeling process if the context is correct. The use case packages should be shown in a context diagram so their relationships to each other can be visually represented.
How to Describe a Use Case
The use case template has this information in it. It is not included here because it would duplicate the information. If we decide to change the use case template we would also need to change the information here. So we will not be repeating the information here.
The use case template has been modified from a traditional use case template and now reflects a product line use case.
UML Stereotypes
The following stereotypes are used for product line use cases.
«kernel»
Used to show a use case that is required by all members of the product line family.
«optional»
Used when a use case is optional to family members of the product line family.
«variant»
Used to show different versions which are required by different members of the family. A good example of this will be the use cases that represent the UI. Many times they will have common intentions, but they will be implemented slightly different for each product line family.
« mandatory alternative »
Used to show different use cases are available, and only one can be used. This stereotype is usually use at extension points.
«mandatory alternative, optional»
Stereotypes can be combine. This combination indicates that there are several use cases available. This stereotype is usually used at an extension point. If one of the other use cases are selected, the use case with this stereotype can also be included as part of the provided functionality of the extension point.
I have implemented three PLE processes in the past. Two of the product lines were implemented, one was not. At the one that didn't the company went broke because of other issues, but the product line project was the project that was axed. PLE is a process that takes time and money to pull off. I have been a lot of places that think process just happens. It doesn't, it takes time, money, experience, and management support. The company that dropped the project didn't have a complete understanding of that.
This series of blogs isn't about company's lack of knowledge in what it takes to implement a process. I will save those soapbox rants for another day. This blog is the first in a series of 3. They all deal with PLE UML modeling. On every PLE project I have been on I have used the UML profile Hassan Gomma published in his book Designing Software Product Lines with UML: From Use Cases to Pattern-based Software Architectures.
Each of the blogs will include a section of some of the specifications I re-use on each project. I created my own generic specifications that I then tailor for each new client. Keep in mind I also provide many other templates that might be referred to in the blog. For example the Use Case specification I provide.
The three blog topics are Use Case Modeling, Feature Modeling, and Static Modeling. I recommend that if you find this information useful, you buy the book Designing Software Product Lines with UML: From Use Cases to Pattern-based Software Architectures By Hassan Gomaa. I do not go nearly into the detail he does in the book. He provides a ton of examples that can help with the understanding of the stereotypes. The information I am providing is simply part of a specification I use. If you own the book, or have previous UML experience, you will most likely be able to use the Sparx EA template I provide right off the bat, others will need to buy the book or do a little more research.
Sparx EA Template
I have built a template in Sparx EA that I re-use on each PLE project I do. 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.
Links
Software Engineering Institute Framework for Product Line Practices Site
Software Product Lines Discussion Board
PLEES
Software Product Lines
Suggested Reading
USE CASE MODELING IN PRODUCT LINE ENGINEERING
OverviewUse cases for product line engineering are different than use cases written for single applications. When gathering requirements for single system all the functional requirements are captured by the use cases and all the use cases are implemented in the system. In a product line engineering environment, the use cases for a given instance of the product line are implemented, but that instance may not use all the use cases that are captured during the process for a product line family of systems.
Use cases should be grouped into use case packages. The use case packages will usually map one to one into Feature Packages. This may not always be true; therefore each package must be reviewed and categorized during Feature Analysis. The feature package will usually include several use cases and those use cases each contain several features.
General Use Case Modeling Guidelines
There are three types of use cases that are involved with product lines.
Kernel use cases define use cases required by all members of the family.
Optional use cases define use cases required by some but not all members of the family. This distinction is given by a specific condition associated with optional use cases.
Variant use cases define use cases with different versions which are required by different members of the family.
- To model variation points, the extension points and the extend relationship are used.
UML stereotypes «kernel», «optional», and «variant» are used to distinguish kernel, optional, and variant use cases.
Use Cases should be grouped by packages. The use case packages later become feature packages during the feature modeling process if the context is correct. The use case packages should be shown in a context diagram so their relationships to each other can be visually represented.
How to Describe a Use Case
The use case template has this information in it. It is not included here because it would duplicate the information. If we decide to change the use case template we would also need to change the information here. So we will not be repeating the information here.
The use case template has been modified from a traditional use case template and now reflects a product line use case.
UML Stereotypes
The following stereotypes are used for product line use cases.
«kernel»
Used to show a use case that is required by all members of the product line family.
«optional»
Used when a use case is optional to family members of the product line family.
«variant»
Used to show different versions which are required by different members of the family. A good example of this will be the use cases that represent the UI. Many times they will have common intentions, but they will be implemented slightly different for each product line family.
« mandatory alternative »
Used to show different use cases are available, and only one can be used. This stereotype is usually use at extension points.
«mandatory alternative, optional»
Stereotypes can be combine. This combination indicates that there are several use cases available. This stereotype is usually used at an extension point. If one of the other use cases are selected, the use case with this stereotype can also be included as part of the provided functionality of the extension point.
posted by tadanderson at 10:19 AM
0 Comments:
Post a Comment
<< Home