Using UML Models Effectively

models help you organise information

We use models to help us organise the important project information. Everyone on the project knows where the models are and how to use them.

We base our process around UML, the Unified Modelling Language, but although we think it is a good standard, we are not UML purists.

UML is a broad-based industry standard that can be used to describe a wide range of types of computing systems. In our use of UML we apply the Pareto Principle - the 80/20 rule. We use an optimal subset of the UML notation in a systematic way, to get the best balance between the benefits achieved and the time and effort expended. We also recognise that projects may need to tailor the use of UML to suit local conditions - the models must prove their worth!

The Business Model

The business model establishes the purpose of the system solution. By developing Business Process Models we establish a shared understanding of the underlying business need.

The models help us to challenge the shared understanding of the business in a systematic way. They also help the business to build up a consolidated understanding of their own processes.

Having a business model, also equips us to address aspects of Business Change which are often associated with the system deployment

The Solution Model

The Solution Model is a systematic and structured description of the system. At one level it allows us to define scope and prioritise functional requirements. At another level it allows us to specify unambiguous system behaviour. The Solution Model comprises:

  • the analysis model, which is a logical view of the system produced by the analyst(s); it is used to drive the design and provides a basis for functional testing.
  • the design model, which shows how the system will be implemented using the selected technical architecture and technical framework; the design model drives programming and technical testing (performance, volume, scalability)

Drawing up the Solution Model forces us to think systematically about the problem we are solving and drives out many questions that might not otherwise come out until late in the process. This improves quality, reducing rework and reducing the number of test cycles.

The Solution Model also provides us with a sound basis for "chunking up" the system into increments so that we avoid the overhead of reworking or refactoring software components as we progress from one increment to the next.

Not UML Purists!

What does this mean in practice? The UML standard has many aspects that are useful, but they are not useful to all the projects all the time. We have found that we can get most of the value of UML by using only some of it. Anyone who has looked in depth at the UML will know that it is driven (some say over-driven) by academic forces as much as by the needs of real IT projects. We think we are pretty good UML modellers, but only to the extent that we use it to deliver projects - its a means to an end.

Use Case Notation

Although the UML Use Case notation looks simple, we find that many people get into difficulty when it comes to use case relationships. So we have written a guide. You can download it below: