oo design for software engineers - western...

Hamada Ghenniwa 2/8/2006

SE203b, ECE UWO 1

Feb. 5, 2006 SE203b, ECE UWO, Hamada Ghenniwa

OO Design for Software Engineers

W3 : Software Design with

Object Oriented Paradigm

Feb. 5, 2006 SE203b, ECE UWO, Hamada Ghenniwa 2

The Road Map

Introduction to Software Design

Software Design Approaches

• Introduction to OO Paradigm

• Software Design with OO Paradigm

• Patterns in Design and Architecture

• Selected Design Topics


SE203b, ECE UWO 2


Design Concepts

• Abstraction

• Refinement

• Modularity

• Information Hiding

• Interface

• Functional Independence

• Architecture

• Reusability


Design Concepts:Recap (Cont.)

P3P2

P4P1RefinementModularity

S1

S4

S3

S2

Abstraction

F


SE203b, ECE UWO 3



S1

S4

S3

S2

Interface S1

S4

S3

S2

Info. Hiding S1

S4

S3

S2



Coupling : to measure the degree of interdependence among modules

S1

S4

S3

S2Min Coupling


SE203b, ECE UWO 4



Cohesion: to measure the degree of the functional strength of a module

S1

S4

S3

S2Max Cohesion


Reusability

• To use the existing software engineering knowledge or artifactsto build new software products

S1

S4

S3

S2

S5

S4

S3

S6

S1

S4S3S2

S6

S5Reusability


SE203b, ECE UWO 5


Object Oriented Paradigm

The OO paradigm is based on the idea that we canconstruct software by assembling interoperable entities (objectsobjects)

o OO as a computational model

o OO as Programming language

o OO as Analysis and Design method


OO: Main Characteristics

• Encapsulation

• Classification

• Identity

• Generalization

• Inheritance

• Polymorphism


SE203b, ECE UWO 6


Encapsulation

• Encapsulation by which an “objectobject” groupsAttributes

Operations

• ExampleAn entity: BankAccountThree attributes:

o No

o Name

o Balance

Five operations: o Balance

o Debit

o Credit

o CalculateInterest

o ChangeName

• ExampleAn entity: BankAccountThree attributes:

o No

o Name

o Balance

Five operations: o Balance

o Debit

o Credit

o CalculateInterest

o ChangeName

Attributes

Operations

Entity Name

NoNameBalance

BalanceDebitCredit CalculateInterestChangeName

BankAccount


Classification

• Class is a grouping for the features of similar objects Features: attributes and operations

NoName

Balance

BalanceDebitCredit

CalculateInterestChangeName

BankAccount

No : 3100Name: Jane

Balance: $100

CalculateInterest Balance

Credit

DebitChangeName

ClassClassClass ObjectObjectObject


SE203b, ECE UWO 7


Identity

• A thing in the universe is captured as distinguishable entity (objectobject)Each object can be uniquely

o identified and

o Referenced

• More than one object can be instantiated from a class, each having its own data storage and attribute values


Example: AccountBank

NoNameBalance


BankAccount

No : 3100Name: Jane

Balance: $100

CalculateInterest Balance?

Credit

DebitChangeName

No : 4111Name: Lee

Balance: $2212

Calculate

Interest Balance?

Credit

Debit

ChangeName

No : 5111Name: Joe

Balance: $20

Calculate

Interest Balance?

Credit

Debit

ChangeName

No : 4110Name: Ali

Balance: $2000

Calculate

Interest Balance?

Credit

Debit

ChangeName

identity

state

behaviors

NoNameBalance


BankAccount


SE203b, ECE UWO 8


Identity + EncapsulationInformation Hiding & Interface

• The five operations provide the interface to access the data elements

• The structure of the Bank Account is hidden

No : 4110Name: Ali

Balance: $2000

Calculate

Interest Balance?

Credit

Debit

ChangeName message


Generalization

• Start with a general (abstract) class and then refinerefine it into successively more specific (concrete) classes

• The ‘is a’ relationship o ‘a student is a person’ Person

Student Employee

UML NotationUML Notation


SE203b, ECE UWO 9


Inheritance

A mechanismmechanism by which elements of the lowerlower--levellevel of abstraction (subclass)

incorporate the structure and behavior of the higherthe higher--levellevel of abstraction(superclass)


Inheritance(Cont.)

Reusability

• BankAccount is an abstract classIt contains things that apply to all types of account

