Topic 13 Object-oriented Analysis · Object-oriented analysis due to Booch (1994)...

1

Humboldt University Berlin, University of Novi Sad, University of Plovdiv,University of Skopje, University of Belgrade, University of Niš, University of Kragujevac

DAAD Project“Joint Course on Software Engineering”

Version: July 30, 2003 (D May 14, 2003)

Topic 13Object-oriented Analysis

Parts of this topic use material from the textbook H. Balzert, “Software-Technik”, Vol. 1, 2nd ed., Spektrum Akademischer Verlag, 2001

a) – f)

2

2DAAD project „Joint Course on Software Engineering“ ©

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, pseudocode

f) Packages

3


Product definition• requirements

specification• product model• user interface• user manual

Definition phase

Analysis andDefinition

Analysis andDefinition

Classical waterfall model: the place of OOA

DesignDesign

ImplementationImplementation

TestTest

Usage and MaintenanceUsage and

Maintenance

Feasibility study• glossary• preliminary require-

ments specification • cost estimation• project plan

Planning phase

Balzert(2001)

4


Methodology:How to develop a model?

Tools:Together, Rational Rose, Paradigm Plus

Modeling language:UML: diagrams

Model paradigm: Decomposition of the SW systems into objects

static / dynamic model(different views)

Aspects of OOA

5


Approaches, literature, systems of OO analysis: early works

P. Coad, E. Yourdon. Objekt-orientierted Analysis. Prentice Hall, 1990J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorensen: Object-Oriented Model and Design. Prentice Hall, 1991 – OMT Object Modelling Technique – Tool OMToolG. Booch: Object-oriented Analysis and Design with Applications. The Benjamin/Cummings Publishing Company, 1994 – Tool Rational RoseI. Jacobson, M. Christerson, P. Jonsson, G. Övergaard. Object-Oriented Software Engineering: A Use Case Driven Approach. Addison-Wesley, 1994 – Use Case Model

Situation in 1996- more than 50 OOA methods- differences: notations, described aspects- Paradigm Plus: 1996, tool supports 11 methods

6


UMLUnified Modeling Language

authors: Rumbaugh, Booch, Jacobson

Sept. 1999: version 1.3industry standard

March 2003: Version 1.5

graphical language:• collection of different diagram types for different views on the SW-

systemcritics:• UML = mixture of methods • UML only with syntax, without defined semantics

7


Approaches, literature, systems of OO analysis: the official UML literature

J. Rumbaugh, I. Jacobson, G. Booch:The Unified Modeling Language Reference Guide, Addison Wesley, 1999

G. Booch, J. Rumbaugh, I. Jacobson: The Unified Modeling Language User Guide, Addison Wesley, 1999

I. Jacobson, G. Booch, J. Rumbaugh: The Unified Software Development Process, Addison Wesley, 1999

8


History (1)

Peter Coad*30.12.1953 in San FranciscoHis book »Object-Oriented Analysis« (1990) (with E. Yourdon) helped to get OOA accepted. Introduced OOA patterns (1995)

9


History (2)

Dr. James Rumbaugh*22.8.1947 in Bethlehem, PA, USA Fellow, Rational Software Corporation

Chief developer of the OMT method (Object Modeling Technique).

10


Goal of OOA

like in case of structured analysis:• produce a formalised product model (as part of product definition)

• with it: specialize requirements document

combination of basic concepts:description of a system from different views

11


Combination of basic concepts in object-oriented analysis

pseudocode

stateautomaton

classdiagram

OOA1990

ER (Entity Rlationship)

collabo-ration diagram

sequencediagram

use casediagram

entities &relations

classstructures

controlstructures

finiteautomaton

interactionstructures

workflow

Data Dictionary (Balzert: attribute structure)

Data flow diagram(Rumbaugh: functional model, 1991)

12


Basic concepts of software developmentBalzert vol. 1, 2nd edition 2001

Function tree

Data-Dictio-nary1979

Class diagram 1980/1990

Box diagram

1973

Program flowchart

1966

Pseudocode

Decision tables

1957

Rules Petri Net1962

Sequ-encediagram

1987

Stateautomaton1954

Entity Relation-ship Model1976

Data flow diagram1966

Use Case Diagram1987

Activity diagram

1997

Collabo-ration diagram

Functional View Data-Oriented View Object-Oriented View

Algorith-mic View

Functionalhierarchy

BusinessProcess

Infor-mationFlow

Class structures

Data Structures

Rule-Based View

State-Oriented View

Controlstructures

If-Thenstructures

Entity types and relations

Finite State Automaton

