Topic14g H

Topic 13b
Object-oriented Analysis
(subtopics g and f)
DAAD Project
“Joint Course on Software Engineering”
Humboldt University Berlin, University of Novi Sad, University of Plovdiv,

University of Skopje, University of Belgrade, University of Niš, University of Kragujevac
Parts of this topic use material from the textbook

H. Balzert, “Software-Technik”, Vol. 1, 2nd ed., Spektrum Akademischer Verlag, 2001
Version: Feb. 28, 2005 (D Jan. 8, 2005)
1
13. Object oriented analysis
a) Overview: approaches, history, literature
b) Object-oriented paradigm: basic notions
c) Sub-models in UML
d) How to read a given static OOA model?
(Class diagram: example „seminar organization“)
e) Detailed specification: DD, pseudo code
f) Packages
g) How to build an OOA model?
h) Analysis patterns of OO
i) Tools
DAAD project „Joint Course on Software Engineering“ © 2
2
Static OOA model: Building and evaluation
Company Person
Booking Lecturer
Shortname: String <10>
Attributes
Attributesand
Number: Serial
and
Name: NameT
Address: AddressT 12
12classes:
classes:
Registered: Date Name: NameT
operations:
Biography: String<400>
Why
Confirmation: Date
operations:
Address: AddressT Daily honorar: Float
Whyexactly
Contact: ContactT
Contact person: NamtT exactly Bill: Date
Checked out: Date
Contact: ContactT
Why
Whyexactly
exactly
Birthday: Date * * *
Sector: String <30> these?
these? Notification: Date
these?
First registered: Date
Contact person birthday: Date
Function: String <30>
these?
Short information: String <200>
Register() Notices: String <200>
Short information: String <200> Check out()
Notices: String <200> Produce notification() Produce address label()
Business volume: Float Prove payment()
Client since: Date
Associate Is able to
Employer 0..1 Contractor 1
Entitlement: RoleET conduct
But: is this
Password: String <6>
Occupation: String <30>
Associate *
model really
Client Biggest problem: useful?
Presentation
* Missing:
Business volume: Currency
Where does
1 Participant Number: Short
Duration: Short * • Classes
Seminar supervisor
(especially)
Substitute participant this From: Date • Attributes
Referent
*
Produce Notification() To: Date
0..1
0..1
model 0..1come* * Daily schedular start: Time • Operations?Seminar type
Daily schedular stop: Time
Customer
*
from?
Client booking Company booking
Start first day: Time Short title: String<10>
* * End last day: Time Title: String <50>
1 Place: String <50> * 1 Purpose: String<400>
Address: AddressT Method: String<400>
Public presentation Overview: String<400>
Participant max: Short
Cooperation partner: String<100> Canceled: YesNoET Daily procedure: String<20>
Cancel fee: Float Durance: Short
1
Participant min: Short Cancel() Documents: String<200>
Participant actual: Short Company internal presentation Produce honorar information() Target group: String<200>
To be able to create All-inclusive

Produce participant list()
model... price: Float To be able to assess model...
Register()
Check out()
Preconditions: String<200>
Charge without tax: Float
Participants max: Short Participant number max: Short
Produce participant certificate() Is free()
Alternative seminars() Participant number min: short
3
Class diagram „Seminar organization“:
alternative approach?
Company
Participant
Invoice recipient
Aggregation
Address
Name Notification
Booking
Date
Payment delay
Registration
confirmation
Lecturer
Public Company internal

seminar presentation
presentation
Seminar type
4
Unified software development process (USDP):
Object oriented analysis
Part of the phase ‚Analysis and design‘, in

which fundamental application (use) cases
Requirements of the system are developed by:
Use-Case diagrams
Analysis
Design
Part of the phase ‚Analysis and design‘, in
Implementation which the fundamental classes of the
problem domain are developed by:
Test
Class diagrams
not only class diagrams have to be created
5
Usage of UML diagrams during the phases of software development:
Object oriented analysis
static model dynamic model
Requirements
use case diagrams activity diagrams
class diagrams
Analysis
package diagrams sequence diagrams
Klassendiagramme
class diagrams
(verfeinert,
(refined,
Design
How mit inheritance
to with
derive Vererbung
overall collaboration diagrams
und
andAssoziationen)
associations) state-automata
model of OOA?
component diagrams
Implementation
code classes definitions code methods
object structure object behaviour

6
How to build an OOA model?
Starting point: Requirements specification

Iterative procedure: OOA model is created through
several revisions
Creative process
• can not be automated
• practice/experience
Guidelines for building OOA models found in
Rumbaugh, Booch etc.
Balzert: Sequence of 83 single steps for building
and verification of an OOA model
7
OOA modelling: Two citations
„Building an OOA-model based on written information, e.g.

of requirements specification, or verbal information, e.g.
through interviews, is one of the hardest tasks in software
engineering.“
(Balzert Vol.1, 1st ed., p.391)
„The process of object oriented analysis and design cannot

be described in a cook-book, yet it is sufficiently well-
defined as to offer a predictable and repeatable process for
the mature software development organization.“
(Booch, p.229)
8
Methodical strategy:
iterative building of OOA model
i=1
Set-up of business
Global analysis
processes, build packages
build build 3. Iteration