• ChequingAccount & SavingAccountare subclasses of Account

It inherits general things from Account

It contains specializations

ChequingAccount SavingAccount

NoNameBalance


BankAccount


• Instances would be made of

ChequingAccount & SavingAccount

but not of BankAccount

• BankAccount serves to group together commonalities

• Instances would be made of

ChequingAccount & SavingAccount

but not of BankAccount

• BankAccount serves to group together commonalities


SE203b, ECE UWO 10


Polymorphism

• A mechansim enables related classes to have different methods that implement some abstract operation


ChequingAccountChequingAccount SavingAccountSavingAccount

NoNameBalance


BankAccount

CalculateInterest CalculateInterest

• e.g., SavingAccount and ChequingAccount CalculateInterest:

SavingAccount.CalculateInterest :

averageMonthlyBalance * interestRate

ChequingAccount.CalculateInterest :

minimumMonthlyBalance * interestRate

• e.g., SavingAccount and ChequingAccount CalculateInterest:

SavingAccountSavingAccount.CalculateInterest :

averageMonthlyBalanceaverageMonthlyBalance * interestRate

ChequingAccountChequingAccount.CalculateInterest :

minimumMonthlyBalanceminimumMonthlyBalance * interestRate


OO: Main Characteristics Design Concepts

• Encapsulation

• Classification

• Identity

• Generalization

• Inheritance

• Polymorphism

Abstraction

Refinement

Modularity

Information Hiding

Interface

Functional Independence

Architecture

Reusability


SE203b, ECE UWO 11


OOA/D Approaches

• In the early 90’s we had around 50 of them

BON, Booch, BOOM, Catalysis, CBD/e, Coad/Yourdon, COMMA

CRC, Convergent Engineering, Demeter, DOORS, DOOS

EROOS, Fusion, Goofee, HOOD, IDEA, ION, KISS

MERODE, MOSES, MWOOD, Object COMX, Objecteering

Objectory, OEP, Octopus, OMT, OOAD/OOIE, OOA/RD, OOBE

OOCL, OOHDM, OOram, OOSC, OOSD, OOSE, OOSP

Open, OSA, ROPES, RUP, Scrum, Skill-Driven Design, SDL

Shlaer & Mellor, Softstar, SOMA, SOMT, Syntropy, XP


OOA/D(Cont.)

• Deign Language + Design Method

Among the well known (combine both Language + Methods)

OMT: (Rumbaugh et al, 1991)

o OOSE: (Jacobson, 1992)

o Booch: (Booch, 1994)

o Unified Software Development Process (Jacobson, Booch & Rumbaugh 1999)

Rational Unified Process (RUP)

UMLo Rumbaugh, Booch and Jacobson got together to form Rational (1995)

UML is a modeling language (Jacobson, Booch & Rumbaugh 1995)


SE203b, ECE UWO 12


Overview of the UML

• UML is a language forvisualizing

specifying

constructing

documenting

the artifacts of a software-intensive system


UML: Structure

• UML is a de facto standard for OOADIt has been adopted by the OMG (Object Management group) as an OOnotation standard

• Support all or most development processes

• UML view things (objectsobjects) in the environment in terms ofStructure (Static)

Behavior (Dynamic)

In the UML, there are 9 standard diagrams


SE203b, ECE UWO 13


UML Diagrams

Use CaseDiagrams

Use CaseDiagrams

ComponentDiagrams

ComponentDiagrams

DeploymentDiagrams

DeploymentDiagrams

CollaborationDiagrams


SequenceDiagrams

SequenceDiagrams

ObjectDiagramsObject

Diagrams

ClassDiagramsClass

DiagramsStatechartDiagrams

StatechartDiagrams

ActivityDiagramsActivity

Diagrams

Static views: Dynamic views:


Team-Based Management

But, for Software DesignUML is Not Enough !

SE203b FocusSE203b Focus

Modeling Language Software

DevelopmentProcess


SE203b, ECE UWO 14


Models vs. SDLC

AnalysisAnalysis

DesignDesign

ImplementationImplementation

TestTest

RequirementsRequirements

AnalysisModel

DesignModel

Use CaseModel

ImplementationModel

TestModel

DeploymentModel

Analysis&

Design

Analysis&

Design


Workflows and Models

DesignModel

ImplementationModel

TestModel

Use CaseModel

DeploymentModel

AnalysisDesign

Implementation

Test

RequirementsRequirements


SE203b, ECE UWO 15


