An Introduction to the Unified Modeling Language

An Introduction to the Unified Modeling Language

The Unified Modeling Language (UML) is a general-purpose, developmental, modeling language in the field of software engineering that is intended to provide a standard way to visualize the design of a system.

The creation of UML was originally motivated by the desire to standardize the disparate notational systems and approaches to software design. It was developed at Rational Software in 1994–1995, with further development led by them through 1996.

In 1997, UML was adopted as a standard by the Object Management Group (OMG), and has been managed by this organization ever since. In 2005, UML was also published by the International Organization for Standardization (ISO) as an approved ISO standard. Since then the standard has been periodically revised to cover the latest revision of UML. In software engineering, most practitioners do not use UML, but instead produce informal hand drawn diagrams; these diagrams, however, often include elements from UML.

Most people refer to the Unified Modeling Language as UML. The UML is an international industry standard graphical notation for describing software analysis and designs. When a standardized notation is used, there is little room for misinterpretation and ambiguity. Therefore, standardization provides for efficient communication (a.k.a. “a picture is worth a thousand words”) and leads to fewer errors caused by misunderstanding.

The U in UML stands for unified because the UML is a unification and standardization of earlier modeling notations of Booch, Rumbaugh, Jacobson, Mellor, Shlaer, Coad, and Wirf-Brock, among others. The UML most closely reflects the combined work of Rumbaugh, Jacobson, and Booch – sometimes called the three amigos. The UML has been accepted as a standard by the Object Management Group1 (OMG). The OMG is a non-profit organization with about 700 members that sets standards for distributed objectoriented computing.

In this appendix, we bring together for ease of reference five fundamental UML models: use case, class, sequence, state, and activity diagrams. The intent is not for this to be your only UML reference, but to succinctly provide you with the essential 20% of the UML that will provide you with the 80% of the capability you will use often.

1. Use Case Diagrams

A use case diagram is a graphical depiction of a user’s possible interactions with a system. A use case diagram shows various use cases and different types of users the system has and will often be accompanied by other types of diagrams as well. The use cases are represented by either circles or ellipses. The actors are often shown as stick figures.

Use case diagrams are used during requirements elicitation and analysis as a graphical means of representing the functional requirements of the system. Use cases are developed during requirements elicitation and are further refined and corrected as they are reviewed (by stakeholders) during analysis. Use cases are also very helpful for writing acceptance test cases. The test planner can extract scenarios from the use cases for test cases. Note: The use case diagram is accompanied by a textual use case flow of events. The flow of events is not explained in this document.

A use case, a concept invented by Ivar Jocbson (Jacobson, Christerson et al., 1992), is a sequence of transactions performed by a system that yields an outwardly visible, measurable result of value for a particular actor. A use case typically represents a major piece of functionality that is complete from beginning to end (Bruegge and Dutoit, 2000).

In UML, a use case is represented as an ellipse, as shown in Figure 1. In a Monopoly game, some use cases are: Enter Player Info, Buy House, and Draw Card. Give your use case a unique name expressed in a few words (generally no more than five words). These few words must begin with a present-tense verb phrase in active voice, stating the action that must take place (notice: Enter Player Info, Buy House, Draw Card, and Switch Turn).

While a use case itself might drill into a lot of detail about every possibility, a use-case diagram can help provide a higher-level view of the system. It has been said before that “Use case diagrams are the blueprints for your system”.

Due to their simplistic nature, use case diagrams can be a good communication tool for stakeholders. The drawings attempt to mimic the real world and provide a view for the stakeholder to understand how the system is going to be designed. Siau and Lee conducted research to determine if there was a valid situation for use case diagrams at all or if they were unnecessary. What was found was that the use case diagrams conveyed the intent of the system in a more simplified manner to stakeholders and that they were “interpreted more completely than class diagrams”.