static dynamic
model model 2. Iteration
1. Iteration
Time
OOA model 1
OOA model 2
OOA model i OOA model 3
i = Iteration number
9
Development of OOA model according to Balzert
Sequences of steps:
• Global analysis: 2 Steps
• Build static model: 7 Steps
• Build dynamic model 3 Steps
Checklists:
• Packages: 5 Steps
• Classes: 8 Steps
• Associations: 11 Steps
• Attributes: 12 Steps
• Inheritance: 4 Steps
• Cardinalities: 4 Steps
• Aggregation and composition: 4 Steps
• Scenarios: 6 Steps
• State automata: 10 Steps
• Operations: 7 Steps
10
Sequence of steps in creation of
OOA-Model: Global Analysis
i=1
Set-up of business
Global analysis
processes, build packages 2 Steps
build build
static dynamic
model model
OOA-Model i
11
Global analysis
1 Set-up of business processes

• Determine essential business processes
- →Description of a business process:
verbal
- →Business process (use case) diagram
2 Building of packages
• Build subsystems, i.e. combine model elements to
packages
- But, when several teams are working on a big system, then
start with building packages
- →Package diagram
12
OOA-Model: Static model
i=1
Set-up of business
build build
7 Steps static dynamic
model model
static model =
Class diagram
OOA model i
13
7 steps towards the static model (1)
coarse approach: Classes

1 Identification of classes
• For each class, identify just as many attributes and
operations as necessary to understand problem and to
essentially and undoubtfully identify classes.
- →Class diagram
- →Brief description of classes
coarse approach:
2 Identification of associations Associations
• First, only „pure“ associations are registered, i.e. yet

without particular data, e.g. cardinality or type of
association
- →class diagram
14
3 Identification of attributes Complete attributes
• Identify all attributes of problem domain

→Class diagram
4 Identification of inheritance structure
Abstraction
• ... based on the identified attributes
→Class diagram
Specify
5 Completion of associations associations
• Finally specify, whether an association is a „normal“
association, an aggregation or a composition and define
cardinalities, roles, names and restrictions
- →Class diagram
- →Objects diagram Steps 1-5:
Class diagram completed stepwise
15
Attributes:
6 Specification of attributes Syntax and semantics
• For all identified attributes create a detailed
specification
→ Attributes specification
Possibly modification of
7 Identification of patterns class diagram
• Check class diagram for presence of patterns and if
there are, check whether they were correctly modeled.
16
OOA-Model: Dynamic model
i=1
Set-up of business
build build
static dynamic 3 Steps
model model
Scenarios
OOA model i
State automata
Operations
17
3 steps towards the dynamic model (1)
Formalize verbal
description of business
1 Set-up of scenarios processes
• Each business process is specified
by a set of scenarios
- →Sequence diagram, Collaboration diagram
- Alternatively or complementary, activity diagrams or state
automata can be used
2 Set-up of state automata Formalization of
semantics of classes
• For each class examine if a non-trivial life-cycle exists
and needs to be specified
- →State diagram
18
3 steps towards the dynamic model (2)
formalized description of
the semantics of operations
3 Description of operations
• Consider if a description is necessary
- If it is, choose one of the following description forms
according to the level of complexity
• → verbal description of the operations
• → State automata
• → Activity diagram
19
Summary: purpose of dynamic model
Use Cases Sequence diagram
Collaboration diagram
Classes
Activity diagram
Operations State automata
dynamic model specifies semantics of

use-cases, classes and operations
20
Development of OOA model according to Balzert:
Checklists
Sequences of steps:
• Build dynamic model: 3 Steps
Checklists:
• Classes: 8 Steps When performing the
• Associations: 11 Steps sequences of steps,
checklists are
• Attributes: 12 Steps applied as action
• Inheritance: 4 Steps guidelines.
• Scenarios: 6 Steps During lecture we shall
apply some checklists
• State automata: 10 Steps to „Seminar
• Operations: 7 Steps organization“
21
Checklist for classes
Sequences of steps:
• Build dynamic model: 3 Steps
Checklists:
22
Classes checklist (1)
Result
• Class diagram
- Every class exists in a class diagram – either only with its
name, or with a few important attributes/operations.
- Brief description of classes.
Constructive steps
1. Which classes are identifiable by document analysis
(bottom-up)?
- Attributes are extracted from lists and forms and put
together in classes.
23
Example: Classes identified through document analysis of
‘Application form for presentation’
Registration to ‘Teachware’ seminars
The following person is registered as a participant
Title First Name Family Name
Presentation no. Description From To
Please send invoice and other documentation to:

Title First Name Family Name
Company
Classes identifiable
Street / P.O.Box
Classes identifiable
Country
Zip City
from
fromthis
this form?
Phoneform?
24
Example: Classes identified through document analysis:
three potential classes
Participant Seminar Presentation Invoice Recipient

Title Presentation Number Title
First name Seminar Title First Name
Family name Starting Date Family Name
Finishing Date Company
Street / P.O.Box
Country
Zip code
Town
Phone
25
2. Reengineering of legacy software (old systems):

• Workflows are established from user-manuals, user-interface
forms, and database descriptions
• Business processes are accomplished from current functioning
system
• Identify classes with help of user-interface forms
3. In technical systems real domain objects are a good
starting points for establishing classes
26
Example: Classes in technical systems
‚Weather observing station‘
Keyboard Clock LCD display
Wind
Wind direction Work
velocity
sensor station
sensor
Temperature Atmospheric Humidity

