Slides Part 2 (OOA, pages 1-128, pdf, 4 slides per page)

LITERATURE
The Fusion Method using UML
Dereck Coleman, Patrick Arnold, Stephanie Bodoff, Chris Dollin, Helena
Gilchrist, F. Hayes and P. Jeremaes:
Object-Oriented Development: The Fusion Method
Prentice-Hall, 1994
(out of print)
1
3
THE FUSION METHOD
➠ was developed by Hewlett-Packard
➠ not only offers notations, but also a methodological guidance
➠ consists of developing a series of models
➠ covers the phases OOA, OOD, OOP
➠ in this lecture: OOA, OOD
➠ prerequisite: The result of an informal requirements elicitation is available
2
Overview
4

ANALYSIS
➠ Goal: Comprehension and description of the visible system behavior within
the application context.
➠ Implementation considerations are not into account.
➠ Models of analysis:
• class model: displays the application context; relations between classes
• system operations
• permitted sequences of system operations
Note: Classes in the Fusion analysis phase have no operations (yet)!
5
The Fusion Analysis Process
7
DESIGN, IMPLEMENTATION
➠ Design:
• Goal: abstract implementation concept
• System operations are represented by the runtime behavior of
interacting objects
➠ Implementation:
• Transforms design models into an executable code
• system class model ❀ classes of the programming language
• object interactions ❀ method calls
• Permitted sequences ❀ control structures
Simultaneously: data dictionary, consistency checks
Starting point: Description of facts and requirements using natural language.
Multiple steps, in each of which a model is developed.
1. Class model
Describes objects and concepts of the problem environment
2. Use case model
Coarse-grained functionality of the system
3. Scenarios
Refinement of the use case model
Identification of system operations
4. Operation model
Specification of the system operations as relations between the “before”
and “after” states
6
8

5. System class model
Borderline between system and environment
Refinement of the class model
6. Life-Cycle model
Global system behavior
Behavior of objects
DATA DICTIONARY
Contains all used names; representation as a table:
Name Kind Description Source
Name of the
element
Class, system operation,
attribute,
etc.
9
Short informal
description
Must be maintained throughout the entire development process!
11
All models that contain
the name
➠ Static aspects of the system: Class model
➠ Dynamic aspects of the system: Interface model
consisting of
• Use cases
• Scenarios
• Operation model
• Life-Cycle model
EXAMPLE
Name Kind Description Source
account.number attribute Unique account number
of an account.
Bank class A bank consists of a
number of accounts
open account system
operation
Transaction life-cycle
expression
10
A customer opens an account
at a bank
A transaction is either an
deposit, a withdrawal, or
a balance query.
class model
class model,
system
model
class
scenario, operation
model
life-cycle model

ASSOCIATIONS
The class model
➠ denote the relations between objects
➠ are drawn as links between classes
➠ can have an arity of more than two
➠ can have names (convention: use capital letters)
➠ can have multiplicities
➠ can have role names
13
15
MODELING THE STATIC ASPECTS OF THE APPLICATION CONTEXT
Different notations for classes:
or or
Class Class Class
a1: T1
a2 : T2
a1: T1
a2 : T2
op1(p: T1) : T2
Classes in the Fusion analysis phase only have basic attributes (i. e., no
object attributes) and no operations!
EXAMPLE
Professor Institute
1 Leads 0..1
name
name
specialty
director
0..2
Gives
*
Course
title
4..6 Takes 3..*
Student
name
participant inscription_number
14
role
association name
mulitplicity reading direction
16

MEANING OF THE CLASS DIAGRAM
➠ Each institute has exactly one professor who leads it.
➠ This professor is called ”director”.
➠ A professor leads at most one institute.
➠ A professor can give course, but need not do so.
➠ Each course is given by at most two professors (also zero professors are
possible).
➠ A student takes four to six courses.
➠ There, he is a “participant”.
➠ A course has to be taken by at least three students.
ROLE NAMES
➠ are written at the ends of the links
➠ per convention, role names are written in small letters
Person
1..*
child
17
IsChildOf
19
parent
2
ASSOCIATIONS WITH ARITY GREATER THAN TWO
Associations can exist between more than two classes.
MULTIPLICITIES
Student Exam
Room
Writes
➠ express cardinality constraints of relations
18
➠ for each object o of Class2, there exist m objects o ′ of Class1, such that o
and o ′ are in relation Rel.
Notation:
Class1
Rel
Class2
m
• number n: exactly n objects
• scope i..j
• * : any number, also 0
• i..∗ : at least i
• ∗..j : at most j
• not specified : means *
• 0..1, 3..4, 6..∗ :
20
all quantities except 2 and 5

ASSOCIATION CLASSES
➠ Associations can also have attributes.
➠ Reasonable, if the attributes cannot be assigned to any of the classes
involved in the association.
Writes
Student Exam
Writes
mark
GENERALIZATION/SPECIALIZATION
➠ Classes correspond to types.
➠ Subclasses correspond to subtypes, not subsets.
➠ Specialization = ”is a” , but ”act as” , ”is a kind of”
BachelorCourse MasterCourse
subject
21
Course Personnel Student
Constraint
title
name
name
pers.nr
inscription_number
salary
{complete}
specialization
23
Professor TeachingAssistent
specialty
AGGREGATION AND COMPOSITION
are special associations.
Room
Wall
The wall is a part of the room.
If a part belongs to only one whole and can only exist with that whole, then this
is a composition relation.
CONSTRAINTS
Window
Frame
or
➠ Are conditions that must hold.
➠ Are written between “{}”.
22
Window
Frame
➠ The example: “{complete}” means that no other subclasses of Course
can exist.
➠ Meaning of constraints must be described informally.
24

