The Business Process Model: An Introduction To UML
The Business Process Model: An Introduction To UML
An Introduction to UML
The Business
Process Model
by Geoffrey Sparks
All material (c) Geoffrey Sparks 2000
www.sparxsystems.com.au
Table of Contents
Introduction to UML
The Unified Modelling Language (UML) is, as its name implies, a modelling language
and not a method or process. UML is made up of a very specific notation and the
related grammatical rules for constructing software models. UML in itself does not
proscribe or advise on how to use that notation in a software development process or as
part of an object-oriented design methodology.
UML supports a rich set of graphical notation elements. It describes the notation for
classes, components, nodes, activities, work flow, use cases, objects, states and how to
model relationships between these elements. UML also supports the notion of custom
extensions through stereotyped elements.
The UML provides significant benefits to software engineers and organisations by
helping to build rigorous, traceable and maintainable models, which support the full
software development lifecycle.
This paper focuses on custom extensions to the UML, which support the modelling of
business processes. The purpose of these extensions, their graphical representation and
where process modelling can be used in the software development lifecycle is
discussed. Some examples are given.
You can find out more about UML from the books mentioned in the suggested reading
section and from the UML specification documents to be found at the Object
Management Groups UML resource pages: http://www.omg.org/technology/uml/ and
at http://www.omg.org/technology/documents/formal/
<<proce ss>>
Busi ness Pro cess
The process notation implies a flow of activities from left to right. Typically an event
element is placed to the left of the process and the output to the right. To specifically
notate the internal activities, UML activity elements may be placed inside the process
element.
<<proce ss>>
Busi ness Pro cess
A supply link indicates that the information or object linked to the process is not used
up in the processing phase. For example, order templates may be used over and over to
provide new orders of a certain style - the templates are not altered or exhausted as part
of this activity.
An input link indicates that the attached object or resource is consumed in the
processing procedure. As an example, as customer orders are processed they are
completed and signed off, and typically are used only once per unique resource (order).
Events
An event is the receipt of some object, a time or date reached, a notification or some
other trigger that initiates the business process. The event may be consumed and
transformed (for example a customer order) or simply act as a catalyst (e.g. nightly
batch job).
Actor
<<proce ss>>
Event Busi ness Pro cess
Outputs
A business process will typically produce one or more outputs of value to the business,
either for internal use of to satisfy external requirements. An output may be a physical
object (such as a report or invoice), a transformation of raw resources into a new
arrangement (a daily schedule or roster) or an overall business result such as
completing a customer order.
An output of one business process may feed into another process, either as a requested
item or a trigger to initiate new activities.
<<proce ss>>
Output
Busi ness Pro cess
<<output>>
An output link indicates that the business process produces some object (either physical
or logical) that is of value to the organisation, either as an externally visible item or as
an internal product (possibly feeding another process).
Goals
A business process has some well defined goal. This is the reason the organization does
this work, and should be defined in terms of the benefits this process has for the
organization as a whole and in satisfying the business needs.
Goa l
<<goal >>
<<proce ss>>
Busi ness Pro cess
A goal link indicates the attached object to the business process describes the goal of
the process. A goal is the business justification for performing the activity.
Putting it together
The diagram below illustrates how the various model elements may be grouped
together to produce a coherent picture of a named business process. Included are the
inputs, outputs, events, goals and other resources which are of significance.
<<proce ss>>
Event Output
Busi ness Pro cess
<<output>>
Traceability
Traceability defines the way a given business process will be implemented in the
proposed system. In an implementation diagram, use cases, packages and other model
artefacts may be linked back to the business process with <<implementation>> links to
signify the dependent relationship. The example below illustrates how a Business
Process is implemented by a Use Case and a package. As the model develops and
functional software components are built and linked to Use Cases, the business
justification for each element can be derived from this model.
Note that this model also implies what is NOT being delivered. The Business Process
will typically include a wide range of manual and automated procedures. This model
illustrates exactly what functionality (Use Cases) will be built to service a particular
business process: any missing functionality must come from other (manual or
automated) systems and procedures.
An Example
The example below is an example of the kind of model that may be built up to
represent a business process. In this model, the goal of the business process is to take
customer orders and to ship those orders out. A user starts the process with an inquiry,
which leads to the involvement of the Book Catalogue, Shopping Cart, On-line pages
and warehouse inventory. The output of significance to the business is a customer
order.
<<in put>>
<<proce ss>>
Customer Deliv ere d Order
Man age Custo mer Orde rs
Order
<<outco me>>
<<uses>>
Shipping Company
The second half of the process model is to respond to a customer order and ship the
required items. The second process involves the warehouse inventory, shipping
company and completes when an order is delivered to the customer.
Recommended Reading
Doug Rosenberg with Kendall Scott ,Use Case Driven Object Modeling with UML.
ISBN:0-201-43289-7. Publisher: Addison-Wesley