Search our
entire site
Enter your search
terms below, or visit
our search page

Search case
studies only
Enter your search
terms below:

For the table
of contents and
hyperlinks to
general topics
proceed to toc

The Unified Modeling Language Takes Shape

What if someone told you that there was an approach to modeling both data and process that combined the best practices of many professionals in the industry? Furthermore, what if this modeling notation all but eliminated the need for different notations that were wed to existing software development methodologies? In addition, what if that modeling notation were officially adopted by an international standards body consisting of more than 700 different organizations? Even better, what if there were several different CASE tool vendors that provided support for this notation as well as extensions that could create both relational and object-oriented DBMS schemas for implementing the modeled relationships? What if these CASE tools could also generate source code in more than a dozen different languages to support the initial creation of the software that implemented the application's functionality? You would probably want to know how this could be true (and how you could find out more).

Some think that the Unified Modeling Language (UML) fills many of these expectations. The Object Management Group (OMG) adopted the UML in November 1997 as the official object-oriented modeling notation for describing application domains. In this article, I'll outline the fundamental components of the UML and the value that the different views provide. In addition, I'll explain the translation of object- oriented models into nonobject-oriented implementation solutions, chiefly relational DBMSs. The UML is also the basis of Microsoft's repository and is being extended to support enterprise modeling.

The UML got its initial start from the combined efforts of Grady Booch, with his Booch method; James Rumbaugh, with his Object Modeling Technique (OMT); and Ivar Jacobson, with his Object-Oriented Software Engineering (OOSE) method. Beginning in 1994, under the auspices of Rational Software Inc., the UML began to take shape. Although it was strongly influenced by the practices of Booch, Rumbaugh, and Jacobson, the UML's evolution also included insights from such organizations as Hewlett-Packard and IBM. The UML was also submitted as a formal response to the OMG's Request for Proposal (RFP) for a standard object-oriented modeling notation.

It's impossible to overlook the ramifications of the OMG's adoption of the UML. For those of us who grew up in the Structured Analysis and Design (SA/SD) world, there were numerous diagramming notations to choose from and several process models to which you could apply them. Wouldn't it have been wonderful if the likes of Ed Yourdon, James Martin, and Tom DeMarco had sat down one day in the late '70s or early '80s and agreed to put aside egos and adopt one notation for the SA/SD approach to software development? Alas, this didn't happen. Not only would all the models in an organization have been similar, but an individual moving from company to company or application domain to application domain would have had a common notation as a foundation.

Some may wonder why object-oriented analysis and design (OOAD) is useful. Although a detailed discussion of the benefits of an OOAD approach is beyond the scope of this article, it is evident from a historical perspective that the formal separation of data and function has rendered much of our software development efforts fragile at best. A better approach is to consider the real-world entities for a given system for what they truly are, things that make up both data and function.

As Dr. David Taylor said in his book Object Technology: A Manager's Guide (Addison-Wesley, 1991), the software industry is much like the cottage industries of the late 1700s and early 1800s. Each product was custom made, no parts were interchangeable, and everything was made from scratch. It wasn't until rigid specifications for parts and the application of good design principles that the mass production of products became a reality. This "paradigm shift" is known as the Industrial Revolution. The software industry is in the same sad shape. Everything is crafted from scratch, and the ability to reuse software to build more systems with less code remains out of reach. The only way to have more systems with less code is to look at projects through object-oriented glasses.

The UML is neither a software process model nor a systems development life cycle. It is merely a notation. The UML is a mechanism to uncover the essence of a project's requirements and ultimate design. It provides a consistent model for proper software implementation and consistent feedback to ensure that a project sponsor understands the project.