STRUCTURING CLASS MODELS
In general the class model must divided into different diagrams. The following
conventions must be obeyed:
➠ Modeling elements with the same name represent the same element.
➠ The set of the attributes of an element is the union of the attributes of all
element representations.
➠ Multiplicities are combined by conjunction, i.e., 1..14 and 0..5 yields 1..5.
➠ Role names must be unique.
25
• The contents of an already placed contract only changes if the client
wishes for changes and the central office approves of these changes. A
client contacts an employee of the agency and informs the employee about
the desired changes. The employee notifies the central office about the
change request. The central office then decides on accepting the request
or not and making changes if necessary.
The procedure for canceling contracts proceeds analogously.
• The data concerning product changes and launches is adjusted monthly.
Here, the central office updates the databases of the agencies for each
product.
27
EXAMPLE: INSURANCE AGENCY
A software system is to be developed for managing an insurance agency.
• The following products are offered: Health insurance- (HI), automobile
liability- (AL) and private liability (PL).
• An employee prepares offers for individual products. These offers contain
the essential data for the respective insurance. The product information
must be available in form of a database. Client data must be entered if they
are not yet present.
• The employee prepares the application together with the client. The
application is sent from the agency to the central office. The central office
checks the application and records the data in its system. If a contract can
be placed, the central office sends this contract to the agency in electronic
form. A newly placed contract can only refer to a current product.
26
• In case of an occurrence of event insured, the client has to contact an
employee of the agency. In case of AL and PL insured events, the agency
authorizes an expert advisor who appraises the damage and sends the
corresponding report back to the agency via Internet. In insured events
within the scope of HI, no expert advisor is appointed. The central office
can decide on assuming the payment for an insured event or not. In cases
of AL and PL, the agency determines the settlement of a claim on the
basis of the expert advisor’s report.
28

PreparesAppl
CLASS MODEL FOR THE INSURANCE AGENCY
Client
clientData
Employee
Application
Checks
CentralOffice
ForAppl
Updates
1
PreparesOffer
Settles
1
Offer
offerData
Product
productData
HI AL PL
Approves
1
WorksFor
ForOffer
1
Decides_onHI
RefersTo
29
Contract
ContractData
Agency
InsuredEvent
Concerning
The Use case model
31
Authorizes
ExpertAdvisor
HI−Event
Report
AL/PL−Event
DecidesOn
Prepares
OBJECT-ORIENTED ANALYSIS
➠ Class model =⇒ Static aspects
➠ Interface model =⇒ Dynamic aspects
AIM
• Use case model
• Scenarios
• Operation model
• System class model
• Life-Cycle model
➠ Coarse-grained view of the system.
➠ Identification of function groups.
PROCEDURE
➠ Identify actors
➠ Identify use cases
➠ Identify associations between actors and use cases
30
32

ACTORS
➠ are outside of the system
➠ represent different user roles
➠ can be either human beings or other systems
➠ should appear in the class model
➠ corresponding classes are not implemented
➠ Notation:
BankClerk
DESCRIPTION OF SEQUENCES OF ACTIONS
➠ necessary, because ovals do not convey any semantics
➠ verbally or with scenarios, which are represented as diagrams
➠ Distinction of
• Normal cases (main flow of events)
• Error cases (exceptional flow of events)
33
35
USE CASES
➠ are sets of sequences of actions
➠ must have a name
➠ describe the interaction between actors and the system
➠ Criteria:
The system supplies an observable result which is of use for the actor.
➠ Notation:
Process
Loan
EXAMPLE: USE CASE ”‘AUTHENTICATE USER”’
➠ Normal case:
1. System asks user for PIN
2. User enters PIN
3. System checks correctness
➠ Exceptional cases:
• User enters wrong PIN 3 times
• User aborts transaction
• User mistyped, presses CLEAR-Button
34
36

Use case diagrams
COMMON BEHAVIOR CAN FACTORED OUT
➠ include-relation
A use case explicitly contains another. The latter does not appear on its
own, instead it serves to avoid repetitions.
Place
Order
37
dependency
Authenticate
User
39
stereotype
GENERALIZATION-/SPECIALIZATION RELATIONS
are possible for actors as well as use cases:
CommercialCustomer
Customer
Check
Password
Authenticate
User
Scan
Retina
UML 2.0: Use cases may have attributes and operations, and behavior may be
specified with state machines.
NEW LANGUAGE ELEMENTS
➠ Dependency: -------->
38
Change in independent things (at the arrow head) causes a change in
dependent things.
e.g. change in PlaceOrder when AuthenticateUser changes.
➠ Stereotypes: >
• Extension of UML by new basic elements.
• describes the above mentioned-dependency between
use cases.
• When verbally describing PlaceOrder, then AuthenticateUser must also
be described.
• There is an additional dependency with a predefined stereotype,
namely .
40