sensor pressure sensor sensor
Wind Temperature
velocity sensor
Data
sensor
source
Data
source
Data Atmospheric
Wind direction
source humidity sensor
sensor Measurement
Data
Data source
inquiry
LCD display Atmospheric

Data
Display pressure sensor
source
manager
Source: Booch, p.367,...
27
4. Which classes can be identified from a requirements

specification (business processes) (top-down)?
- Search description for classes
• Nouns are often potential classes
- Potential classes are checked for attributes
- Actors, of which something needs to be "remembered", are
potential classes.
28
Example: Classes identified from
requirement specification
4 Product functions Recognize
Recognize
Client:
Client:
class
Actor
Actor
and
one
one
of
of
its
class
which and
data its
are
which data from
are
operations
operations
saved from
this saved
use-case!
4.1 Use cases this use-case!
/F10/ (/PF10/)
Use case: Informing: From question to information
Category: primary
Preconditions: -
Post condition success: Client gets required information.
Post condition failure: The required information can not be issued
Actor: Client manager, client, company
Triggering event: Client writes (letter, fax, e-mail) or calls
Description:
1 Client data retrieval Operations
2 Information issue Operationsofof
class Client
class Client
Extension:
1A client data actualization
2A Production of address label (for sending info material)
Alternatives:
1A An inclusion of a new client Attributes
Attributesof
ofclass
classClient:
Client:
cf.
cf.5.1
5.1Client
Clientdata
data
29
5 Product data
Attributes
Attributesofof
5.1 Client data class
classClient
Client
/D10/ (/LD10/) Client data (max. 50.000)
Client number, name, adress, communication data, date of birth,
function, exchange, short information, notices, info material, client since.
Attributes
Attributesofof
class
classCompany
Company
/D20/ (/LD20/) Company data (max. 10.000), when a client is an associate
of a company:
Company‘s short name, company name, adress, communication data,
contact person, section, date of birth, function of a contact person, short
information, notices, exchange, client since.
/D21/ If a company is in paying delay, then the following data should be
saved:
Date of still unpaid invoice, as well as amount.
Attributes
Attributesofofclass
classPayment
Paymentdelay
delay
30
Client Lecturer Booking Company
Name Number Registred when Short name
Adress Name Validated when Company name
Communication data Address Billed when Address
Date of birth Communication data Cancelled when Communication data
Function Date of birth Notification when Contact person
Exchange Biography Section
Client from Salary per day register() Date of birth
Short information cancel() Function of contact prs.
create Adress-label() Notices create notification() Short information
create Card Lecturer since Notices
Exchange
Client since
Presentation Seminar type Comp. booking Associate

Number Short title Name
register()
Duration (in days) Title Title
cancel()
From Purpose Password
create card()
To Methodic Action
Daily-period-split beginning Overview
Daily-period-split end Daily procedure
Beginning of the first day Duration
End of the last day Records Payment delay
Presentation place Target group
Address Requirements Date unpaid invoice
Max. participant rate Fee without tax Amount unpaid invc.
Cancelled Max.participant rate
cancell()
Min.participant rate
Result:
create Fee-communicatin()
create Participant-list() Classes identified by analysis of
create Certificate()
requirements specification of
‘Seminar organization’
31
/F20/ (/PF20/)
Use case: Booking: from registration to booking. Candidate
Candidateforfor
Category: primary aaclass
class
Preconditions: -
Post condition success: Client is notified.
Post condition failure:
Notification to clients that presentation is overbooked, or does not exist, or
a booking for the client is already made.
Actor: Client manager, client, company
Triggering event: Client registration is available.
Description:
1 Client data retrieval
2 Presentation verification Operations
Operationsofof
3 Booking undertaking class
class
4 Registration notification and sending invoice
5 Sending invoice copy to the accounts department
Extension:
- Attributes:
Attributes:
cfcf5.3
5.3Booking
Bookingdata
Alternatives: data
1A Inclusion of a new client
2A When the presentation is over booked, to point out the alternative one
2B Notification of "false presentation", if the presentation does not exist
32
5.2 Seminar data Attributes:
Attributes:
Presentation,
Presentation,
/D30/ (/LD30/) Presentation data (max. 10.000) Seminar
Seminartype,
type,
Presentation number, duration (in days), from, to, daily period split-
Lecturer
Lecturer
beginning, daily period split-end, beginning of the first day, end of the
last day, presentation place (hotel/company, address, room), public
(yes/no), net price, cancel fee, min. participant rate, max. participant
rate, actual participant, carried out (yes/no)
/D40/ (/LD40/) Seminar type data (max. 10.000)
Short title of seminar, seminar title, purpose, methodic, overview, daily
procedure, duration, records, target group, requirements, fee without
tax, max. participant rate, min. participant rate
/D50/ (/LD50/) Lecturers data (max. 5.000)
Lecturer number, name, address, communication data, date of birth,
biography, daily allowance, short information, notices, lecturer since.
5.3 Booking data
/D60/ If a lecturer conducts a seminar, this information should be saved. .
/D70/ For every seminar booking by company or client, following
information should be saved:
Registered when, validated when, billed when, canceled when,
notification when.
Attributes
Attributesofofclass
classBooking
Booking
33
5. Which categories do classes belong to?

