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:
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:
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:
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.
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:
Note the naming of the instance. This name will simplify references to the new instance in other post - condition statements.
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:
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
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.
UML Related Interview Questions
|Adv Java Interview Questions||Java collections framework Interview Questions|
|Design Patterns Interview Questions||Rational robot Interview Questions|
|Web semantic Interview Questions||Spring MVC Framework Interview Questions|
|Advanced C++ Interview Questions||Advanced jQuery Interview Questions|
|XML DOM Interview Questions||Object Oriented Analysis and Design Interview Questions|
Object-oriented Analysis And Design
Iterative, Evolutionary, And Agile
Inception Is Not The Requirements Phase
Iteration 1 Basics
System 'sequence Diagrams
Requirements To Design-iteratively
Logical Architecture And Uml Package Diagrams
On To Object Design
Uml Interaction Diagrams
Uml Class Diagrams
Grasp: Designing Objects With Responsibilities
Object Design Examples With Grasp
Designing For Visibility
Mapping Designs To Code
Test - Driven Development And Refactoring
Uml Tools And Uml As Blueprint
Iteration 2 - More Patterns
Quick Analysis Update
Grasp: More Objects With Responsibilities
Applying Gof Design Patterns
Iteration 3 Intermediate Topics
Uml Activity Diagrams And Modeling
Uml State Machine Diagrams And Modeling
Relating Use Cases
Domain Model Refinement
More Ssds And Contracts
Logical Architecture Refinement
More Object Design With Gof Patterns
Designing A Persistence Framework With Patterns
Uml Deployment And Component Diagrams
Documenting Architecture: Uml & The N+1 View Model
More On Iterative Development And Agile Project Management
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.