➠ extend-relation
extension points:
RushOrder
PlaceOrder
Place
Rush
Order
Condition: {rushOrderCond}
extension point: RushOrder
• Base use case can appear on its own, but in some cases its behavior is
extended through another use case.
• This expresses optional system behavior.
• Sequence of actions: If condition is satisfied at extension point, then
optional behavior is executed.
• Note: Here the dependency is the other way around than with
! The optional behavior depends on the basic behavior!
ANOTHER EXAMPLE
BankClerk
LoanExpert
extension points:
NC
OpenAccount
Close
Account
Process
Transaction
extension points:
NC
ProcessLoan
41
Condition: {NewClient}
extension point: NC
Schufa−
Query
Bank
Schufa
Note: Loan experts are allowed to open accounts while ”‘regular”’ employees
are not allowed to process loans.
43
LAST STEP
• Use associations for connecting the actors with the use cases.
• Draw system boundaries.
Example: Cellular telephone
CellularNetwork
User
extension points:
CC
PlacePhoneCall
Place
Conference−
call
Condition: {CCButtonPressed}
extension point: CC
extension points:
RAC
ReceivePhoneCall
Condition: {AddCallArr}
extension point: RAC
Use
Scheduler
42
Receive
additional
call
Cellular Telephone
USE CASE MODEL FOR THE INSURANCE AGENCY
Employee
extension points:
CD
Prepare
offer
extension points:
CD
Prepare Application/Contract
Update
Products
Change/
cancel
contract
Treat
ensured
event
Treat
HI ensured
event
Treat
AL/PL ensured
event
44
Enter
Client
Data
Condition: {NoClientData}
extension point: CD
Authorize
report
Agency
CentralOffice
ExpertAdvisor

Next step: Describing sequences of actions
SCENARIOS
➠ Describe all sequences of actions contained in the use cases.
➠ Describe communication flows between the system and its environment.
45
➠ Participants: System as well as actors according to the use case diagram.
➠ Notation: UML 2.0 sequence diagrams.
➠ At least one scenario must exist for each use case!
➠ Each scenario describes one possible flow of events (normal case or
exceptional case).
47
OBJECT-ORIENTED ANALYSIS
➠ Class model =⇒ Static aspects
➠ Interface model =⇒ Dynamic aspects
• Use case model
• Scenarios
• Operations model
• System class model
• Life-Cycle model
MODELING ALTERNATIVES
➠ Define one scenario for each normal case and each exceptional case
+ simple scenarios
- repetitions
➠ Use combined fragments to define scenarios
+ exploit include- and extend-relations from use case model
- scenarios become more complex
- no indeterminism; conditions have to be given
46
48

EXAMPLE: OPENING AN ACCOUNT
• Normal case 1: A new customer wants to open an account. A Schufa query
is necessary. Schufa confirms credit-worthiness, the account is opened.
• Exceptional case 1: A new customer wants to open an account. Schufa
query is negative. Account-opening is rejected.
• Exceptional case 2: A customer wants to open an account as new
customer. This customer is however already known as customer.
• Normal case 2: A customer wants to open another account.
Credit-worthiness is checked in-house. Credit-worthiness is good, account
is opened.
• Exceptional case 3: A customer wants to open another account.
Credit-worthiness is checked in-house. Credit-worthiness is negative,
account-opening rejected.
NOTE:
➠ System operations are arrows from an actor to the system.
➠ We use asynchronous messages to model system operations (UML2.0
also allows synchronous and reply messages).
➠ Output events are arrows from the system to an actor.
➠ Parameters are not yet specified.
49
➠ Each scenario has to start with a system operation (i. e., the system does
not initiate anything)
➠ Not all system operations have associated output events.
➠ In general, a scenario may contain several actors, system operations and
output events.
➠ The output is not necessarily sent to the actor who calls the system
operation.
51
SIMPLE SCENARIOS: NORMAL CASE 1
sd OpenAccountN1
BankClerk
open_new_customer_account
account_opened
name
system (object) (not underlined)
: Bank
schufa_query
credit_worthiness_ok
50
Schufa
output event
SIMPLE SCENARIOS: EXCEPTIONAL CASES 1 AND 2
sd OpenAcccountE1
system operation
lifeline
actor
(asynchronous message)
Scenario for exceptional case 1: Scenario for exceptional case 2:
BankClerk
account_not_opened
sd OpenAcccountE2
: Bank : Bank
Schufa BankClerk
open_new_customer_account open_new_customer_account
schufa_query
credit_worthiness_not_ok
52
customer_already_known

SIMPLE SCENARIOS: NORMAL CASE 2 AND EXCEPTIONAL CASE 3
Scenario for normal case 2:
sd OpenAcccountN2
sd OpenAcccountE3
: Bank
BankClerk BankClerk
account_opened
Szenario for exceptional case 3:
open_known_customer_accout open_known_customer_accout
ignore to define messages to be ignored in the execu
loop repetition
neg to define forbidden behavior
53
account_not_opened
par parallel independent execution of several operands tion
seq weak sequencing (default)
strict strict sequencing
We will only use alt and opt.
Moreover: ref: Reference to another sequence diagram.
Avoids repetitions; semantics: replace reference by its contents.
55
: Bank
COMBINED FRAGMENTS
Operators for combining different sequence diagrams. The following operators
are defined:
alt alternatives; more than two alternatives are possible.
opt option
assert assertion, to define a message sequence that must occur
break description of behavior expected after a break
coregion messages can be received in any order
consider to define messages to be considered in the execution; equivalent to
defining every other message to be ignored
critical critical region
PATTERN FOR MODELING “”
sd UC1_i
54
UC1 UC2
:X :Y
ref
M1
M2
M3
M4
UC2
56

