UML Models

Reading our What is UML and Why Use UML pages should have provided a sound case for incorporating UML in your next software project. But what UML models are available, what use are they and how do they link together?

We need to consider the primary modelling purposes of UML. These are:

Business Process Modelling with Use Cases

Class and Object Modelling

Behaviour Modelling

Component Modelling

Distribution and Deployment Modelling

Each UML model is designed to let analysts, developers and customers view a system from different perspectives and with varying levels of abstraction. Each diagram will fit somewhere into these five architectural views representing a distinct problem solution space. These can be described as the user model view, structural model view, behavioural model view implementation model view and the environment model view.

The UML User Model View

The UML user model view encompasses the models which define a solution to a problem as understood by the client or stakeholders. This view is often also referred to as the Use Case or scenario view. The main UML model encompassed by this view is the:

Use Case Diagram: These models depict the functionality required by the system and the interaction of users and other elements (known as actors) with respect to the specific solution.

The UML Structural Model View

The UML structural view encompasses the models which provide the static, structural dimensions and properties of the modelled system. This view is often also referred to as the static or logical view. UML Models applicable to this view include:

Class Diagrams: These models describe the static structure and contents of a system using elements such as classes, packages and objects to display relationships such as containment, inheritance and associations.

Object Diagrams: Depict a class or the static structure of a system at a particular point in time.

The UML Behavioural Model View

These UML models describe the behavioural and dynamic features and methods of the modelled system. This view is often also referred to as the dynamic, process, concurrent or collaborative view. UML Models applicable to this view include:

Sequence Diagram: Describe timing sequence of the objects over a vertical time dimension with interactions between objects depicted on a horizontal dimension.

Collaboration Diagrams: Describe the interactions and relationships between objects and sequences of a system organised in time and space. Numbers are used to show the sequence of messages.

State Diagrams: Describe the sequence, status conditions and appropriate responses or actions to conditions during the life of the objects within the system.

Activity Diagrams: Describe the methods, activities and resulting transitions after completion of the elements as flows of processing within a system.

The UML Implementation Model View

The UML Implementation View combines the structural and behavioural dimensions of the solution realisation or implementation. The view is often also referred to as the component or development view. UML Models applicable to this view include:

Component Diagrams: These depict the high level organisation and dependencies of source code components, binary components and executable components and whether these components exist at compile, link or run time.

The UML Environment Model View

These UML models describe both structural and behavioural dimensions of the domain or environment in which the solution is implemented. This view is often also referred to as the deployment or physical view. UML Models applicable to this view include:

Deployment Diagrams: These UML Models depict and describe the environmental elements and configuration of runtime processing components, libraries and objects that will reside on them.

How do the UML Models fit together?

After this high level tour of the UML architectural views and diagrams available, it is important to remember once again that UML is not a process and as such there is no right or wrong order in which these models should be constructed.

In practice, the only real pre-requisite to a UML model is a business process model, use case or a use case diagram. From then on, a method of refinement on each model will often be used as many elements of the system will not become obvious until it is modelled from a different perspective. The activities of analysis (what are the objects?) and design (the allocation of behaviour) will be iterative and be a mutually complementary process.