The answer to Steve Cook's Question:
Tad, which parts of UML do you think we should implement?

From: http://realworldsa.dotnetdevelopersjournal.com/dsl.htm

Right now my answer to what UML tools I would like to see MS provided is driven by what UML diagrams I need to use to complete my current project which is a Product Line Engineering process implementation.  We are using these tools http://realworldsa.dotnetdevelopersjournal.com/net_20_tools_evaluation_dsl_gat_sql_2005_mobile_5_vsts_enter.htm

We chose to use the UML Profile outlined in http://www.awprofessional.com/title/0201775956 Designing Software Product Lines with UML: From Use Cases to Pattern-based Software Architectures.  This book is great for the UML syntax we will need to use.  But I warned my team to beware because it excludes many of the Architectural practices that we will be using that are found in the other resources I put in our educational resources (and yes Software Factories: Assembling Applications with Patterns, Frameworks, Models & Tools is included in those resources http://www.softwarefactories.com/TheBook.html ).  Designing Software Product Lines with UML: From Use Cases to Pattern-based Software Architectures does not use Attribute Driven Design, Cost-Benefit Analysis, or Architectural Tradeoff Analysis which we refer to Software Architecture in Practice, 2nd Edition http://www.awprofessional.com/title/0321154959 as a reference. Designing Software Product Lines with UML is only good for an artifact creation reference, not the process behind arriving at the artifacts.  The Profile seems to be complete, but will need to be managed closely.  It is driven by stereotypes and they need to be dual stereotypes, a feature Visio does not support.

I will borrow a list from Sparx (copied below) for common UML Diagrams we may need to provide in our project.  Not all of these need to be used in all views we present.  We are using the books Documenting Software Architectures: Views and Beyond http://www.awprofessional.com/title/0201703726 and Software Systems Architecture http://www.viewpoints-and-perspectives.info/ as our core references for the views and perspectives we are applying.  Of course just like the UML diagrams we plan to use to represent our views, not all the view and perspectives that the books outline will be presented.  It will depend on the stakeholders we are addressing.  We are also very feature driven and will be doing feature diagrams.

1. Structural Modeling Diagrams

Structure diagrams define the static architecture of a model.  They are used to model the 'things' that make up a model - the classes, objects, interfaces and physical components.  In addition they are used to model the relationships and dependencies between elements.

-  Package diagrams are used to divide the model into logical containers or 'packages' and describe the interactions between them at a high level

- Class or Structural diagrams  define the basic building blocks of a model: the types, classes and general materials that are used to construct a full model

- Object diagrams show how instances of structural elements are related and used at run-time.

- Composite Structure diagrams provide a means of layering an element's structure and focusing on inner detail, construction and relationships

- Component diagrams are used to model higher level or more complex structures, usually built up from one or more classes, and providing a well defined interface

- Deployment diagrams show the physical disposition of significant artifacts within a real-world setting.

2. Behavioral Modeling Diagrams

   Behavior diagrams capture the varieties of interaction and instantaneous state within a model as it 'executes' over time. 

-  Use Case diagrams  are used to model user/system interactions. They define behavior, requirements and constraints in the form of scripts or scenarios

- Activity diagrams  have a wide number of uses, from defining basic program flow, to capturing the decision points and actions within any generalized process

- State Machine diagrams  are essential to understanding the instant to intant  condition or "run state" of a model when it executes

- Communication diagrams  show the network and sequence of messages or communications between objects at run-time during a collaboration instance

- Sequence diagrams  are closely related to Communication diagrams and show the sequence of messages passed between objects using a vertical timeline

- Timing diagrams fuse Sequence and State diagrams to provide a view of an object's state over time and messages which modify that state 

- Interaction Overview diagrams fuse Activity and Sequence diagrams to provide allow interaction fragments to be easily combined with decision points and flows  

***Of course the most important thing a tool needs to provide is traceability between all these diagrams.

We are also borrowing from the book Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries http://www.awprofessional.com/title/0321246756, which by the way is a mandatory read before joining our core asset framework team, and will be our design guidelines for the core assets.  We are using the API specification to put together an API spec for each component/module that our off shore development teams will be developing.  The specs will be supplemented in the following way:

API Specification

One specification for each component of the product line core assets will generated.  Depending on the component, there may be additional information included with the specification to complete it's context.  There may be use cases, UML diagrams, or E/R diagrams that accompany it.  Our goal will be to supply just enough information for the component to be thoroughly explained, without creating unnecessary documentation.  The API Specification will be as complete as we can make it before sending it off to development.  If it needs to be changed, approval will be given or denied after a review of the change request by the architecture team.

Module Specification

The Module Specification will be done in a similar manner, but will be more likely to include UI prototypes, UX Diagrams, use cases, UML diagrams (class, sequence, etc.), and E/R diagrams.  One specification for each module of the product line application will generated.  As with the API specification, our goal will be to supply just enough information for the module to be thoroughly explained, without creating unnecessary documentation.  If the Module Specification needs to be changed, approval will be given or denied after a review of the change request by the architecture team.

We of course are following the PLE framework http://www.sei.cmu.edu/productlines/framework.html and reference Software Product Line Engineering : Foundations, Principles and Techniques http://www.springer.com/sgw/cda/frontpage/0,11855,4-146-22-50808140-0,00.html for some of the Principles of Variability. Of course one problem with this book is that it uses the Orthogonal Variability Model to trace the variability in the project's artifacts, and there are no tools to support an Orthogonal Variability Model.

I also use a lot of free form diagrams as described in The Object Primer 3rd Edition http://www.ambysoft.com/theObjectPrimer.html at the beginning of project to create an architectural context.  I am almost afraid to mention these as they may fall in to the category of "throw away models", and that topic seems to be a topic to stay away from these days. http://blogs.msdn.com/stevecook/archive/2005/12/15/504241.aspx ;-)

I also use Restrictive development to enforce the architectural patterns I arrive at during the architectural synthesis and SAD creation as described in http://realworldsa.dotnetdevelopersjournal.com/guidance_automation_toolkit_gat_architectural_description_do.htm. The GAT should lend itself well to this.  The patterns catalog I create usually uses sequence diagrams along with code samples to depict the patterns and how they work.

Round trip engineering, or at least synchronization was a feature of XDE I will greatly miss.  Visio doesn't come close.  It is nice to model in the model and in the code at the same time and have synchronization available.  I think the DSL class designer will be nice to use while coding, but won't do too much for design.  It would be nice to see stereotypes add to it.

I have used UML profiles and UML diagrams as a communication tool on all my projects.  The WAE profile, along with UX diagrams, was great for putting together free form architectures that communicated web applications features, even back in the ASP 2.0/3.0 days.  I have never developed an application without first putting together the architecture, use cases, analysis, and design diagrams first.  Whether the client wanted them or not.

links: digg this    del.icio.us    technorati    reddit