UML or not UML?

Everybody heard about Unified Modeling Language, but when there is some specific question like “what empty diamond means in UML?” most of people don’t know the full answer (including myself :) ). This situation is common as in current complicated world the most important thing is not to know the full answer, but to know where to find it.

UML tools

One of the most popular tool to draw UML diagrams is Enterprise Architect from Sparx Systems. Most of people, whom I know agree that using Visio for UML is kind of masochistic entertainment and IBM Rational Rose is expensive plus you need to buy extra packages to use it fully. EA is not probably the most beautiful tool at the world, but it delivers a lot of horse power to your toolbox and it is very handy. Among others Sparx Systems delivers the tutorial and samples allowing you quickly to find out, which exactly diagram you should draw and how to do it. Nevertheless there is plenty of the other tools like free tinyUML. Full list and quick comparison of free and commercial tools for UML you may find in here.

UML in real

Most of organizations have learned already that stiff approach to UML diagrams does not work. There is no point to draw every single thing, generate the skeleton of classes and then keep constant consistency between logical representation in UML and physical in code. This approach generates very high costs and frustration. The open question is only how many times these two layers need to be synchronized. Absolute minimum is to create them up-front and update UML diagrams during final product delivery, so the customer gets the results with the actual documentation. It happens though in far too many projects, that there is none such an endpoint. As soon as the development starts the UML diagrams are forgotten.

UML in practice basing on RUP

If there is no need to draw every single thing, what is the rule of thumb? Rational Unified Process (RUP) gives here couple of good answers. RUP has been created by Rational Software, which created the first serious tool for UML – Rational Rose. This is why, we can risk saying that RUP was created as the project management opaque for UML. Hans Admiraal very nicely describes necessity to prepare:

• Business Use Case Model (package, use case, activity diagrams) – to represent the interaction between organization and outside world. For example it may describe use case ‘Order a product’ from ‘Customer’ (actor) perspective.
• Business Analysis Model (package, class, activity, interaction, state machine diagrams) - to represent how the business case is realized internally.
• Domain model (class diagrams) – to represent a general concept of a system as a black box.

These models should be prepare during RUP Inception phase, which is responsible for preparing the general vision of the project. Except UML drawings, which describes functionalities and constraints, the vision should contain also the information about:

• business justification (budget versus possible benefits) – the Net Present Value (NPV) may be used in here
• general schedule proposal
• first version of risks register

This is package is called High Level Definition (HLD). If it get the acceptance from the decision makers the RUP Lifecycle Architecture Milestone is achieved.

Then, we go with RUP Elaboration phase and technical details of the vision are specified in Low Level Definition (LLD) package. If HLD is business-driven and it is delivered mainly to take business decisions, LLD is technical-driven and it answers on technical questions. How particular functionalities will be developed? What components are we going to have? Which database will used? Etc..

Of course RUP is just the example and most of the other approaches have similar phases, which boxes preparing the business vision and technical vision. For example:
• Prince2 – “Starting up the Project” and “Initiate the Project”
• PMBoK - initiating and planning processes groups
• MSF – Envisioning and Planning phases

UML in practice basing on EA
Except of three models mentioned above EA offers rich set of model patterns:
Of course there is no need to use them all in each project and this is just the library, from which you may pick up right set of things:

• Business Process Model Pattern – is Business Analysis Model mentioned above

• Requirements Model Pattern – it is a very useful model, which helps you organize the required functionalities especially if there is a big set of them. Privately, when I see the specification where each requirement has its own unique number like FUN_02_03, the one immediately score extra points. The interesting point in here is that a new version of PMBoK (Mr. number 4) contains new processes delivered to support requirements management.

• Use Case Model Pattern – is Business Use Case Model mentioned above

• Domain Model Pattern – is a Domain model mentioned above

