The benefits of UML in the face of EAI
What is UML and What UML is not
UML is…
The Unified Modeling Language (UML) is
a simple and extensible modeling language.
The UML is implementation independent in that it can be applied to any programming
language, technology, and domain. The UML is supported by a number of tools by
independent software vendors. The UML is process independent. It does not dictate nor
require that a particular process is followed. With that said, the authors of the UML do
encourage users to follow a use case driven, architecture-centric, iterative and incremental
process that is object oriented and component based. Many current system design
processes build upon such a framework. The UML is scalable; it can provide benefit and value to projects ranging from small-business application development to multi-national
enterprise-wide application integration projects.
UML is Not…
The UML is not a visual programming language; it is a visual modeling language. It is not
simply a notation but a robust language for capturing knowledge and expressing knowledge
about the system under design. During its short lifetime, the UML has become the
industry-standard language for system modeling.
The UML is not a process; in fact the UML is process independent. A process should be
tailored to the organization, the culture, and the problem domain at hand. Organizations
will benefit from the UML as it provides a common modeling language but it does not
require a common process.
The UML does not establish a specification of the interface, the storage, or the behavior of
a modeling tool. It is a modeling language specification. The authors and managing
consortium of the UML do not maintain or dictate the look and feel of the UML modeling
tools. The tools used to implement UML can range from the centuries-old technology of
pen and paper through to sophisticated off-the-shelf applications.
UML Diagrams
UML diagrams provide many perspectives of a system during analysis and development.
A complex system can be most effectively understood and therefore developed by
understanding it from many angles. Let’s look at a simple analogy to system modeling:
you plan to build the house of your dreams. You meet with an architect to explain the
features that will make this house perfect. The architect then sketches a drawing of your
dream house. And voila, you are now looking at your perfect home. It is a beautiful house;
the outside features include large windows, a huge red front door, and the yard is full of
quaking aspens. You are looking at the house of your dreams, you write a check and tell
the architect to build it. How realistic is this? What about the floor plan, the wiring plan,
the window and door plan, etc.? Would you write a check at this point? My guess is you
wouldn’t.
Developing the many views of a system is as critical to the success of system development
as are the detailed blueprints of a house plan. The UML defines a set of graphical diagrams
that are used for many planning, design and implementation tasks depending on the angle
that you are viewing the system. The major views of the system that UML supports are: 1)
the user view, 2) the structural view, 3) the behavioral view, and 4) the implementation
view. One or more diagrams for each view is defined by the UML and each provide a
unique window into the system. At this point it is important to point out that few projects
will utilize all the available diagrams. The UML diagrams are to be treated as a set of
resources for system modeling and take care to utilize only those diagrams that provide a
useful and beneficial view of your system. As you gain familiarity with the UML
diagrams, it will become apparent that some diagrams are more critical than others for
system modeling depending on the size of your project. The process your organization
follows will determine the order in which the diagrams are created; however, the general
order is: 1) use case diagrams, 2) structural and behavioral diagrams concurrently, 3)
component diagram, and 4) deployment diagram.
Using a sound modeling language is essential for good communication among project
teams and to provide an architectural reference to be followed through the life of a project
and during future system upgrades. As systems increase in complexity, visualization and
modeling become even more critical. Such is the case with EAI. An EAI project will often
be comprised of specialized teams each with an expertise in GIS or OMS or CIS or
middleware or business processing and the list goes on. The major benefits of using UML
is it provides a common language between the teams and it provides a central repository for
the EAI analysis, design, development, and implementation project plan.
The UML graphical diagrams are grouped according to their view -- user, structural,
behavioral and implementation -- of the system and the diagrams of each are described in
the following sections. A simplistic OMS example is followed through the rest of this
section.
The User View
The user view includes use case diagrams and business use case diagrams.
Use Case Diagram
The user view provides a
window into the system from
the users perspective, in that
the functionality of the
system is modeled in terms
of the user and what the user
expects of the system. In
UML-ease, the user of the
system is called an actor,
which can represent either a
human user or users as other
systems. The functionality of the system is defined by the use cases. The lines connecting
the actors and the use cases show that the actors interact with the functionality provided by
the use case, refer to Figure 2. Use cases are usually described in greater detail in an
accompanying textual document often referred to as the Functional Requirements
Specification (FRS). For each use case, the FRS usually contains the following sections:
a brief description, preconditions, a process and alternate processes, outputs, a user
interface, and business rules. The testing team writes test cases from the information
provided in the FRS and the end-user documentation is developed from the FRS. The
UML enables and promotes a use case-driven approach; as such it is critical to define the
actors, the use cases and their interactions early in the design process.
Figure 2: Use Case Diagram
Business Use Case Diagram
The business use case diagram is an extension to the use
case diagram and is defined in and supported by UML
and the OMG. Business process modeling is central to
the design of an EAI project. A goal of EAI is to enable
the sharing of data and business processes among all
interested users without making significant changes to
existing applications and data structures. Understanding
the as-is business processes and modeling the to-be
business processes can accomplish this goal. The first
step in business modeling using the UML is identifying
the interactions between the business processes and those
entities outside the business, such as customers and
suppliers. The interactions between an electric utility and
a customer include: requests for new service, requests
for service disconnect, change of billing address, service billing, and outage reporting. The
example in Figure 3 illustrates the business interactions of an electric utility customer
reporting service outage. The electric customer initiates the Report Trouble business
process by reporting an outage. Also modeled in Figure 3 are the additional processes that
are included with the Report Trouble process, Fix Trouble and Find Trouble, that the user
does not interact with but that are used by the report trouble use case.
Figure 3: Business Use Case