- Concrete objects or things, e.g. Car
- Persons and their roles, e.g. Client, Lecturer
- Information about actions, e.g. Carrying out bank transfer,
Carrying out booking
- Places, e.g. Waiting room
- Organizations, e.g. Office, Company
- Containers, e.g. Warehouse
- Things in containers, e.g. Tyres in warehouse
- Events, e.g. Wedding
- Catalogues, e.g. Product catalog, Seminar type catalog,
Events catalog
- Contracts, e.g. Car-buying contract
34
Persons
Exchange and roles Biography Section
create Card Lecturer since Notices Organization
Exchange
Client since
Information about
actions
Presentation data Seminar type Comp. booking Associate

register()
cancel()
create card()
To Methodic Action
cancell()
Catalogues
create Participant-list()
create Certificate()
Participating categories
35
Analytical steps
6. Is a class name meaningful?
not:
not:Lecturers
Lecturers
- Class name should
• correspond to domain terminology
• be a noun in singular form
• mean the same as the entirety of attributes
• not describe the role of the class with respect to another
class
• be distinct in package resp. in system
• not be synonymous to the name of another class
7. Is chosen abstraction level appropriate?
no
noclasses:
- Goals are not classes:
Address,
Address,Name,Name,
• to create as many classes as possible or ......
• to identify classes of small complexity.
36
Checklist for associations
Sequence of steps:
• Static model creation: 7 Steps
• Dynamic model creation: 3 Steps
Checklist:
37
Checklist associations (2)
2 What associations can be established from description of
business processes?
- Look for the verbs, in particular:
• Spatial closeness (near the)
• Ownership (has)
• Actions (drives)
• Communication (talks to), (married with)
• General relations
3 Is the association part of one of the following categories?
- A is physical component of B
- A is logical component of B
- A is a description of B Illustrated
Illustratedby
bythe
the
- A is a row of a list B example
example
- A is a member (employee) of B.
38
Example of association: Seminar organization
Identified associations, roles, associative classes, categories,
restrictions
is able to conduct
Company booking Seminar type
Category:
Client is an
employee of
a company Company Lecturer
Customer
Employer Conductor Seminar manager
Category:
Category: {subset}
Presentation
Presentationisisaa
Paying delay logical
logicalcomponent
componentofof
Seminar
Seminartype
type
Employee
Participant
Client Presentation
Substitute
participant Booking
39
- A is organizational unit of B
- A uses B
- A communicates with B
- A owns B
4 Which restrictions needs the association to fulfill?
- One association: {ordered} Illustarted
Illustartedby
bythe
the
example
example
- Several associations: {or}, {subset}
5 Which roles do participating classes play?
- State the name of role, when
• Association exists between objects of the same class
• A class plays different roles in different associations
• The meaning of the class in the association can be
specified more precise through role name.
40
restrictions
is able to conduct
Company Lecturer
Customer
{subset}
Paying delay
Employee
Participant Restriction
Client Presentation
Substitute
participant Booking
41
8 Are there more than one association between 2 classes?

- Examine if associations
• have a different meaning and/or
• have different cardinality
9 Are associations used correctly?
- Adding no new information to a model
- Recognizible by object diagrams
10 Associative class or independent class?
- Associative class emphasizes the association between
member classes
- Associative classes can be changed to independent
classes
11 Sources of errors Booking
- Confusion of association with inheritance
42
restrictions
is able to conduct
Company Lecturer
Customer
{subset}
Paying delay
Employee
Participant
Client Presentation
Substitute
participant Booking associative
class
43
restrictions Reading
order
is able to conduct
Category:
Client is an
employee of Company Lecturer
a company Customer
Category:
Category: {subset}
Presentation
Presentationisisaa
Paying delay
logical
logicalcomponent
componentofof
Seminar
Seminartype
type
Employee
Participant Restriction
Client Presentation
Substitute
participant Booking associative
class
44
Example:
Class Payment delay changed to association
before: class
‘Payment delay ‘
Participant
Client Debtor Booking
{ordered by date}
Where
Wherearearethe
the
Restriction attributes of
attributes of
‚Payment
‚Paymentdelay‘?
delay‘?
45
Checklist for attributes
Sequence of steps:
Checklists:
46
Attributes checklist (1)
Result
• Class diagram
- For each attribute put corresponding name to class
diagram
- Class attributes and derived attributes are marked
• Attributes Specification
- Specify each attribute
- For complex attributes corresponding types are to be
defined (where appropriate).
Attribute types of
different kinds
47
Example attribute types: Seminar organization
Company Person
Shortname: String <10> Booking Lecturer
Number: Serial
Name: NameT Registered: Date Name: NameT Biography: String<400>
Address: AddressT Confirmation: Date Address: AddressT Daily honorar: Float
Contact: ContactT Bill: Date Contact: ContactT
Contact person: NamtT * * *
Sector: String <30>
Checked out: Date
Notification: Date
Birthday: Date
First registered: Date structured
Function: String <30> Register()
Notices: String <200>
types (data-
Check out()
Produce notification() Produce address label()
structures)
Client since: Date
elementary Password: String <6>
Associate * and
Client predefined Presentation
*
Enumeration type
Business volume: Currency
1 Participant
types Number: Short
Duration: Short *
Seminar supervisor
From: Date Sem.