Use Case Model Use CaseDiagrams

Use CaseDiagrams



ComponentDiagrams

ComponentDiagrams

DeploymentDiagrams

DeploymentDiagrams

ObjectDiagramsObject

Diagrams

StatechartDiagrams

StatechartDiagrams

SequenceDiagrams

SequenceDiagrams

ClassDiagramsClass

Diagrams

ActivityDiagramsActivity

Diagrams

Use CaseModel

DesignModel

Depl.Model

Impl.Model

AnalysisModel

TestModel


Use Case Modeling

• Captures software requirement specificationsWith emphasis on functional requirement

• Emphasizes the functionality and behavior as it appears to outside entities

• A use case transforms SRS, and represents system functionality as transactions (‘use cases’) that are meaningful to

entities (‘actors’) interact with the system


SE203b, ECE UWO 16


Use Case Modeling: Main Elements

Construct Description Syntax

use case A sequence of actions, including variants, that a system (or other entity) can perform, interacting with actors of the system.

actor A coherent set of roles that users of use cases play when interacting with these use cases.

system boundary

Represents the boundary between the physical system and the actors who interact with the physical system.

UseCaseName

ActorName


Construct Description Syntax

association The participation of an actor in a use case. i.e., instance of an actor and instances of a use case communicate with each other.

generalization A taxonomic relationship between a more general use case and a more specific use case.

<<extend>> A relationship from an extension use case to a base use case, specifying how the behavior for the extension use case can be inserted into the behavior defined for the base use case.

<<include>> A relationship from a base use case to an inclusion use case, specifying how the behavior for the inclusion use case is inserted into the behavior defined for the base use case.

Use Case Modeling: Main Relationships

<<extend>>

<<include>>


SE203b, ECE UWO 17


• The main elements actor

relationships

use caseo use case diagramo use case description

use case internals can be specified by

– text and/or

– interaction diagrams

Use Case Modeling

Use case name:Actors:PreconditionsPostconditions:Normal Flow:……

Use case name:Actors:PreconditionsPostconditions:Normal Flow:……


Modeling in the Context of a System Use Case

FinancialOfficer

Client DB

TSX

Trader

Analyze risks

Price details

Capture deal

CurrencyExchange

<<extend>>

Valuation

<<include>>

<<include>>

Officer

eTrading System eTrading System eTrading System eTrading System


SE203b, ECE UWO 18


Actors

• Role that a human/hardware/software system plays during its interaction with the system

Actors do not need to be humans!

• Actors carry out use caseslook for actors, then their use cases

• Actors can get value from the use case or participate in it

Client DB

FinancialOfficer

Capture deal


Actors(Cont.)

• Actors can be specialized

• Actors can be connected to use cases only by association

• association will representcommunication means

o (both can send messages to, or receive messages from the other one)

Capture deal

FinancialOfficer

Officer


SE203b, ECE UWO 19


• Generic, step-by-step written description of a use case’s event flow

o List sequence of steps

interactions with actor(s), and

o describes what objects are exchanged

• Clear, precise, short descriptions

• May contain extension points

Use Case Description

FinancialOfficer

Client DB

TSX

Trader

Analyze risks

Price details

Capture deal

CurrencyExchange

<<extend>>

Valuation

<<include>>

<<include>>


Use Case Description:Capture

• Name: Capture deal

Actorso Trader, Financial Officer, TSX, Client DB

Preconditiono Financial Officer is logged in

Main flow of events1. Financial Officer enters the client name & bank account

2. Check that the client name & bank account are valid

3. Trader enters the number & code of shares to buy

4. Calculate price

5. Check limit

6. If below limit, send order to TSX

7. Store confirmation number in Client DB

Trader Client DB

FinancialOfficer

Capture deal

TSX


SE203b, ECE UWO 20


Use Cases: Terms and Concepts

• Unique name

e.g., “Capture deal”, “Validate user ID”

• Sequence of actions (event flows)textual (informal, semi formal, formal)

Main (normal) flow of events:

If below limit, send order to TSXStore confirmation number in Client DB

…….

Alternative flow of events:

If within limit…..

Alternative flow of events:

If above limit…..

It is a bases for interaction diagrams


Organizing Use Cases

• Generalization

• Include

• Extend


SE203b, ECE UWO 21


Generalization Relationship

• Child use case inherits behavior and meaning of the parent use case

may add or override the parent’s behavior

may be substituted any place the parent appears

Validate client

