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.

Web Client Software Factory :: Composite Web Application Block

This definitely looks like it is worth checking out. We used the Smart Client Composite UI Application Block (CAB), and it saved us a ton of development time when adding new modules.

There is a ramp up time involved for developers, but we developed our own reusable framework around the CAB. We limited the functional touch points of the CAB from the dozens available to about 10, and provide a builders guide to help the new developers get familiar with the framework. We developed it before the release of the Smart Client Software Factory, so I haven't looked into that much.

Our framework add some features to the CAB like a reporting architecture, we used the ASP.NET Membership API for security, built Exception Handling, Error Handling, and Logging using Enterprise Library 2.0, encapsulated it all in a Service Oriented Architecture, and use Product Line Engineering as the development methodology.

The Web Client Software Factory/Composite Web Application Block looks like it will have a sizable ramp up time involved. The payoff using the CAB was worth the ramp up time, and I will be looking into how we can take advantage of this software factory on our web application projects.

Agile != Ignoring Requirements

Below is a note I recently placed on an architectural context diagram.

"The initial release of the XYZ Application does not take any workflow or application integration into consideration. This was at the request of our client ABC. This context diagram shows the XYZ Application as delivered, without the proper integration and workflow built into it.

Future enhancements will need to build the workflow and the integration into the architecture. Because the client has requested we ignore these aspects of the application architecture upfront, it will be a greater effort and take more time to accomplish than if we would have been allowed to account for them upfront.

It is a misconception to think of this as an agile approach. An agile approach would take into consideration all known requirements and plan releases accordingly. The client requested we ignore the requirements believing this would save time because they believe that is what agile methodologies do. In the long run this approach will greatly increase the complexity of future releases, and therefore increase the effort and time required to deliver them."

Although it is wrong to add features, or plan for features, that 'may' be added in the future, it should be an absolute must to account for all known requirements. They may not all be built into the first few releases, but the first releases are built taking them into account. I have run into this several times now. Someone hears the term agile, they look into it enough to become dangerous, and then start applying it in the above fashion.

They want a first partial release, and they want no thought put into the following releases. Agile development does not ignore known requirements. It does allow for new requirements that were not know at the start of a project and changing requirements, but it absolutely does not call for the ignoring of know requirements.

This particular project will end up costing the client twice the money it would have cost if they would not be demanding that we ignore known requirements.

ASP.NET AJAX 1.0 Released

From the AJAX.NET site:
ASP.NET AJAX is a free framework for quickly creating a new generation of more efficient, more interactive and highly-personalized Web experiences that work across all the most popular browsers.

With ASP.NET AJAX, you can:

• Create next-generation interfaces with reusable AJAX components.
• Enhance existing Web pages using powerful AJAX controls with support for all modern browsers.
• Continue using Visual Studio 2005 to take your ASP.NET 2.0 sites to the next level.
  Access remote services and data directly from the browser without writing a ton of complicated script.
• Enjoy the benefits of a free framework with 24x7 technical support provided by Microsoft.
  
  GET IT HERE

Installer Beware- WSS 3.0 and Office 2007 are Memory Pigs

I recently installed Office 2007 and upgraded to Windows SharePoint Services (WSS) 3.0 at the advice of a friend. Don't worry Siva I won't mention your name.

Yesterday I shut down all the WSS services, all the app pools associated with it, and the Embedded SQL Database running to support WSS 3.0.

The Office 2007 install requires a new windows search module to be downloaded and installed that has a friendly message every time you hover over it that says it will throttle down when you are using your computer. Exiting and shutting down the service was about the only thing that slowed it down on my box.

I have 2 Gig of Ram and WSS 3.0 chews up every bit of it and was bringing my box to a screeching halt.

I will admit it has some great features and using the SharePoint Designer 2007 is a great experience. Just don't expect to be doing anything else on your box if you are designing WSS 3.0 sites. WSS 2.0 was no where close to being the memory hog WSS 3.0 is.

Windows Presentation Foundation Unleashed (WPF)... The Coolest Book I Own...

This book kicks butt. The color adds an amazing way to present the code and the UI's the code creates.

It covers everything you need to get started in WPF and goes into great detail about every topic I can think of that deals with WPF.

Adam is an awesome author. His style of writing is great. He has Tips, FAQ, Warning, and Digging Deeper side bars that are really helpful.

Everything in the book description is there, and presented excellently.

If you buy one book this year on the .NET 3.0 technologies, buy this one.