Substitute participant manager *
0..1 0..1 * *
0..1
Daily schedular start: Time Seminar type
* Client booking Company booking Daily schedular stop: Time
Customer Start first day: Time Short title: String<10>
* 1 Purpose: String<400>
problem-adequate
1 Place: String <50>
Public presentation
Cooperation partner: String<100>
types Participant max: Short
Canceled: YesNoET
Overview: String<400>
Daily procedure: String<20>
1
Register() Preconditions: String<200>
All-inclusive price: Float Charge without tax: Float
Produce participant list() Check out()
48
Checklist for inheritance
Sequence of steps:
Checklists:
49
Checklist inheritance (2)
Illustrated
Illustrated
Analytical steps by
bythe
the
example
example
3 Is there a „good“ inheritance structure?
- Does inheritance structure improve understanding of
model?
- Are all inherited attributes, operations and associations
required for every subclass?
- Does „is-a“ relationship apply?
- Does inheritance structure correspond to „natural“
structure of problem domain?
- Are there maximally 3 to 5 hierarchy levels?
4 When do we not need inheritance?
- The subclasses denote only different kinds but otherwise
differ neither by their properties nor their behaviour.
50
Inheritance example: Seminar organization (1)
Person
Number: Serial
Name: NameT
Address: AdresseT
compare:
compare:layout
layout
Contact: KontaktT problem
problem infinal
in final
Date of birth: Date
First registred: Date
model
model
All
Allinherited
inherited Notices: String <200>
attributes
attributes produc address label()
required
required
Client Associate Lecturer

Date of birth: Date
Function: String <50> Title: RolleET
Biography: String <400>
Business volume: Currency Password: String <6>
Salary per day: Float
Lecturer since: Date
produce Notification()
51
Inheritance example: Seminar organization (2)
Booking
Presentation
Registered: Date
Confirmation: Date Number: Short
Bill: Date Duration: Short
Checked out: Date Natural
Naturalstructure
structure
From: Date
To: Date
Notification: Date
of problem
of problem
Daily schedular start: Time
Daily schedular stop: Time
Register()
Check out() domain
domain
Start first day: Time
End last day: Time
Produce notification()
Prove payment() Place: String <50>
Address: AddressT
Canceled: YesNoET
Cancel()
Produce honorar information()
Company internal presentation Public presentation

Contractor All-inclusive price: Float
Participants max: Short
Cancel fee: Float
Parti- Participant min: Short
cipant Customer Participant actual: Short

Employee Produce participant certificate()
Client Company
Employer
52
Checklist for state automata
Sequence of steps:
Checklists:
53
Checklist for state automata (1)
Description
Descriptionof
of
Result classes
classes
• State diagram
Constructive steps
1 Does a non-trivial life-cycle exist? e.g.
e.g.not
notinin
2 What states does the automat contain? Seminar
Seminartype
type
- Initial state is the starting point
- By which events is a state left?
• Events colloquially described, as „what influences the object
from outside“
- What are the subsequent states?
- How is the state defined (attribute values, object
associations)?
54
Example state automaton:
Seminar organization (Presentation)
updating
/ modify()
new presentation is canceled deleted

/ enter() / delete()
exists
client registers
client registers
/ register()
/ register()
client checks out
/ checkOut()
canceled
booking
client when
checks out (full)
/ checkOut()
when
(seminar is
canceled canceled over)
Seminar_presentation
booked
entry/canceling()
when enter()
(presentation is modify()
done)
delete()
register()
performed checkOut()
canceling()
55
Checklist for operations
Sequence of steps:
Checklists:
56
Checklist operations (1)
Result
• Class diagram with operations inserted
• Description of the operations
Constructive steps
1 Insert operations into class diagram
- Take from scenarios & state automata
- List operations added
- Insert no administrative operations
2 Consider inheritance of operations
- Insert operations into inheritance hierarchy as high as
possible
3 Create descriptions (only where necessary).
57
Example operation: Seminar organization
Company Person
Number: Serial
Checked out: Date Birthday: Date
Sector: String <30> Notification: Date First registered: Date
Contact person birthday: Date Short information: String <200>
Function: String <30> Register() Notices: String <200>
Client since: Date
Associate *
Client Presentation
*
Function: String <50> 1 Participant Number: Short Conductor
Business volume: Currency Duration: Short *
From: Date Sem.
Substitute participant Manager *
0..1 0..1 * *
0..1
1
Documents: String<200>
Participant min: Short
Participant actual: Short
new operations Company
from internal presentation Cancel()
Produce honorar information() Target group: String<200>

state automaton
All-inclusive price: Float
Register()
CheckOut()
Preconditions: String<200>
AlternativePresentation() Participant number min: short
58
Summary:
Evolution of OOA class models
Classes from document analysis

Classes from the requirements
specification
Enhancement with associations
Enhancement with attribute types
Introduction of inheritance
Extend with operations
59
OOA classes: Classes from
document analysis
Participant Seminar Presentation Invoice Recipient

Title Presentation Number Title
First name Seminar Title First Name
Family name Starting Date Family Name
Finishing Date Company
Street / P.O.Box
Country
Zip code
Town
Phone
60
Exchange Biography Section
create Card Lecturer since Notices
Exchange
Client since
Presentation data Seminar type Comp. booking Associate