PATTERN FOR MODELING “”
REMARKS
extension points:
EXT
UC1
sd UC1_i
:X :Y
opt
[U2_Cond]
M1
M2
➠ Nested combined fragments are possible.
Op1
Op2
EXT
M3
M4
57
UC2
Condition: {U2_Cond}
extension point: EXT
Condition or
Continution
Secnario ofr UC2
➠ In this example, we did not use the pattern for “”, because
we had to make a more general case distinction (customer already known
or not).
➠ Conditions have to be given for the alt and opt operators.
59
COMBINED FRAGMENTS: NORMAL CASE 1, EXCEPT. CASES 1, 2
sd OpenAccountS1
: Bank
BankClerk Schufa
open_new_customer_account
alt
[ClientKnown]
customer_already_known
[else]
alt
[queryOK]
[else]
account_opened
account_not_opened
REFERENCED SCENARIO
sd SchufaQuery
alt
[creditWorthinessOK]
[else]
: Bank
ref
58
schufa_query
SchufaQuery
credit_worthiness_ok
credit_worthiness_not_ok
60
Schufa

METHOD
➠ Consider all use cases given in the use case diagram.
➠ For each use case:
• Enumerate all normal and exceptional cases.
• Set up a simple scenario for each case, or use combined fragments to
cover several cases.
➠ Collect the names of all arrows from an actor to system. These are the
system operations which have to be specified in the following.
USE CASE “PREPARE OFFER”, SIMPLE SCENARIOS
sd PrepareOfferN1 sd PrepareOfferN2
Employee
c_data_present?
c_data_present!
prepare_offer
offer_prepared
61
: Agency : Agency
63
Employee
c_data_present?
c_data_not_present!
enter_c_data
c_data_entered
prepare_offer
offer_prepared
Scenarios for the insurance agency
USE CASE “PREPARE OFFER”, COMBINED FRAGMENTS
sd PrepareOffer
Employee
62
c_data_present?
alt
[cdp] c_data_present!
[else]
c_data_not_present!
enter_c_data
c_data_entered
prepare_offer
offer_prepared
64
: Agency

OBJECT-ORIENTED ANALYSIS
➠ Class model =⇒ Static aspects
➠ Interface model =⇒ Dynamic aspects
AIM
• Use case model
• Scenarios
• Operation model
• System class model
• Life-Cycle model
➠ Descriptive specification of exactly the identified system operations
➠ Specification of the state changes and generated output events
➠ No programming, no behavior inside the system.
➠ An operation schema must be specified for each system operation.
➠ Operation model = set of operation schemas
65
67
The operation model
EACH OPERATION SCHEMA CONTAINS
➠ Name of the system operation
➠ Informal description
➠ Input/Output, communication with environment
66
➠ Assumptions on the state of the system before execution of the operation.
➠ State change (effect) achieved by the operation.
68

FUSION NOTATION
Operation = 〈Name〉
Description = 〈Informal description〉
Reads = 〈Input〉
Changes = 〈Objects/Attributes/Associations, that might be changed 〉
Sends = 〈Output events〉
Pre = 〈Precondition〉
Post = 〈Postcondition〉
Sends Events that can be but do not have to be created.
Must contain all output events occurring in the scenarios.
Receiving actor is stated, e.g.
Employee: {give money(amount), no cover}
69
Pre refers to the system state before calling the system operation and the
supplied values.
The effect of system operation as given by postcondition is only specified if
the precondition is fulfilled.
The precondition should be established by the sequences of events
specified in the scenarios and in the life-cycle model.
71
COMPONENTS OF AN OPERATION SCHEMA
Reads Objects/Attributes/Associations, whose state or value can be read but
not changed.
Keyword supplied for arguments that are from an actor (from exterior)
Inputs that are not ”‘supplied”’ come from the internal state.
Changes The concerned values can be read as well as changed but need not
be changed.
Keyword new for objects that are created by the system operation.
Keyword delete for objects that are deleted by the system operation.
Reads and Changes clauses must be disjoint!
Post Relation (expressed as predicate) between pre-state and inputs on the
one hand and post-state and outputs on the other hand.
Variables of the post-state are decorated with ”‘ ′ ”’.
70
Predicate is sent{event} describes that event is sent to the actor given in
the sends-clause as an effect of the system operation.
No program! Only the effect is specified but not how it is achieved!!!
72

Excursion: Design by Contract
What are preconditions and postconditions good
EXAMPLE
I want to travel from Berlin to Duisburg.
for?
Commitments Advantages
Passenger Pay ticket getting to Duisburg
Traffic
provider
73
Be there at departure time
must keep precondition Has advantages from the postcondition
Must take the passenger to
Duisburg
receives the price for the ticket;
does not have to take passengers
who have not paid or did not arrive
in time
Must guarantee postcond. Can assume precondition
75
SOURCE
Bertrand Meyer
Object-Oriented Software Construction
Prentice Hall 1988 (1. Aufl.), 1997 (2. Aufl.)
online see:
http://archive.eiffel.com/doc/manuals/technology/contract/page.html
CONTRACTS IN DAILY LIFE
➠ Contractual partners are clients and sellers or service providers.
➠ Both expect advantages from the contract and are willing to make a
commitment.
ADVANTAGES OF EXPLICIT CONTRACTS
Meyer:
74
A contract document protects both the client, by specifying how much
should be done, and the supplier, by stating that the supplier is not
liable for failing to carry out tasks outside of the specified scope.
APPLICATION TO SOFTWARE
A contract is a formal agreement between a system / a class and its actors /
clients. It specifies the rights and duties for both sides.
76

