Day1_OOAD & UML.ppt [Compatibility Mode]

7/31/2019 Day1_OOAD & UML.ppt [Compatibility Mode]

1/62

FPT SOFTWARE TRAINING MATERIAL Internal use 04e-BM/NS/HDCV/FSOFT v2/3

Instructor:


2/62


3/62

General IntroductionObject Oriented Software Development

Object-Oriented Methodologydevelopment approach used to build complex systems using

the concepts of object, class, polymorphism, and inheritance

with a view towards reusability

encourages software engineers to think of the problem in


erms o e app ca on oma n ear y an app y a cons s en

approach throughout the entire life-cycle

Object-Oriented Analysis and Design (OOAD)

analysis models the real-world requirements, independent ofthe implementation environment

design applies object-oriented concepts to develop and

communicate the architecture and details of how to meet

requirements


4/62

General IntroductionSoftware Design

Design transforms requirements intoan architecture diagram

subsystems, modules and their relationships

a detailed design


p n r n r , ru ur , n

algorithms of each module

Also develops

a review plan for ensuring the design meets therequirements

a test plan for ensuring the implementation meets the

design


5/62

General IntroductionObject-Oriented Analysis 1/2

Builds a real-world model from requirementsclient interviews

domain knowledge

real-world experience


Model is more precise and concise than the

informal problem definition

The model addresses three aspects of objectsclass structure and relationships

sequencing of interactions and events

data transformations and computations


6/62

General IntroductionObject-Oriented Analysis 2/2

Class Model static structure

what objects are in the system?

how are they related?

Dynamic Model

Data-Oriented

Action-Oriented


what events occur in the system

when do they occur and in what

order?

Functional Modeldata transformations

what does the system do

Both Data and Actions


7/62

General IntroductionOMT & UML (OMT turned into UML)

OMT [Object Modeling Technique - Rumbaugh et al.,1991]consists of

building three complementary models of the system

adding implementation details to the models

implementing the models

OMT includes a set of


phases [processes]

diagramming techniques

OMT has four phases

object-oriented analysis builds a real-world model system design determines overall architecture of system

object design decides upon data structures and algorithms

implementation translates design into programming language


8/62

The Unified Modeling Language (UML) is a standard language for

Constructin Documentin

General IntroductionWhat is UML?


8

Business Modeling Communications


9/62

General IntroductionOMT Stages & Models

Analysis- Model of real-world situation- What ?

System Design- Overall architecture (sub-systems)

Object Design

ObjectModel

-Staticstructureofobjectsandtheirrelationships

(objectdiagram) DynamicModel

-Controlaspectsofthesystem

(statediagrams)FunctionalModel

-Datavaluetransforamtions

(dataflowdiagrams)


-- Algorithms/data structures to

implement each class

Implementation- Translation of object classes and

relationships to a particularobject-oriented language

time

System


10/62

General IntroductionOO Analysis & Design Steps

Class Modeling

Dynamic Modeling

Functional Modeling

Add O erations to the Class Model


Iterate and refine the models

After the first iteration, steps may occur in parallel

or out of orderAll models must be kept in synch as changes are made


11/62

Class Modeling

Identify objects and classes

Prepare a data dictionary

Identify associations between objects

Identif class attributes and initial set of


operations

Organize object classes using inheritance


12/62

Class ModelingWhat is an object?

Represent an entity in the real world

Possesses operation (behavior) and attributes

data state


Operation/BehaviorMethod inside class

Consists of things that the object know how to do

Unique Identifiable

Is a black box which receives messages

Data contain information describe

the state of objects


13/62

Class ModelingAbstraction

Polygon

Attributes:

- vertices

- border color


- fill color

Operations:

- draw

- erase

- move


14/62

Nouns suggest candidate Classes.

Not every noun is an Object Class.

Some are attributes of another Class.

Class ModelingDomain Analysis

Problem Domain

Natural Language


Some are irrelevant, outside the scope of the application.

Verb phrases suggest class associations

Some relationships are irrelevant (caution).

Proper nouns suggest Objects of a Class type. Beware

of singular nouns.


15/62

Class ModelingClasses Identifying 1/2

Class defines methods, variables for a kind of object Class is an abstract description of a set of objects

We actually write code for a class, not object

Use class as a blue-print to create (instantiate) an object


Polygon

Attributes:

- vertices

- border color

- fill color

Operations:

- draw

- erase

- move

instantiate

instantiate

instantiate


16/62

Finding classes:Use domain analysis as before.

Derive them from the use cases (descriptions).

Look for data which must be stored or analysed.

