0% found this document useful (0 votes)
124 views10 pages

Object-Oriented Analysis (OOA)

This document provides an overview of object-oriented analysis (OOA) techniques for modeling software problems prior to design and implementation. It discusses elements of the analysis model like use cases, activity diagrams, class diagrams, and state diagrams. Specific OOA techniques covered include object-oriented scenario-based modeling, class-responsibility-collaborator modeling, and identifying classes and responsibilities. The document also discusses modeling concepts like associations, aggregations, generalizations and provides examples of class and sequence diagrams.

Uploaded by

Ioan Todorovici
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
124 views10 pages

Object-Oriented Analysis (OOA)

This document provides an overview of object-oriented analysis (OOA) techniques for modeling software problems prior to design and implementation. It discusses elements of the analysis model like use cases, activity diagrams, class diagrams, and state diagrams. Specific OOA techniques covered include object-oriented scenario-based modeling, class-responsibility-collaborator modeling, and identifying classes and responsibilities. The document also discusses modeling concepts like associations, aggregations, generalizations and provides examples of class and sequence diagrams.

Uploaded by

Ioan Todorovici
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 10

Foundations of Software Engineering

Foundations of Software Engineering

Object-oriented analysis (OOA)


! What are the relevant objects? How do they relate to one
another?

Object-Oriented Analysis and Modeling

! How do we specify/model a problem so that we can create


an effective design?

! OOA aims to model the problem domain, by developing an


object-oriented (OO) system.

Dr. Radu Marinescu

Dr. Radu Marinescu

Foundations of Software Engineering

Elements of the Analysis Model


Object-oriented Analysis Scenario-based modeling
Use case text & diagrams Activity diagrams

Structured Analysis Flow-oriented modeling


Data structure diagrams Data flow diagrams Control-flow diagrams

Class-based modeling
CRC models Class diagrams

Overview of the OOA Process...

Behavioral modeling
State diagrams Sequence diagrams

Dr. Radu Marinescu

Class Diagrams

Sequence Diagrams

Foundations of Software Engineering

Foundations of Software Engineering

Class-Responsibility-Collaborator (CRC) Modeling


! Technique to identify candidate classes and indicate their
responsibilities and collaborators
! K.Beck&W.Cunningham (1989), R.Wirfs-Brock(1990,2002)

CRC Cards Session Scenario


! Use-Case driven
! a use-case is the token

! Uses simple index cards

! Goal: be able to go through the whole use-case description


by using the responsibilities written on the CRC cards
! ...and of course following the Collaborator links

Dr. Radu Marinescu

Dr. Radu Marinescu

Foundations of Software Engineering

Foundations of Software Engineering

Rules for Identifying Classes


1. Retained Information information about object must be remembered for the system to function 2. Needed Services have a set of operations that change the value of its attributes 3. Multiple Attributes focus on major information object with single attribute is ok during design, but during analysis is just
an attribute of another object

Identifying Responsibilities

! attributes and operations of an identified class ! Guidelines of Wirfs-Brock:


1. System intelligence should be evenly distributed 2. Information about one thing should be localized within a single class 3. Information and its related behavior should stay in the same class 4. Responsibilities should be shared among related classes

4. Essential Requirements objects entities that produce or consume information of the system, in any
solution

Dr. Radu Marinescu

Dr. Radu Marinescu

Foundations of Software Engineering

Foundations of Software Engineering

Operations = Verbs
! Computation ! Manipulation of data
! e.g., add, delete, modify attributes

Collaborations

! Query
! about the state of an object

! Monitor an object
! for the occurrence of a controlling event

! Class can fulfill responsibilities by:


1. using its own operations to manipulate its own attributes 2. collaborating with others

! Has knowledge about the state of class and its associations

! Three types of generic relationships:


1. has-knowledge-of (association) 2. is-part-of (aggregation) 3. composition

Dr. Radu Marinescu

Dr. Radu Marinescu

10

Foundations of Software Engineering

Foundations of Software Engineering

Problema Proliferarii Claselor [Riel96]


! Spaghetti Code vs. Ravioli Code

Heuristics for Object-Oriented Modeling

! Cum se manifesta Codul Ravioli


! Vreau sa adaug o facilitate noua in sistem. Care 23 de clase din cele 4.200 de clase trebuie sa le modific?

Fiti retinuti in a modela ca si clase entitati din afara sistemului de implementat!

! Exemplu: Clientul unui Bancomat


! trimite un mesaj bancomatului

Clase sunt acelea care PRIMESC MESAJE (sunt apelate) nu cele care TRANSMIT MESAJE (apeleaza)!
Dr. Radu Marinescu 11 Dr. Radu Marinescu 12

Foundations of Software Engineering

Foundations of Software Engineering

Roluri vs. Clase

Euristici pentru Eliminare Claselor Inutile


Nu transformati operatiile in clase

! Comportamentul este cel care decide!


! daca comportamentul difera: avem clase; ! daca nu: doar roluri ale aceleeasi clase ! depinde de domeniul modelat de aplicatie
"

naste() vs. schimbaScutece()


Dr. Radu Marinescu 13 Dr. Radu Marinescu 14

Foundations of Software Engineering

Foundations of Software Engineering

Cand Poate Fi Operatia o Clasa?

Class Diagrams

! cand cerintele sunt de asa natura incat operatiile reprezinta un


! ex. tiparirea tranzactiilor --> operatii persistente ! tiparul Command
Dr. Radu Marinescu 15

atom adica obiectiveaza o anumita entitate intr-un context dat

Dr. Radu Marinescu

Foundations of Software Engineering

Foundations of Software Engineering

Class Diagrams
TariffSchedule Enumeration getZones() Price getPrice(Zone) Trip zone:Zone price:Price

Classes
Name
TariffSchedule zone2price getZones() getPrice()