register()
cancel()
create card()
To Methodic Action
cancell()
create Participant-list()
create Certificate() OOA classes: Classes from the
requirements specification
61
OOA class diagram:
Enhancement with associations
is able to conduct
Company Lecturer
Customer
{subset}
Paying delay
Employee
Participant
Client Presentation
Substitute
participant Booking
62
OOA class diagram:
Enhancement with attribute types
Associate
Company Lecturer << Enumeration>>
Name: NameT Associate
Shortname: String <10> Name: NameT
Entitlement: RoleET
Name: NameT Address: AddressT Seminar manager
Address: AddressT Contact: ContactT Client manager
Contact: ContactT Birthday: Date Presentation manager
Contact person: NamtT Biography: String <400> Administrator
Sector: String <30> Salary per day: Float
Contact person birthday: Date Contractor Short information: String <200>
Function: String <30> Notices: String <200>
Short information: String <200> Lecturer since: Date
is able to conduct
Notices: String <200> Company booking
Business volume: Float
Client since: Date Registered: Date Seminar-
Confirmation: Date
Conductor
Bill: Date manager
Employer Checked out: Date
Notification: Date Presentation
Number: Short
Register()
Duration: Short
Substitute participant Check out()
From: Date
Produce notification()
To: Date
Associate Daily schedular start: Time
Daily schedular stop: Time Seminar type
Client
Start first day: Time
Booking Short title: String<10>
Name: NameT End last day: Time
Address: AddressT Registered: Date Place: String <50> Title: String <50>
Contact: ContactT Confirmation: Date Address: AddressT Purpose: String<400>
Birthday: Date Participant Bill: Date Participant max: Short Method: String<400>
Function: String <50> Checked out: Date Canceled: YesNoET Overview: String<400>
Business volume: Currency Notification: Date Daily procedure: String<20>
First registered: Date Cancel() Durance: Short
Register() Produce honorar information() Documents: String<200>
Customer Target group: String<200>
Produce address label() Check out() Produce participant list()
Produce notification() Produce notification() Produce certificate() Preconditions: String<200>
Participant number max: Short
Participant number min: short
63
OOA class diagram:
Introduction of inheritance
Booking
Presentation
Registered: Date
Confirmation: Date Number: Short
Bill: Date Duration: Short
Checked out: Date From: Date
Notification: Date To: Date
Daily schedular start: Time
Register() Daily schedular stop: Time
Check out() Start first day: Time
Produce notification() End last day: Time
Prove payment() Place: String <50>
Address: AddressT
Canceled: YesNoET
Cancel()
Produce honorar information()
Company internal presentation Public presentation

Contractor All-inclusive price: Float
Participants max: Short
Cancel fee: Float
Parti- Participant min: Short
cipant Customer Participant actual: Short

Employee Produce participant certificate()
Client Company
Employer
64
OOA class diagram:
Company
Extend with operations
Person
Number: Serial
Contact person: NamtT Birthday: Date * * *
Checked out: Date
Client since: Date
Associate *
Client Presentation
*
From: Date Sem.
0..1 0..1 * *
0..1
1
65
Class diagram Seminar organization
Company Person
Number: Serial
Contact: ContactT i=1 Bill: Date Contact: ContactT
Checked out: Date
Set-up
Short information: business
String <200>
Register()
Check out()
processes,
Business volume: Float
build packages Produce notification() Produce address label()
Prove payment()
Client since: Date
Employer 0..1 Contractor 1 Result of the

Associate
Entitlement: RoleET
Is able to
conduct
first iteration
Associate *
build build Presentation
Client
static 1
dynamic
Participant Number: Short
*
Seminar supervisor
Business volume: model
Currency
Produce Notification()
model
Substitute participant
0..1
Duration: Short
From: Date
To: Date
☺ *
Referent
*
0..1 * *
0..1
OOA Model i
Canceled: YesNoET Daily procedure: String<20>
1
Participant actual: Short i = Iteration
Companynumber
internal presentation Produce honorar information() Target group: String<200>
66
13. Object oriented analysis
a) Overview: approaches, history, literature
b) Object-oriented paradigm: basic notions
c) Sub-models in UML
d) How to read a given static OOA model?
(Class diagram: example „seminar organization“)
e) Detailed specification: DD, pseudo code
f) Packages
g) How to build an OOA model?
h) Analysis patterns of OO
i) Tools
67
Aims of OOA patterns
OOA pattern = characteristic subsystems of

OOA model (class diagram)
Why
WhyOOA
OOApattern?
pattern?
identify proven structures

