Using UML Models Effectively

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.

You can find out more here:

Project Management - Making Change Work - Software Testing

Useful Resources

These links and resources will tell you more about our approach and the techniques we use.

Use Case Relationships Explained

Are you finding it difficult to organise your Use Case Model? Do you understand how Use Case Relationships should be used? Can't figure out when to use <<extend>> rather than <<include>>?
Download our handy guide here

Contact Us

If you are interested in talking to us about application development, and how your organisation could do it better, please your details and we will do our best to help

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 from 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.

Business Model? - sounds tricky!

We know that modelling all the concerns of an enterprise is a difficult thing to do. The focus for us is creating a basis for understanding the context and priority of system requirements, so we use a fairly simple, but powerful, technique to model the important business activities. This helps the project team and the business develop a shared understanding of the problem that needs to be solved. But, we only model to down to the level that helps us reduce risk from subsequent project stages - and no further.

Our Business models use a simple notation and provide an effective medium for facilitating the conversation with the business experts and end-users. The models provide a comprehensive documentation trail of key decisions about benefits and priorities.

Models - Too Much Work?

All these UML models will take too long, you think? Well they do represent a lot of effort BUT the time you invest now will pay back later:

• Reduced rework during coding
• Reduced high-impact defects in system testing, resulting in reduced testing cycles
• Better fit to business needs

Our clients have seen the pay-back that they get from front-loading the project lifecycle. Improved quality without an overall increase in time and effort. But they also get more maintainable systems and better documentation as a side benefit.