Guideline: How to Create and Write Contracts - UML

Apply the following advice to create contracts:

  1. Identify system operations from the SSDs.
  2. For system operations that are complex and perhaps subtle in their results, or which are not clear in the use case, construct a contract.
  3. To describe the postconditions, use the following categories:
    • instance creation and deletion
    • attribute modification
    • associations formed and broken

Writing Contracts

  1. As mentioned, write the postconditions in a declarative, passive past tense form (was ...) to emphasize the observation of a change rather than a design of how it is going to be achieved. For example:
    • better) A SalesLineltem wascreated.
    • (worse) Create a SalesLineltem.
  2. Remember to establish an association between existing objects or those newly created. For example, it is not enough that a new SalesLineltem instance is created when the enterltem operation occurs. After the operation is complete, it should also be true that the newly created instance was associated with Sale; thus:
    • The SalesLineltem was associated with the Sale(association formed).

What's the Most Common Mistake?

The most common problem is forgetting to include the forming of associations. Particularly when new instances are created, it is very likely that associations to several objects need be established. Don't forget!

Changes to the POS Domain Model

There is at least one point suggested by these contracts that is not yet represented in the domain model: completion of item entry to the sale. The end Sale specification modifies it, and it is probably a good idea later during design work for the make Payment operation to test it, to disallow payments until a sale is complete (meaning, no more items to add).

One way to represent this information is with an is Complete attribute in the Sale:

There are alternatives, especially considered during design work. One technique is called the State pattern. Another is the use of "session" objects that track the state of a session and disallow out - of - order operations; this will be explored later.

Example: Monopoly Contracts

I'll use this case study to emphasize that many analysis artifacts aren't always needed, including contracts. The UP encourages avoiding creating an artifact unless it addresses a risk or solves a real problem. People who know the rules of the game from experience as a child or teenager (most people, it seems) can implement it without looking at many written details.

All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

UML Topics