Process Essentials

Chapter 1 - Review of UML
byAndrew Filevet al.?
Wrox Press ©2002

	Team FLY

UML is a notation not a process, but invariably you will use UML in the context of a software development process; so which one to choose?

As indicated already, you are not compelled to use any particular process. You could adopt a pure Rapid Application Development (RAD) approach, or join the growing band of practitioners adopting the eXtreme Programming approach. Just a few years ago you might have been tempted by the Select Perspective method, which was - and still is - biased towards component-based development and based on an iterative-incremental approach. In all cases there would be nothing to stop you using UML as the analysis and design notation.

To round off this chapter we'll focus in on two processes in particular, the (Rational) Unified Process and the Microsoft Solutions Framework; the former because it has been devised by the authors of UML as the preferred partner process, and the latter because in this book we're interested in designing software for the Microsoft environment.

(Rational) Unified Process

The Unified Process has its roots in the Objectory method devised originally by Ivar Jacobson. It represents the unification of the process ideas of the three amigos, thus it is complementary to the Unified Modeling Language and is marketed by Rational Software as the Rational Unified Process (RUP).

In practical terms what you get when you purchase this product is a set of HTML pages describing the process, its roles, activities, and artifacts, along with a set of Microsoft Word templates that provide a starting point for those artifacts - not to mention a great deal of encouragement to buy the Rational Suite.

Three of the essential points of this process are that it is:

• Use-case driven - this ensures that the system we build will actually meet the requirements of the business.

• Architecture-centric - so we won't complete the analysis under the blind assumption that we can build the application on our chosen technical platform. Early on we'll do some technical prototyping.

• Risk managed - with an emphasis on tackling the tricky parts of the system - the architecturally significant use cases - at the beginning rather than at the end to reduce the likelihood of nasty surprises later on.

The fact that the process is use-case driven suggests that we start with the use case diagram(s). That's true to an extent, but not the whole story. We've already suggested that activity diagrams may add value early on by describing the workflow of the business, in essence the ordering of the use cases. There's a lot to be gained by producing a static structure diagram (class diagram) of fundamental business entities up front, to be called the domain model.

The point is that although the various diagrams will each have a lesser, or greater, impact as we move through various stages of the process, we won't simply be stepping through the diagrams in waterfall fashion. Rather, we'll analyze, design, and build the software as a series of increments via a set of iterations.

Within each iteration, any combination of diagrams may be valuable, those diagrams becoming more detailed as we go along. However, it goes without saying that as we approach implementation we'll have much greater need for component diagrams than for use case diagrams!

Though the Unified Process is iterative, not waterfall in nature, these iterations do fit into a series of distinct phases called Inception, Elaboration, Construction, and Transition.

• Inception is the initial phase in which you establish the business case for the project and determine the project scope.

• Elaboration is the phase in which you gather detailed requirements, undertake analysis and high-level design, define the architecture, and plan for construction.

• Construction is the phase in which you undertake the detailed design and build the software components themselves.

• Transition is the final phase in which you test the software, tune for performance, and train the users in preparation for going live.

The relationship between phases and iterations is shown in the following figure.

RUP .NET Developer's Configuration

Since we're dealing specifically with .NET application design in this book it's worth mentioning that the Rational Software web site (http://www.rational.com/products/rup/sample.jsp) describes a variant of the Rational Unified Process called RNDC, which is defined as the following:

"The RUP .NET Developers' Configuration (RNDC) is a straightforward, lightweight process configuration of the Rational Unified Process® that has been specifically customized to address the needs of the .NET software developer. "

There are two important aspects here.

Firstly, it's a customization of the Rational Unified Process specifically for the .NET development environment. Historically RUP has been biased towards Java software development and tools, with .NET now presenting some new technical challenges - and marketing opportunities - for customized version of the process.

Secondly, it's aimed specifically at software developers rather than all the team members defined by RUP. Presumably, no customization was required for technology-independent business analysts, but this also seems to reflect Rational's positioning of UML in the context of .NET. Experimentation with the new Rational XDE UML modeling tool shows this to be much more of a developer tool than Rational Rose ever was.

At the URL listed above is the RNDC roadmap, which provides a somewhat disappointing overview of the customized process. Under the headings Requirements Activities and Analysis Activities it simply states the following, which is at least consistent with the presumption that certain aspects of the process require no customization:

"Requirements activities are technology independent."

"Analysis activities are technology independent."

Under the heading Define an Initial Architecture, the reader is encouraged to use the .NET Framework - in particular Enterprise Templates - "to create reusable reference architecture templates for .NET applications that can be tailored to support a certain application structure or a specific application domain"

Finally, the RNDC roadmap references several concepts and guidelines such as "Concepts: Microsoft .NET Architectural Mechanisms"and "Guidelines: Partitioning Strategies in Microsoft .NET". Unfortunately these additional references are not hyperlinked in the RNDC, which renders it not too useful in itself. For a complete picture - with hyperlinks to all the required content - we need to look into the RUP .NET Plug-in.

RUP .NET Plug-In

The vanilla Rational Unified Process may be enhanced by applying various plug-ins for:

• Compatibility with alternative approaches, such as eXtreme Programming

• Technologies such as IBM Websphere and, of course, .NET

You can find general information about the .NET Plug-in at URL http://www.rational.com/tryit/rup/seeit.jsp and, more usefully, you can step through a slide-show presentation at URL http://www.rational.com/demos/viewlets/rup/msnet/MSNET_Tour_viewlet.html.

In that presentation you will see that this plug-in contains detailed information in the form of workflows, roadmaps, guidelines, and links to relevant information on the Microsoft Developer Network (MSDN) and Rational Developer Connection web sites.

Microsoft Solutions Framework

The Microsoft Solutions Framework (MSF) is a process-methodology for development in a Microsoft environment. In effect, we can view MSF to be a potential substitute for the Rational Unified Process, perhaps one that is more relevant to the Microsoft tools we'll be working with.

A Framework not a Process

We've referred to the MSF as a process, to justify a comparison with RUP. In fact, it's a framework incorporating a Process Model (the process), a Team Model, and a Risk Management Model. Let's start with the process model.

The process model is described as phase-based, milestone-driven, and iterative. We've taken the liberty of incorporating iterations within the four phases of the core process - Envision, Plan, Develop, and Stabilize - to come up with the following figure.

You should be experiencing some déjà vu now, and if you're not you should look back at the RUP process described previously. For Envision (MSF) read Inception (RUP), for Plan (MSF) read Elaboration (RUP), for Develop (MSF) read Construction (RUP), and for Stabilize (MSF) read Transition (RUP).

The process model is not the only area of similarity between the MSF and RUP. As mentioned above, the MSF includes a Risk Management Model and earlier we described RUP as being a risk-managed process, and where the MSF incorporates a Team Model this corresponds with RUP roles and activities.

A sensible conclusion then is that whichever process you start off with - RUP or MSF - the underlying concepts and approach are similar enough to allow a degree of compatibility or a change of mind later on. Indeed the MSF datasheet proclaims the following:

"[MSF] ... can easily coexist with virtually any other process framework or provide sufficient structure where no methodologies are in place."

	Team FLY