This chapter introduces the Unified Modeling Language (UML). I discuss why the UML is important and how one can learn it, by focusing on the object-oriented paradigm, structural modeling techniques, behavioral modeling techniques, and other capabilities of the UML. There are many good reasons to learn and use the UML. Quite simply, the UML is the lingua franca of the information systems and technology industry. More formally, the UML is a general-purpose and industry-standard language that is broadly applicable and well supported by tools in today’s marketplace.
System development involves creating systems that satisfy requirements using a system development lifecycle process. Essentially, requirements represent problems to be addressed, a system represents a solution that addresses those problems, and system development is a problem-solving process that involves understanding the problem, solving the problem, and implementing the solution. Natural languages are used to communicate the requirements. Programming languages (and more broadly, technology-based implementation languages such as the Extensible Markup Language (XML), the Structured Query Language (SQL), Java, C#, and so forth) are used to communicate the details of the system. Because natural languages are less precise than programming languages, modeling languages (such as the UML) are used in a problem-solving process to bridge the chasm between the requirements and the system.
A general-purpose language such as the UML may be applied throughout the system-development process all the way from requirements gathering to implementation of the system. As a broadly applicable language, UML may also be applied to different types of systems, domains, and processes. Therefore, we can use the UML to communicate about software systems and non-software systems (often known as business systems) in various domains or industries such as manufacturing, banking, e-business, and so forth. Furthermore, we can apply the UML with any process or approach. It is supported by various tool vendors, industry-standardized, and not a proprietary or closed modeling language.
Quite simply, the UML is a visual language for modeling and communicating about systems through the use of diagrams and supporting text. For example, Figure 1-1 communicates the following:
A manager leads a team that executes a project.
Each manager has a name and phone number, and may initiate a project or terminate a project.
Each project has a name, start date, and end date.
Each team has a description, and that is all we are interested in concerning the team.
Don’t worry if Figure 1-1 does not make complete sense. We will explore this figure and the UML in more detail in Chapter 2.
As you know by now, UML is an abbreviation for Unified Modeling Language. Each of these words speaks to an important aspect of the UML. The next few sections talk about these aspects, working through the words of the abbreviation in reverse order.
A language enables us to communicate about a subject. In system development, the subject includes the requirements and the system. Without a language, it is difficult for team members to communicate and collaborate to successfully develop a system.
Languages, in the broad sense, are not always composed of written words. For example, we commonly use “counting language” to introduce children to counting and arithmetic. A child is given a number of apples, oranges, pebbles, or some other type of object to represent a quantity. For the child, the representation of five might end up being five apples. The operations of addition and subtraction are then represented by the physical action of adding or removing objects from the child’s collection. We adults, on the other hand, prefer the language of arithmetic, which represents a specific quantity using a string of Arabic numerals, and which uses the + and - operators to represent addition and subtraction.
Figure 1-2 contrasts a young child’s counting language with the more abstract arithmetic language used by adults.
Now consider these two languages for communicating some specific number of days for a project. To model and express the quantity of five, the counting language uses five objects while arithmetic uses the string “5”. To model and express a more involved quantity of, say, 365, the counting language uses 365 objects (however, having so many objects may be impractical), while the arithmetic language uses the string “365”. To model and express the quantity of four and a half, the counting language uses 4 objects and one half of an object (again, however, one half of an object may or may not be practical), and arithmetic uses the string “4.5”. Because arithmetic allows us to more easily and practically represent a wider range of quantities than the counting language, arithmetic is said to be more expressive than the counting language. Likewise, a quantity is expressed more concisely using arithmetic rather than the counting language. By using languages that are more expressive, we can communicate complex information about complex subjects in a more concise manner than would be possible otherwise.
Stated somewhat formally, the UML is a language for specifying, visualizing, constructing, and documenting the artifacts of a system-intensive process. A system-intensive process is an approach that focuses on a system, including the steps for producing or maintaining the system given the requirements the system must meet. Specifying involves the creation of a model that describes a system. Visualizing involves the use of diagrams to render and communicate the model (the model is the idea and the diagrams are the expression of the idea). Constructing involves the use of this visual depiction to construct the system, similar to how a blueprint is used to construct a building. Documenting uses models and diagrams to capture our knowledge of the requirements and of the system throughout the process.
The UML itself is not a process. A process applies a set of steps described by a methodology to solve a problem and develop a system that satisfies its user’s requirements. A method addresses only part of the development process; for example, requirements gathering, analysis, design, and so forth, whereas a methodology addresses the whole development process from requirements gathering until the system is made available to its users. The different ways for gathering and using requirements, analyzing requirements, designing a system, and so forth are known as techniques. Artifacts are work products that are produced and used within a process, including documentation for communication between parties working on a system and the physical system itself. Each type of UML diagram is also known as a modeling technique.
A model is a representation of a subject. For example, as I noted earlier, to model and express the quantity of five, the counting language uses five objects, whereas arithmetic uses the string “5”. A model captures a set of ideas known as abstractions about its subject. Without a model, it is very difficult for team members to have a common understanding of the requirements and the system, and for them to consider the impact of changes that occur while the system is being developed.
When creating a model, if we try to represent everything about the subject all at once, we will be easily overwhelmed by the amount of information. Therefore, it is important to focus on capturing relevant information required for understanding the problem at hand, solving that problem, and implementing the solution, while excluding any irrelevant information that may hinder our progress. By managing what abstractions make up a model, how detailed they are, and when to capture them throughout the development process, we can better manage the overall complexity involved in system development.
The term unified refers to the fact that the Object Management Group (OMG), an industry-recognized standardization organization, and Rational Software Corporation created the UML to bring together the information systems and technology industry’s best engineering practices. These practices involve applying techniques that allow us to more successfully develop systems. Without a common language, it is difficult for new team members to quickly become productive and contribute to developing a system.
By understanding the OMG’s goals and scope for the UML, we can better understand the motivations behind the UML. The OMG’s goals were to make the UML:
Ready to use
Expressive
Simple
Precise
Extensible
Implementation-independent
Process-independent
By being ready to use, expressive, simple, and precise, the UML can immediately be applied to development projects. To enable the development of precise models, the OMG introduced the Object Constraint Language (OCL), a sublanguage for attaching conditions that the elements of a model must satisfy for the model to be considered correct (also known as well formed). The OCL is discussed in Chapter 10.
An extensible language allows us to define new concepts, similar to introducing new words and extending the vocabulary of a natural language. Extensibility is discussed in Chapter 9. An implementation-independent language may be used independently of any specific implementation technologies, such as Java or .NET. A process-independent language may be used with various types of processes.
The OMG’s scope when creating the UML included combining the modeling languages of three of the most prominent system-development methods — Grady Booch’s Booch `93 method, James Rumbaugh’s Object Modeling Technique (OMT) -2 method, and Ivar Jacobson’s Object-Oriented Software Engineering (OOSE) method — with the information systems and technology industry’s best engineering practices. Separately, these are only methods, but together, they form a fairly complete methodology.
The UML’s history consists of five distinct time periods. By understanding these periods, you can understand why the UML emerged and how it is still evolving today.
Between the mid-1970s and the mid-1990s, organizations began to understand the value of software to business but only had a fragmented collection of techniques for producing and maintaining software. Amongst the various emerging techniques and methods that focused on producing and maintaining software more effectively (each having its own modeling languages), three methods stood out:
Grady Booch’s Booch `93 method (from Booch `91) emphasized the design and construction of software systems.
James Rumbaugh’s Object Modeling Technique (OMT) -2 method (from OMT-1) emphasized the analysis of software systems.
Ivar Jacobson’s Object-Oriented Software Engineering (OOSE) method emphasized business engineering and requirements analysis.
As object-oriented methods began to evolve from structured methods, the industry fragmented around these three—and other—methods. Practitioners of one method could not easily understand artifacts produced using a different method. In addition, practitioners encountered problems moving from one organization to the next because such a move frequently entailed learning a new method. Furthermore, tool support was nonexistent to minimal because there were so many methods. Therefore, it was often cost prohibitive to use any method at all.
Between the mid-1990s and 1997, the UML 1.0 emerged. James Rumbaugh, and later Ivar Jacobson, joined Grady Booch at Rational Software Corporation to unify their approaches. Because of their unification effort, they became known as the Three Amigos. As organizations began to see the value of the UML, the OMG’s Object Analysis and Design Task Force issued a Request for Proposal (RFP) to establish a standard that defines the meaning of object-oriented technology concepts for tools that support object-oriented analysis and design. Together with various other organizations, Rational Software Corporation formed the UML Partners Consortium, and the partners submitted Version 1.0 of the UML to the OMG as one of many initial RFP responses.
In the later half of 1997, the UML 1.1 emerged. All the RFP responses were combined into Version 1.1 of the UML. The OMG adopted the UML and assumed responsibility for further development of the standard in November 1997.
After adoption of the UML 1.1, various versions of the UML emerged. The OMG charted a revision task force (RTF) to accept public comments on the UML and make minor editorial and technical updates to the standard. Various product and service vendors began to support and promote the UML with tools, consulting, books, and so forth. The current version of the UML is 1.4, and the OMG is currently working on a major revision, UML 2.0.
In parallel with the revision period, the OMG is proposing the UML standard for international standardization as a Publicly Available Specification (PAS) via the International Organization for Standardization (ISO). The most current version of the UML specification is available from the OMG at http://www.omg.org.
Get Learning UML now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