• Class Model Pattern – can be used during the work on LLD to specify technical details of the solution. That is especially useful to detect relations and generalizations, especially when you plan to deliver the complex framework and not some standard, typical project. Cool thing about EA is that in resources you may find ready to use design patterns from GoF. EA delivers tools to generate class skeletons in various languages, reengineering tools and even tools to create build scripts. If you are going to document every single class in your code you may draw. This may happen especially if you build your solution over some legacy code. My rule of thumb is that the best approach is to create the class model at the beginning and synchronize it with reality shortly after the delivery to the customer (when waiting for his feedback).

• Database Model Pattern – the same as above, applying it to DB.

• Component Model Pattern – that is a very useful approach to look at physical design from higher level than classes and tables. This thing lies somewhere between HLD and LLD and it is prepared the most often during a planning phase.
  

• Deployment Model Pattern – that is an opaque for deployment diagrams necessary to specify how the solution will be delivered on hardware

• Testing Model Pattern – that is model useful for QA teams to prepare test cases and scenarios.

• Maintenance Model Pattern – during on going use of the system, maintenance model helps to keep the track about the changes to the original requirements. The model can be supportive to introduce the solution like the Integrated Change Control. Nevertheless the most important is to have on board the Bug Tracking System or more advanced Issue Tracking Systems – the nice comparison can be found in here.

• Project management Model Pattern – EA contains the support for resource allocation, effort management, risks management and metrics like use case metrics. That is not a thing, which will replace the MS Project, Excel or the intranet tools, but in some cases it may be useful.

• User Interface Model Pattern – one of the most difficult things during analysis is the design of GUI. Very often the things are sketched on paper or flip chart. Usually when you create some system for the customer, they already have their customs. They may have previous version of the application or there are used to some other critical application. Very often it is just enough to follow the base line. If you create brand new system and there is no base line, my rule of thumb is to create the mock-up. The quickest way to do it, is to use IDE, which will be used later for development (MS Visual Studio, Eclipse, NetBeans). Then you present it to the customer for the acceptance and development has also the start point. Alternatively the EA offers the model dedicated for these purposes. It is not too sexy and if you want to model some specific controls you may need some time, but it allows to show nicely the flow of user interactions at least.

UML specific techniques
Even when you have used the UML there is couple of non-obvious tricks, which can be useful in particular situations:

• Class diagrams – there are the following base type of relations between objects, where each of them may be strong (solid line) or light (dashed line):

o Regular relation – linking two objects. It may have linked association class. It is often used for technical purposes in many to many relations. (regular line without arrow)
o Generalization - indicating some abstracts for some of real objects. It is often used because of OOP when abstract class or interfaces are designed. (triangle, empty arrow)
o Aggregation – presenting that an object consists of 0 or many of the other objects. If the child element is deleted when master element is deleted, we speak about strong aggregation (full diamond). If not, then there is a weak aggregation (empty diamond).
o Dependencies – unlike the regular relation, if there is some direction like using or dependency we use the arrowed line. Very often that line contains also some description, which is a stereotype like <> or <>

• Communication diagrams contains three very nice objects which comes from MVC design pattern

o Boundary - the View equivalent
o Control - the Control equivalent
o Entity – the Model equivalent

• Activity diagrams contains a number of specific options like:o object flow between two activities

o parallel processing (fork and join nodes) versus alternative processing (decision and merge)
o exception handling and exception regions
o partitioning (splitting the diagram on horizontal or vertical stripes)

• Composite diagram specifies:

o Provided (“ball on a stick”) and required (“cup on a stick”) interfaces, which nicely represent the communication issues on technical level. In this way you may for example model communication over WebServices.
o Ports which are represented by the named rectangle on a border of component.
o Delegate mechanism which allows to show that particular class is responsible for delivering external service through the interface or port.
o Collaboration, which allow to group set of elements

At last, but not at least… Whatever you do with UML, it is a communication tool and the most important thing is that it brings add-on value. It definitely helps in communication between two, independent organizations – one picture is worth thousand of words. You should not though document for documentation. Usually it is just enough to document the general idea and the most specific things just in case you come back to the solution after long period of absence. or take over is necessary. The new person in a project should be able to catch quickly the big picture and then to get some answers in more complicated processes and modules. This is where UML can be at great help.