Class ModelingClasses Identifying 2/2


Are there external systems?

Are there any devices under the control of the

system?

Are there any organisational parts?


17/62

Class ModelingClasses, Attributes & Operations

Attributes define the properties of the objects every instance of the class has the same attributes

an attribute has a data type

the values of the attributes may differ

among instances

O erations define the behavior of the


objects

action performed on or by an object

available for all instances of the class

need not be unique among classes

hand-o

pitch,

Class Attributes Operationsball radius, weight catch, throw

football air pressure pass, kick, hand-o

baseball liveness hit, pitch,


18/62

Class ModelingAttributes

Describe the state and characteristics of the object. Must be typed, primitives like integer, real, Boolean,

point, area, enumeration, these are primitives. May

be language specific.


, .

Class variables have scope across every instance of

class, change one changes all (static attributes)

Syntax visibility name : type-expression = initial-value

{property-string}

Only name and type are mandatory.


19/62

Class ModelingOperations

Operations manipulate attributes and performother tasks.

Scope is the Class.

Operation signature is composed of name,


parameters and return type. name(parameter-list) return-type-expression

Scope and visibility rules apply.


20/62

Class ModelingObject Model Notation

Class NameInstanceVariable1

InstanceVariable2: type

Method1()

Method2(arguments) return type

Classes are represented as rectangles;

The class name is at the top, followed by

attributes (instance variables) and methods

(operations)

Depending on context some information can be

hidden such as types or method arguments


(Class Name)

InstanceVariable1 = value

InstanceVariable2: type

Method1()

Method2(arguments) return type

Objects are represented as rounded rectangles;

The objects name is its classname surrounded

by parentheses

Instance variables can display the values that

they have been assigned; pointer types will

often point (not shown) to the object being

referenced

Cl M d li


21/62

Class ModelingEncapsulation

Allow to show only the important methods asinterface

Hide detail information

Hide the data item


Access to data item only through member methods

Cl M d li


22/62

Class ModelingAccess modifiers

Used for accessibility of data member andmember methods

Example:

Private


Protected

Friendly (Java)

Cl M d li


23/62

Class ModelingInformation Hiding

Implemented by the Private access modifier

Hidden methods, member data can only be

accessed by member methods

Benefit:


Your brains doesnt have to deal with it unless youre

specifically concerned with it

When change occurs, the effects are localized

Cl M d li


24/62

Class ModelingClass Diagram

Class diagrams show the

classes of the system, theirinterrelationships (including

inheritance, aggregation, and

association), and the

operations and attributes of

Name

Inheritance


24

Attributes

Operations

Relations Associations

Aggregation

Cl M d li g


25/62

Class ModelingInheritance

Classes with a set of similar attributes and operationsmay be organized into a hierarchical relationship

Common attributes and operations are factored out and

assigned to a broad superclass (generalization)

eneralization is the is-a relationshi


superclasses are ancestors, subclasses are descendants

A class can be iteratively refined into subclasses that

inheritthe attributes and operations of the superclass

(specialization)

Class Modeling


26/62

Class ModelingOMT Inheritance Notation

GeneralizationSuperclass

Class

Attributes

Operations

Ball

Radius, Weight

Throw, Catch


Specialization

Subclasses

Football

air pressure

pass, kick, hand-off

Baseball

liveness

hit, pitch, tag

Basketball

air pressure , dimples

shoot, dribble, pass

Class Modeling


27/62

Class ModelingMultiple & Multilevel Inheritance

Single inheritance: Inherit from only one superclass

Multiple inheritance: a class have common

characteristics with more than one super class


Multilevel inheritance :

Level of inheritance

hierarchy.

Class Modeling


28/62

Class ModelingAdvantages of Inheritance

Development model closer to real life object modelwith hierarchical relationships

Reusability reuse public methods of base class

Extensibility Extend the base class


derive class cannot change it

Rapid prototyping

Class Modeling


29/62

Class ModelingAssociations

Associations model Class relationships. Associations should be named where

appropriate. Usual to use verbs from the

problem domain.


Roles played by classes may also be named.

Associations have a cardinality.

Rules from programming about sensiblenames apply.

Class Modeling


30/62

Association Name

Exactly One

(default)

Class1 Class2

Class

*

Class ModelingAssociations & Cardinality


Class

Class

Class

ClassZero or more

Optional (zero or one)

One or more

Numerically specified

1.. *

1..5,8

0..1

Class Modeling


31/62

Class ModelingAggregation

Aggregation is a special form of association thatindicates a part-of relationship between a

whole and its parts

