Embed Size (px)
Citation preview
An Introduction to Object-Oriented Analysis and Design and the Unified Process “Applying UML and Patterns, 3rd ed.” – Craig Larman, pp. 100 – 196
Kakarontzas George [email protected]
Other Requirements
Use cases document most of the requirements (mostly functional requirements)
Non-functional requirements are usually captured in UP in the Supplementary Specification
Other documents include: The Glossary: terms and definitions The Vision: an executive summary. Communicates
the big ideas behind the project. The Business Rules (or Domain Rules): rules
transcending any particular application (e.g. tax rules)
Supplementary Specification
When first writing a use case, non-functional requirements (the “URPS” in “FURPS”) should be informally written in the Special Requirements section
After that informal step they should be moved to the Supplementary Specification in order to be analyzed more thoroughly and have all non-functional requirements kept in on place, for reference during architectural analysis and design.
On to Elaboration
Elaboration follows Inception and is the second phase of the UP
During Elaboration: the core, risky software architecture is
programmed and tested the majority of requirements are discovered
and stabilized the major risks are mitigated or retired
Key Ideas and Best Practices in Elaboration Do short timeboxed risk-driven iterations Start programming early Adaptively design, implement, and test the core
and risky parts of the architecture Test early, often, realistically Adapt based on feedback from tests, users,
developers Write most of the use cases and other
requirements in detail, through a series of workshops, once per elaboration iteration
UP Artifacts that may start in Elaboration Artifact Comment
Domain Model This is a visualization of the domain concepts; it is similar to a static information model of the domain entities.
Design Model This is the set of diagrams that describes the logical design. This includes software class diagrams, object interaction diagrams, package diagrams, and so forth.
Software Architecture Document
A learning aid that summarizes the key architectural issues and their resolution in the design. It is a summary of the outstanding design ideas and their motivation in the system.
Data Model This includes the database schemas, and the mapping strategies between object and non-object representations.
Use-Case Storyboards, UI Prototypes
A description of the user interface, paths of navigation, usability models, and so forth.
You didn’t understand elaboration when… It is more than "a few" months long for most projects. It only has one iteration (with rare exceptions for well-
understood problems). Most requirements were defined before elaboration. The risky elements and core architecture are not being
tackled. It does not result in an executable architecture; there is
no production-code programming. It is considered primarily a requirements or design
phase, preceding an implementation phase in construction.
You didn’t understand elaboration when… (cont.) There is an attempt to do a full and careful
design before programming. There is minimal feedback and adaptation; users
are not continually engaged in evaluation and feedback.
There is no early and realistic testing. The architecture is speculatively finalized before
programming. It is considered a step to do the proof-of-concept
programming, rather than programming the production core executable architecture.
Use Case Ranking Use cases are ranked for implementation.
Early iterations will implement high ranking use cases and use case scenarios.
For example:
Rank
Requirement (Use Case or Feature)
Comment
High Process Sale Logging …
Scores high on all rankings. Pervasive. Hard to add late. …
Medium Maintain Users …
Affects security subdomain. …
Low … …
Domain Modelling
Domain modelling is concerned with identifying conceptual classes related to the current iteration.
The initial domain model is created during the first iteration of the elaboration phase.
The domain model contains the conceptual classes as well as appropriate attributes and associations.
Process Sale
1. Customer arrives ...2. ...3. Cashier enters item identifier.4....
Use Case Text
Operation: enterItem(…)
Post-conditions:- . . .
Operation Contracts
Sale
date. . .
SalesLineItem
quantity
1..*1 . . .
. . .
the domain objects, attributes, and associations that undergo state changes
Domain Model
Use-Case Model
Design Model
: Register
enterItem(itemID, quantity)
: ProductCatalog
spec = getProductSpec( itemID )
addLineItem( spec, quantity )
: Sale
. . .
conceptual classes in the domain inspire the names of some software classes in the design
conceptual classes – terms, concepts attributes, associations
Cashier: …Item ID: …...
Glossary
elaboration of some terms in the domain model
Require-ments
Business Modeling
Design
Sample UP Artifact Relationships
An Example Domain Model for the POS System
Register
Item
Store
addressname
Sale
date time
Payment
amount
SalesLineItem
quantity
Stocked-in
*
Houses
1..*
Contained-in
1..*
Records-sale-of
0..1
Paid-by
1
1
1
1
1
1
0..1
1
Captured-on
conceptor domain object
association
attributes
Domain Model Definition In the UP, the term "Domain Model" means a
representation of real-situation conceptual classes, not of software objects. The term does not mean a set of diagrams describing software classes, the domain layer of a software architecture, or software objects with responsibilities.
Domain model depicts: Domain objects (or conceptual classes) Associations between conceptual classes Attributes of conceptual classes
It doesn’t contain operations It serves as a visual dictionary of the noteworthy
abstractions, domain vocabulary, and information content of the domain.
Elements not Suitable for a Domain Model A domain model is not a software representation, and some
elements are not appropriate for it: Software classes (such C# or Java classes) Elements representing artifacts related to the implementation of the
system (e.g. a database, or a window) – unless the domain being modeled is of software concepts (e.g. a Graphical User Interface library)
Responsibilities or methods SalesDatabase software artifact; not part
of domain modelavoid
software class; not part of domain model
Sale
datetime
print()
avoid
What are Conceptual Classes?
Formally, a conceptual class may be considered in terms of its symbol, intension, and extension: Symbol words or images
representing a conceptual class.
Intension the definition of a conceptual class.
Extension the set of examples to which the conceptual class applies.
Sale
datetime
concept's symbol
"A sale represents the event of a purchase transaction. It has a date and time."
concept's intension
sale-1
sale-3sale-2
sale-4
concept's extension
Lower Representation Gap
There are two reasons to create a domain model: The first is getting to know the domain during early
elaboration iterations, understanding the concepts involved and their relationships
The second is that the domain model inspires the software classes of the domain layer in the design model. This prevents software from being far away from the reality of the domain. The similarity of concepts in the domain layer with concepts of the domain is known as ‘lower representation gap’.
Lower Representation Gap Example
Payment
amount
Sale
datetime
Pays-for
Payment
amount: Money
getBalance(): Money
Sale
date: DatestartTime: Time
getTotal(): Money. . .
Pays-for
UP Domain ModelStakeholder's view of the noteworthy concepts in the domain.
UP Design ModelThe object-oriented developer has taken inspiration from the real world domain in creating software classes.
Therefore, the representational gap between how stakeholders conceive the domain, and its representation in software, has been lowered.
1 1
1 1
A Payment in the Domain Model is a concept, but a Payment in the Design Model is a software class. They are not the same thing, but the former inspired the naming and definition of the latter.
This reduces the representational gap.
This is one of the big ideas in object technology.
inspires objects
and names in
How to Create a Domain Model
1. Find conceptual classes by a) Reusing existing domain models b) Using a category list c) Identification of noun phrases
2. Draw the identified conceptual classes as UML classes in a class diagram
3. Add to conceptual classes associations and attributes (but not methods)
Common Categories of Domain Classes Business transactions: Sale, Payment Transaction line items: SalesLineItem Product or service related to a transaction
line item: Item Where is the transaction recorded?
Register Roles of people or organization related to
the transaction; actors in the use case: Cashier, Customer, Store
Common Categories of Domain Classes (cont.) Noteworthy events, often with a time or
place, we need to remember: Sale, Payment
Physical objects: Item, Register Descriptions of things: ProductDescription Catalogs: ProductCatalog Containers of things (physical or
information): Store
Common Categories of Domain Classes (cont.) Things in a container: Item Other collaborating systems:
CreditAuthorizationService Records of finance, work, contracts, legal
matters: Receipt, Ledger Financial instruments: Cash, Check Schedules, manuals, documents that are
regularly referred to in order to perform work: DailyPriceChangeList
Noun Phrases Identification
Identify nouns and noun phrases in a textual description of the domain and consider them as candidate conceptual classes and attributes
Caution: Mechanical noun-to-class mapping isn’t
possible Natural language is ambiguous
Using Use Case Text Descriptions to Identify Nouns and Noun Phrases
Main Success Scenario (or Basic Flow): 1. Customer arrives at a POS checkout with goods and/or services
to purchase. 2. Cashier starts a new sale. 3. Cashier enters item identifier. 4. System records sale line item and presents item description,
price, and running total. Price calculated from a set of price rules. Cashier repeats steps 2-3 until indicates done. 5. System presents total with taxes calculated. 6. Cashier tells Customer the total, and asks for payment. 7. Customer pays and System handles payment. 8. System logs the completed sale and sends sale and payment
information to the external Accounting (for accounting and commissions) and Inventory systems (to update inventory).
9. System presents receipt. 10. Customer leaves with receipt and goods (if any).
Drawing Conceptual Classes as UML Classes After discovering the conceptual classes we can
start creating our domain model, as in the figure which contains the conceptual classes for the initial POS domain model.
StoreRegister SaleItem
CashPayment
SalesLineItem Cashier Customer
ProductCatalog
ProductDescription
Ledger
Report Objects & Domain Vocabulary Don’t include Report Objects (e.g. Receipt) since
their information is derived by other conceptual classes. Include them only when they have a special role in
terms of business rules (e.g. a receipt entitles the bearer to return purchased items).
Use the domain vocabulary Use the existing names in the territory Exclude irrelevant out-of-scope features Do not add things that are not there.
Modeling the Unreal World
Modeling the unreal world (e.g. telecommunication systems): Requires a high degree of abstraction,
listening carefully to the core vocabulary and concepts the domain experts use (e.g. message, connection, port, dialog, route, protocol are conceptual classes for telecom. systems)
Is this Concept an Attribute or a Class? Attributes vs. Classes: perhaps the most common
mistake is representing something as an attribute when it should be represented as a class. Rule: If we do not think of some conceptual class X
as a number or text in the real world, X is probably a conceptual class, not an attribute
When do we Need Descriptions? Add a description class (for example, ProductDescription) when:
There needs to be a description about an item or service, independent of the current existence of any examples of those items or services.
Deleting instances of things they describe (for example, Item) results in a loss of information that needs to be maintained, but was incorrectly associated with the deleted thing.
It reduces redundant or duplicated information. Item
descriptionpriceserial numberitemID
ProductDescription
descriptionpriceitemID
Item
serial numberDescribes Better
Worse
1 *
Another Description Example Assume we have an
airline with a number of flights. We use a FlightDescription to describe the service of a particular flight (i.e. it’s route) regardless of whether this particular flight is scheduled at the moment or not.
Worse
Flight
datetime
FlightDescription
number
Airport
name
Describes-flights-to
Described-by
Flight
datenumbertime
Airport
nameFlies-to
Better
1*
1*
1
*
Associations in Domain Models
We use associations in domain models in order to: Denote a relationship that needs to be preserved for
some duration (“need-to-remember” associations) Denote associations derived from the Common
Associations List (i.e. common categories of associations)
Example: We need to remember what SalesLineItem instances
are associated with a Sale, otherwise it would not be possible to reconstruct a sale, print a receipt, or calculate a sale total.
Associations on Domain Models Be parsimonious about adding too many association
lines. Use the “need-to-remember” criterion and avoid “visual noise”.
During domain modeling an association is not a statement about : data flows foreign key relationships instance variables, or object connections
It is more a statement a relationship is meaningful in the real domain (from a conceptual perspective).
Many such relationships, however, will be implemented in software as paths of navigation and visibility (both in Design and Data models).
Association Notation
An association is represented as a line between classes with a capitalized association name.
The ends of an association may contain a multiplicity expression indicating the number of instances that may participate in the association.
SaleRegisterRecords-current
1 1
association
Direction of Association The association is inherently bidirectional. This traversal
is purely abstract; it is not a statement about connections between software entities.
An optional "reading direction arrow" indicates the direction to read the association name.
SaleRegister Records-current 0..11
association name multiplicity
-"reading direction arrow"-it has no meaning except to indicate direction of reading the association label-often excluded
Names of Associations
Name an association based on a ClassName-VerbPhrase-ClassName format where the verb phrase creates a sequence that is readable and meaningful.
In naming associations avoid vague phrases or phrases that don’t enhance understanding of the domain For example
Sail Paid-by CashPayment Not “Sale Uses CashPayment”
In general avoid names such as “Has” or “Uses”
UML Roles
Each end of an association is called a role.
Roles may optionally have: multiplicity expression name navigability
Multiplicity
Multiplicity defines how many instances of a class A can be associated with one instance of a class B
ItemStore Stocks
*
multiplicity of the role
1
zero or more; "many"
one or more
one to 40
exactly 5
T
T
T
T
*
1..*
1..40
5
T3, 5, 8
exactly 3, 5, or 8
Comments on Multiplicity Multiplicity is about associations at a particular moment
(e.g. a Person can be Married-To one other Person at a particular moment)
Multiplicity, even in domain models, is affected by the reason we develop software: for example if a Person works for one company at a time or many depends on why we’re building the software for (tax department or union).
What is the correct multiplicity for the Store-Item association in the following figure (1 or 0..1)?
ItemStore Stocks 1
or 0..1
*
Multiple Associations Between two Classes Two classes may have multiple associations
between them The following example is from the airlines
domain
Flight Airport
Flies-to
Flies-from
*
* 1
1
Finding Associations from a Common Associations List
Category Examples A is a transaction related to another transaction B CashPayment-Sale
Cancellation-Reservation A is a line item of a transaction B SalesLineItem-Sale A is a product or service for a transaction (or line item) B
Item-SalesLineItem (or Sale) Flight-Reservation
A is a role related to a transaction B Customer-Payment Passenger-Ticket
A is a physical or logical part of B Drawer-Register Square-Board Seat-Airplane
A is physically or logically contained in/on B Register-Store, Item-Shelf Square-Board Passenger-Airplane
Finding Associations from a Common Associations List (cont.)
Category Examples A is a description for B ProductDescription-Item
FlightDescription-Flight A is known/logged/recorded/reported/ captured in B
Sale-Register Piece-Square Reservation-FlightManifest
A is a member of B Cashier-Store Player-MonopolyGame Pilot-Airline
A is an organizational subunit of B Department-Store Maintenance-Airline
A uses or manages or owns B Cashier-Register Player-Piece Pilot-Airplane
A is next to B SalesLineItem-SalesLineItem Square-Square City-City
Partial POS Domain Model
Register
ItemStore
Sale
CashPayment
SalesLineItem
CashierCustomer
ProductCatalog
ProductDescription
Stocks
*
Houses
1..*
Used-by
*
Contains1..*
Describes
*
Captured-on
Contained-in
1..*
Records-sale-of
0..1
Paid-by Is-for
Logs-completed
*
Works-on
11
1
1 1..*
1
1
1
1
1
1
1
0..1 1
1
Ledger
Records-accounts-
for
1
1
Attributes
Attributes are information that we need to remember The date and the time of a
Sale The total amount of the
sale The ID number of a
Cashier In UML class diagrams
attributes are shown in the second compartment of the class box.
Sale
dateTime/ total : Money
attributes
derived attribute
Full Attribute UML Syntax The full syntax for an attribute in the UML is:
visibility name : type multiplicity = default {property-string} Where:
Visibility: Is +, -, # or ~ Name: Is the name of the variable Type: is a data type such as Integer, Date, String etc. Multiplicity: is the multiplicity of the variable (e.g.
[0..20]) Default: is the default value for the variable Property-String: a property of the variable such as
{readOnly} or {frozen} As a convention, if visibility is missing, it is
assumed to be private (-).
Attribute Examples Sale
- dateTime : Date- / total : Money
Private visibility attributes
Math
+ pi : Real = 3.14 {readOnly}
Public visibility readonly attribute with initialization
Person
firstNamemiddleName : [0..1]lastName
Optional value
As a guideline: put all attributes in the UP Glossary, in addition to the Domain Model, since the Glossary serves as the dictionary of the domain. Alternatively, use a tool that integrates UML models with a data dictionary.
Derived Attributes The total attribute in the Sale can be calculated or derived from the
information in the SalesLineItems. When we want to communicate that 1) this is a noteworthy attribute, but 2) it is derivable, we use the UML convention: a / symbol before the attribute name.
SalesLineItem ItemRecords-sale-of 10..1
SalesLineItem ItemRecords-sale-of 0..1 1..*
Each line item records a separate item sale.For example, 1 tofu package.
Each line item can record a group of the same kind of items.For example, 6 tofu packages.
SalesLineItem
/quantity
ItemRecords-sale-of 0..1 1..*
derived attribute from the multiplicity value
Attributes have Data Types
The attributes in a domain model should preferably be data types. Very common data types include: Boolean, Date (or DateTime), Number, Character, String (Text), Time.
Other common types include: Address, Color, Geometrics (Point, Rectangle), Phone Number, Social Security Number, Universal Product Code (UPC), SKU, ZIP or postal codes, enumerated types
Avoid Showing Complex Concepts as Attributes
Cashier
namecurrentRegister
Cashier
name
Register
numberUses
Worse
Better
not a "data type" attribute
1 1
Flight
Flight
destinationWorse
BetterFlies-to Airport1 1
destination is a complex concept
Data Types vs. Classes
Data type is a UML term that implies a set of values for which unique identity is not meaningful. By contrast classes represent entities in which identifying between different instances is meaningful even when their value might be the same.
Data types are also immutable
When to Define new Data Types
Represent what may initially be considered a number or string as a new data type class in the domain model if: It is composed of separate sections.
phone number, name of person There are operations associated with it, such as parsing or
validation. social security number
It has other attributes. promotional price could have a start (effective) date and end date
It is a quantity with a unit. payment amount has a unit of currency
It is an abstraction of one or more types with some of these qualities. item identifier in the sales domain is a generalization of types such
as Universal Product Code (UPC) and European Article Number (EAN)
Data Types as Classes in the Conceptual Model Should we show data types as class boxes in the
domain model? There is no correct answer: it depends on how the domain model
is being used as a tool of communication, and the significance of the concept in the domain.
OK
OK
ProductDescription
ProductDescription
itemId : ItemID
1Store
Store
address : Address
11 1ItemID
idmanufacturerCodecountryCode
Address
street1street2cityName...
Modeling Quantities and Units Most numeric quantities should not be represented as plain
numbers. Consider price or weight. Saying "the price was 13" or "the weight was 37" doesn't say much. Euros? Kilograms?
it is common to require knowledge of the unit to support conversions Payment
amount : Number
Payment Quantity
amount : Number
Unit
...
Payment
amount : Quantity
Has-amount1*
Is-in1*
not useful
quantities are pure data values, so are suitable to show in attribute section better
Payment
amount : Money
variation: Money is a specialized Quantity whose unit is a currency
POS Domain Model with Attributes
Register
id
ItemStore
nameaddress
Sale
dateTime/ total
CashPayment
amountTendered
SalesLineItem
quantity
Cashier
id
Customer
ProductCatalog
ProductDescription
itemIDdescriptionprice
Stocks
*
Houses1..*
Used-by
*
Contains1..*
Describes
*
Captured-on
Contained-in
1..*
Records-sale-of
0..1
Paid-by Is-for
Logs-completed
*
Works-on
11
1
1 1..*
1
1
1
1
1
1
1
0..1 1
1
Ledger
Records-accounts-
for
1
1
Domain Models Within the UP Discipline Artifact Incep. Elab. Const. Trans.
Iteration I1 E1..En C1..Cn T1..T2
Business Modeling Domain Model s Requirements Use-Case Model (SSDs) s r
Vision s r Supplementary Specification s r Glossary s r
Design Design Model s r SW Architecture Document s Data Model s r
s: start, r: refine
System Sequence Diagrams (SSD)
A system sequence diagram (SSD) is a fast and easily created artifact that illustrates input and output events related to the systems under discussion.
They are used for operation contracts as well as input to object design.
The UML contains notation in the form of sequence diagrams to illustrate events from external actors to a system.
Operation: enterItem(…)
Post-conditions:- . . .
Operation Contracts
Sale
date. . .
SalesLineItem
quantity
1..*1 . . .
. . .
Domain Model
Use-Case Model
Design Model: Register
enterItem(itemID, quantity)
: ProductCatalog
spec = getProductSpec( itemID )
addLineItem( spec, quantity )
: Sale
Require-ments
Business Modeling
Design
Sample UP Artifact Relationships
: System
enterItem(id, quantity)
Use Case Text
System Sequence Diagrams
makeNewSale()
system events
Cashier
Process Sale
: Cashier
use case
names
system operations
Use Case Diagram
Vision
SupplementarySpecification
Glossaryparameters and
return value details
starting events to design for
Process Sale
1. Customer arrives ...2. Cashier makes new sale.3. ...
What is Depicted in an SSD
An SSD shows, for a particular course of events within a use case, the external actors that interact directly with the system, the system (as a black box), and the system events that the actors generate. Time proceeds downward, and the ordering of events should follow their order in the scenario.
SSD for a Process Sale Scenario
enterItem(itemID, quantity)
:System: Cashier
endSale
makePayment(amount)
a UML loop interaction frame, with a boolean guard expression
external actor to system
Process Sale Scenario
system as black box
the name could be "NextGenPOS" but "System" keeps it simple
the ":" and underline imply an instance, and are explained in a later chapter on sequence diagram notation in the UML
a message with parameters
it is an abstraction representing the system event of entering the payment data by some mechanism
description, total
return value(s) associated with the previous message
an abstraction that ignores presentation and medium
the return line is optional if nothing is returned
total with taxes
change due, receipt
makeNewSale
[ more items ]loop
What are SSDs? Use cases describe how external actors interact with
the software system we are interested in creating. During this interaction an actor generates system events to a system, usually requesting some system operation to handle the event.
The UML includes sequence diagrams as a notation that can illustrate actor interactions and the operations initiated by them.
A system sequence diagram is a picture that shows, for one particular scenario of a use case, the events that external actors generate, their order, and inter-system events. All systems are treated as a black box; the emphasis of the diagram is events that cross the system boundary from actors to systems.
Guideline: Draw an SSD for a main success scenario of each use case, and frequent or complex alternative scenarios.
Why Draw an SSD?
Because it is useful to know precisely what are the external input events, the system events, to which the system should react.
System events include: External events from actors (humans or computers) Timer events Faults or exceptions (usually caused by external
events). SSDs depict system behavior in terms of what
the system does, not how it does it. System behavior is also captured by use cases and operation contracts (to be discussed later).
Relation between SSDs and UML Sequence Diagrams The UML does not define something
called System Sequence Diagrams. We use the general UML sequence diagram notation to create system sequence diagrams.
The term ‘system’ in SSDs is used to emphasize the application of the UML sequence diagram to systems viewed as black boxes.
Relationship Between SSDs and Use Cases
: Cashier :System
Simple cash-only Process Sale scenario:
1. Customer arrives at a POS checkout with goods and/or services to purchase.2. Cashier starts a new sale.3. Cashier enters item identifier.4. System records sale line item and presents item description, price, and running total. Cashier repeats steps 3-4 until indicates done.5. System presents total with taxes calculated.6. Cashier tells Customer the total, and asks for payment.7. Customer pays and System handles payment....
enterItem(itemID, quantity)
endSale
makePayment(amount)
description, total
total with taxes
change due, receipt
makeNewSale
[ more items ]loop
Process Sale Scenario
How to name System Events and Operations? System events should be expressed at the
abstract level of intention rather than in terms of the physical input device.
Which is better: scan(itemID) or enterItem(itemID)? The enterItem name is better since it
communicates intention rather than the input device.
SSDs and the UP
UP doesn’t mention explicitly SSDs, but you can use them since the UP is very flexible allowing any useful technique to be applied in its context.
Most SSDs are created during elaboration, when it is useful to identify the details of the system events to clarify what major operations the system must be designed to handle, write system operation contracts, and possibly to support estimation
Operation Contracts
Operation contracts use a pre- and post-condition form to describe detailed changes to objects in a domain model, as the result of a system operation.
Although operation contracts are usually used in a Design Model for object methods, they can also be used in a Domain Model as contracts of high-level system operations.
Operation: enterItem(…)
Post-conditions:- . . .
Operation Contracts
Sale
date. . .
SalesLineItem
quantity
1..*1 . . .
. . .
Domain Model
Use-Case Model
Design Model: Register
enterItem(itemID, quantity)
: ProductCatalog
spec = getProductSpec( itemID )
addLineItem( spec, quantity )
: Sale
Require-ments
Business Modeling
Design
Sample UP Artifact Relationships
: System
enterItem(id, quantity)
Use Case Text
System Sequence Diagrams
makeNewSale()
system events
Cashier
Process Sale
: Cashier
use case
names
system operations
Use Case Diagram
Vision
SupplementarySpecification
Glossary
starting events to design for, and more detailed requirements that must be satisfied by the software
Process Sale
1. Customer arrives ...2. ...3. Cashier enters item identifier.
the domain objects, attributes, and associations that undergo changes
requirements that must be satisfied by the software
ideas for the post-conditions
What are the Sections of a Contract? Operation: Name of operation, and parameters Cross References: Use cases this operation
can occur within Preconditions: Noteworthy assumptions about
the state of the system or objects in the Domain Model before execution of the operation. These are non-trivial assumptions the reader should be told.
Postconditions: This is the most important section. The state of objects in the Domain Model after completion of the operation.
Example: the enterItem system operation contract Operation: enterItem(itemID: ItemID, quantity:
integer) Cross References: Use Cases: Process Sale Preconditions: There is a sale underway. Postconditions:
A SalesLineItem 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
on itemID match (association formed).
Postcondition Definition
The postconditions describe changes in the state of objects in the domain model. Domain model state changes include: instances created or deleted associations (or to be precise, UML links
which are instantiations of associations) formed or broken, and
attributes changed value.
Discussion on Postoconditions
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.
Breaking associations is rare Example: Operation for the deletion of line items
Instance deletions are most rare: Example: 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: this is a conceptual perspective, not implementation. These are not statements about freeing up memory in a computer occupied by software objects.
Why Postconditions
Postconditions are only necessary when the outcome of a system operation is not clear from the use case description. We could put these conditions in the use case, but
that would make them too verbose. Contracts are excellent tool for requirements
analysis: they describe in detail the changes required by system operations (in terms of the domain model objects), without describing how they are achieved.
The Most Common Mistake in Writing Contracts 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! For example:
A SalesLineItem instance sli was created (instance creation).
sli was associated with the current Sale (association formed).
In this example instance creation is followed by an association formation.
UML Formal Definitions of Operations and Methods “An operation is a specification of a
transformation or query that an object may be called to execute.”
“[A method is] the implementation of an operation. It specifies the algorithm or procedure associated with an operation.”
In the UML metamodel operations have a signature (name and parameters) and are associated with constraints (preconditions and postconditions).
The formal language for expressing constraints in UML is OCL (Object Constraint Language).
