Slide 5 of 42
Notes:
Putting a little more flesh on the goal, we can write it more precisely by looking at the types of the actors.
This example shows how we can state exactly what the transaction achieves by modeling the cash and goods assets of the actors. The goal is a postcondition, a boolean expression relating the states immediately before and after any occurrence of the use-cas
Notice how we are using the type model to provide the vocabulary for defining the use-cases. This is an example of how Catalysis provides coherence between UML models.
Notice also how the goal is precisely defined, even though we have said nothing about how the effect is achieved. It encompasses mail-order, private transactions, shop sales, by cash or card or barter: the stated goal includes all these varieties and more
This example may be a domain or ëbusinessí model, describing interactions between people or companies; but we can use exactly the same techniques in software design, to describe interactions between large or small pieces of software, or between software a
If this is part of a software specification, the goal can be used as the basis for a test harness. Quality Assurance people like the idea of test plans being laid early.
* The goal is a postcondition, not an imperative statement. The idoiom x += y is here short for x == x@pre + y, where @pre is a UML keyword referring to the previous state.
* Other forms of goal include guarantees, which state what an ongoing process achieves for the duration it is in place.
* In UML, actors are types used in a specific way; those types can be drawn in a type diagram. In several of the current tools, attributes, associations and use-cases can all be presented on the same diagram like this; but that isnít essential to the tech