EXAMPLE: STACK (GENERIC CLASS)
class Stack[T]
attribute nb elements: integer
method empty(): Boolean
full(): Boolean
push(x: T)
pop()
top(): T
end class Stack[T]
pop()
pre not empty
post not full and nb elements’ = nb elements - 1
and ”‘top element of the stack is deleted ”’
top(): T
pre not empty
post noChange and Result = ”‘top element of the stack”’
77
79
SPECIFICATION OF THE STACK OPERATIONS WITH
PRECONDITIONS AND POSTCONDITIONS
empty()
full()
pre true
post Result = true ⇔ nb elements = 0
pre true
post Result = true ⇔ nb elements = . . .
push(x: T)
pre not full
post not empty and nb elements’ = nb elements + 1
and ”‘x is the new top element of the stack”‘
COMMITMENTS AND ADVANTAGES
Commitments Advantages
Client Call push(x) only if stack is
not full
78
Element x is put on stack, top() results
in x, nb elements increases
by 1.
Must keep precondition has advantages from postcondition
Server Makes sure that x is placed
on the stack
Must guarantee postcondition
80
Unnecessary to handle the case if
stack is full.
Can assume precondition

APPLICATION OF THE DESIGN-BY-CONTRACT-PRINCIPLE
➠ Fusion OOA: Specifies system operations by means of preconditions and
postconditions.
➠ Fusion OOD: Specifies all added operations by means of preconditions
and postconditions.
➠ OOI: Give preconditions and postconditions as documentation in the
source code.
➠ There are programming languages (e. g. Eiffel) which allow for dynamic
checking of preconditions and postconditions.
CLASS MODEL FOR BANK
Schufa
Bank
81
Queries
Owns
Customer Account
Checking
Keeps
Works_for
Savings Credit
83
BankClerk
LoanExpert
EXAMPLE: WITHDRAW MONEY FROM BANK ACCOUNT
sd WithdrawN
sd
: Bank
WithdrawE
BankClerk BankClerk
withdraw_money
withdraw_money
give_money no_cover
OPERATION SCHEMA
82
Operation = withdraw money
Description = Money should be withdrawn from an account. This is possible
only if the account is not overdrawn.
Reads = supplied accountnr : Accountnr
supplied amount : N
: Bank
Changes = account : Account with account.number = accountnr
with: Predicate which uniquely determines an object.
number must be introduced as attribute of the class Account
(=⇒ system class model)
84

Sends = BankClerk: {give money(amount), no cover}
Pre = accountnr is a valid account number, account.balance ≥ 0
Post = If account.balance − amount ≥ 0:
account.balance ′ = account.balance − amount
is sent{give money(amount)}
If account.balance − amount < 0:
account.balance ′ = account.balance
is sent{no cover}
account.balance ′ ≥ 0
=⇒ The class Account has the attribute balance.
account.balance ≥ 0: Invariant. Contained in pre- and in postcondition.
Note: the output event give money gets a parameter (These are not contained
in the scenarios ).
MORE EXAMPLES
sd OpenAccountS1
: Bank
BankClerk Schufa
open_new_customer_account
alt
[ClientKnown]
customer_already_known
[else]
alt
[queryOK]
account_opened
[else]
account_not_opened
ref
85
87
SchufaQuery
REMARK
The precondition of the operation must be consistent with the scenarios.
If it cannot be taken for granted that only valid account numbers can be given
as a parameter of the operation withdraw money, then a scenario must be
added that states how to treat the case of an invalid account number.
Once such a scenario is added, the precondition “accountnr is a valid account
number” may be dropped.
Assumption: cd is sufficient to distinguish different customers
86
Operation = open new customer account
Description = A new customer wants to open an account. A query is sent to
the Schufa before the account can be opened.
Reads = supplied cd : Customer data
Changes = —
Sends = BankClerk: {customer already known},
Schufa: {schufa query(cd))}
Pre = —
Post = If exists account : Account with account.customer data = cd:
is sent{customer already known}
Otherwise: is sent{schufa query(cd)}
=⇒ The class Account has the attribute customer data.
88

SCHUFA QUERY
REMARKS
sd SchufaQuery
alt
[creditWorthinessOK]
[else]
: Bank
schufa_query
credit_worthiness_ok
credit_worthiness_not_ok
89
Schufa
• Associations are sets of tuples (in case of binary associations: sets of
pairs).
• When a new object is created, all associations of the corresponding class
must be considered, and new tuples involving the new object have to be
added if appropriate.
• In the example, the new account is added to the Keeps association which
holds between the bank and its accounts.
• The scenario OpenAccountS1 guarantees that the precondition of the
system operation credit worthiness ok is fulfilled.
• It is not stated how the new account number is determined.
• We abstract from details of the customer data.
91
Operation = credit worthiness ok
Description = Schufa confirms credit-worthiness of the new customer. The account
can be opened.
Reads = supplied cd : Customer data
bank : Bank
Changes = Keeps, new account : Account
Sends = BankClerk: {account opened(accountnr)},
Pre = exists no account : Account with account.customer data = cd
Post = Keeps ′ = Keeps ∪{(bank, account)}
UML NOTATION
account.customer data ′ = cd, account.balance ′ =0
account.number ′ = accountnr, where accountnr is a new account
number
is sent{account opened(accountnr)}
90
Sequence of tagged values, i. e., sequence of pairs consisting of keyword and
value.
sd operation
Actor
operation
{Description = ...,
Reads = ...,
Changes = ...,
Sends = ...,
Pre = ...,
Post = ... }
92
: System