hints for building the model
easier understanding of an unknown model
68
Seminar organization: identification of patterns
Company Person
Number: Serial
Sector: String <30> Pattern 9:
Checked out: Date
Notification: Date
Birthday: Date
Pattern 6:
Function: String <30> Group
Register() Roles
Client since: Date
Pattern 5: Password: String <6>
Associate * Coordinator
Client Presentation
*
From: Date Sem.
0..1 0..1 * *
0..1
Customer
* Client booking Pattern
Company 2:
booking Daily schedular stop: Time
Start first day: Time Short title: String<10>
Title: String <50>
*
1
Instance
*
type End last day: Time
Place: String <50> * 1 Purpose: String<400>
1
69
OOA pattern 1: List (Example) Not
in
case study
Stock report Stock module List
Number 4 Number
Malfunction status ok Malfunction status
Note
1
X Y Occupation Waiting
coordinate coordinate status sign Shelf 1.*
50 100 Free No A
50 200 Occupied No A Stock place
50 300 Free No A
X coordinate
Y coordinate
Occupation status
Waiting sign
Shelf
70
Pattern 1: List not
in case
study
There is a composition
Consists only of same parts, therefore there is
only one part-class
Part-objects are strongly connected to aggregate
object
• However they can be deleted before the whole
aggregation is deleted
The attribute values of the aggregate object hold
also for part-objects
The aggregate object contains at least one part-
object, i.e. the cardinality of it is generally 1..*.
71
Seminar type
OOA Pattern 2:
Title Instance type
Purpose (case study)
Method
Overview
Type (kind) of
Instances
1 (description)
Presentation
Instance
Number
Duration
From
To
72
Pattern 2: Instance type
Simple association
Once created object connections will generally not
be changed
• They will only be deleted when corresponding instance
is removed
The name of the type class often consists of the
notion of type, group, description, specification
A type class (description) may – from time to time
– exist independently of concrete instances
• Therefore, the cardinality is generally many (0..m)
Removing type class (description) leads to
redundant „storing“ of attribute-values
73
Company Person
Number: Serial
Checked out: Date
Client since: Date
Associate *
Client Presentation
*
From: Date Sem.
0..1 0..1 * *
0..1
Customer Pattern 2: Start first day: Time Short title: String<10>
Title: String <50>
* * End last day: Time
1 Instance type Place: String <50> * 1 Purpose: String<400>
1
74
OOA pattern 3: Assembly (Example) not
in case
study
Physical objects are considered
There is a composition Car
Object connections exist for a 1 1
longer period of time

1 4
• A part-object can be disconnected
Motor Wheel
from its aggregate object and
become connected to another
aggregate object
A whole (entirety) can consist of
different parts.
75
OOA pattern 4: Parts list (Example) not
in case
study
:Graphic :Component
:Graphic :Rectangle :Text :Component :Component
:Rectangle :Line :Rectangle :Component :Component
Graphic element Parts list

Position
Color *
Size *
Created in Component
0..1 Title
0..1
Contents
Line Rectangle Text Graphic
Begin point Length Font Version number

End point Width Release
76
Pattern 4: Parts list not
in case
study
There is a composition
The aggregate-object and its part-objects need
the ability to be dealt with as a union as well as
individual objects.
Part-objects can become connected with other
aggregate objects.
The cardinality of aggregate class is 0..1
An object of type A can be composed of more
objects of types A, B and C
A special case of parts list is, that the list does not
consist of objects of different kinds, but only of
objects of the same kind.
77
OOA pattern 5: Coordinator
Seller Coordinator Seller
1 1
1 1
Customer Product Customer Selling Product
Date
Discount
Selling
Date
Discount
Coordinator
Association Class
replaced by
an associative
class
78
Pattern 5: Coordinator
There are simple associations

The coordinator-class replaces an n-ary (n >=
2) association by binary associations with the
associative class
The coordinator-class hardly has any
attributes/operations, but has more
associations to other classes – generally with
exactly one object of every class.
79
Company Person
Number: Serial
Checked out: Date
Client since: Date
Pattern 5: Password: String <6>
Associate * Coordinator
Client Presentation
*
From: Date Sem,
0..1 0..1 * *
0..1
1
80
OOA-Pattern 6: Roles (Example)
:Presentation
Refe Roles
rent Seminar
Number = 4632
Sem :Lecturer * manager
i
m an nar Presentation Lecturer
age
r Name = Smith {subset}
:Presentation
t Number Number
r ticipan Duration * Name
Number = 4712
Pa From Conductor* Address
To
Participant
{Participant ≠ Referent}
several associations
between two classes
81
Pattern 6: Roles
Between two classes exist two or more simple

associations
An object can – at one time - play different
roles concerning the objects of the other class
Objects, that can play different roles, possess
the same properties and if necessary the
same operations, independent of their
respective role.
82
Company Person
Number: Serial
Checked out: Date
Sector: String <30> Notification: Date Pattern 6:
Function: String <30> Register() Roles
Client since: Date
Associate *
Client Presentation
*
From: Date Sem.
0..1 0..1 * *
0..1
1
83
:Customer
Not
in
case study
:Prospective
:Addressee
Period =
customer
Period =
:Participant
OOA pattern 7:
(1.1.00,
30.6.00)
(1.7.00,
7.10.00)
Period =
(8.10.00) Alternating Roles
(Example)
Alternating Customer
roles
Name
Address
1
CustomerRole
Abstract
Period role
Priority category
Concrete
role
Addressee Prospective Participant

customer
Address where the Catalog FirstBooked

shipping goes Claim on LastBooked
…
84
Pattern 7: Alternating roles Not
in
case study
An object of the real world can play different roles

at different times
• In each role it can possess different properties (attributes,
associations) and operations
The different roles are modeled by inheritance
Object references between the object and its roles
are only extended, therefore neither deleted nor
directed to other objects.
85
:Book copy
Not
Inventory Nr.= 1222 in
Period = (12.1.00, case study
31.1.00)
OOA-Pattern 8:
History
:Book copy
Inventory Nr.= 1387

:Customer
Period = (13.3.00, (Example)
16.3.00)
:Book copy
Inventory Nr.= 9712

Period = (25.12.00)
Customer Book copy

