9.1. Introduction
Although semantic approaches to information modeling appeared in the early seventies, no single approach has yet achieved universal adoption. By and large, the history of information systems modeling has been characterized by a plethora of techniques and notations, with occasional religious wars between proponents of different approaches. Each year, many new approaches would be proposed, leading to groans from academics who were charged with teaching the state of the art. This is referred to as the “yama” (Yet Another Modeling Approach!) or “nama” (Not Another Modeling Approach!) syndrome. Figure 9.1 pictures this as a mountain of modeling methods, piled on top of one another, which nicely ties in with the Japanese meaning of “yama” (mountain), depicted as a kanji that is high in the middle and low on the ends.
Figure 9.1. “Yama” (Yet Another Modeling Approach) or Japanese for “Mountain”.
While diversity is often useful, the modeling industry would benefit if practitioners agreed to use just a few standard modeling approaches, individually suited for their modeling scope, and collectively covering the tasks needed to model a wide variety of applications. This would improve communication between modelers and reduce training costs, especially in an industry with a high turnaround of employees.
Recently, the rapid rise of the Unified Modeling Language (UML) has been accompanied by claims that UML by itself is an adequate approach for modeling any software application. Some UML proponents have even been so bold as to claim that “the modeling wars are over—UML has won”. This claim has been strongly rejected by several experienced data modelers, including Dave Hay, who argues that “there is no such thing as ‘object-oriented analysis’” (Hay 1999a), only object-oriented design, and that “UML is ... not suitable for analyzing business requirements in cooperation with business people” (Hay 1999b).
To date, UML is mainly used in industry for designing object-oriented program code. Although it can be used for designing databases, UML has so far had little success in displacing other approaches such as ER for this purpose. Given UML’s object-oriented focus, and the dominance of relational DBMSs, this is perhaps not surprising. Nevertheless, UML is a very important language that could well become popular for database design in the future.
Initially based on a combination of the Booch, Object Modeling Technique (OMT), and Object-Oriented Software Engineering (OOSE) methods, UML was further developed by a consortium of companies and individuals working within the Object Management Group (OMG). It includes adaptations of many other techniques (e.g., Harel’s state charts) and is continually being refined and extended.
Version 1.1 of UML was adopted in November 1997 by the OMG as a language for object-oriented analysis and design. Versions 1.2, 1.3, 1.4, and 1.5 were approved in 1998, 1999, 2001, and 2003, respectively. Version 1.4.2 was accepted as a standard by the International Standards Organization (ISO). A major revision (2.0) was recommended in 2004, comprising Infrastructure and Superstructure specifications, plus related specifications on the Object Constraint Language (OCL) and Diagram Interchange. At the time of writing (2007), UML 2 has been updated to version 2.1.1[1]. When using a UML tool, be aware that vendor support typically lags behind the latest OMG adopted version (e.g., some tools are still at UML 1.2).
As discussed later, the UML metamodel and notation have inconsistencies, with some unresolved problems being fundamental. Despite these issues, UML is the closest thing to a de facto standard in industry for object-oriented software design, and hence is worthy of study.
The UML notation is really a set of languages rather than a single language. It includes a vast number of symbols, from which various diagrams may be constructed to model different perspectives of an application. The nine main diagram types in UML 1.5 are Use Case (use case diagram); Static Structure (class diagram, object diagram); Behavior (statechart, activity diagram); Interaction (sequence diagram, collaboration diagram); and Implementation (component diagram, deployment diagram). UML 2 extended these to 13 diagram types, as set out in Table 9.1.
Table 9.1. The 13 predefined diagram types in UML 2.
Some of these diagrams (e.g., collaboration diagrams) are useful only for designing object-oriented program code. Some (e.g., activity diagrams and use case diagrams) can be useful in requirements analysis, and some (e.g., class diagrams) have limited use for conceptual analysis and are best used for logical design.
The UML specification provides syntax and semantics for these diagram types, but not yet a process for developing UML models, other than to suggest that model development should be use case driven, iterative, and architecture centric. Various companies promote their own modeling process for UML, such as the Rational Unified Process (RUP).
Although all the UML diagram types are worth studying, this book focuses on information modeling for databases. This chapter addresses data modeling in UML, so considers only the static structure (class and object) diagrams. Class diagrams are used for the data schema. Object diagrams provide a limited means to discuss data populations. Some other UML diagram types are discussed in Chapter 15.
Like ER, UML uses attributes. As discussed in earlier chapters, attributes are great for logical models, but are best modeled as relationships when performing conceptual analysis, since this facilitates validation and minimizes the impact of change. For such reasons, we believe the best way to develop UML data models is to first do an ORM model and then map it to UML. Since ORM will be used to clarify the data modeling concepts in UML, to gain the full benefits of this clarification you should be familiar with the ORM concepts covered in earlier chapters.
No language is perfect, ORM included. Overall, UML provides a useful suite of notations for both data and process modeling, while ORM is currently focused on data modeling only.