Useful when the parts do not have independent


A part is subordinate to the whole

In an aggregation, properties and operations may

be propagated from the whole to its parts

Class Modeling


32/62

Class ModelingOMT Aggregation Notation

Window


TitleBar ScrollBar Border

Class Modeling


33/62

Microcomputer

Monitor System boxMouse Keyboard

1+

Class ModelingMultilevel Aggregation


Chassis CPU RAM Fan

1+1+

Class Modeling


34/62

Class ModelingAbstract class 1/2

Class that contains one or more abstractmethods

Abstract method: Method that has only

declaration but no implementation.


Classes that extend abstract class make them

concrete by implementing those abstract

methods

Class Modeling


35/62

Class ModelingAbstract class 2/2

class animal{ protected: int speed;

char color[20];

public:

pure virtual void init();

float run(int distance){

animal *p = new animal();

animal p;

It is impossible to instantiatean object from abstract class


It is possible to create a pointerto abstract class

float time = round(((float)

distance)/speed,2);

cout


36/62

Class Modeling


37/62

C ass ode gPolymorphism - Overloading

To assign an operator, identifierorliteral morethan one meaning, depending upon the data types

associatedwith it at any given time during

program execution.

Two or more method with the same name,


different signature

Example:

void display (int iX)

void display (float fY)

void display (char[] chC)

void display (char[] chC, int offset, int numchar)

Class Modeling


38/62

gPolymorphism - Overriding

Process of defining/re-defining the methods inthe derived class

Methods have same name/same signature


Class Modeling


39/62

gPolymorphism Example 1/2

class animal

{

protected: int speed;

char color[20];

public:

virtual void init(){}


{

float time = round(((float) distance)/speed,2);

cout


40/62

gPolymorphism Example 2/2

class dog: public animal{

public:

void init()

{

speed = 40;

class tiger: public animal{

public:

void init()

{

speed = 90;


strcpy(color, Black);

}

void show()

{

cout


41/62

Dynamic Modeling

Prepare scenarios Identify events between objects

Prepare an event trace for each scenario

Build a state diagram


Match events between objects to verify

consistency

Dynamic Modeling


42/62

y gDynamic Model Diagrams

The dynamic model tracks behavior over timedescribed in terms of change in objects or event

sequences between objects

Event Trace Diagrams


show typical dialog or usage scenarios as well as

exceptional and/or special cases

State Diagrams

relates events, states, and state transitions

a scenario is a path through the state diagram

Dynamic Modeling


43/62

Events & Scenarios

An event is something that occurs between objects events have attributes, which are the information transferred

from one object to another

A scenario is a specific sequence of events representing

a path through a systems states


Legitimate scenarios

Common paths (e.g. frequently used functionality)

Error conditions and known exceptions

An event trace extends the scenario to clarify eventsbetween objects

Dynamic Modeling


44/62

Event classes & attributes

Event Classesairplane departs

(airline, flight number,

city)

EventsUnited Flight 23

departs from Rome


mouse u on pus e

(button, location)

phone receiver lifted

digit dialed (digit)

r g mouse u on

pushed at (29, 30)

phone receiver lifted

digit dialed (2)

Dynamic Modeling


45/62

An example scenario

Scenario for a phone callcaller lifts receiver

dial tone begins

caller dials digit (2)





specified phone rings

etc.

Dynamic Modeling


46/62

OMT Event Trace Notation

objects are vertical lines

events are horizontal lines

arrows indicate sender and receiver

time passes from top to bottom

Customer Pump Credit Corpselect method of payment

select credit

insert card

slide card through reader


select grade

select premium

return approved

display unit cost, total cost, gallons dispensed

pump on

pump gas

update display with total cost, gallons dispensedcharge total cost to account

Dynamic ModelingE T E l


47/62

Event Trace Example

Caller Phone line Callee

caller lifts receiver

dial tone begins

dials (2)

dial tone ends

dials (7)


ringing tone phone rings

answers phone

phones connectedphones connected

callee hangs up

connection broken connection broken

caller hangs up

dials (6)

Dynamic ModelingE t T S Di


48/62

Event Trace ~ Sequence Diagram

Asequence diagram

is

An interaction diagramthat details howoperations are carried out.

What messages are sentand when.

Sequence diagrams areorganized according to

Object: Class


48

Lifeline

Operations

Message

Dynamic ModelingSt t & T iti


49/62

States & Transitions

A state is an interval between eventsit may have an activity that can trigger starting,

intermediate and ending events

defined in terms of a subset of object attributes and


A state transition is a change in an objects

attributes and links

it is the response of an object to an eventall transitions leaving a state must correspond to

distinct events

Dynamic ModelingState Machine Diagram


50/62

State Machine Diagram

A State Machine diagram

shows the possible states ofthe object and the transitions

that cause a change in state.


50

Functional ModelingHierarchical DFD


51/62

Hierarchical DFD

High-level functionality iteratively refined into smaller functional

units

each high-level process may be expanded into a separate DFD

top-level processes correspond to operations on complex objects, while

lower-level processes are operations on basic objects

Nesting depth is dependent on application


terminates with simple functions

each level must be coherent

Hierarchical DFD corresponds to the following

context diagram shows boundaries of system

mid-level DFDs show context decomposition

primitive DFDs are simple functions that need not be expanded

Functional ModelingDFD Example: Office Supply


52/62

DFD Example: Office Supply

Web Server input

stream

employee

Employee DB

validate

employee

name/

passwordverification

validate

order

order

verificationaccount

number

AccountDB


response (receipt)

order process

order

Product DB

verification item

finalize

order

validated

order

Order DB

orderorder

info

Add Operations to the Object Model


53/62

Add Operations to the Object Model

From the Object Model:

Reading/writing object attributes (e.g., get_width, get_height of

Rectangle)

From Events, State Actions, and Activities

in the Dynamic Model:


Each event sent to an object => operation

(e.g., Vending machine: set_balance)

Actions/activities may be operations

(e.g., Vending machine: do: test item and compute change)

From Functions in the Functional Model:

Each function in the DFD corresponds to an operation (e.g., bank

example: subtract withdrawal from Account)

OMT: Four Phases


54/62

OMT: Four Phases

Object-oriented analysisbuilds a real-world model

System design

determines overall architecture of system


Object design

decides upon data structures and algorithms

Implementation translates design into programming language

OMT: Four phases1 System Design


55/62

1. System Design

Devises high-level strategyfor solving problem Set trade-off priorities

Construct system architecture by organizing into

subsystems (system structuring) Choose an approach for persistent data management (repository model)


ocate components to processors an tas s str ut on mo e

Choose the implementation of control in software

system (control modeling) Identify concurrency inherent in the problem

Define access to global resources

Divide problem into implementable components

(modular decomposition)

OMT: Four phases2 Object Design


56/62

2. Object Design

Full definition of all the classes in the system

Implementation alternatives evaluated and chosen

Combine three models to obtain class operations

Design algorithms to implement operations


Implement control for external interactions

Adjust class structure to increase inheritance

Design associations Determine object representation

Package classes and associations into implementable

modules

OMT: Four phases3 Detailed Design 1/2


57/62

3. Detailed Design 1/2

Detailed design is the process of completely

specifying an architectural design such that module

implementation can proceed (independently)

Interface specifications

brief description of each module

FPT SOFTWARE TRAINING MATERIAL Internal use04e-BM/NS/HDCV/FSOFT v2/3

attributes

brief description and specify types

operations

brief description

list of parameters and parameter types

return type (if applicable)

OMT: Four phases3. Detailed Design 2/2


58/62

3. Detailed Design 2/2

Algorithm and data structure specificationthe designer can give hints as to what algorithms

or data structures might be most useful for a

particular module


,algorithm or data structure that must be used

in addition, constraints in the requirements may

require one approach over another

for instance, implementing a data structure so that it

uses the minimum amount of memory possible vs.

keeping everything in memory for speed

OMT: Four phases4. Implementation 1/2


59/62

4. Implementation 1/2

Most programming languages provide verysimilar sets of features

user-defined types

control structures


i ...t en...e se...

while x do y

for i = 1 to x

etc

etc.

This means that, in general, operations can be

expressed in many different languages

OMT: Four phases4. Implementation 2/2


60/62

4. Implementation 2/2

Major differences between languages usuallyfall into these categories

compiled vs. interpreted

procedural vs. object-oriented


general purpose vs. application/domain specific

e.g. C++ vs. FileMaker Pros scripting language

If a design takes advantage of, or depends on,

one or more of these features then certainprogramming languages have to be excluded

from implementation

OMT: Four PhasesModularity Mechanisms


61/62

y

One import feature of any programming language is

how it can represent modules directly

C and C++ have separate header and body files

Java, .NET has package names and class files

Ada has a construct called a package with a specification


and body (implementation)

etc.

These features are important since it makes it easier

to map the design into code and to trace a code

module back to its design counterpart


62/62

Q & A


Documents

Day1_OOAD & UML.ppt [Compatibility Mode]