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!
