Definition: Postconditions - UML

Notice that each of the postconditions in the enterltem example included a learning aid categorization such as instance creation or association formed. Here is a key point:

Postconditions are not actions to be performed during the operation; rather, they are observations about the domain model objects that are true when the operation has finished - after the smoke has cleared.

To summarize, the postconditions fall into these categories:

  • Instance creation and deletion.
  • Attribute change of value.
  • Associations (to be precise, UML links) formed and broken.

Breaking associations is rare. But as an example, consider an operation to allow the deletion of line items. The postcondition could read "The selected Sales - Lineltem's association with the Sale was broken." In other domains, when a loan is paid off or someone cancels their membership in something, associations are broken.

Instance deletion post conditions are most rare, because one does not usually care about explicitly enforcing the destruction of a thing in the real world. As an example: In many countries, after a person has declared bankruptcy and seven or ten years have passed, all records of their bankruptcy declaration must be destroyed, by law. Note that this is a conceptual perspective, not implementation. These are not statements about freeing up memory in a computer occupied by software objects.

How are Post conditions Related to the Domain Model?

These post conditions are expressed in the context of the Domain Model objects. What instances can be created? - those from the Domain Model; What associations can be formed? - those in the Domain Model; and so on.

Motivation: Why Postconditions?

First, they aren't always necessary. Most often, the effect of a system operation is relatively clear to the developers by virtue of reading the use case, talking with experts, or their own knowledge. But sometimes more detail and precision is useful. Contracts offer that.

Notice that the postconditions support fine - grained detail and precision in declaring what the outcome of the operation must be. It is also possible to express this level of detail in the use cases, but undesirable they would be too verbose and low - level detailed.

A contract is an excellent tool of requirements analysis or OOA that describes in great detail the changes required by a system operation (in terms of the domain model objects) without having to describe how they are to be achieved.

In other words, the design can be deferred, and we can focus on the analysis of what must happen, rather than how it is to be accomplished.

Consider these postconditions:

Postconditions:

  • A SalesLineltem instance sli was created (instance creation).
  • sli was associated with the current Sale (association formed).
  • sli.quantity became quantity (attribute modification).
  • sli was associated with a ProductDescription, based onitemID match (association formed).

No comment is made about how a SalesLineltem instance is created, or associated with a Sale. This could be a statement about writing on bits of paper and stapling them together, using Java technologies to create software objects and connect them, or inserting rows in a relational database.

Guideline: How to Writea Postcondition?

Express postconditions in the past tense to emphasize they are observations about state changes that arose from an operation, not an action to happen. That's why they are called postconditions! For example:

  • (better) A SalesLineltem was created rather than
  • (worse) Create a SalesLineltem, or, A SalesLineltem is created.

Analogy: The Spirit of Postconditions: The Stage and Curtain

Why write postconditions in the past tense? Think about them using the following image:

The system and its objects are presented on a theatre stage.

  • Before the operation, take a picture of the stage.
  • Close the curtains on the stage, and apply the system operation (background noise of clanging, screams, and screeches...).
  • Open the curtains and take a second picture.
  • Compare the before and after pictures, and express as postconditions the changes in the state of the stage (A SalesLineltem was created...).

Guideline: How Complete Should Postconditions Be? Agile vs. Heavy Analysis

Contracts may not be useful. This question is discussed in a subsequent section. But assuming some are useful, generating a complete and detailed set of postconditions for all system operations is not likely - or necessary. In the spirit of Agile Modeling, treat their creation as an initial best guess, with the understanding they will not be complete and that "perfect" complete specifications are rarely possible or believable.

But understanding that light analysis is realistic and skillful doesn't mean to abandon a little investigation before programming - that's the other extreme of misunderstanding.

Example: enterItem Postconditions

The following section dissects the motivation for the postconditions of the enter - Item system operation.

Instance Creation and Deletion

After the itemID and quantity of an item have been entered, what new object should have been created? A SalesLineltem. Thus:

  • A SalesLineltem.instance sli was created (instance creation).

Note the naming of the instance. This name will simplify references to the new instance in other post - condition statements.

Attribute Modification

After the itemID and quantity of an item have been entered by the cashier, what attributes of new or existing objects should have been modified? The quantity of the SalesLineltem should have become equal to the quantity parameter. Thus:

  • sli.quantity became quantity (attribute modification).

Associations Formed and Broken

After the itemID and quantity of an item have been entered by the cashier, what associations between new or existing objects should have been formed or broken? The new SalesLineltem should have been related to its Sale, and related to its
ProductDescription. Thus:

  • sli was associated with the current Sale (association formed).
  • sli was associated with a ProductDescription, based on itemID match (association formed).

Note the informal indication that it forms a relationship with a ProductDescription - the one whose itemID matches the parameter. More fancy and formal language approaches are possible, such as using the Object Constraint Language (OCL). Recommendation: Keep it plain and simple.


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

UML Topics