1 1..*
Inventory Nr.
Name {t<5} Title
Address
Period
86
Pattern 8: History Not
in
case study
There is a simple association

For one object there are several procedures resp.
facts to be documented
For each procedure or fact the period in time has to
be memorized
References of objects to procedures or facts are
only extended
The temporal restriction {t#k} (k = valid
cardinality) says, what has to hold at one point in
time, where # stands for relational operators: =,
<, >, <=, >= and ≠ .
87
OOA pattern 9: Group (Example)
Single object Group object
Associate Project team

* 0..1
Name Sign
Address Denotation
Region Period
several
severalsingle
singleobjects
objects
belong to the same
belong to the same
group
groupobject
object
88
OOA pattern 9: Group
There is a simple association

Several single-objects belong – at one time – to the
same group-object
It is always necessary to check, if the group can –
from time to time – exist without any single-objects,
or if it always has to contain a minimal number of
single-objects
Object references can be added and removed.
89
Company Person
Number: Serial
Sector: String <30> Pattern 9:
Checked out: Date
Notification: Date
Birthday: Date
Function: String <30> Group
Register()
Client since: Date
Associate *
Client Presentation
*
From: Date Sem.
0..1 0..1 * *
0..1
1
90
Not
OOA pattern 10: Group history (Example) in
case study
Associate Project team

* *
Name Sign
Address {t=0..2}
Denotation
Region Period
Membership
Period
Ending reason
91
Pattern 10: Group history Not
in
case study
A single object belongs – over a certain time – to

different group-objects
The history is modeled by an associative class
• with that the correlation between single-objects and
groups is clearly visible
The temporal restriction {t=k} (k = valid
cardinality) says what has to hold at one point in
time.
Because information on a time period is to be
memorized, existing object references remain
created and only new ones are added.
92

Topic14g H

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Topic14g H

Caricato da

Copyright:

Topic 13b

Humboldt University Berlin, University of Novi Sad, University of Plovdiv,

Parts of this topic use material from the textbook

Version: Feb. 28, 2005 (D Jan. 8, 2005)

To be able to create All-inclusive

DAAD project „Joint Course on Software Engineering“ © 3

Public Company internal

DAAD project „Joint Course on Software Engineering“ © 4

Part of the phase ‚Analysis and design‘, in

not only class diagrams have to be created

DAAD project „Joint Course on Software Engineering“ © 5

static model dynamic model

object structure object behaviour

Starting point: Requirements specification

DAAD project „Joint Course on Software Engineering“ © 7

 „Building an OOA-model based on written information, e.g.

 „The process of object oriented analysis and design cannot

DAAD project „Joint Course on Software Engineering“ © 8

build build 3. Iteration

DAAD project „Joint Course on Software Engineering“ © 9

DAAD project „Joint Course on Software Engineering“ © 11

1 Set-up of business processes

DAAD project „Joint Course on Software Engineering“ © 12

DAAD project „Joint Course on Software Engineering“ © 13

coarse approach: Classes

• First, only „pure“ associations are registered, i.e. yet

DAAD project „Joint Course on Software Engineering“ © 14

3 Identification of attributes Complete attributes

• Identify all attributes of problem domain

DAAD project „Joint Course on Software Engineering“ © 16

DAAD project „Joint Course on Software Engineering“ © 17

DAAD project „Joint Course on Software Engineering“ © 18

DAAD project „Joint Course on Software Engineering“ © 19

Use Cases Sequence diagram

Operations State automata

dynamic model specifies semantics of

DAAD project „Joint Course on Software Engineering“ © 23

Title First Name Family Name

Presentation no. Description From To

Please send invoice and other documentation to:

DAAD project „Joint Course on Software Engineering“ © 24

Participant Seminar Presentation Invoice Recipient

DAAD project „Joint Course on Software Engineering“ © 25

2. Reengineering of legacy software (old systems):

DAAD project „Joint Course on Software Engineering“ © 26

Temperature Atmospheric Humidity

LCD display Atmospheric

4. Which classes can be identified from a requirements

DAAD project „Joint Course on Software Engineering“ © 28

DAAD project „Joint Course on Software Engineering“ © 30

Presentation Seminar type Comp. booking Associate

DAAD project „Joint Course on Software Engineering“ © 32

DAAD project „Joint Course on Software Engineering“ © 33

5. Which categories do classes belong to?

Presentation data Seminar type Comp. booking Associate

DAAD project „Joint Course on Software Engineering“ © 39

DAAD project „Joint Course on Software Engineering“ © 40

DAAD project „Joint Course on Software Engineering“ © 41

8 Are there more than one association between 2 classes?

DAAD project „Joint Course on Software Engineering“ © 42

DAAD project „Joint Course on Software Engineering“ © 43

DAAD project „Joint Course on Software Engineering“ © 44

DAAD project „Joint Course on Software Engineering“ © 45

DAAD project „Joint Course on Software Engineering“ © 47

From: Date Sem.

DAAD project „Joint Course on Software Engineering“ © 48

Starting point: Requirements specification

„Building an OOA-model based on written information, e.g.

„The process of object oriented analysis and design cannot

Classes from document analysis

identify proven structures

Object connections exist for a 1 1

There are simple associations

Between two classes exist two or more simple

An object of the real world can play different roles

There is a simple association

There is a simple association