RULES
➠ An operation schema must be set up for each system operation occurring
in the scenarios.
➠ The actors given in the sends-clause must be the same as in the
scenarios.
➠ The entities in the reads- and changes-clauses must be disjoint.
➠ Preconditions and scenarios must be consistent (number and type of error
cases)
➠ The actors are responsible for guaranteeing the precondition of a system
operation! The system operation does not check if the precondition is
fulfilled, but assumes that it is!
Operation = c data present?
Description = It is checked if the client exists.
Reads = supplied cd : CData
93
client : Client with client.clientData = cd
Changes = –
Sends = Employee:{c data present!(client.nr),
Pre = —
c data not present!}
Post = exists client : Client with client.clientData = cd
⇒ is sent{c data present!(client.nr)}
otherwise: is sent{c data not present!}
=⇒ The class Client belongs to the system and has the attributes
clientData and nr.
95
Operation schemas for the insurance agency
Operation = enter c data
Description = Data of a new client is entered.
Reads = supplied cd : CData
Changes = new client: Client
Sends = Employee : {c data entered(cl nr)}
Pre = not exists client : Client with client.clientData = cd
Post = client.clientData ′ = cd
client.nr ′ = cl nr, where cl nr is an new client number
is sent{c data entered(cl nr)}
94
96

USE CASE “PREPARE APPLICATION/CONTRACT”, COMBINED
FRAGMENTS
sd EnterClientData
Employee
c_data_present?
alt
[cdp] c_data_present!
[else]
c_data_not_present!
enter_c_data
c_data_entered
: Agency
sd PrepareAppl/Contr
Employee
ref EnterClientData
alt
[ok]
[else]
97
prepare_application
application_prepared
contract_prepared
contract_not_prepared
: Agency
Pre = exists client : Client with client.nr = cl nr
coregion
check_application
application_accepted
application_not_accepted
CentralOffice
Post = application.nr ′ = app nr, where app nr new appl. number
prod = car ⇒
application.applicationData ′ =
generate application(client.clientData,
al.productData, al.alData, a data)
ForAppl ′ = ForAppl ∪{(application, al)}
prod = liability ⇒
application.applicationData ′ =
generate application(client.clientData,
pl.productData, pl.plData, a data)
ForAppl ′ = ForAppl ∪{(application, pl)}
99
Operation = prepare application
Description = An application for a known client is prepared.
Reads = supplied cl nr : CNr
supplied prod : Prod ID
supplied a data : applicationData
client : Client with client.nr = cl nr
hi, al, pl : Product
Changes = new application : Application
PreparesAppl, ForAppl
Sends = Employee: {application prepared(app nr)},
CentralOffice:{check application(prod,
application.applicationData ′ , app nr, client.clientData)}
prod = health ⇒
98
application.applicationData ′ =
generate application(client.clientData,
hi.productData, hi.hiData, a data)
ForAppl ′ = ForAppl ∪{(application, hi)}
PreparesAppl ′ = PreparesAppl ∪{(client, application)}
is sent{application prepared(app nr)}
is sent{check application(prod, application.applicationData ′
100
app nr, client.clientData)}

CONSEQUENCES FOR THE SYSTEM CLASS MODEL
• The class Application gets the attributes applicationData and nr
• The association PreparesAppl should be part of the system. Therefore, it
must be transformed into a binary relation, because Employee is an actor.
• The classes HI, AL and PL, respectively, get attributes that contain
product-specific information.
FURTHER REMARK
• The function generate application is an internal function that computes the
application data from its inputs. It will not be specified any further.
Pre = exists application : Application with
application.nr = app nr
Post = contract.nr ′ = c nr
contract.contractData ′ = c data
ForAppl ′ = ForAppl \{(application, product)}
101
PreparesAppl ′ = PreparesAppl \{(client, application)}
RefersTo ′
= RefersTo ∪{(contract, client, product)}
is sent{contract prepared(c nr)}
103
Operation = application accepted
Description = An application is accepted by the central office and transformed
into a contract.
Reads = supplied app nr : Appl nr
supplied c data : Contract Data
supplied c nr : Contract Nr
client : Client with (client, application) ∈ PreparesAppl
product : Product with (application, product) ∈ ForAppl
Changes = new contract : Contract
delete application : Application with
application.nr = app nr
PreparesAppl, ForAppl, RefersTo
Sends = Employee: {contract prepared(c nr)}
REMARKS
102
• We assume that the contract number is determined by the cental office.
• The class Contract must have the attributes nr and contractData.
• The associations PreparesAppl and ForAppl must be unique and total, i.e.
for each application there is exactly one client or one product, respectively,
that is a member of the relation PreparesAppl or ForAppl, respectively.
Then, it follows that the precondition “exists application : Application with
application.nr = app nr suffices to uniquely determine client : Client and
product : Product.
• The association RefersTo is completely contained in the system. Moreover,
for each contract, there is exactly one product and exactly one client such
that these belong to the relation RefersTo.
104

