The benefits of UML in the face of EAI

The benefits of UML in the face of EAI

Sharon A. Allpress
Geographic Information Technology, Inc
101 Inverness Drive East
Suite 130
Englewood, Colorado 80112

The Unified Modeling Language (UML) is an important tool for modeling Enterprise Application Integrations (EAI). The complex interaction among multiple applications, such as GIS, outage management (OMS), workforce management, and customer information systems, requires a tool to support many system development tasks. UML aids in modeling the business processes, managing EAI requirements, providing test criteria, and building end-user documentation. The applications that a GIS is required to interface with are constantly increasing and the applications are not only linked within a company but are also linked between companies. Traditionally, communication between the GIS and other applications has been customized, one integration at a time. The result is a set of complex and unique integration points with redundancy throughout the system. The EAI approach uses a set of tools to share data and business processes among connected applications and data stores within and, optionally, between organizations.

Though EAI provides a common communication interface between the systems, an EAI implementation still consists of a complex web of systems, people and processes. As the complexity of systems -- whether new or refurbished -- increases in scope and scale, so does the importance of good modeling techniques. The UML meets the modeling needs of such complex systems and thus has developed into a well-defined and widely accepted modeling language.

The history of UML
The beginnings of documented object-oriented modeling languages can be traced back to the mid-1970’s when methodologists were experimenting with different approaches to object-oriented analysis and design. The number of identifiable object-oriented modeling languages increased from less than 10 to more than 50 between 1989 and 1994 (OMG, 2001). In the mid-1990’s, the primary authors of the leading modeling languages (Booch, OMT, and OOSE) realized that each of their models were evolving into very similar models. In late 1995 Grady Booch, Jim Rumbaugh, and Ivar Jacobson, the primary authors of the leading modeling languages, joined forces at Rational Software Corporation and began collaborating on a unified modeling language. In early 1996 the authors released the UML 0.9 and requested feedback from the general community. The feedback they received was incorporated into the model and the authors then released the UML 0.91 document. During 1996 the Object Management Group (OMG) issued a Request for Proposals for a definition of a modeling language standard, which proved to be a catalyst for interested parties and organizations to join forces and provide a response. The UML Figure 1: History of the UML Partners consortium, established by Rational, provided a response to the RFP. The consortium included the “three amigos” (Booch, Rumbaugh, and Jacobson) and organizations such as Digital Equipment Corp., HP, IBM, MCI Systemhouse, Microsoft, Oracle, Rational, TI, and Unisys. The UML Partners focused on improving the UML 0.91 architecture so that it met the demands of all mainstream methods and ensuring that it was general purpose in nature. The UML Partners submitted their initial UML proposal (UML 1.0) to the OMG in January 1997 and the final proposal to the OMG in September 1997, which the OMG adopted as its object modeling standard. The OMG and the UML Partners consortium recognized that the UML was an evolving language that would need to be reviewed and evolved on a continual basis. As shown in Figure 1, the UML Partners have followed standard software development practices by planning and following a revision schedule for the UML. In September 2001, the OMG released a minor revision, UML 1.4. The first major revision since UML was adopted by the OMG in 1997 is scheduled for release in late 2002.

Figure 1. History of the UML
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

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.