Many software process models  which describe how the project flows through the stages of development  and systems development life cycles  which describe the steps necessary to complete phases of the project  can use the UML as a consistent notation. In addition, many existing methodologies (including Hewlett-Packard's Fusion, Microsoft's Solutions Framework, and Rational Software's Objectory) either are incorporating or have incorporated UML into their methodologies.

The UML is collectively broken into three views of the application: the static view, which is modeled using the use-case and class diagrams; the dynamic view, which is modeled using the sequence, collaboration, and state transition diagrams; and the functional view, which can be represented by activity diagrams and more traditional descriptive narratives such as pseudocode and minispecifications. There is actually a fourth view mingled with the static view called the architectural view. This view is modeled using the package, component, and deployment diagrams.

Static View

The static view contains the king of all the diagrams offered by the UML, the class diagram. Unlike the models produced using SA/SD, the class diagram continues to evolve throughout the project's life cycle. As a result, the static view isn't static at all. As information is uncovered in the later models, the static view is continually updated with each new piece of information. Actually, the classical entity-relationship diagram (ERD) is a model that also evolves throughout a traditional SA/SD approach; however, the ERD represents only the data relationships and avoids any notion of functionality. This is where it differs from the class diagram, which captures both the data and the operations that the real-world entities, or objects, need to support.

The other diagram contained in the static view, the user case diagram, uncovers the classes of an application. It takes a step back and initially identifies who the actors are in the system. Actors are usually the human elements of the system that generate or receive events about which the system must know. Actors can also be other systems or even an event. In addition, one human can actually play many roles, and there can be several different actors in the system. Once it has identified the actors, the use-case diagram then captures actual use cases. These are high-level "whats" that the future system is responsible for implementing. The use cases are cast in the language of the user, so they contain no "object speak" at this point. Use cases could be applied to any software process model, whether or not its intent is to build an object-oriented system.

Each use case contains a complete set of events initiated by an actor and specifies the interaction that takes place between an actor and the system. It does not describe the "how," which will be detailed in the system's functional view. Instead, a use-case diagram should model when a use case begins, what it does, and when it ends.

The next step is to collect all these descriptions, extract the nouns, and make a list of potential classes. Sound familiar? This is exactly the practice that many data modelers apply to the ERD in the SA/SD approach. The difference is the source of the nouns. In the past, this information was gathered during a blitz or joint application development session with the users where the key entities of the system were extracted. Developers asked users to focus on the subjects in the system and then built a matrix to determine high-level relationships and their cardinalities (such as one-to-many and many-to-many).

The list of nouns is cut to a core set, and an initial class diagram is built. At this point, an ERD may have captured much of the same information. However, in an ERD, things such as aggregations and compositions (whole and part relationships) are not modeled any differently from a normal relationship. ERDs also do not single out generalizations, although subtype and supertype relationships indicate that inheritance may be lurking below the surface.

My contention is that a good ERD modeler will have a very easy time extracting the nouns and learning some variations in standard ERD notation and will quickly come up to speed on the data side of the UML class diagram.

Dynamic View

The dynamic view of the application domain details the events that the system must support. More important, it shows how the various objects in the system, or instances of the classes identified in the static view, interact.

The dynamic view begins with the use cases. Remember that a use case describes an actor's involvement with the system. However, a use case can have many different paths of interaction. For example, the "handle transactions" use case that the actor "teller" is involved with has several possible paths or scenarios. One could be a deposit, the other a withdrawal, and still another a balance inquiry. Each of these scenarios will interact with many different objects in the application domain, such as account, customer, and transaction.

Note that if the use case only contains one scenario, then chances are the team has only documented the most commonly occurring thread through a use case. This "happy path" should not be the only one.

A sequence diagram captures and subsequently models each scenario. The sequence diagram and collaboration diagrams are collectively called interaction diagrams in the UML. They are both views of the same thing; however, you typically use a collaboration diagram later in design (more on collaboration diagrams later). The sequence diagram captures the messages sent between objects for a single scenario in the use case. It is difficult to show more than one scenario on a sequence diagram but relatively easy to show on a collaboration diagram.

The state transition diagram is another dynamic model the UML offers. State diagrams model the life cycle of only one class. Although the diagram can note when an event is sent to another class in the system, its mission is to elaborate on one and only one class. State diagrams are only performed for those classes that exhibit interesting dynamic behavior. The good news is that many classes on the class diagram will not warrant a state diagram. Actually, for most projects on which I consult, the ratio of classes to state diagrams is very low. However, if you have a realtime or embedded system, you may need more state diagrams.

Collaboration diagrams provide another view of the messaging between classes. Some CASE tools such as Rational's Rose will generate a base collaboration diagram from a sequence diagram. The collaboration diagram lets the project represent multiple scenarios and how they interact with each other. I expect that in the future, CASE vendors will add a code-generation capability using the collaboration diagram.

Functional View

The functional view focuses on the "how" side of the picture. For example, the static and dynamic views may describe "what" an operation called calcInterest does without focusing on the algorithm necessary to perform the operation. The functional view, on the other hand, would focus on the algorithm.

The UML supports one model in the functional view, the activity diagram. The activity diagram is similar to a data flow diagram. You typically use the activity diagram to detail the steps that take place in a complex operation.

Architectural View

Packages are an elegant way to group project components. You use packages to break up complex systems into more coherent groupings. Many projects will use packages to portray which use cases and related scenarios will be delivered. For instance, the first iteration of a bank teller application may implement the first six scenarios from the first use case, while the second iteration implements the remaining scenarios in the first use case plus all the scenarios from the second use case.

Deployment diagrams let you visualize how the software will be implemented on the hardware. Many projects get into trouble here when they don't pay attention to the characteristics of the hardware on which the software is run. Deployment diagrams are easy to learn because they have the same diagramming notations available to them that are available for modeling classes (such as generalization and aggregation).

You use component diagrams to model the runtime software elements. These diagrams are drawn in conjunction with the deployment diagram. This combination provides a clear picture of which hardware interacts with which software. For example, we would see that the teller application was stored as an .exe on a disk but brought into memory on a workstation and actually executed. These views challenge the team to analyze their deployment architecture and analyze any potential performance or support issues.

From Models to Code: DBMS

A common notation serves itself well as long as it promotes the ultimate goal of producing quality software. One component of the software side is the DBMS schema. The majority of information applications built today use some form of RDBMS to provide a persistence layer (something that many of you manage on a daily basis). The DBMS components should get attention early so you can explore any performance assessments and loading ramifications.

The UML's framework has given CASE vendors the necessary metamodel information to generate RDBMS schemas in the form of back-end data definition language (DDL) specifications. Most of these CASE tools will generate, at a minimum, ANSI DDLs, while some will generate DDLs specific to certain databases such as Oracle and SQL Server.

As you might expect, object modeling and ERD vendors are building relationships, such as the one between Rational, which makes Rational Rose, and LogicWorks Inc., the maker of ERWin (recently acquired by Platinum Technology). For instance, a free bridge available from Rational's Web site allows the DBMS schema to be generated directly into ERWin. This bridge is helpful because ERWin can generate DBMS DDLs in more than a dozen different dialects, extending the reach of the UML class diagram, the source of the DBMS schema. If ERwin isn't your product of choice, however, then most ERD modeling tools support some form of reverse engineering. A good approach is to generate an ANSI DDL with the object tool and then feed these files into your ERD tool so they can be further processed by the database.

From Models to Code: Business Rules

The UML formalizes what object practitioners have known for years: Real-world objects are best modeled as self-contained entities that contain both data and functionality. In the UML, this is expressed as attributes and operations. I've mentioned how you might handle the transformation from the class diagram to the data side. But what about the functionality side of the system?

In the UML, the class diagram holds the operation specifications. The operations directly support the data initially uncovered in the use cases and further refined by sequence and collaboration diagrams. Operations deal with the questions, "What is it I am expected to do by others?" and "What is my mission in life?" Each operation will have a signature that consists of the name of the operation, the input parameters and their data types, and the output parameters. An operation does not need to have all the signature components. Some operations will not need any input parameters to do their job, while others might not need to return anything. Code generation gets its start from these signatures and the relationships between classes.

Some CASE vendors are handling more of the system's scenario aspects. They may handle scenarios from the state diagram  this is not a new concept, so many vendors are finding this transition easier. An example is ObjectTime's recently announced effort to support the UML after years of generating C/C++ from state diagrams. The other approach, which hasn't seen much progress, involves generating more code from the other diagrams, namely, sequence and collaboration diagrams. A scenario, originally identified in the use cases, is a path through the system. The scenario detailed on the sequence diagram is a map of the messages between the objects to get that scenario completed. It is, so to speak, the life cycle of one of the system's scenarios. Code generated from these scenarios could package operations but only execute them in the order of the scenarios.

From Models to Code: Distributed

This discussion wouldn't be complete if I didn't mention the impact of the UML on distributed applications. Again, the UML provides the constructs, and the CASE vendors have taken it from there. Most CASE vendors will produce interface definition language (IDL) stubs from the class diagram. Frameworks such as the OMG's Common Object Request Broker Architecture (CORBA) and Microsoft's Distributed Component Object Model (DCOM) rely on IDL files to orchestrate the interaction among objects.

For instance, the customer objects in my example, once instantiated, may reside on client workstations while the account objects are instantiated on various servers. Facilitating this design using CORBA requires the generation of IDL files that are eventually input into the compile process. Because the IDL's mission is to define the public interface to a class, this information can be picked right out of the UML class diagram.

What Does the Future Hold?

At press time, version 1.1 of the UML was available for download from the Rational Web site. The version ratified by the OMG was version 1.0, however, and there are very few differences between the two. UML will most certainly evolve as the market evolves. The OMG has task groups that oversee the UML and nurture its growth. According to Rational, the evolution of the core UML framework will take the form of extensions, particularly in the area of business and enterprise modeling.

Another related effort within the OMG that bodes well for the UML's extensibility is a new RFP for determining a common interchange format for all the UML modeling components. This effort would let someone use one CASE vendor's tool for the static views and then import these into a different CASE vendor's product to create the dynamic view.

UML has also found its way into the Microsoft camp in a big way via its repository product. The repository uses the UML as its foundation and is being ported for Microsoft by Platinum Technology to other platforms such as the AS/400 and Unix. In addition, more than 65 different vendors have announced support for the repository. Using UML as its core, the repository further enhances the role the UML is playing in the marketplace.

Another offering from Microsoft that touts its support of the UML is the Visual Modeler product shipping with the enterprise edition of Visual Basic 5.0. It is a slimmed-down version of Rational Rose for Visual Basic. It doesn't support the dynamic view modeling but will generate Visual Basic code from the class diagrams.

The number of tools supporting the UML is growing rapidly. More important, the process adaptations and the support of the UML will continue to develop. As I mentioned before, many popular process models such as Hewlett-Packard's Fusion and Microsoft's Solutions Framework support the UML. Rational Software's Objectory also supports the UML.

Companies today are interested in the entire project development life cycle and how it ties into the UML. In most cases, the various methodologies will easily adapt to the UML. One of the UML's key goals, and one demanded by the OMG RFP, was that it be flexible. This flexibility appears to be one of the catalysts for its adoption by both the corporate and vendor worlds.

The UML has given the development arena a much-needed shot in the arm. Its biggest contribution has been in further legitimizing the application of object-oriented concepts to build better software and in providing a common notation to express a given project's requirements.

For those of us who have built software and designed databases for many years, the UML will also remove additional risk from the development process. Although the UML is not a process, it offers a succinct and workable notation that you can apply to any domain. Many project ills can be traced to poorly defined requirements and a lack of history in the project's life cycle. The UML provides this traceability. The UML also doesn't demand that every model be created only those called for by the domain. At a minimum, projects will create use cases, a class diagram, and a certain number of sequence diagrams.