Operation = application not accepted
Description = An application is rejected by the central office.
Reads = supplied app nr : Appl nr
client : Client with (client, application) ∈ PreparesAppl
product : Product with (application, product) ∈ ForAppl
Changes = delete application : Application with
application.nr = app nr
PreparesAppl, ForAppl
Sends = Employee: {contract not prepared(app nr)}
Pre = exists application : Application with application.nr = app nr
Post = ForAppl ′ = ForAppl \{(application, product)}
THE SYSTEM CLASS MODEL
PreparesAppl ′ = PreparesAppl \{(client, application)}
is sent{contract not prepared(app nr)}
105
➠ Shows the classes to be implemented.
➠ Is developed from a part of the class model.
➠ Is delineated by a dashed line.
➠ Actors and non-implementable classes (e.g., persons who do not directly
interact with the system) do not belong to the system class model.
➠ The interpretation of a class can change from “real object” to “data
representation”.
➠ Classes on the system border may be divided into internal and external
classes.
107
OBJECT-ORIENTED ANALYSIS
➠ Class model =⇒ Static aspects
➠ Interface model =⇒ Dynamic aspects
• Use case model
• Scenarios
• Operation model
• System class model
• Life-Cycle model
➠ Usually, additions to the class model are necessary by:
106
• attributes that are introduced when setting up the operation model
• “communication classes” for actors, i.e., classes that receive the system
operations (see OOD)
➠ The system class model is a well-formed class model, i.e., an association
only belongs to it if all concerned classes are inside the system.
108

EXAMPLE
class model
Checking
Schufa
Bank
Queries
Owns
Customer Account
REMARKS
Keeps
Works_for
Savings Credit
BankClerk
LoanExpert
Customer
109
system class model
Owns
Checking
Schufa
Bank
Account
Queries
Keeps
number
customer_data
balance
Savings Credit
Works_for
BankClerk
LoanExpert
• We have decided that offers, applications, contracts and clients should be
part of the agency. Each class of the system class model should have a
relation to the agency (at least indirectly), because the agency constitutes
the system to be implemented.
• How the part-of relations exactly look like will result from the reference
model to be constructed in the design phase.
• Associations from the class model that have an actor as a participant have
been eliminated from the system class model, or have been transformed
into an association without a participating actor.
• Instead, the actors have got an association to the agency.
111
SYSTEM CLASS MODEL FOR INSURANCE AGENCY
Client
clientData
nr
1
Application
PreparesAppl
applicationData
nr
ForAppl
PreparesOffer
1
Offer
offerData
Product
productData
ForOffer
HI AL PL
hiData alData plData
OBJECT-ORIENTED ANALYSIS
➠ Class model =⇒ Static aspects
1
1
RefersTo
110
Employee CentralOffice
Contract
contractData
nr
➠ Interface model =⇒ Dynamic aspects
• Use case model
• Scenarios
• Operation model
• System class model
• Life-Cycle model
112
WorksFor IsConncectedTo
1
Agency
InsuredEvent
Concerning
Report
repData
HI−Event
ExpertAdvisor
Prepares
1
AL/PL−Event
eventData
nr
regulation
Authorizes

LIFE-CYCLE EXPRESSIONS
The Life-Cycle model
Expressions over the alphabet: 〈system operation〉, #〈output event〉
113
Each system operation and each expression of the form #〈output event〉 is a
life-cycle expression.
If x and y are life-cycle expressions then so are
x;y x is followed by y
x | y either x or y
x∗ x is executed 0 or more times
x + x is executed at least once
[x] x is optional
x || y x and y are executed concurrently
Operator precedences: [], ∗ , + , ;, |, ||
115
PURPOSE
➠ describe the overall behavior of the whole system or describe the life-cycle
of important objects
➠ restrict the order in which the system operations may be invoked
➠ Notation:
• Fusion: life-cycle expressions
• UML: state machine diagrams
Definitions: name = life-cycle expression
name can then be used in other life-cycle expressions (but recursion is not
allowed!)
114
Rule:
All system operations and all output events must occur in the life-cycle model!
116

