How do I analyse and document an existing business process using the Unified Modeling Language (UML)? - Part 2

 

If we are going to model a process using UML, we need to know what it is. Here is a concise introduction to UML. If this is your first time with UML, then you will probably have to read a little further. References to key texts are provided in a separate document.

 

In the Beginning

 

The Unified Modeling Language (Modeling with one 'l' is the American spelling) was devised by Grady Booch, James Rumbaugh (pronounced 'Rumbow') and Ivor Jacobson, as a language that could be applied to all forms of modelling. Modelling is widely practised in software development circles, and so most of the examples to date are based on the process of describing software programs. However, UML's ability to describe OO systems suggests that it also lends itself to the description of other 'real-world' systems, such as business processes.

 

The Basics

 

Any modelling language has a notation and a set of rules that govern use of the language. The notation describes the symbols used in the models, and the rules can be classified into three types:

 

  1. Syntactic. These rules dictate how the symbols should look and how they may be combined.
  2. Semantic rules tell us what each symbol means and how it should be interpreted.
  3. Pragmatic rules explain how to use the language.

 

If you are not quite sure how these rules are applied, don't worry too much. It will become clearer when we start modelling.

 

UML symbols are mostly rectangles, circles and lines, or combinations of all three. The UML standard defines how the symbols should look (syntactic rules), and what the symbols should mean (semantic rules), but not how the language should be used (pragmatic rules).

 

Quick Question: What rule types are defined by the UML standard?

 

 

UML has nine predefined diagram types:

 

  1. Class Diagram. Used to describe the structure of a system, and in some cases are not unlike the traditional organisational chart. The structures are built from classes and relationships. Each of the classes can represent and structure information, products, documents or organisations.
  2. Object Diagram. These express possible object combinations of a specific class diagram. What this means is that a specific instance or 'snap-shot' of a class diagram can be described.
  3. Statechart Diagram. Otherwise known as 'State Transition' diagrams, these express the possible states of a class or system.
  4. Activity Diagram. Describes activities and actions taking place in a system.
  5. Sequence Diagram. Illustrates one or several sequences of messages exchanged between objects.
  6. Collaboration Diagram. Describes a complete collaboration amongst a set of objects.
  7. Use case Diagram. Illustrates the relationships between use cases. Each use case is a textual description of a part of the system's functionality.
  8. Component Diagram. A special case of class diagram used to describe components within a software system.
  9. Deployment Diagram. Similar to the component diagram, but describing hardware within a software system.

 

These diagrams capture the three most important aspects of a system; structure, behaviour and functionality.

 

Review Questions

 

Test your understanding of this topic with the following questions.

 

What is the difference between an Object and a Class Diagram?

 

 

Write down the three most important aspects of a system.

 

 

Part 3

Reference: UML Explained, Kendall Scott, Addison-Wesley, http://aw.com/cseng/, ISBN 0-201-72182-1