Using UML Object Class Diagrams

7.4 Using UML Object Class Diagrams

UML has become increasingly popular in the last few years. UML is without doubt a very useful object-oriented application component design and development environment, and the growing object-oriented developer community has taken to it with justifiable enthusiasm. You should have little trouble finding guides to UML and its use; however, the overwhelming majority of these are written by enthusiastic  – even evangelical - advocates. Here we focus on some of the issues and limitations that the data modeler will also need to take into account in making the best use of UML, or in deciding whether to use it. It is certainly possible to represent entity classes and relationships using UML class models, and indeed at least one UML CASE tool can use these to generate physical data models representing tables and columns in a manner indistinguishable from an E-R CASE tool. However, this overlooks a significant issue: UML class models are very much focused on the physical system to be built rather than on the business requirements that that system will support. For example, when drawing a class model, the dialogues with which you are presented to define association (relationship) characteristics include such system function concepts as navigability (or visibility) and privacy across the link in each direction.

As an example of this focus, we have observed that many UML class models produced by object modelers contain implementation classes as well as, or instead of, genuine business object classes. In much the same vein, UML use cases often focus on system dialogues apparently unsupported by any analysis of business functions and processes. You may wish to use (or be required to use) a UML Object Class Diagram to represent data requirements. If you are using object classes, the UML symbols that we introduced in Chapter 3 (Figure 3.10) are appropriate as a representation of your entity classes and relationships (since each of your entity classes is treated as an object class).

7.4.1 A Conceptual Data Model in UML

Figure 7.8 shows a simple UML class model diagram. In this type of diagram each box represents an object class, and we can therefore represent each entity class using a box. Each line between two boxes represents an association, of which there are many varieties, distinguishable by the symbols at the ends of the line; a line with only open arrowhead symbols on the line itself (as in Figure 7.8) or with no arrow heads represents a relationship. Cardinality (multiplicity in UML terminology) and optionality of a relationship is represented by one of the following legends placed somewhere near each end of the line:

■ 0..1 optional “1” end

■ 1…1 or 1 mandatory “1” end

Figure 7.8 A simple UML class model.

■ 0…* or * optional “many” end

■ 1…* mandatory “many” end.

In fact, numerals other than 0 and 1 can be used (e.g., 2…4 indicates that each instance of the class at the other end of the relationship line must be associated with at least 2 but no more than 4 instances of the class at this end of the relationship line). Attributes can be listed within a class box. Boxes can be divided into two or three “compartments” by means of horizontal lines; the lower compartment of a two-compartment box or the middle compartment of a three - compartment box is available for listing the object class’s attributes (the lowest compartment of a three-compartment box is for the object class’ methods or operations).

7.4.2 Advantages of UML

UML has many notational facilities not available in standard E-R modeling. In our experience the most useful of these for business information requirement modeling are derived attributes and relationships, association classes, n-ary relationships (those involving more than two entity classes), and on-diagram constraint documentation. Derived attributes are marked by preceding the attribute name with a solidus (“/”). Derived relationships can also be drawn. The name of such a relationship is similarly preceded by a solidus. Figure 7.9 features a derived attribute and a derived relationship.

Association classes are a means of overcoming the dilemma as to whether to represent a many-to-many relationship as a relationship or as an entity class. In UML a class box can be drawn with a dashed line connecting it to

Figure 7.9 Derived attributes and relationships.

Figure 7.10 An association class.

an association line: any class represented in this way is known as an association class. Any attributes of the relationship can be listed within the association class box, yet the original many-to-many relationship continues to be depicted. This is obviously an improvement on the replacement of a many-to-many relationship by an entity class and two one-to-many relationships that is required in E-R diagramming if the many-to-many relationship has attributes. Association classes are not limited to many-to-many relationships. Figure 7.10 features an association class. Relationships can involve more than two entity classes in UML. An association class can also be used to document the attributes of such a relationship, as illustrated in Figure 7.11, which also shows that the Chen notation for a relationship has been adapted for this purpose. Constraints (business rules) can be documented on a UML class diagram using statements (in natural language or a formal constraint language) enclosed in braces ({ and }).

Figure 7.11 An n-ary relationship. 

7.4.1.3 Use Cases and Class Models

If you are a data modeler working in a UML environment you may be expected to infer the necessary object classes by reading the Use Cases, as this is a claim often made for UML. Since a Use Case can and does contain anything its author wishes to include, the usefulness of a set of use cases for inferring object classes is not guaranteed; indeed, Alex Sharp has coined the term “useless cases” to describe Use Cases from which nothing useful about object classes can be inferred. Even if the Use Cases are useful for this purpose, the absence from UML of a “big picture” in the form of a function hierarchy correlated to entity classes via a “CRUD matrix” means that the question, “Have we yet identified all the Use Cases?” is not able to be answered easily and is sometimes not even asked.

Let us assume however that you have managed to convince the business stakeholders to submit to a second round of interviews and workshops to help you establish their information requirements and you are now developing UML class models. There are some features of the notation that have the potential to cause trouble. 
 