Concurrentstructures

Interactionstructures

Scenario-Based View

Concepts and Views

Alte

rnat

ive

Not

atio

nsO

ften

used

Rar

ely

used

nearly all concepts allowed ☺

13


OOA

from OOP:• object • operation• class • inheritance• attribute • message

from semantical data modelling:• aggregation• (generalization type/

specialization type)

from ER model:• associaltion with

cardinalities• (attribute)• (entity type)

from state automaton:• Mealy automaton• Moore automaton• Harel automaton

from time diagrams:• sequence diagram

from business processes:• use case

Sources of OOA

14





c) Submodels in UML



f) Packages

15


OO paradigm: basic notions

basic notion: objectused in all phases of SW developmentmany definitions

basic idea: decomposition of a SW system into objects and (object) classes

16


Basic concepts of OOoriginally: on the level of programming (1970,1985)

later: OOA, OOD (1990)

ObjectClass (collection of similar objects)Attribute (state, data of an object)Operation (behaviour)Message (sending messages to objects)Inheritance (class hierarchy)Polymorphism (overlaying of operations)

known from OOPknown

from OOP

basic concept class diagram encompasses these OO concepts

17


Object-oriented analysis due to Booch (1994)

„Object-oriented analysis is a method of analysis that examines requirements from the perspective of the classes and objects found in the vocabulary of the problem domain.“Source: G. Booch: Object-oriented Analysis and Design with Applications, 1994, page 39

18


The notion of ‚object‘

In the literature we find very different definitions!

What is an object?What is an object?

The official definition ... ?

19


The notion of object (1)

Hopkins, Smalltalk:• An Object is a combination of two parts:

1. ‚Data‘ – the state of the object is maintained within that object

2. ‚Operation‘ – all mechanisms to access and manipulate that state.

ParcPlace VisualWorks Tutorial:• Objects (are) software units that contain collections of

related data plus operations for manipulating that dataRumbaugh:• An object combines both data structure and behavior

in a single entity.

20


The notion of object (2)

Booch:• Objects ... are data abstractions with an interface of

named operations and a hidden local state (1994, page 38).

A. Goldberg, Smalltalk – 80:• An object consists of some private memory and a set of

operations.

Booch:• An object has state, behavior, and identity; the

structure and behavior of similar objects are defined in their common class; the terms instance and object are interchangeable(1994, page 83).

21





c) Submodels in UML



f) Packages

22


attribute operation

classobject

basic concepts

Statical and dynamical model

associations

packageinheritance

static concepts

use case scenario

state-automatonmessage

dynamic concepts

static model

dynamic model

also static?also

static?

also dynamic?

also dynamic?

23


attribute operation

classobject

basic concepts

associations

packageinheritance

static concepts

use case szenario

state-automatonmessage

dynamic concepts

static model

dynamic model

Statical and dynamical model:used UML diagrams

class diagramspackage diagrams

component diagrams

state automatonactivity diagrams

sequence diagramscollaboration diagrams

? ?

use case-diagrams

?

24


Diagrams in UMLuse case diagram: interaction of persons with systemsclass diagram: classes and their static relationssequence diagram: time-dependent flow of messagescollaboration diagram: the same as sequence diagrampackage diagram: modularisationstate diagram: dynamical behaviour of objectsactivity diagram: parallel processescomponent diagram: compilation units, hardware structureobject diagram: objects and their relations

25


Application of UML diagrams in the phases of SW development(source: Informatik Spektrum, April 1998)

Requirements

Analysis

Design

Implementation

static model dynamic model

use case diagrams

class diagramspackage diagrams

class diagrams (refined, with inheritance

and associations)

component diagramscode classes definitions

activity diagrams

sequence diagrams

collaboration diagramsstate-automaton

code methods

object structure object behaviour

26





c) Submodels in UML



f) Packages

27


Static OOA model: ‘seminar organisation’

*

*

0..1

Associate

Contractor

Participant

Substitute paricipant

Customer

Seminar supervisor

Referent

Is able to conduct

* * *

*

* 1*

1

**0..1

1

*

*

*

1

1

0..1

0..1

BookingRegistered: DateConfirmation: DateBill: DateChecked out: DateNotification: Date

Register()Check out()Produce notification()Prove payment()

Client booking Company booking

PresentationNumber: ShortDuration: ShortFrom: DateTo: DateDaily schedular start: TimeDaily schedular stop: TimeStart first day: TimeEnd last day: TimePlace: String <50>Address: AddressTParticipant max: ShortCanceled: YesNoET