Retinal scan

Check password


<<include>> Relationship

• Can be used to avoid describing the same flow of events several times,

o by putting the common behavior in a use case of its own

• Avoids copy & paste of parts of use case descriptions

Validate client

Place order

<<include>>

Track order

<<include>>


SE203b, ECE UWO 22


<<include>> Example

Use Case: Track orderPrecondition:

Financial Officer is logged in

Main flow:1. Obtain and verify order number

2. Include (Validate client)

3. For each part in the order,…Validate

clientPlace order

<<include>>

Track order

<<include>>


<<extend>> Relationship

• Allows to model an optional part of a use case Allows to model conditional subflows

• Allows to insert subflows at a certain point, governed by actor interaction

• Extension points (in textual event flows) <<extend>>(set priority)

Place order

Extension point:Set priority

Place rush order

Trader requests12 hrs deal-settlement


SE203b, ECE UWO 23


<<extend>> Example

Use Case: Place order

Precondition: o Financial Officer is logged in

Main flow:1. …

2. Collect the client’s order items

3. (set priority)

4. Submit order for processing<<extend>>(set priority)

Place order

Extension point:Set priority

Place rush order

Trader requests12 hrs deal-settlement


<<extend>> vs. <<include>> Different intent

<<include>>o to extract common behavior

o often no actor associated with the common use case

o different actors for “caller” use cases possible

<<extend>>o to distinguish variants

o associated actors perform use case and all extensions

o actor is linked to “base” case

Update MedicalPlan

Update DentalPlan

Update Benefits______________Extension pointsbenefit options:

after required enrollments

UpdateInsurance Plan

Employee

<<include>> <<include>> <<include>>

ElectReimbursementfor Healthcare

Elect StockPurchase

<<extend>>employee requestsstock purchase option

<<extend>>employee requestsreimbursement option

extensioncondition

extension pointname andlocation


SE203b, ECE UWO 24


When to Use…

• Model user requirements with use cases

• Model test scenarios with use cases

• If you are using a use-case driven methodstart with use cases

Use-case model to derive

o structural and behavioral models

• If you are not using a use-case driven methodmake sure that structural and behavioral models are

o consistent with use cases


How to Develop …

1. Identify actors that interact with the system

2. Organize actors

3. Consider primary ways of interaction with actors

4. Consider alternative (exceptional) ways

5. Organize behaviors as use casesuse generalize/include/extend relationships


SE203b, ECE UWO 25


Use Case Modeling Tips

• A use case diagram shouldcontain only use cases at the same level of abstraction

include only actors who are required

• each use case should describe a significant part of the system usage should be understandable by both domain experts and software engineers

• in use case description use nouns and verbs accurately and consistently

o Will be used to derive objects and messages for interaction diagrams

• Factor out common usages that are required by multiple use casesIf the usage is required use <<include>>

If the base use case is complete and the usage may be optional, consider use <<extend>>

• Large numbers of use cases should be organized into packages


How to Develop …

1. Identify actors that interact with the system

2. Organize actors

3. Consider primary ways of interaction with actors

4. Consider alternative (exceptional) ways

5. Organize behaviors as use casesuse generalize/include/extend relationships


SE203b, ECE UWO 26


Use Case Modeling Tips

• A use case diagram shouldcontain only use cases at the same level of abstraction

include only actors who are required

• each use case should describe a significant part of the system usage should be understandable by both domain experts and software engineers

• in use case description use nouns and verbs accurately and consistently

o Will be used to derive objects and messages for interaction diagrams

• Factor out common usages that are required by multiple use casesIf the usage is required use <<include>>

If the base use case is complete and the usage may be optional, consider use <<extend>>

• Large numbers of use cases should be organized into packages


Use Case Diagram

Regi ster

Add

Update Student Record Registration DBStudent Drop


SE203b, ECE UWO 27


Static and Dynamic Example

requestToRegister(aStudent)

addToSchedule

GUI

requestToRegister

aStudent:Student

:Registration

:CourseSection :Course

[hasPrerequisite]<<create>>

getPrerequisitehasPassedCourse(prereq)

addToRegistrationList

GUIDynamicBehaviorAdd a Course

StaticStructure

***** ****** *CourseSection+ requestToRegister

RegistrationCourse+getPrerequisite

Student+addToSchedule+hasPassedCourse+addToRegistrationList

+removeFromRegistrationList +removeFromSchedule

oo design for software engineers - western...

Documents