7.4.1.4 Objects and Entity Classes

One of the most fundamental issues is how the concept of an object class relates to concepts in the E-R model. Many practitioners and CASE tool vendors state or imply that an object class is just an entity class. There are, however, other approaches that appear to define an object class as a cluster of related entity classes and processes that act on them, and still others that consider an object class to be a set of attributes that support a business process.

A significant contributor to this issue is the fact that the Object-Oriented Model is less prescriptive than the Relational Model and object modelers are relatively free to define the concept of an object class to suit their own needs or approaches. That flexibility can be used to advantage, however; an object class can include any set of things with similar behavior, be they entity classes, attributes, or relationships. Date and Darwen7, for example, pursue this argument in interesting directions in their approach to reconciling the O-O and Relational Models. In Chapter 9 we introduce the concept of an Object Class Hierarchy, which can include entity classes, attributes, and

Figure 7.12 An aggregation and a composition.

relationships as a powerful means of capturing business data requirements in the earlier stages of modeling.

7.4.1.5 Aggregations and Compositions

The original UML specification made a distinction between aggregation and composition but many UML modelers do not make such a distinction, perhaps because these terms have been used interchangeably so often. So what is the difference? In an Aggregation each part instance may belong to more than one aggregate instance, and a part instance can have a separate existence. For example, an employee who is part of a team may be part of other teams and will continue to exist after any team to which he/she belongs is deleted.

In a Composition, by contrast, each part instance may belong to only one composite instance, and a part instance cannot have a separate existence, which means that a part instance can only be created as part of a composite instance and deletion of a composite instance deletes all of its associated part instances. For example, an order line that is part of an order may only be part of that order and is deleted when the order is deleted.

7.4.1.6 Qualified Associations

A  Qualified Association is an association with identifying attributes. Unfortunately the designers of UML have chosen to use the same cardinality adornment symbols as for an unqualified association, but with a different meaning, as can be seen in Figure 7.13, in which a piece is rightly constrained

Figure 7.13 Qualified and unqualified associations.

to occupy only one square (at a time) and a square to hold only one piece (at a time) but a chessboard apparently has only one square. What these symbols are meant to convey is that a chessboard has only one square per combination of rank and file. This change of meaning of a symbol depending on context can only hinder understanding of the model by business stakeholders, so we recommend you do not use qualified associations. 
 

7.4.1.7 Generalization and Inheritance

We saw in Section 4.9 that UML’s representation of inheritance structures (superclasses and subclasses) can be ambiguous unless the modeler adopts a disciplined approach to representing them. To recap, the subtypes of a supertype do not have to be nonoverlapping or exhaustive in UML. There are symbols to distinguish these cases, but no compulsion to use them. 
 

7.4.1.8 Diagram Understandability

UML exhibits two major weaknesses in terms of the understandability of diagrams, not only by business reviewers but by analysts and developers (although one of these is shared by some variants of E-R modeling). One of these is the UML notation for relationship cardinality. The use of numerals and asterisks rather than graphic devices to indicate relationship cardinality is not only less intuitive (in that it engages the other side of the brain from the one that is dealing with the implications of a line between two boxes) but also has the potential to lead to confusing diagrams. UML’s representation of inheritance structures (subtype boxes outside rather than inside supertype boxes) can (like some E-R variants) make it difficult to establish what relationships an entity class is involved in, particularly if the inheritance hierarchy is deep (subtypes themselves have subtypes and so on). In that situation the inheritance of a relationship by a subtype can only be inferred by tracing the generalization lines back through the hierarchy of supertypes. 

7.5 Object Role Modeling 

          Object-Role Modeling (ORM) has a long history. Its ancestors include Binary Modeling and NIAM,10 and (more so than most alternative languages) it has been used quite widely in practice and generated a substantial body of research literature.

         Given the semantic richness of this notation, it perhaps deserves to be more popular than it is. Now that more CASE tools (in particular Microsoft Visio™) support ORM diagramming and the generation of business sentences and a relational logical data model from an ORM model, we may see more use made of ORM.

           Figure 7.14 depicts an ORM model. In ORM ellipses represent object classes, which are either entity classes (sets of entity instances) or domains (sets of attribute values). Each multicompartment box represents a relationship between two or more object classes and enables the attributes of an entity class and the relationships in which it participates to be modeled in the same way. This confers a particular advantage in establishing which attributes and relationships of an entity class are mandatory and which are optional (by contrast, E-R modeling uses different mandatory/optional notations for attributes and relationships). ORM also provides a rich constraint language, an example of which is discussed in Section 14.6.2.

         Perhaps the major disadvantage of ORM as a means of capturing business information requirements is that many more shapes are drawn on the page when compared to the E-R or UML representation of the same model. This may make it difficult for business stakeholders to come to grips with, at least initially. It also needs to be said that ORM’s richness means that it

takes longer to learn; we would be the last to suggest that data modelers should not invest time in learning their profession, but simpler languages have consistently proved more attractive. 