EXAMPLE: BANK
Life-Cycle Bank system:
Openacc;(Transaction|Query|Openacc) ∗
Openacc = OpenaccNC | OpenaccKC
Query = query balance;#current balance
Transaction = deposit money | Withdrawal
OpenaccNC = open new customer account;
(Schufaquery|#customer already known)
OpenaccKC = open known customer account;
(#account opened|#account not opened)
Withdrawal = withdraw money;
(#give money|#no cover)
Schufaquery = #schufa query;
(credit worthiness ok; #account opened)
|(credit worthiness not ok;
#account not opened)
117
LIFE-CYCLE MODEL AS STATE MACHINE
➠ System operations as events
➠ Output events as actions
➠ Transitions between states: event / action
Example: life-cycle of an account
2
1
no account
3
5
no account
Schufa
queried
1: open_known_customer_account / #account_not_opened
2: open_new_customer_account / #customer_arlready_known
3: open_new_customer_account / #schufa_query
4: open_known_customer_account / #account_opened
5: credit_worthiness_not_ok / #account_not_opened
4
6
119
account
without
deposit
7
7
8
account
with
deposit
7: query_balance / #current_balance
8: deposit_money
9: withdraw_money / #give_money
10: withdraw_money / #no_cover
8
6: credit_worthiness_ok / #account_opened
9
10
PROBLEM
We can only express that some account must be opened before a transaction
or query can take place. We cannot express that before a transaction or query
on account X can take place, X must have been opened before.
Alternative: Describe life-cycle of specific objects.
Example: Lifecycle Account: Open | n Open
Open = NewAcc; (query balance;#current balance) ∗ ;
deposit money; (Transaction|Query) ∗
n Open = (open new customer account;#schufa query
credit worthiness not ok;#account not opened)
|(open new customer account;#customer already known)
|(open known customer account;#account not opened)
NewAcc = open new customer account;#schufa query;
credit worthiness ok;#account opened |
open known customer account;#account opened
LIFE-CYCLE MODEL FOR INSURANCE AGENCY
Summary of system operations and their output events:
118
Upd = update product;#product updated
EntCDat = enter c data;#c data entered
Query = c data present?;
(#c data present!|#c not data present!)
Offer = prepare offer;#offer prepared
Appl = prepare application;
(#check application || #application prepared)
Acc = application accepted;#contract prepared
NAcc = application not accepted;#contract not prepared
Chg = change contract;#confirm change
ChY = change confirmed;#contract changed
ChN = change not confirmed;#contract not changed
120

Canc = cancel contract;#confirm cancellation
CanY = cancellation confirmed;#contract canceled
CanN = cancellation not confirmed;
#contract not canceled
HIEv = report HI event;#settle HI event
HIOK = HI settlement ok;#HI event settled
HINOK = HI settlement not ok;#HI event not settled
ALPLEv = report AP/PL event;#authorize expert
DelRep = deliver report; #report delivered
ALPLOK = settle AP/PL event;#AP/PL event settled
ALPLNOK = not settle AP/PL event;
#AP/PL event not settled
Top-Level-Behavior:
121
V 1 = Query ∗ || Upd + || QuerEnt +
V 2 = Offer ∗ || Query ∗ || Upd ∗ || QuerEnt ∗
V 3 = (Appl;NAcc) ∗ || Offer ∗ || Query ∗ || Upd ∗ || QuerEnt ∗
V 4 = (Appl;Acc) + || Offer ∗ || Query ∗ || Upd ∗ || QuerEnt ∗
V 5 = Offer ∗ || Query ∗ || Upd ∗ || QuerEnt ∗
|| Contract ∗ || Change ∗ || Cancellation ∗ || Event ∗
Lifecycle Agency:
V 1; V 2; V 3; V 4; V 5
123
Definition of “business processes”:
QuerEnt = c data present?
; #c data not present! ; EntCDat
Contract = Appl ; (Acc | NAcc)
Change = Chg ; (ChY | ChN)
Cancellation = Canc ; (CanY | CanN)
HI Event = HIEv ; (HIOK | HINOK)
AL/PL Event = ALPLEv ; DelRep ; (ALPLOK | ALPLNOK)
Event = HI Event | AL/PL Event
REMARKS
122
• It is always possible to enter client data, to query if client data are present, and
to update products (V 1). However, before an offer can be prepared (V 2), at
least one update and one entering of client data must take place (V 1).
• Moreover, it is possible that applications are prepared which are rejected (V 3).
• Before the full functionality of the agency is possible (V 5), at least one
application must have been accepted (V 4).
• The different business processes may be executed concurrently (operator ||).
Note:
The life-cycle model should not only consist of life-cycle expressions that reproduce
the scenarios, because the scenarios do not contain all possible/ permitted
behavior. However, each scenario must be permitted by the life-cycle model.
124

4 Develop
the
operation
model.
Fusion OOA
Summary and Validation Checklist
125
1. Exactly the system operations occurring in the scenarios must be
described.
2. The entities mentioned in the Reads and Changes clauses are
disjoint.
3. In the supplied clause, only simple data types may occur, no objects
can be supplied.
4. All objects mentioned in the Changes clause belong to the system.
5. The output events occurring in the Post clause are exactly the
ones occurring in the Sends clause.
6. The actors named in the Sends clause are the same as in the
scenarios.
7. All objects referenced in Pre and Post are contained in the Reads
or Changes clauses.
8. Post covers all cases exhibited in the scenarios.
9. All objects that are changed in Post are contained in the Changes
clause.
127
No. Phase Validation
1 Develop the class
model.
2 Develop the use
case model.
3 Refine the use
cases by scenarios.
5 Develop the
system class
model.
6 Develop
life-cycle
model.
the
1. All important notions of the application domain
must occur in the class model.
2. For all associations, their multiplicities must be
given, if not *.
The identified actors should occur in the class model.
For each use case, there must be at least one scenario.
The actors in the scenarios must be consistent
with the use case diagram, i.e., there is an arrow
from/to an actor in the scenario iff there is an association
between the use case and the actor in the use
case diagram.
126
1. The border of the system must be consistent with the
use case diagram, i.e., actors and their associations
are outside the system.
2. Exactly the classes of the system class model must
occur in some system operation.
1. Exactly the system operations and output events occurring
in the scenarios must occur in the life-cycle
model.
2. All scenarios must be permitted according to the lifecycle
model.
3. The life-cycle model should establish the preconditions
of the system operations, if possible.
128