TariffSchedule Table zone2price Enumeration getZones() Price getPrice(Zone)

Attributes Operations

Signature

! Class diagrams represent the structure of the system. ! Class diagrams are used
! during requirements analysis to model problem domain concepts ! during system design to model subsystems and interfaces ! during object design to model classes.

! A class represent a concept. ! A class encapsulates state (attributes) and behavior


(operations). ! Each attribute has a type. TariffSchedule ! Each operation has a signature. ! The class name is the only mandatory information.
17 Dr. Radu Marinescu 18

Dr. Radu Marinescu

Foundations of Software Engineering

Good Object-Oriented Design

Instances
tariff_1974:TarifSchedule zone2price = { {1, .20}, {2, .40}, {3, .60}}

Instance vs. Class

! An instance represents a phenomenon. ! The name of an instance is underlined and can contain the class of
the instance.

! The attributes are represented with their values.


Rene Magritte, Treachery of Images - 1929
Dr. Radu Marinescu 19 Dr. Radu Marinescu 20

Foundations of Software Engineering

Foundations of Software Engineering

Associations
TarifSchedule Enumeration getZones() Price getPrice(Zone) Trip

1-to-1 and 1-to-Many Associations


Country name:String Has-capital 1 1 City name:String

price zone

1-to-1 association

Polygon

Point x:Integer y:Integer

! Associations denote relationships between classes. ! The multiplicity of an association end denotes how many
objects the source object can legitimately reference.
Dr. Radu Marinescu 21

draw()

1-to-many association
Dr. Radu Marinescu 22

Foundations of Software Engineering

Foundations of Software Engineering

Aggregation
! An aggregation is a special case of association denoting a
consists of (HAS-A) hierarchy. ! The aggregate is the parent class, the components are the children class.
Car

Composition
! A solid diamond denote composition, a strong form of
aggregation where components cannot exist without the aggregate.

TicketMachine 3

ZoneButton

1 Engine

2..4 Door

Dr. Radu Marinescu

23

Dr. Radu Marinescu

24

Foundations of Software Engineering

Foundations of Software Engineering

Generalization
Button

CancelButton

ZoneButton

Sequence Diagrams

! Generalization relationships denote inheritance between classes. ! The children classes inherit the attributes and operations of the
parent class. ! Generalization simplifies the model by eliminating redundancy.
Dr. Radu Marinescu 25 Dr. Radu Marinescu

Foundations of Software Engineering

Foundations of Software Engineering

UML Sequence Diagrams


! Sequence Diagram: an "interaction diagram" that models a
single scenario executing in the system
! perhaps 2nd most used UML diagram (behind class diagram)

Representing Objects
! squares with object type, optionally preceded by object
name and colon
! write object's name if it clarifies the diagram ! object's "life line" represented by dashed vert. line

! Participant: an object or entity that acts in the sequence


diagram
! sequence diagram starts with an unattached "found message" arrow

! Message: communication between participant objects ! Axes in a sequence diagram:


! horizontal: which object/participant is acting ! vertical: time (down -> forward in time)

Dr. Radu Marinescu

27

Dr. Radu Marinescu

28

Foundations of Software Engineering

Foundations of Software Engineering

Messages between objects ! message (method call) indicated by horizontal arrow to


other object
! write message name and arguments above arrow

Indicating method calls


! Activation: shows when object's method is on the stack
! either that object is running its code, or it is on the stack waiting for another object's method to finish ! nest to indicate recursion
Activation

! dashed arrow back indicates return ! different arrowheads for normal / concurrent (asynchronous) methods

Nesting

Dr. Radu Marinescu

29

Dr. Radu Marinescu

30

Foundations of Software Engineering

Foundations of Software Engineering

Example 1:
! Building an executable from sources
! load source files and compile them ! load resulting object files and link them ! write executable file

Sequence Diagram Compilation


:Compiler Actor
Compile

Linker
Load Files

FileSystem

Compile files Save OBJ Files Link Load OBJ files

Link OBJ files


Write EXE file

Dr. Radu Marinescu

31

Dr. Radu Marinescu

32

Foundations of Software Engineering

Foundations of Software Engineering

Creating and Deleting objects

Branching Flow: flow goes to different objects [if condition is met]


:Editor
Load File

FileSystem

:BinaryViewer

:TextViewer

[text file] [binary file]


from M.Fowler-UML Distilled, 2004
Dr. Radu Marinescu 33 Dr. Radu Marinescu 34

Foundations of Software Engineering

Foundations of Software Engineering

Flow of messages
ZoneButton TarifSchedule Display

Iteration & condition


continued from previous slide...

Passenger

Passenger selectZone() lookupPrice(selection) price

ChangeProcessor

CoinIdentifier

Display

CoinDrop

*insertChange(coin)
Iteration

lookupCoin(coin) price displayPrice(owedAmount)

Dataow

displayPrice(price)

to be continued... Condition

[owedAmount<0] returnChange(-owedAmount)

! ! ! !

The source of an arrow indicates the activation which sent the message An activation is as long as all nested activations Horizontal dashed arrows indicate data flow Vertical dashed lines indicate lifelines
Dr. Radu Marinescu 35

! !

Iteration is denoted by a * preceding the message name Condition is denoted by boolean expression in [ ] before the message name
Dr. Radu Marinescu 36

Foundations of Software Engineering

Foundations of Software Engineering

Alternative Notation for Condition and Loops

Sequence Diagram Summary


! UML sequence diagram represent behavior in terms of
interactions. ! Useful to find missing objects. ! Time consuming to build but worth the investment. ! Complement the class diagrams (which represent structure).

from M.Fowler-UML Distilled, 2004


Dr. Radu Marinescu 37 Dr. Radu Marinescu 38

You might also like