The Object Constraint Language: Getting Your Models Ready for MDA (2nd Edition)

Apart from mending apparent flaws in the model, OCL expressions can also be used to express the same information in a different manner. There are various styles of modeling. This section explains some of the different modeling styles.

3.9.1 Definitions of Attributes or Operations

Attributes or operations may be defined in the class diagram by adding them to a type, but they may also be defined by an OCL expression. In that case, the new attribute or operation need not be shown in the diagram. In the following example, two attributes, wellUsedCards and loyalToCompanies , and one operation, cardsForProgram , are defined:

context Customer def : wellUsedCards : Set( CustomerCard ) = cards->select( transactions.points->sum() > 10,000 ) def : loyalToCompanies : Bag( ProgramPartner ) = programs.partners def : cardsForProgram(p: LoyaltyProgram) : Set(Cards) = p.Membership.card

The expression following the equal sign in an attribute definition indicates how the value of the attribute must be calculated. It is a derivation rule (see Section 3.3.1). For example, the newly defined attribute loyalToCompanies is always equal to the collection of program partners associated with the programs, in which the customer is enrolled. The attribute wellUsedCards is always equal to the set of cards for which the total of points earned with the transactions carried out with that card is larger than 10,000.

The expression following the equal sign in an operation definition states the result of the operation. It is a body expression (see Section 3.3.3). Note that operations defined by an OCL expression are query operations. They cannot have side effects. In the preceding example, the operation cardsForProgram will always result in the set of cards issued for the loyalty program p provided as a parameter to the operation.

3.9.2 The Subset Constraint

A class diagram may contain subset constraints , as shown in Figure 3-13. This constraint means that the set of links for one association is a subset of the set of links for the other association. In Figure 3-13, flightAttendants is a subset of crew . The singleton set pilot is also a subset of crew .

By showing all subset constraints in the diagram, it may become cluttered and difficult to read. In that case, you may choose to specify the subset constraints using OCL expressions. The two subset constraints shown in Figure 3-13 are identical to the following invariants on Flight and Person :

context Flight inv : self.crew->includes(self.pilot) inv : self.crew->includesAll(self.flightAttendants) context Person inv : self.flights->includes(self.captainOn) inv : self.flights->includesAll(self.attendedOn)

3.9.3 Adding Inheritance Versus Invariants

During modeling, we often encounter situations in which we add detail to the class model to specify the real-world situation precisely. For example, suppose we have a simple class diagram of a guitar, in which a guitar has a number of guitar strings. Furthermore, there are two types of guitars: electric and classic. We also have two types of guitar strings. Each guitar type has its own kind of guitar strings.

The association between Guitar and GuitarString specifies that a Guitar has GuitarString s. The association between ClassicGuitar and PlasticString is a redefinition of the same association, which constrains a ClassicGuitar to have PlasticString s only. The generalization between the associations shows that the lower association is a specialization of the upper, more general association. The association between ElectricGuitar and MetalString is also a redefinition of the top association. This situation is depicted in Figure 3-14.

As you can see, the model becomes comparatively complex. It can be simplified using invariants. The two specializations of the upper association can be captured in two invariants on the two types of guitars, as depicted in the class model shown in Figure 3-15. The visual class model becomes more readable, while the level of detail is retained. The invariants are as follows :

context ClassicGuitar inv strings1: strings->forAll(s s.oclIsTypeOf(PlasticString) ) context ElectricGuitar inv strings2: strings->forAll(s s.oclIsTypeOf(MetalString) )

The preceding model can be simplified even more by removing the subclasses of Guitar, GuitarString , or both. If the main reason for having the subclasses is to distinguish between different kinds of strings for different guitars, this simplification makes sense. Depending on the situation, this simplification may result in either Figure 3-16 or Figure 3-17.

Here are the invariants for the class model shown in Figure 3-16:

context ClassicGuitar inv strings3: strings->forAll(type = StringType::plastic) context ElectricGuitar inv strings4: strings->forAll(type = StringType::metal )

Here are the invariants for the class model shown in Figure 3-17:

context Guitar inv strings5: type = GuitarType::classic implies strings->forAll(type = StringType::plastic) context Guitar inv strings6: type = GuitarType::electric implies strings->forAll(type = StringType::metal )

The deciding factor in the trade-off that must be made in these circumstances is which solution will be best in your situation. Figure 3-17 keeps the model simple, because there is no need for subclasses. If no attributes or behaviors are specific to the subclasses, this is a good solution. In Figure 3-16, we have a more elaborate model that is suitable when there are attributes or operations specific to the different subclasses. In Figure 3-14, we have an elaborate model with probably too much detail. This option is desirable only if you want to show all details in the visual diagram. In general, showing your model in graphical or visual form is best for giving a good overview, whereas a textual form is good for adding detail. The art is finding the right balance, and that depends on both the intended use of the model and the intended audience.