UML graphics bridge diverse systems

The Unified Modeling Language (UML) is the standard graphical language for specifying the analysis and design of object-oriented software. The UML defines a set of diagrams, also called models, with well-defined graphical symbols so developers can easily understand each other's diagrams.

The graphical symbols are augmented by textual descriptions that also aid in model comprehension. The Object Management Group maintains the UML standard. The UML is a graphical notation only. You must choose a software development process that defines which diagrams to create and the order in which to create them.

The UML is expressive and effectively supports a variety of software development processes and applications from real-time to information systems. Most processes use a subset of UML constructs that best model the subject matter of the system. For example, reactive real-time systems will make extensive use of state chart diagrams while database systems will focus on the data modeling provided by class diagrams.

Classes and objects are two fundamental concepts in UML. A class is an abstraction of a set of real-world things that all have the same data and behavior. A class may have many instances called objects.

Each object conforms to the rules defined by its class. For example, a vehicle class in an automated toll collection application represents the concept of a car or truck that will be charged when passing through a tollbooth. Each vehicle has a VIN (vehicle identification number), make and model.

Thus, there will be a vehicle object for each car and truck registered with the toll collection system. Each vehicle will have a unique VIN and a make and model for the particular car or truck.

Attributes define the data encapsulated in the class. Services, functions that act on attributes, describe synchronous class behavior. Asynchronous behavior is described in state machines, life cycles that determine how an object responds to an event.

When modeling a class, only include the attributes, services and states required by the application. For example, the vehicle class in the toll collection system does not capture the color of the vehicle because it is not important for calculating the toll amount. Classes cooperate with one another to satisfy the requirements of the system. Associations link classes together. Classes communicate with one another by passing events and invoking services.

UML defines nine diagram types that document the system software from different viewpoints and at different points in the software process. Some diagrams are very abstract, showing a high-level view of the system without much detail. Others show a lot of detail about a small part of the system. UML diagrams show a higher-level view of the system that is hard to grasp when looking at just the code. There are nine diagram types that serve as the basic building blocks of models generated in this environment:

• Class diagram. Shows classes, packages and their associations. Describes the static data used by the system. Shows the separation of the system into packages.
• Object diagram. Shows snapshot of objects and their relationships at a particular time during the execution of a system. Useful for documenting complex data structures and object topology.
• Use case diagram. Shows relationships between use cases and actors. Describes context of the system. May be used to formalize and develop behavioral requirements.
• Sequence diagram. Shows order of events exchanged by objects during the execution of a scenario. Shows how objects collaborate to implement the behavior of the system.
• Shows the same information as the collaboration diagram. Format highlights timing.
• State chart diagram. Shows the life cycle of a class as a state machine. Also shows details of class behavior.
• Collaboration diagram. Shows the same information as the sequence diagram in a different format. Lines that are labeled with events connect object nodes. Format highlights the relationships between objects.
• Activity diagram. A special case of a state chart diagram used to show work flow and model business processes.
• Component diagram. Shows the mapping of the system to physical components such as files, executables and libraries.
• Deployment diagram. Shows topology of the hardware executing the system.

Many UML analysis constructs can be automatically mapped to an implementation language such as C, C++ or Java. Automatically mapping models to an implementation language can increase developer productivity, improve the quality of the system software and enable a team to react more quickly to changes in requirements.

Automatic mapping has the added advantage that the models and code are always in sync, because the code is generated from the models. The effort to create models in the analysis phase will continue to benefit existing and new team members throughout the entire life cycle.

Reducing complexity
The first step when starting a project is to reduce the complexity of the system by dividing it into manageable pieces called domains, which are sets of closely related classes that work together to provide services to other domains.

A server domain is any domain that provides services required by another domain, the client domain. Domains implement services using a variety of techniques including object-oriented analysis, handwritten code, code generated from a Rapid Application Development environment, legacy code and off-the-shelf libraries.

Client domains access the provided services of a server domain through bridges. The bridge is the only interface permitted from one domain to another. The classes in the client domain requesting the service do not have any knowledge of the details or implementation strategy of the server domain providing the service.

The client only knows the data inputs and outputs of the bridge service and any expected asynchronous returns. Restricting accesses between domains to bridges reduces the coupling between parts of the system and enhances maintainability and reusability. Some domains are reusable and may be included in more than one system.

An important step in any programming project is to identify the nature of the design and the basic building blocks that need to be built. In UML this is a five-step process:

Step 1: Identify the application domain. The application domain provides the services specific to this particular system. Almost all systems have a single application domain named for the purpose of the system from the end user's point of view.

Step 2: Identify key system functions. Examine the requirements and list the key system functions, which are high-level functions the system must perform to satisfy the end-user requirements.

Step 3: Assign key system functions to domains. Group related key system functions together into domains and select a meaningful domain name. Allocate key system functions specific to this particular application to the application domain.

Step 4: Write domain descriptions. Developers come from a variety of backgrounds, so even the best domain names may be unfamiliar to some members or may imply one thing to one developer and something completely different to another.

Write a description of the domain that communicates its capabilities as well as the services it requires. The domain description is the definitive definition of the domain. Well-written descriptions improve model comprehension and reduce confusion.

Step 5: Build a domain chart. Build a domain chart diagram to show the domains identified in previous steps and their dependencies. Domains are represented by UML packages, tabbed rectangles, and bridges by dependencies, dotted arrows from client domain to server domain.

Shown in the packages are the name and system-unique prefix of the domain. The prefix is a short name for the domain used for identifying services that the application depends upon.

See related chart