Now you know the UML. So what?
Learning the techniques and applying those techniques in the business and systems environment
are not always as simple as it seems in the classroom or in the latest UML book you have bought.
With this in mind we have designed a very simple approach to modelling business using the UML
techniques.
But before we begin, we need to understand a few concepts first. A business model typically is
described from the point of view of the business. With that we mean that the business model should
be described in the words and thoughts of the persons that execute it and those that participate in it.
When modelling a business process, or system, the business process/system (= business problem)
becomes the subject of the model. In order to properly describe the business problem in simple
and easy-to- understand terms, and yet not lose the complexity, we look at the business problem
from different perspectives, or views. Within each of these views, different UML diagrams may be
used in order to properly describe the view.
For a simple business model we will consider the following views, or dimensions:
-
Functional - The functional view describes the functions that are performed in the business.
Functions(drawn as use cases) are typically executed by an actor, who takes responsibility for
the successful execution of the function. Use case diagrams may be organized within package
structures. Package diagrams may also be used to describe dependencies between the parts of
the business. Functions defined in the functional view typically refers to the "What" that is being
done in the business and the "Who" who performs it.
-
Structural - The structural view identifies all of the business entities that come into play and
how these entities are related to each other. The business entities typically represents the
"With what" entities that are used by, or is affected by the functions described in the functional
view.
-
Behavioural - The behavioural view is used to describe the flow of activities that are executed
in order to successfully achieve the function's outcome, or workflow across the functions. The
behavioural view describes "How" things are done. The behavioural view often also describes
how the business entities are referenced, or used, as part of the activities.
Figure 1. Model views
Taking a use case centric approach to business modelling means that the use cases drive the other
dimensions. This implies that the functional view will determine and drive the structural and
behavioural views as can be seen in Figure 2.
Figure 2. Use case centric approach
The use case centric approach consists of a few simple steps:
Step 1: Model the Functional View
The functional view is described by taking the business problem and subdividing it into smaller
domains. Each domain will contain related areas of work, or related functions. The dependencies
between these domains may be modelled by using package diagrams. a very high level example
can be seen in Figure 3:
Figure 3: High level business domains
Once the model is properly segmented by package structures the use cases may be modelled. It is
always a good idea to model use cases according to a definition in order to avoid confusion around
abstraction. We break down the model using more and more detailed package diagrams and once
the next level decomposition satisfies the use case definition we use use cases. Our definition of an
elementary use case is:
An elementary use case is a self contained interaction that is executed by one primary actor, in one
place, with no intervening time delays. A use case is named with a verb and a noun that describes
the functional interaction.
This leads to use case diagrams as described in the following figure:
Figure 4. Use case diagram
The verb-noun requirement in the naming of the use cases helps us when we identify the classes in
the structural view, since the nouns becomes the business entities in the class diagrams. Describing
and documenting the use cases are important and as much detail should be described against the
individual use cases and actors.
Step 2: Model the Structural View
Once the business functions are properly documented and described in the functional view, we can
document the structural view. The first pass would be to create class diagrams using the use case
nouns as the business entities (classes).
A business entity represents a significant and persistent piece of information that is manipulated by
business actors. They are passive; that is, they do not initiate interactions on their own but may be
used in many different business use-case realizations and usually outlives any single interaction.
Business entities provide the basis for sharing information (document flow) among business actors.
This is illustrated by the following figure:
Figure 5. Class diagram
It is important to note that more business entities will appear from the use case detailed
descriptions and that the nouns from the use cases may not be the only business entities.
Operations against the business entities may be derived from the use case verbs and the detailed
use case descriptions.
Step 3: Model the Behavioural View
In the behavioural view there are two flows of behaviour we are interested in.
The first is internal behaviour that describes what happens if a use case interaction is executed.
This typically describes the workflow from when the use case interaction is initiated to when it
logically concludes.
The second describes behaviour as it flows across use case interactions and typically may describe
entire end to end process work flows.
Both types of work flows are described using activity diagrams.
Figure 6 shows the internal behaviour of a use case and describes how the object in the workflow is
derived from an existing class:
Figure 6. Internal behaviour workflow
The internal behaviour workflow of a business use case describes what the business must do to
provide the value the primary actor requires. The business use case consists of a sequence of
activities that, together, produce something for the business actor. This is described using the
activity diagram that explores the ordering of tasks or activities that accomplish the business goals.
An activity may be a manual or an automated task that completes a unit of work.
To model workflow across use cases the following may be done:
Figure 7. End to end workflow across use cases
External events will typically initiate workflow across enterprise. An activity = Execution of business
function. If the business function does not exist, you may have missed functions in your functional
decomposition.
Conclusion
Creating business models that are easy to understand are invaluable tools for understanding the
inner workings of the organization, its functions, its role players and the business entities it uses,
creates and consumes. It is a critical foundation for the system models that describe the supporting
software architecture and allows for easy trace ability and impact assessments of business to
system and system to business. Using the simple approach described here will allow the business
modeller to rapidly create accurate business models.
Making life easy!