Cancel()Produce honorar information()Register()Check out()Is free()Alternative seminars()

Company internal seminarAll-inclusive price: FloatParticipants max: Short

Public seminarCooperation partner: String<100>Cancel fee: FloatParticipant min: ShortParticipant actual: Short

Produce participant list()Produce participant certificate()

LecturerBiography: String<400>Daily honorar: Float

Seminar typeShort titel: String<10>Titel: String <50>Purpose: String<400>Method: String<400>Overview: String<400>Daily procedure: String<20>Durance: ShortDocuments: String<200>Target group: String<200>Preconditions: String<200> Charge without tax: FloatParticipant number max: ShortParticipant number min: short

PersonNumber: SerialName: NameTAddress: AddressTContact: ContactTBirthday: DateFirst registered: DateShort information: String <200>Notices: String <200>

Produce address lable()

AssociateEntitlement: RoleETPassword: String <6>Occupation: String <30>

Employer

CompanyShortname: String <10>Name: NameTAddress: AddressTContact: ContactTContact person: NamtTSector: String <30>Contact person birthday: DateFunction: String <30>Short information: String <200>Notices: String <200>Business volume: FloatClient since: Date

ClientFunction: String <50>Business volume: Currency

Produce Notification()

28


DFD 0: Manage Seminars and Customers

invoice data sets

5 Manage

companies

4 Manage

customers

1 Managelecturers

2 Manage

seminars3

Record paying delay

6Read

invoice data

invoice

information

comp. booking data

booking data

notification letter

notific. letter

request datarequests

information

invoice copies

paying delays

seminar information

info to lecturer

lecturer data

invoice


seminar requestsseminar data

certi

ficat

eslis

t of p

artic

ipan

tssem

inar

sho

rt tit

le

pres

enta

tionN

o

lect

urer

dat

a

data base seminars and customers

payin

g de

lays

invo

ice

data

invo

ice

data

invo

ice

data

29


Correlationsrequirements specification

product model 1: structured analysis

product model 2: OO analysis

relation ?

Problems:1. Is the information included in PM1 also included in PM2 (and vice

versa)?2. What about the understandability of the models?

(readability, problem adequacy)3. Is there a methodology to develop the corresponding model (easy to

establish)?

30


Some relations to OOAClient

invoice data sets

5 manage

companies

4 manage

customers

1 managelecturers

2 manage

seminars3

record paying delay

6read

invoice data

invoice

information

comp. booking data

booking data

notification letter

notific. letter


information

invoice copies

paying delays

seminar information

info to lecturer

lecturer data

bill


seminar requestsseminar data

certi

ficat

eslis

t of p

artic

ipan

tssem

inar

sho

rt tit

le

pres

enta

tionN

o

lect

urer

dat

a

data base seminars and customers

payin

g de

lays

billi

ng d

ata

invo

ice

data

invo

ice

data

Interface: comparable with a class

Interface: comparable with a class

Product function (F):comparable with• use cases

(general F)• operation of a

class (specific F)

Product function (F):comparable with• use cases

(general F)• operation of a

class (specific F)

Data flows: collected sets of

attributes

Data flows: collected sets of

attributes

31


Static OOA model: ‘seminar organisation’

*

*

0..1

Associate

Contractor

Participant

Substitute participant

Customer

Seminar supervisor

Referent

Is able to conduct

* * *

*

* 1*

1

**0..1

1

*

*

*

1

1

0..1

0..1






Company internal presentationAll-inclusive price: FloatParticipants max: Short

Public presentationCooperation partner: String<100>Cancel fee: FloatParticipant min: ShortParticipant actual: Short







Employer




32


0..1

Associate

Contractor

Participant


Customer

**0..1

1

*

*

10..1

0..1




Employer




Static OOA model: notions

Classes: - nameattribute- operations

Association

Cardinality

Role

Generalization /

Inheritance

33


*

*

0..1

Associate

Contractor

Participant


Customer

Seminar supervisor

Referent

Is able to conduct

* * *

*

* 1*

1

**0..1

1

*

*

*

1

1

0..1

0..1














Employer




Static OOA model: problems (1)

To be able to read a final model

To be able to produce a model

To be able to assess a final model

But: is the model also

reasonable? Are there missing:• classes

• attributes• operations ?

Do we have the choice

of other classes?

Most challenging problem:

How to develop just this model?

34


*

*

0..1

Associate

Contractor

Participant


Customer

Seminar supervisor

Referent

Is able to conduct

* * *

*

* 1*

1

**0..1

1

*

*

*

1

1

0..1

0..1














Employer





12 classes:Why just these

