The benefits of UML in the face of EAI
The Structural View
Class Diagram
Class diagrams describe the static
structure of a system. The focus of the
class diagram is to describe how a system
is structured rather than how it behaves.
Class diagrams are probably the most
versatile of the UML diagrams. Data
models, software components, software
classes, and business objects are modeled
using the class diagram, each in it’s own
diagram. Figure 4 is an example using the
class diagram data modeling. The
attributes, operations and relationships of
each class are displayed as part of the class
diagram. Tools, available from GIS
vendors, have been built that generate
database schemas and code from UML
compliant models. This feature is referred
to as forward and reverse engineering.
Figure 4: Class Diagram
The Behavior View
The Interaction Diagrams
Interaction diagrams include sequence and
collaboration diagrams.
The Sequence Diagram
Sequence diagrams describe the behavior of a
use case by diagramming the classes and the
messages exchanged between them arranged in
chronological order. It is important to note that
sequence diagrams do not describe object
relationships; that view of the system is
reserved for collaboration diagrams. Object and
actor instances can be displayed in the sequence
diagram along with how the objects
communicate by sending messages to one another, figure 5. Sequence diagrams are
intuitive to create because humans tend to arrange and plan in order of events. Oftentimes,
system analysts will prefer to create sequence diagrams before they create class diagrams.
The system analysts will often find themselves evolving the sequence and class diagrams
through much iteration.
Collaboration Diagram
The collaboration diagram is a view of the interactions of objects and unlike the sequence
diagram that describes the objects messaging over time; collaboration diagrams display the
relationships between objects. Some UML tools can automatically generate collaboration
diagrams from sequence diagrams, and vice versa. Collaboration and sequence diagrams
express similar information but they display it from different perspectives. As you gain
experience and familiarity with both the
sequence and collaboration diagrams, you will
most likely gravitate towards one over another
depending on personal preference.
Activity Diagram
The activity diagram is a specialization of the
state diagram and it displays the dynamics of a
system by showing the workflow. The activity
diagram complements the business use case
diagram in that it shows the process flow behind
the use case. Since defining and understanding
the business processes are critical steps in
designing an EAI solution, activity diagrams
provide the common language and a common
understanding between business analysts and
system analysts. Activity diagrams, at first
glance, resemble flow charts since they use
Figure 5: Sequence Diagram
Figure 6: Activity Diagram
Figure 7: State Diagram
Figure 8: Component Diagram
activities and flow lines. But activity diagrams provide additional important and unique
features including conditional threads, nested activity diagrams, and swimlanes. The
swimlanes represent organizational units or roles and are used to display who will be
responsible for each activity in the process. In Figure 6, the electric utility customer
performs the activities in the left column and the Voice Response Unit (VRU) performs the
activities in the right column.
State Diagram
The state diagram describes the sequence of states that an object
goes through during its lifetime. The state diagram displays the
events that act upon the object that enables the transition from one
state to the next. In Figure 7, the state of the trouble is modeled
along with the events that move the trouble through its lifecycle
starting as “New Trouble” and ending as “Trouble Closed”. In this
example the states of a business process are modeled. State
diagrams are also useful for modeling the various states of a class
that has a complex lifecycle.
The Implementation View
Component Diagram
The component diagram displays the static structure of the
implementation view. The component diagram shows the
organizations and dependencies of the components, subsystems,
and their relationships, figure 8. Additionally, the diagram models
the interface that can be used to show the externally visible
operations of a class or component.
Deployment Diagram
The deployment diagram “shows the
configuration of run-time processing elements
and the software components, processes and
objects that execute on them” (OMG, 2001).
The deployment diagram can be used for
business modeling where employees and
organizations are displayed as run-time
processing elements and the procedures and
documents that they use are displayed as the
software components.
Benefits of UML to implementing an EAI solution
The purpose of EAI is to support business processes by tying together the company’s
components. Components include databases, applications, COM and CORBA objects, and
any system with data that may be useful to other systems.
EAI nirvana involves completely transparent access to all of the company’s components
from anywhere within the company. This is desirable because companies have often
invested large sums creating their existing data stores and other components, and new
regulatory or financial pressures require them to make new uses of their existing systems.
Unfortunately, this nirvana is unattainable given the complexity of most organizations. A
measured approach is essential, beginning with critical business processes whose
automation provides high value to the company. Success in a small, proof-of-concept EAI
implementation will pave the way to larger EAI projects within the company. UML
provides critical tools for this success.
One of the first steps involves understanding the business processes that currently exist (the
“as-is” state) and that need to exist (the “to-be” state). Activity and state diagrams assist
this endeavor. Many of the swimlanes in the as-is diagrams will refer to manual processes,
perhaps involving paper shuffling and phone calls between departments. Such processes
can still be modeled effectively. After modeling is complete, assess each business process
according to its frequency, value, desired completion speed, and cost. Then make
appropriate judgements about which processes need to be refined with EAI technologies.
For example, perhaps timecard submissions have high frequency, low value, must be
completed every week, and cost one hour of each employee’s time per week. Automated
crew dispatch to a serious SCADA event may occur once a week, affect hundreds of
customers, must be completed as quickly as possible, and can cost thousands of dollars per
minute in lost revenue. The latter may be considered more meritorious for EAI
streamlining that the former. This management level decision is assisted with simple
diagrams that show the differences between as-is and to-be (or “could-be”) business
processes.
Comparing as-is to to-be diagrams provides a powerful visual tool that encourages
management support of a project and provides valuable assistance during early EAI
acquisition phases. Top-down management support of EAI initiatives is imperative, since
the owners of a company’s data stores are justifiably hesitant to allow outside influences on
their data. UML diagrams help with this support.
The key to supporting business processes is the movement and manipulation of data within
the enterprise. Writers of use case diagrams should keep this goal in mind for the lowest-level
use cases. After the use case diagrams are completed, additional information is
available to help decide on appropriate infusions of EAI technology. Such technology
should facilitate data movement in the service of important business processes. Eventually,
EAI developers will need the use case diagrams and sequence diagrams to develop and test
the pieces that move data between components.
It’s clear from this discussion that UML provides important benefits to a company’s EAI
plans. Management needs simple visual tools to help make important acquisition decisions
and decide which business processes deserve EAI attention. Developers need it to help
with implementation and testing. Users need it to cooperate with developers during early design phases of the project. Everyone benefits from UML’s common, understandable
language.
References
- Alhir, S, 1998, UML In a Nutshell.
- Hansen, T, Activity Diagrams to Model the Client’s Work Process, www.rational.com.
- Kobryn, C, 1999, UML 2001: A Standardization Odyssey: Communications of the ACM,
Vol. 42 No. 10.
- Marshall, C, 2000, Enterprise Modeling with UML.
- OMG, 2001, OMG Modeling Language Specification, Version 1.4, pp. 3-172.