7.6 Summary 

     There are a number of alternatives to the simple E-R modeling conventions for conceptual modeling. Relatively few, however, have a significant following in the practitioner community.

     The Chen conventions provide for a more detailed and consistent representation of relationships but are not widely used in practice.

     UML has a substantial following and offers a wide variety of constructs for representing concepts and constraints which require skill to employ correctly and may be difficult for business stakeholders to grasp.

     ORM is a powerful language that has been taken up only sporadically in industry. The lack of a distinction between entity classes and attributes is a key conceptual feature but can lead to diagrams becoming unacceptably complex.

     The professional modeler, even if restricted to using a single language, will gain from an understanding of alternative conventions. 

8.1 Data Modeling in the Real World 

     In the preceding chapters, we have focused largely on learning the language of data modeling without giving much attention to the practicalities of modeling in a real business environment.

     We are in a position not unlike that of the budding architect who has learned the drawing conventions and a few structural principles. The real challenges of understanding a set of requirements and designing a sound data model to meet them are still ahead of us.

     As data modelers, we will usually be working in the larger context of an information systems development or enhancement project, or perhaps a program of change that may require the development of several databases. As such, we will need to work within an overall project plan, which will reflect a particular methodology, or at least someone’s idea of how to organize a project.

     Our first challenge, then, is to ensure that the project plan allows for the development and proper use of high quality data models.

     The second challenge is to actually develop these models or, more specifically, to develop a series of deliverables that will culminate in a complete physical data model and, along the way, provide sufficient information for other participants in the project to carry out their work.

This second part of the book is organized according to the framework for data model development that we introduced in Chapter 1. We commence by gaining an understanding of business requirements then by developing (in turn) conceptual, logical, and physical data models. Finally, we need to maintain the model or models as business requirements change, either before or after the formal completion of the project. Figure 8.1 provides a more detailed picture of these stages. You should note that data model development does not proceed in a strictly linear fashion; from time to time, discoveries we make about requirements or alternative designs will necessitate revisiting an earlier stage. If the project methodology is itself iterative, it will support this (and perhaps encourage too much data model volatility!); conversely if you are following a waterfall method (based on a single pass through each activity), you will need to ensure that mechanisms are in place to enable some iteration and associated revision of documentation.

     Not all methodologies follow the framework exactly. The most common variations are the introduction of intermediate deliverables within the conceptual modeling stage (for example, a high-level model to support system scoping) and the use of an iterative approach in which the modeling stages are repeated, along with other project tasks, to achieve increasing refinement or coverage. None of these variations changes the nature of the tasks, as we describe them, in any substantial way.

     It is beyond the scope of this book to explore in detail the role of data modeling across the range of generic and proprietary methodologies and their local variants. In this chapter we look at the critical data modeling issues in project planning and management, with the aim of giving you the tools to examine critically any proposed approach from a data modeling perspective. We look in some detail at the often-neglected issue of managing change to the data model as it develops within and across the various stages. 
 

8.2 Key Issues in Project Organization 

As a data modeler, you may find yourself participating in the development of a project plan or (perhaps more likely) faced with an existing plan specifying how you will be involved and what you are expected to deliver. What should you look for and argue for? Here is a minimum list. 
 

8.2.1 Recognition of Data Modeling 

Let us repeat what we said in Chapter 1: No database was ever built without a data model. Unfortunately, many databases have been built from models that existed only in the minds of database technicians, and it is not uncommon for projects to be planned without allowing for a data model to be properly developed and documented by someone qualified to do so.

     You are most likely to encounter such a situation in a “short and sharp” project that does not use a formal methodology, or loosely claims allegiance to a “prototyping,” “agile,” or “extreme” approach. Typically, the response to suggestions that a formal data modeling phase be included is that it will take too much time; instead, the database will be developed quickly and modified as necessary.

     You should know the arguments by now: good data modeling is the foundation for good system design, and it is easier to get the foundations right at the outset than to try to move them later.

     If these arguments are not effective, your options are to distance yourself from the project or to do what you can to make the best of the situation. If you opt for the latter, we recommend you rebadge yourself as a “logical database designer” and use the logical database design as the focus of discussion. The same quality issues and arguments will apply, but you

will lack the discipline of staged development and deliverables. 

8.2.2 Clear Use of the Data Model 

It is not sufficient to develop a data model; it is equally important that its role and value be recognized and that it be used appropriately. We have seen projects in which substantial resources were devoted to the development of a data model, only for it to be virtually ignored in the implementation of the system. The scenario is typically one in which lip service is

given to data modeling; perhaps it is part of a mandated methodology or policy, or the development team has been prevailed upon by a central data management or architectures function without truly understanding or being convinced of the place of data modeling in the project.

     The crucial requirement is that the physical data modelas agreed to by the data modeleris the ultimate specification for the database. Another take on this is that any differences between the logical and physical data models must have the data modeler’s agreement.

     Other important uses flow from this requirement. If process modelers and programmers know that the data model will truly form the specification for the database, they will refer to the model in their own work. If not, they will wait for the arrival of the “real” data structures.