W5 OO Design Approach - Instructinstruct.uwo.ca/engin-sc/se203b/notes/HG-SE203b... · W5: OO Design...

Hamada Ghenniwa 3/2/2006

SE203b, ECE UWO 1

Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa

SE203b: OO Design for Software EngineersSE203b: OO Design for Software Engineers

W5W5 : OO Design ApproachOO Design Approach

Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 2

NotesNotes

• Assignment 2Due Date March 8th


SE203b, ECE UWO 2


Project Plan DocumentProject Plan Document

• 1 OverviewProvide a brief introduction about the project and its nature.

• 2 Life Cycle Model Present a prescriptive, temporal model of the intended development life cycle.

• 3 Work Breakdown Structure (WBS)Develop a deliverable-oriented grouping of the project components (products, documentsand services), which organizes and defines the total project scope.

• 4 Team Organization Name the team members and their roles and responsibilities. Describe the team organization and decision-making method.

• 5 Size and Cost Estimates

Based on your WBS estimate the size and cost of the project.


Project Plan DocumentProject Plan Document

• 6 Project Schedule Present the project schedule, which must at least include the target dates for completion of the deliverables, major supporting documents, and project milestones. Gantt charts are highly recommended.

• 7 Resource Assignments Show resource assignments for the project, particularly the staff work assignments, usually illustrated with Gantt charts.

• 8 Engineering Environment and Methodology Describe the software engineering environment chosen for the project, including the hardware, operating system, compilation systems, and CASE tool support. State the software development methods chosen.

• 9 Risk Analysis List known risks, their probability and cost, and discuss ways to reduce the worst risks.

• 10 Appendix 1: Gantt Charts


SE203b, ECE UWO 3


Software WBS: Example

ATM

EntryTransaction

DepositWithdraw


Relationship of WBS toSoftware Lifecycle

ATM

Transaction

Withdraw

Requirementsof Withdraw

Design of Withdraw

Code of Withdraw

Def

ined

Sof

twa r

e Li

fecy

cle

Co d

eR

e qm

t sA

n aly

sis

De s

ign


SE203b, ECE UWO 4


Allocating ResourcesAllocating Resources……

Activities

Skills

NeedsInventory

Staff

Skills

SkillsInventory

+ Staff

Activities

StaffAssignments

=


Gantt ChartsGantt Charts

WeeksTask 1 2 3 4 5 6 7 8

Specify Withdraw

Specify Deposit

Design Withdraw


SE203b, ECE UWO 5


The Road MapThe 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


Workflows and ModelsWorkflows and Models

DesignModel

ImplementationModel

TestModel

Use CaseModel

DeploymentModel

AnalysisDesign

AnalysisDesign

ImplementationImplementation

TestTest

RequirementsRequirements


SE203b, ECE UWO 6


Analysis ModelAnalysis Model Use CaseDiagram

CollaborationDiagrams

CollaborationDiagrams

ComponentDiagrams

ComponentDiagrams

DeploymentDiagrams

DeploymentDiagrams

ObjectDiagramsObject

Diagrams

StatechartDiagrams

StatechartDiagrams

SequenceDiagrams

SequenceDiagrams

ClassDiagramsClass

Diagrams

ActivityDiagramsActivity

Diagrams

Use CaseModel

Depl.Model

Impl.Model

Analysis& DesignModel

TestModel


Analysis ModelAnalysis Model

• Class Model: The concepts

• Class Model: The Process

NoNameBalance

BalanceDebitCredit CalculateInterest ChangeName

BankAccountidentity

state

behaviors


SE203b, ECE UWO 7


Class Model: Class Model: The ProcessThe Process

Identify Potential ClassesClasses

Identify AssociationsAssociations

Identify AttributesAttributesOrganize Classes

Group Classes Into Packages


ATM:SRSATM:SRS

ATM: OverviewATM: Overview

The objective of the project is to design a software to support a computerized banking network including both human Tellers and automatic teller machines (ATM) to be shared by a consortium of banks. The banks will provide their own software for their own computers; this phase of the project focuses on designing the software for ATMs and the network.

The EnvironmentThe Environment

Each bank provides its own computer to maintain its own accounts and process transactions against them. Teller stations are owned by individual banks and communicate directly with their own bank’s computers.

Functional RequirementsFunctional Requirements• Human Tellers enter account and transaction data• ATMs communicate with central computer which clears transactions with the appropriate banks• An ATM accepts a debit card, interacts with the user, communicates with the central system to carry out the transaction,

dispenses cash, and prints receipts

