1

It's maybe an old horse to beat (not dead yet?), but I'm wondering if OCL allows modeling the problem of the business rules for building houses and hotels in the game of Monopoly within a domain model (conceptual class diagram, separate from an implementation).

I've supplied the rules after my naive attempt, but I'm not sure how to go about capturing the ordering aspects in OCL. That is, one must own all properties of a colour-group, then build the houses on those properties "evenly" (see below), then replace the 4 houses on a property with a hotel, etc. There is also the case of a "housing shortage" because there are only a total of 32 houses and 8 hotels in the game. I realize this question is ambitious, but I'm trying to see if it's possible in OCL and to have some pointers of where to go.

So far, I've managed to specify the fact that a property can't have houses and hotels at the same time with the {xor} option between two associations.

enter image description here

Model done with PlantUML/PlantText.

Here are the rules concerning Houses and Hotels, cited from a fan site.

HOUSES

When a player owns all the properties in a colour-group they may buy houses from the Bank and erect them on those properties.

If you buy one house, you may put it on any one of those properties. The next house you buy must be erected on one of the unimproved properties of this or any other complete colour-group you may own.

The price you must pay the Bank for each house is shown on your Title Deed card for the property on which you erect the house. The owner still collects double rent from an opponent who lands on the unimproved properties of there complete colour-group.

Following the above rules, you may buy and erect at any time as many houses as your judgement and financial standing will allow. But you must build evenly, i.e., you cannot erect more than one house on any one property of any colour-group until you have built one house on every property of that group. You may then begin on the second row of houses, and so on, up to a limit of four houses to a property. For example, you cannot build three Houses on one property if you have only one house on another property of that group.

As you build evenly, you must also break down evenly if you sell houses back to the Bank (see SELLING PROPERTY).

HOTELS

When a player has four houses on each property of a complete colour-group, they may buy a hotel from the Bank and erect it on any property of the colour-group. They return the four houses from that property to the Bank and pay the price for the hotel as shown on the Title Deed card. Only one hotel may be erected on any one property.

N.B. This is not a homework, although it would make a great one maybe for a graduate class?

5
  • Might be a silly question, but "OCL" = "Object Constraint Language" right? It's not something I've seen before. – Greg Burghardt Jul 11 '17 at 20:02
  • @GregBurghardt indeed, part of UML. – Fuhrmanator Jul 11 '17 at 20:16
  • Driveby downvoters gonna downvote. – Fuhrmanator Jul 12 '17 at 1:09
  • Nice edit of the diagram. Much more comprehensive ! The next step would be to have a class property and two specialisations "constructible property" (whwich is the one that you already have) and "utility property" (like trainstations, that you can own but you're not allowed to construct anything on it). – Christophe Jul 12 '17 at 16:17
  • 1
    @Christophe Yeah, Craig Larman has a pretty detailed domain model of Monopoly in his Applying UML and Design Patterns book (ch. 31). I didn't want to put all the details here, since it would be unreadable and I was more interested in the construction aspect (not covered in his book). In the model he suggested, a LotSquare (Terrain en français) is what would be a Property in this model. – Fuhrmanator Jul 12 '17 at 18:28
3

With OCL, you can document class invariants like for example structural constraints in your class diagram, like for example:

  • "a constructible property can have either 1 hotel or 0..4 houses" (i.e. your {xor} between two links)
  • "1 house or more, and one 1 hotel, require that all the other constructible properties of the same group (color) belong to the same player". This requires that you identify the group and the player ownership in your class diagram and use OCL collection operations (e.g. forAll and Exist)
  • "having n houses on a property requires that all the other properties of the same group have at least n-1 houses" (same principle as above)
  • "having an hotel on a property requires that all other properties of the same group have at least 4 houses or an hotel".

However, the UML contraints in a class diagram are not really designed to document dynamic constraints in a class diagram.

Of course, OCL allows you to define pre and post conditions on methods (i.e. pre and post keywords). This could express that "before adding an hotel, you'd need 4 houses on the property, and that after adding the hotel you have no longer any house". However, these kind of constraints make diagrams quickly unreadable for the common mortals. And readability is the main purpose of UML diagrams.

A more pleasant approach would be to use a state diagram to document the allowable state transitions and the corresponding constraints. This has the benefit of making a clear distinction between structural constraints and behavioral constraints.

4
  • 1
    I updated the model per your answer. Building evenly is indeed a state machine. It makes sense that you can't easily specify behavior in a static diagram. I misunderstood what OCL does. – Fuhrmanator Jul 12 '17 at 14:50
  • 1
    Some analysis/design methodologies defer assigning methods to classes until responsibilities have been decided in the design. For example, the method to add a house to a property might be done in a controller rather than the Property domain class, because it provides a better design in terms of coupling/cohesion/reuse/etc. Defining OCL (pre/post conditions) used with methods seems to be very useful to do early and is supposed to be implementation-dependent. But if analysis models have no methods, where are the OCL pre/post conditions? In use cases, activity diagrams, state machines? – Fuhrmanator Jul 12 '17 at 14:58
  • Indeed, design by contract and responsibility driven design adress such issues. However for deciding where such methods should go, you'd better consider domain driven design: "adding a house to a property" belongs to the game. So it should be in the model. The controller may invoke the method from the model and offer a similar interface, but the principle of separation of concerns and encapsulation should speak in favor of the property. – Christophe Jul 12 '17 at 16:31
  • UML and OCL are very expressive. However, they are not meant to replace a programming language. Complex pre and post condition should better be expressed in the code (as asserts) than in OCL (or you'd do the work twice, one in OCL and one in the code, and sooner or later both won't be synched anymore). Any diagram with more than 6-8 elements become difficult to read for most people, if you add to that a lot of OCL constraints which are not critical for understanding the general design, the model will become overcomplicated. You may use OCL for state transition guards and events. – Christophe Jul 12 '17 at 16:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.