To this point, the UML has expressed the simple business rules such as integrity constraints and domain constraints with standard notation. There are many business rules that go beyond these simple constraint expression
mechanisms in the UML. The UML therefore provides a formal language for expressing these constraints: the UML Object Constraint Language (OCL) [Rational Software 1997c]. There is no room to go into the details of the OCL here; consult the language specification if you want to use it.
Note
You can express constraints in whatever language is appropriate as long as it meets the requirements. A constraint is a Boolean expression that evaluates to true or false (not null) at the end of each transaction in whatever context you place it. The expression cannot have side effects on the state of that context object. You can use an SQL or OQL expression, for example, instead of OCL, or you can use Java, Smalltalk, or first-order predicate calculus if that makes sense to you. In some systems such as Oracle8, you do have to avoid language that results in side effects on object state, which you can't use in constraints.
Where can you use OCL expressions in UML diagrams?
Classes and types: >Constraints on all instances of the class or type (class invariants)
Operations: >Pre- and postconditions and other constraints on operation behavior
Transitions/flows: >Guard conditions in state transition and activity diagrams
As an extension, you can also use the class invariant expressions on the individual attributes of a class diagram to express rules on each attribute. As with SQL CHECK constraints, there is really no limit on what you can express with
such constraints, but it is often convenient to place the rule with the attribute to which it applies.
The UML notation for constriants is a note attached to the constrained object. Figure 7-20 shows a simple class invariant constraint on the CriminalOrganization class. The constraint, expressed in SQL, tells you that a criminal organization cannot simultaneously have a LegalStatus of "LegallyDefined" and a Prosecution Status of anything but "History" In English, if you have successfully had a court define an organization as a criminal organization, your prosecution status must be "History" meaning you've won your case.
Summary
This exceptionally long chapter is very hard to summarize, since it is itself a summary of a much larger corpus, the UML specification. The chapter focuses on those parts of the UML notational system that are of direct use in data modeling and database design.
Most of the UML classifiers play some kind of role in database design: packages, subsystems, types, interfaces, database, and classes are all elements of such a design. As well, the association, generalization, and realization relationships of UML play a direct role in data modeling by relating classifiers to one another.
You use package and subsystems to build the high-level architecture of your database application. These classifiers represent a name space that organizes your classes and other subsysems into cleanly separable units. You specify those units with transactional use cases, and you realize the use cases with the various classifiers that collaborate with each other. In this way, you build up the data model that realizes the transactions your requirements specify. Classes may be abstract (no instances) or concrete. Each class has a set of attributes and operations, with attributes and their data types representing the state of the class (the data) and operations being the behavior. Methods are the implementation of the operations. Both attributes and operations have public, protected, or private visibility, a feature that gives you the ability to encapsulate your data and operations within the class, reducing overall coupling in your subsystems.
The generalization relationship lets you relate classifiers into an inheritance hierarchy, with either single or multiple inheritance. You should avoid multiple inheritance in your design whenever possible. you can use interfaces to avoid mix-in multiple inheritance while still maintaining a strongly typed design.
The association relationship lets you relate classifiers into a visibility hierarchy. Each side of an association is a role that a classifier plays. Each role has a multiplicity (1, *, 0..*, 2..6, and so on) that tells you how many objects may link to other objects through the association. A composite aggregation strengthens the association to ownership instead of just visibility: the parent owns the child object. Associations can themselves become objects through association classes, which have their own attributes and operations.
Finally, you can use UML to specify constraints on your classifiers and relationship. Object identity may be implicit (the UML standard) or explicit (the extended {OID} and }alternate OID}) tags. You can place domain constraints on define with the type classifier). You can use extended tags to specify data model constraints, such as {nullable}. you can specify arbitrarily complex constraints through constraint comments, boxes you attach to the constrained notation. You can use any kind of constraint language ranging from the UML's OCL to SQL expressions. Now you've seen most of the UML relevant to data modeling. The next chapter brings everything together in the process of data model design.
Chapter 8: Patterns of Data Modeling
Imagination continually frustrates tradition; that is its function.John Pfeiffer
Overview
Design in the object-oriented world has taken an odd turn in recent years. The usual course of design in the software world is revolution upon revolution. Every new generation of designer ignores what came before and builds a new way of doing what needs doing. The evolution of programming languages over the last 30 years reflects this revolutionary way of thinking, to the consternation of experienced language designers.
In the OO world, designers have begun to accept that there are aspects of design that should not change, or should change very little. Much of the rationale for this thinking comes from the fact that OO designers emphasize
architectural design thinking and philosophy could apply just as well to software design. These software architects adapted the work of Christopher Alexander, the great architectural philosopher, to software design through the concept of the pattern:
Design patterns capture solutions that have developed and evolved over time. Hence they aren't the designs people tend to generate initially. They reflect untold redesign and recoding as developers have struggled for greater reuse and flexibility in their software. Design patterns capture these solutions in a succinct and easily applied form. [Gamma et al. 1995, p. xi]
The essence of a pattern is tradition. The tradition is the core of the solution. The funny thing about traditions is that they constantly confront imagination, and vice versa. Design patterns, like most traditions, help establish a context for your solution to a design problem. Your imagination then takes over to move beyond the tradition to solve the problem. Occasionally, your imagination comes up with the beginnings of a new pattern—"out of the box" thinking, as many people now call it. If you spend all your time out of the box, however, you won't get very far with your work. This chapter shows you how to use patterns in your data modeling. It provides examples of some common abstract and concrete solutions to data modeling problems and suggests ways you can move beyond patterns to achieve working solutions to specific problems.
The art of building a database-centric system doesn't lie with the notation you use but rather with your use of the notation. As you go through the examples of analysis and design patterns, think about the modeling techniques from
Chapter 7 and how they apply to the patterns. The thinking itself, and its expression through UML, is the essence of designing databases. This data modeling, reusing patterns and integrating views of the data, prepares the way for the more concrete tasks of implementing the conceptual and physical schemas.