NonNon--functional Requirementsfunctional Requirements• The system requires appropriate recordkeeping and security provisions• The system must handle concurrent accesses to the same account correctly• The cost of the shared system will be apportioned to the banks according to the number of customers with debit cards


SE203b, ECE UWO 8


ATM ClassesATM Classes

Bank Computer

CentralComputer

DebitCard

Account Transaction TellerStation

Teller ATM Consortium

Customer

Bank


Entry SystemEntry System TransactionsTransactions

ATM(from Logical View)

Entry Stat ion

ID(from Logical View)

Te llerSt at io n(from L ogical V iew) TellerTransac t ion

(from L og ical Vi ew)

C entral C om puter(f rom Logical View)

1..n1..n

<< c om m un ic at e>>

T ran sa ct io n

D ateTim eStam pTrans ac t ionTy peAm m ount

(from Logical View)

1. .n1. .n

EnteredOn

C us tom er

N a m eAddres s

(from Logical Vi. . .

R em ote Trans ac t ion(from Logical View)

Bank C om puter(f rom L ogical V iew)

1. .n1. .n

<<c om m unic ate>>

1. .n1. .n

<< com m un ic at e>>

Ac c ount

Ac countN oTy peBalanc eATMC reditLim it

(f rom Logical View)

1. .n1. .n

Own s

1. .n1. .n

Part ic ipate

Teller

IDN am e


1. .n1. .n

Pe rf orme d

C ons ort ium(from Logical View)

1..n1..n

Ow ns

C as h C ard

N oPas sword

(from Logical Vi. . .Ow ns

1. .n1. .n

Au thorizedB y

1. .n1. .nAc c es s

B an k

Co de : St rin gBan k Na m e

(from L ogical V iew)

1. .n

1

1. .n

1Ow ns

0. .n1 0. .n1Holds

1..n

1

1..n

1

Employ ees

Bank C ode

+C ons is ts Of

Bank C ode

1 . .n1 . .n

Is s ue

Class ModelClass ModelATM System V3.0ATM System V3.0


SE203b, ECE UWO 9


Class ModelClass ModelATM SystemATM System

TransactionEntrySystem

Access Dependency


TransactionTransaction

TellerTransaction

DateTimeStampTransactionTypeAmmount

(from Logical View)

Customer

NameAddress

(from Logical View)

Remote Transaction


(from Logical View)

Teller

IDName

(from Logical View)

1..n1..n

Performed

Cash Card

NoPassword

(from Logical View) Owns

1..n1..n

AuthorizedBy

Bank

Code : StringBankName

(from Logical View)

1..n

1

1..n

1

Employees

1..n1..n

Issue

Account

AccountNoTypeBalanceATMCreditLimit

(from Logical View)

1..n1..n

Owns

1..n1..n

Access

0..n1

0..n1

Holds

EntryStation


Transaction


(from Logical View)

1..n1..n

Participate

1..n1..n

EnteredOn


SE203b, ECE UWO 10


Entry SystemEntry System

E n t r y S t a t i o n

ID(f r o m Lo gi ca l V ie w )

A T M

I DC a sh O n H a n dD isp e n se d

(f r o m Lo gi c a l V i e w )T e l l e rS t a t i o n

ID( f r o m L o g i c a l V i e w )

C e n t r a l C o m p u t e r(f r o m Lo gi c a l V i e w )

1 . . n1 . . n

< < c o m m u n i c a t e > >

B a n k C o m p u t e r( f r o m L o g i c a l V i e w )

1 . .n1 . .n

< < c o m m u n i ca t e > >

1 . . n1 . . n

< < c o m m u n i c a t e > >

B a n k

C o d e : S t r in gB a n kN a m e

( f r o m L o g i c a l V i e w )

1 . . n

1

1 . . n

1O w n s

C o n s o r t i u m(f r o m Lo gi c a l V i e w )

1 . . n1 . . n

O w n s

B a n k C o d e+ C o n s i s t sO f

B a n k C o d e



Identify Potential ClassesClasses

Identify Associations

Identify AttributesOrganize Classes



SE203b, ECE UWO 11


Identify Potential Classes Identify Potential Classes

• Extract nouns from the requirements statement/Use case

• Keep the right classes


Identify Potential Classes:Identify Potential Classes:ATM ExampleATM Example

Extract potential classes classes (nounsnouns) from the SRS/Use Cases

OverviewOverview

The objective of the project is to design a softwaresoftware to support a computerized banking networkbanking network including both human TellerTellerss and automatic teller machines ((ATMATM)) to be shared by a consortiumconsortium of bankbanks. The banks will provide their own software for their own computerown computerss; this phase of the project focuses on designing the software for ATMs and the network.


Each bank provides its own computer to maintain its own accountaccountss and process transactiontransactionss against them. Teller stationTeller stationss are owned by individual banks and communicate directly with their own bank’s computers.


SE203b, ECE UWO 12


ATM ExampleATM Example(Cont.)(Cont.)

Functional RequirementsFunctional Requirements• Human Tellers enter account and transaction datatransaction data

• ATMs communicate with central computercentral computer which clears transactions with the appropriate banks

• An ATM accepts a debit carddebit card, interacts with the useruser, communicates with the central system to carry out the transaction, dispenses cashcash, and prints receiptreceiptss

NonNon--functional Requirementsfunctional Requirements• The systemsystem requires appropriate recordkeepingrecordkeeping and security provisions

• The system must handle concurrent accesses to the same account correctly

• The costcost of the shared system will be apportioned to the banks according to the number of customercustomers with debit cards


ATM: ATM: Potential ClassesPotential Classes

Software

Bank Computer

RecordkeepingProvision

CentralComputer

DebitCard

Account

CashUser

Transaction TellerStation

BankingNetwork


AccountData

System

Customer

Receipt

CostAccessSecurityProvision

Bank

TransactionData


SE203b, ECE UWO 13


Revisit the SRSRevisit the SRS

• Possibly expand the problem statementclient

users

domain knowledge, etc.

• Identify additional classeso e.g. Transaction Log, Communication Line


ATM: ATM: Expanded ClassesExpanded Classes

Software

Bank Computer


CentralComputer

DebitCard

Account

CashUser

Transaction Teller Station

BankingNetwork


AccountData

System

Customer

Receipt


Bank

TransactionData

CommunicationLines

TransactionLog


SE203b, ECE UWO 14


Identify Potential Classes Identify Potential Classes

Extract nouns from the requirements statement

• Keep the right classes


Eliminate redundant, irrelevant, or vague classesEliminate redundant, irrelevant, or vague classes

• Eliminate Redundant ClassesTwo classes that show the same information are redundant

o Keep the most descriptive name

e.g., Customer vs. User

• Eliminate a class with little or nothing to do with the problem Judgment will be involved

o e.g., Cost

• Clarify vague classes Rename classes that are not specific, eliminate them if not possible

o Look for classes with very broad scope

o Look for classes with poorly defined boundaries

e.g., Recordkeeping Provision,

– rather it is part of TransactionTransaction


SE203b, ECE UWO 15


ATM:ATM:Expanded ClassesExpanded Classes

Software

Bank Computer


CentralComputer

DebitCard

Account

CashUser

Transaction Teller Station

BankingNetwork


AccountData

System

Customer

Receipt


Bank

TransactionData

CommunicationLines

TransactionLog


ATM Classes:ATM Classes:RevisionRevision--II

Software

Bank Computer


CentralComputer

DebitCard

Account

CashUser


BankingNetwork


AccountData

System

Customer

Receipt


Bank

TransactionData

CommunicationLines

TransactionLog


SE203b, ECE UWO 16


Set asideSet aside……

• AttributesNames that describe individual objects should be treated as attributes rather than classes

Account Data, Cash, Transaction Data, Receipt

• OperationsA name describing an operation that is applied to a class should not be modeled as a class

e.g., telephone call

• RoleA name should show the nature of the object and not the role it plays in an association

e.g., Owner, Employee


ATM Classes:ATM Classes:RevisionRevision--IIII

Software

Bank Computer

CentralComputer

DebitCard

Account

Cash



AccountData

Customer

Receipt

Access

Bank

TransactionData

CommunicationLines

TransactionLog


SE203b, ECE UWO 17


Eliminate Implementation ConstructsEliminate Implementation Constructs

• Eliminate nouns represent things outside the context of the application domain

Items that are part of the implementationo should not be part of the class modelclass model

e.g., Transaction Log, Access , Communication Line, Software

Items related to data structurese.g., tables and trees are implementation


ATM Classes:ATM Classes:RevisionRevision--IIIIII

Software

Bank Computer

CentralComputer

DebitCard



CustomerAccess

Bank

CommunicationLines

TransactionLog


SE203b, ECE UWO 18


ATM Classes:ATM Classes:V1.0V1.0

Bank Computer

CentralComputer

DebitCard



Customer

Bank


Keeping the right ClassesKeeping the right Classes(Recap)(Recap)

• Eliminate redundant, irrelevant, or vague classes

• Set aside nouns that should be modeled asAttributes

Operations

Roles

• Remove implementation constructs


SE203b, ECE UWO 19



Identify Potential Classes

Identify AssociationsAssociations

Identify AttributesOrganize Classes



ATM ClassesATM ClassesV1.0V1.0

Bank Computer

CentralComputer

DebitCard



Customer

Bank


SE203b, ECE UWO 20


Class ModelATM System V1.0

TellerTransaction

(from Logical View)

TellerStation

(from Logical View) 1..n

ATM

(from Logical View)

Central Computer

(from Logical View)

1..n1..n

<<communicate>>

Bank Computer

(from Logical View)

1..n1..n

<<communicate>>

1..n1..n

<<communicate>>Teller

(from Logical View)

1..n1..n

Performed

Consortium

(from Logical View)

1..n

Account

(from Logical View)

nn

Participate

Customer

(from Logical View)

1..n1..n

Owns

Remote Transaction

(from Logical View)

nn

Participate

1..n1..n

EnteredOn Cash Card

(from Logical View)

1..n1..n

Access

Owns

1..n1..n

AuthorizedBy

Bank

(from Logical View)

1..n

1

1..n

1Owns

0..n1 0..n1

Holds

1..n

1

1..n

1

Employees

BankCode+ConsistsOf

BankCode

1..n1..n

Issues

EnteredOn

1..n

Owns1..n


Identifying AssociationsIdentifying Associations

• Identify potential associations among classes

• Keeping the right association

• Fill in details, such as multiplicity

• Refine associations


SE203b, ECE UWO 21


Identifying Potential AssociationsIdentifying Potential Associations

• Association represents a relationships between two or more classes

• Associations are stated as verbsverbs or verb phrasesverb phrases in SRS/Use Cases

Physical location o e.g., next to, contained in

Directed actions o e.g., drives

Communication o e.g., talks to

Ownership o e.g., has, part of

Satisfaction of some condition o e.g., works for, manages


ATM: ATM: Potential AssociationPotential Association

Extract Potential associationsassociations (verbsverbs or verb phrasesverb phrases) from SRS/Use Cases

Overview

The objective of the project is to design a software to support a computerized banking network including both human Tellers and automatic teller machines (ATM) to be shared by a consortium of banks. The banks will provide their own software for their own computers; this phase of the project focuses on designing the software for ATMs and the network

The Environment

Each bank provides its own computer to maintain its own accounts and processtransactions against them. Teller stations are owned by individual banks and communicatedirectly with their own bank’s computers

OverviewOverview

The objective of the project is to design a software to support a computerized banking network includingincluding both human Tellers and automatic teller machines (ATM) to be shared by a consortium of banks. The banks will provideprovide their own software for their own computers; this phase of the project focuses on designing the software for ATMs and the network


Each bank provides its own computer to maintainmaintain its own accounts and processprocesstransactions against them. Teller stations are owned owned by individual banks and communicatecommunicatedirectly with their own bank’s computers


SE203b, ECE UWO 22


ATM: ATM: Potential AssociationPotential Association

Functional Requirements• Human Tellers enter account and transaction data.

• ATMs communicate with central computer which clears transactions with the appropriate banks.

• An ATM accepts a debit card, interacts with the user, communicates with the central system to carry out the transaction, dispenses cash, and prints receipts.

Non-functional Requirements• The system requires appropriate recordkeeping and security provisions.

• The system must handle concurrent accesses to the same account correctly.

• The cost of the shared system will be apportioned to the banks according to the number of customers with debit cards.

Functional RequirementsFunctional Requirements• Human Tellers enter enter account and transaction data.

• ATMs communicatecommunicate with central computer which clearsclears transactions withwith the appropriate banks.

• An ATM acceptsaccepts a debit card, interactsinteracts with the user, communicates with the central system to carry out the transaction, dispensesdispenses cash, and printsprints receipts.

NonNon--functional Requirementsfunctional Requirements• The system requires appropriate recordkeeping and security provisions.

• The system must handle handle concurrent accesses to the same account correctly.

• The cost of the shared system will be apportioned toapportioned to the banks according to the number of customers with debit cards.


Identify Missing and Implicit AssociationsIdentify Missing and Implicit Associations

• In addition to SRSDomain knowledge and domain experts of the application

should be included in the process loop

• Additional associations may be discovered during analysis

Implicitlyo Customer owns debit card

o Bank holds account

o Consortium owns central Computer

o System Provides record Keeping

o System Provides security

o Consortium consists of banks

From domain knowledgeo Debit card accesses account

o Bank employs Teller


SE203b, ECE UWO 23


Update the list of AssociationsUpdate the list of Associations

• Add any missing associations

.… Make sure to verify them with the customer & userscustomer & users, .

as they are not in the SRS


Association:Association:ExampleExample

Central Computer(from Logical View)


Customer(from Logical View)

Remote Transaction(from Logical View)

Account(from Logical View)

Teller(from Logical View)

Consortium(from Logical View)

Cash Card(from Logical View)

Bank(from Logical View)

<<communicate>>

EnteredOn

Owns

Owns

Access

Owns

AuthorizedBy

Holds

Employees

+ConsistsOf

Issues


SE203b, ECE UWO 24


Identifying AssociationsIdentifying Associations

Identify potential associations and aggregations among classes

• Keeping the right association

• Fill in details such as multiplicity



Deal with Action PhrasesDeal with Action Phrases

• Association should not model an action that is a transient evento e.g., ATM accepts Debit card

ATM interacts with user

However, be carefulo with action verb phrases that implies a structural relationship

e.g., Central Computer Clears Transactions of Bank

Redefine it as

Central Computer Connected with Bank


SE203b, ECE UWO 25


Eliminate Irrelevant Associations Eliminate Irrelevant Associations

• Associations between eliminated classes

can’t relate things that don’t exist!o e.g., ATM dispenses cash; cost apportioned to banks

• Association that are not important to the application domain o e.g., Systems handles concurrent access

• Implementation Associations


Redundant Associations Redundant Associations

• Eliminate associations that can be defined by other associations

Keep the more general association

o e.g., ATM shared by a consortium; Consortium owns central Computer;

ATM connected with central computer

• Multiple paths usually indicate derived associationsBe careful that

o information is not lost while discarding unneeded associations

e.g., multiplicity, constraints


SE203b, ECE UWO 26


Derived AssociationDerived Association

Company

Person

Department

WorksForDepartment

/WorksForCompany

∗

∗∗

1

1

1employer

employerdepartment

Company

Person

Department

WorksForDepartment

/WorksForCompany

∗

1..10∗

1

1

1employer

employerdepartment

1..500


Identifying AssociationsIdentifying Associations(Roadmap)(Roadmap)

Identify potential associations and aggregations among classes Associations are stated as verbsverbs or verb phrasesverb phrases in SRS/Use Cases

Keeping the right association Eliminate Irrelevant Associations

Deal with Action Phrases

Eliminate Redundant associations

• Fill in detailsmultiplicity

Roles



SE203b, ECE UWO 27


Determining MultiplicityDetermining Multiplicity

• Multiplicity must be determined for each end (role) of an association

• Optional

should zero be included in the range?o An association is optional unless the link exists

for every instance in the class

• -toone

should the range be one?o Very few association are truly onetoone

• -tomany

should the range allow more than one?o If more than one instance can be linked,

then the association is a tomany association Class

m..nNumericallySpecified

Class ManyZero or More*

Class OptionalZero or One

0..1

Class Exactly one1


Example…Example…

Central Computer

ATM

Customer

Remote Transaction

Account

Teller

Consortium

Debit Card

Bank

Central Computer

ATM

Customer

Remote Transaction

Account

Teller

Consortium

Debit Card

Bank

1..n

1..n1..n

1..n1..n1..n1..n 1..n1..n

1..n1..n

1 *1

1..n

11

1..n

1

1

1

1

11

1

1

*

1


SE203b, ECE UWO 28


RolesRoles

• Clarify ambiguous associations

Add relation (or role) names to identify the context of an association

especially for reflexive associations

• An association name should say

what the association is

not how it came abouto e.g., Bank computer maintains accounts

should beshould be

Bank holds account


Without…Without…

Central Computer

ATM

Customer

Remote Transaction

Account

Teller

Consortium

Debit Card

Bank

1..n

1..n1..n

1..n1..n1..n1..n 1..n1..n

1..n1..n

1 *1

1..n

11

1..n

1

1

1

1

11

1

1

*

1


SE203b, ECE UWO 29


With…With…

Central Computer

ATM

Customer

Remote Transaction

Account

Teller

Consortium

Cash Card

Bank

1..n

<<communicate>>

1..n1..nEnteredOn

1..n1..n

Owns

1..n1..nOwns

1..n1..n

Access

Owns

1..n1..n

AuthorizedBy

1 *1Holds

1..n

11

Employees

+ConsistsOf

1..n

Issues

1

1

1

1

11

1

1

*

1


Refine AssociationsRefine Associations

• Decompose highorder associationsMost 3-ary and higher associations can be decomposed into binary associations

o e.g., ATM connected with central system about transactionequivalent toequivalent to

Transaction entered on ATM;ATM connected with central system

• Reduce multiplicity A qualifier can be used to distinguish objects on the many side of an association

o e.g., bank code as qualifier for Bank objects in a Consortium


SE203b, ECE UWO 30


ATM Classes: ATM Classes: V1.0V1.0

Bank Computer

CentralComputer

DebitCard



Customer

Bank



TellerTransaction(from Logical View)

TellerStation(from Logical View)

1..n



1..n1..n

<<communicate>>

Bank Computer(from Logical View)

1..n1..n

<<communicate>>

1..n1..n


(from Logical View)

1..n1..nPerformed


1..n


nn

Participate


1..n1..n

Owns


nn

Participate

1..n1..nEnteredOn Cash Card

(from Logical View)

1..n1..n

Access

Owns

1..n1..n

AuthorizedBy


1..n

1

1..n

1Owns

0..n1 0..n1Holds

1..n

1

1..n

1

Employees

BankCode+ConsistsOf

BankCode

1..n1..n

Issues

EnteredOn

1..n

Owns1..n


SE203b, ECE UWO 31


Class Model: The ProcessClass Model: The Process



Identify AttributesOrganize Objects



Identify attributesIdentify attributes

• Identify potential attributes • Keeping the right attributes• Refine attributes


SE203b, ECE UWO 32


Identify AttributesIdentify Attributes

• Attributes are properties of individual objects

Usually correspond to nouns followed by possessive phrasese.g., Name of a Customer;

o Also identifiable by specific enumerated values

• Look back at what has been set aside when deciding on classes and associations

• Only add those attributes that directly related to the application

Customer

NumberName

Attribute


Keeping the right AttributesKeeping the right Attributes

Throw away things that might be

objectso e.g., Address

varies from application another

internal identifierso if the attribute will never be used by the end-user in their business function,

then remove it

qualifierso If the value of the attribute depends on a particular context, then it’s a qualifier,

e.g., Bank code for a Bank listed in the Consortium


SE203b, ECE UWO 33


ConstrainsConstrains

• Constraintsformal or informal expressions

must not contradict inherited base semantics

ATM_WithdrawalATM_Withdrawal

customer : idamount : Money{amount is multiple of $20}

customer : idamount : Money{amount is multiple of $20}

AccountAccount

customer : idbalance : Moneycustomer : idbalance : Money

«constraint»{ATM_Withdrawal.customer = Account.customer}«constraint»{ATM_Withdrawal.customer = Account.customer}








SE203b, ECE UWO 34


ATM:ATM:SRSSRS

ATM: OverviewATM: Overview

The objective of the project is to design a software to support a computerized banking network including both human Tellers and automatic teller machines (ATM) to be shared by a consortium of banks. The banks will provide their own software for their own computers; this phase of the project focuses on designing the software for ATMs and the network.


Each bank provides its own computer to maintain its own accounts and process transactions against them. Teller stations are owned by individual banks and communicate directly with their own bank’s computers.

Functional RequirementsFunctional Requirements• Human Tellers enter account and transaction data• ATMs communicate with central computer which clears transactions with the appropriate banks• An ATM accepts a debit card, interacts with the user, communicates with the central system to carry out the transaction,

dispenses cash, and prints receipts

NonNon--functional Requirementsfunctional Requirements• The system requires appropriate recordkeeping and security provisions• The system must handle concurrent accesses to the same account correctly• The cost of the shared system will be apportioned to the banks according to the number of customers with debit cards


ATM Classes: ATM Classes: V1.0V1.0

Bank Computer

CentralComputer

DebitCard



Customer

Bank


SE203b, ECE UWO 35



TellerTransaction(from Logical View)

TellerStation(from Logical View)

1..n



1..n1..n

<<communicate>>


1..n1..n

<<communicate>>

1..n1..n


(from Logical View)

1..n1..nPerformed


1..n


nn

Participate


1..n1..n

Owns


nn

Participate

1..n1..nEnteredOn Cash Card

(from Logical View)

1..n1..n

Access

Owns

1..n1..n

AuthorizedBy


1..n

1

1..n

1Owns

0..n1 0..n1Holds

1..n

1

1..n

1

Employees

BankCode+ConsistsOf

BankCode

1..n1..n

Issues

EnteredOn

1..n

Owns1..n



TellerStation



TellerTransaction


(from Logical View)

1..n1..n

EnteredOn

ATM

IDCashOnHandDispensed

(from Logical View)

1..n1..n

<<communicate>>

Customer

NameAddress

(from Logical View)

Remote Transaction


(from Logical View)

1..n1..n

EnteredOn


1..n1..n

<<communicate>>

1..n1..n

<<communicate>>

Account


(from Logical View)

nn

Participate

1..n1..n

Owns

nn

Participate


1..n1..nPerformed


1..n1..nOwns


1..n1..n

Access

Owns

1..n1..n

AuthorizedBy

Bank


(from Logical View)

1..n

1

1..n

1Owns

0..n1 0..n1Holds

1..n

1

1..n

1

Employees

BankCode+ConsistsOf

BankCode

1..n1..n

Issues


SE203b, ECE UWO 36








Organize ObjectsOrganize Objects

• Organize the classes using inheritance mechanism, and

generalization/specialization notation

• Objectiveo achieve a common structure

o improve understandability

o simplify associations


SE203b, ECE UWO 37


Inheritance: Inheritance: BottomBottom--up (up (GeneralizationGeneralization))

• Identify classes with similar featureso attributes, associations, or operations

Look for associations with similar meanings

o but maybe different names

• Define a superclass assign the common attributes, associations, or operations to it

o e.g., Remote Transaction and Teller Transaction

generalized by Transaction



TellerStation



TellerTransaction


(from Logical View)

1..n1..n

EnteredOn

ATM

IDCashOnHandDispensed

(from Logical View)

1..n1..n

<<communicate>>

Customer

NameAddress

(from Logical View)

Remote Transaction


(from Logical View)

1..n1..n

EnteredOn


1..n1..n

<<communicate>>

1..n1..n

<<communicate>>

Account


(from Logical View)

nn

Participate

1..n1..n

Owns

nn

Participate


1..n1..nPerformed


1..n1..nOwns


1..n1..n

Access

Owns

1..n1..n

AuthorizedBy

Bank


(from Logical View)

1..n

1

1..n

1Owns

0..n1 0..n1Holds

1..n

1

1..n

1

Employees

BankCode+ConsistsOf

BankCode

1..n1..n

Issues


SE203b, ECE UWO 38



T el lerStation

ID(fr om Log ica l Vie w)

Central Com p ute r(from Logical View)

T e l lerT ransaction

DateT ime Sta m pT ra nsa ction T ypeAm mo unt

(from Logical View)

1 ..n1..n

EnteredOn

AT M

IDCashOnHan dDispen sed

(fr om Log ica l Vie w)

1..n1..n

<<com m unicate>>

Custom er

Nam eAddress

(from Logical View)

Rem ote T ransaction

D ate T im e Sta mpT ran sac tion T ypeA mm o unt

(from Logical View)

1 ..n1..n

EnteredOn

Bank Com puter(fr om Log ica l Vie w)

1 ..n1..n

<<com m unicate>>

1. .n1. .n

<<com m unicate>>

Account

AccountNoT ypeBa lan ceAT M Credi tL im i t

(from Logical View)

nn

Par tic ipa te

1..n1..n

Ow ns

nn

Participate

T e ll er(from Logical View)

1 ..n1..nPerformed


1 ..n1..n

Ow ns


1 ..n1..n

Access

Ow ns

1..n1..n

AuthorizedBy

Ba nk

Code : S trin gBankNam e

(fr om Log ica l Vie w)

1. .n

1

1. .n

1Ow ns

0..n1 0..n1

Holds

1..n

1

1..n

1

Employees

BankCode+ConsistsOf

BankCode

1..n1..n

Issues




Entry Stat ion





1..n1..n


T ran sa ct io n


(from Logical View)

1. .n1. .n

EnteredOn

C us tom er

N a m eAddres s




1. .n1. .n

<<c om m unic ate>>

1. .n1. .n


Ac c ount



1. .n1. .n

Own s

1. .n1. .n

Part ic ipate

Teller

IDN am e


1. .n1. .n

Pe rf orme d


1..n1..n

Ow ns

C as h C ard

N oPas sword


1. .n1. .n

Au thorizedB y

1. .n1. .nAc c es s

B an k



1. .n

1

1. .n

1Ow ns

0. .n1 0. .n1Holds

1..n

1

1..n

1

Employ ees

Bank C ode

+C ons is ts Of

Bank C ode

1 . .n1 . .n

Is s ue


SE203b, ECE UWO 39


Determine Inheritance: Determine Inheritance: TopTop--down (down (SpecializationSpecialization))

• Subclasses should be definedif they will be treated differently in the application

• Refine classes with complex attributes or operations into specialized subclasses








SE203b, ECE UWO 40


Grouping Classes Into PackagesGrouping Classes Into Packages

• A Package, fundamentally, isa set of closely related modeling elements (classes, use-cases, packages)

that are related to a common sub-domain

• Packages are intended to support o large scale development

o provide a framework


Core ConceptsCore Concepts

Construct Description Syntax

Access

Import A dependency indicating that the public contents of the target package are added to theare added to thenamespace of the source package.

«import»

A dependency indicating that the public contents of the target package are available in theavailable in thenamespace of the source package.

«access»

Package A grouping of model elements


SE203b, ECE UWO 41


PackagePackage

• A package can contain model elements of different kindsIncluding other packages to create hierarchies

• A package defines a namespace for its contents

• Packages can be used for various purposes


PackagePackage

A package is a grouping of model elements


SE203b, ECE UWO 42


WarehouseWarehouse

Package Package –– ExampleExample

SalesSales

OrderCustomer

Location Item

Stock Item Order Item


VisibilityVisibility

• Each contained element has a visibility relative to the containing package

o A public ‘+’ element is visible to elements outside the packageo A protected ‘#’ element is visible only to elements within inheriting packageso A private ‘-’ element is not visible at all to elements outside the package

Same syntax for visibility of attributes and operations in classes


SE203b, ECE UWO 43


X Y

ImportImport

«import»A

B +C-D

+E

A

B +C-D

+E

X Y

Y::C

Y::E

«import»

The associations are owned by package XThe associations are owned by package X


Import Import –– AliasAlias

«import»A

B +B-D

+E

X Y

A

B +B-D

X Y

+E«import»

+Y::E

+Y::B--C

same class

An imported element can be given a local alias and a local visibilityAn imported element can be given a local alias and a local visibilitylocal visibility


SE203b, ECE UWO 44


A

B +C-D

+E

X Y«access»

AccessAccess

The associations are owned by package XThe associations are owned by package X


X Y Z

Import vs. AccessImport vs. Access

«import»

A

B +C-D

+E

«import»

+G

+F

-H

-Z::G

+Z::F

«access» «access»

X Y Z

A

B +C-D

+E +G

+F

-H

Y::C

Y::E

Y::F

Need to qualify the names of the accessed elements


SE203b, ECE UWO 45


Package InheritancePackage Inheritance

• A package with a generalization to another package inherits public and protected elements that the parent’s

owned

imported

DatabaseInterfaceDatabaseInterface

SybaseInterfaceSybase

Interface

OracleInterfaceOracle

InterfaceATM

SystemATM

System«import»


Grouping Classes Into PackagesGrouping Classes Into Packages

• Gather model elements with strong cohesion in one package

• Keep model elements with low coupling in different packages

• Minimize relationshipsespecially associations, between model elements in different packages

•• Namespace implicationNamespace implication: an element imported into a package does not “know” how it is used in the imported package


SE203b, ECE UWO 46


Entry SystemEntry System TransactionsTransactions


Entry Stat ion





1..n1..n


T ran sa ct io n


(from Logical View)

1. .n1. .n

EnteredOn

C us tom er

N a m eAddres s




1. .n1. .n

<<c om m unic ate>>

1. .n1. .n


Ac c ount



1. .n1. .n

Own s

1. .n1. .n

Part ic ipate

Teller

IDN am e


1. .n1. .n

Pe rf orme d


1..n1..n

Ow ns

C as h C ard

N oPas sword


1. .n1. .n

Au thorizedB y

1. .n1. .nAc c es s

B an k



1. .n

1

1. .n

1Ow ns

0. .n1 0. .n1Holds

1..n

1

1..n

1

Employ ees

Bank C ode

+C ons is ts Of

Bank C ode

1 . .n1 . .n

Is s ue



Class ModelClass ModelATM SystemATM System

TransactionEntrySystem

Access Dependency


SE203b, ECE UWO 47








Quiz…Quiz…

• The class model Design-1 captures the following:A Boundary is the smallest region that will contain the associated Ellipse or Rectangle

• Modify Design-1by generalizing the classes Ellipse and Rectangle to class GraphicsPrimitive, call it Design-2

• State any improvements that Design-2 has over Design-1

Ellipse Rectangle

Boundary

0..n 0..n

Design-1

Date post:	02-Sep-2018
Category:	Documents
Upload:	hathien
View:	216 times
Download:	0 times

W5 OO Design Approach - Instructinstruct.uwo.ca/engin-sc/se203b/notes/HG-SE203b... · W5: OO Design...

Documents