ones ?

12 classes:Why just these

ones ?

Why not?

printDoP()

customerbill dateamount

delay of paymentname streetnumbercountryZIPcityphone

address

35


*

*

0..1

Associate

Contractor

Participant


Customer

Seminar supervisor

Referent

Is able to conduct

* * *

*

* 1*

1

**0..1

1

*

*

*

1

1

0..1

0..1














Employer





carried out: Booleannet price: Short

acquire()change()delete()printInfo()...

Presentation

additional attributes and

operations

additional attributes and

operations

5.2 Seminar dataD30 (PD30) Presentation data (max. 100 000):Presentation number, duration (in days), from, to,

daily period split-beginning, daily period split-end, beginning of the first day, end of the last day, presentation place (hotel/company, address, room), cooperation partner, public (yes/no), net price, cancel fee, min. participant rate, max. participant rate, actual participant, carried out (yes/no)

attributes and operations:

Why just these ones?

attributes and operations:

Why just these ones?

36


*

*

0..1

Associate

Contractor

Participant


Customer

Seminar supervisor

Referent

Is able to conduct

* * *

*

* 1*

1

**0..1

1

*

*

*

1

1

0..1

0..1














Employer




Static OOA model: inheritance

3 generali-sation

classes

3 generali-sation

classes

has 3 derived classes

has 3 derived classes

Problem:comprehensible arrangement of classes (automatizationis subject of research)

37


*

*

0..1

Associate

Contractor

Participant


Customer

Presentation custodian

Referent

Is able to conduct

* * *

*

* 1*

1

**0..1

1

*

*

*

1

1

0..1

0..1














Employer




Static OOA model : associations, roles

name of the association

name of the association

several roles in associations between

the same classes

several roles in associations between

the same classes

38


*

*

0..1

Associate

Contractor

Participant


Customer

Seminar supervisor

Referent

Is able to conduct

* * *

*

* 1*

1

**0..1

1

*

*

*

1

1

0..1

0..1














Employer




Static OOA model : cardinalities

some cardinalities

some cardinalities ?

Is a 1:1 relation between client and public presentation

Is a 1:1 relation between client and public presentation

39





c) Submodels in UML



f) Packages

40


Combination of basic concepts in object-oriented analysis

pseudocode

stateautomaton

classdiagram

OOA1990

ER (Entity Relationship)

collabo-ration diagram

sequencediagram

use casediagram

entities &relations

classstructures

controlstructures

finiteautomaton

interactionstructures

workflow

Data Dictionary (Balzert: attribute structure)

Data flow diagram(Rumbaugh: functional model, 1991)

41


What is to be specified in more detail for classes?

classes• general task of a class

attributes• meaning

(Which information is represented?)• structure, type: DD

operations• effect, transformational behaviour• parameter, types of parameter (signature of operation)

Customer

name: NameTaddress: AddressTfunction: Stringbusiness volume: Currency

produce notification()

42


Example: specification of attributes (1)

Class CustomerAttribute Name

Description: the name of the customerType: NameT

Attribute AddressErgonomic Name: private addressDescription: the private address of the customerType: AddressTOptional attribute: yes

user interface? DD

43


Example: specification of attributes (2)

Specification of the user defined Type NameTNameT = Salutation + (Title) + First name + NameAttribute Salutation

Type: enumRange: Mr., Mrs., MissDefault value: Mr.

Attribute TitleDescription: academic degreeType: enumRange: Dr., Prof., Prof. Dr., emptyExtendable: yes %new Titles possibleDefault value: emptyOptional Attribute: yes

Attribute First name...Attribute Name ...

DD - notation

44





c) Submodels in UML



f) Packages

45


Packages

Goal:Collect components to a larger unit.

Analog notion: Subsystem

UML• A package collects model elements (e.g. classes)

and diagrams• A package may contain packages.

46


Packages in UML notation

Package name

Trading system

Stock

SalePurchase

Dependence

47


*

*

0..1

Associate

Contractor

Participant


Customer

Seminar supervisor

Referent

Is able to conduct

* * *

*

* 1*

1

**0..1

1

*

*

*

1

1

0..1

0..1














Employer




Package ‘Seminar management’: Offers of the company

48


Package diagram ‚Seminar management‘

Person

Associate

Presentation

Lecturer

Public presentation

Company internal presentation

Seminar type

Seminar management

Topic 13 Object-oriented Analysis · Object-oriented analysis due to Booch (1994)...

Documents

Transcript of Topic 13 Object-oriented Analysis · Object-oriented analysis due to Booch (1994)...