Upload
hathien
View
216
Download
0
Embed Size (px)
Citation preview
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
Hamada Ghenniwa 3/2/2006
SE203b, ECE UWO 2
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 3
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.
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 4
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
Hamada Ghenniwa 3/2/2006
SE203b, ECE UWO 3
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 5
Software WBS: Example
ATM
EntryTransaction
DepositWithdraw
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 6
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
Hamada Ghenniwa 3/2/2006
SE203b, ECE UWO 4
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 7
Allocating ResourcesAllocating Resources……
Activities
Skills
NeedsInventory
Staff
Skills
SkillsInventory
+ Staff
Activities
StaffAssignments
=
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 8
Gantt ChartsGantt Charts
WeeksTask 1 2 3 4 5 6 7 8
Specify Withdraw
Specify Deposit
Design Withdraw
Hamada Ghenniwa 3/2/2006
SE203b, ECE UWO 5
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 9
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
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 10
Workflows and ModelsWorkflows and Models
DesignModel
ImplementationModel
TestModel
Use CaseModel
DeploymentModel
AnalysisDesign
AnalysisDesign
ImplementationImplementation
TestTest
RequirementsRequirements
Hamada Ghenniwa 3/2/2006
SE203b, ECE UWO 6
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 11
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
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 12
Analysis ModelAnalysis Model
• Class Model: The concepts
• Class Model: The Process
NoNameBalance
BalanceDebitCredit CalculateInterest ChangeName
BankAccountidentity
state
behaviors
Hamada Ghenniwa 3/2/2006
SE203b, ECE UWO 7
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 13
Class Model: Class Model: The ProcessThe Process
Identify Potential ClassesClasses
Identify AssociationsAssociations
Identify AttributesAttributesOrganize Classes
Group Classes Into Packages
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 14
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
Hamada Ghenniwa 3/2/2006
SE203b, ECE UWO 8
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 15
ATM ClassesATM Classes
Bank Computer
CentralComputer
DebitCard
Account Transaction TellerStation
Teller ATM Consortium
Customer
Bank
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 16
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
(from L og ical Vi ew)
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
Hamada Ghenniwa 3/2/2006
SE203b, ECE UWO 9
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 17
Class ModelClass ModelATM SystemATM System
TransactionEntrySystem
Access Dependency
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 18
TransactionTransaction
TellerTransaction
DateTimeStampTransactionTypeAmmount
(from Logical View)
Customer
NameAddress
(from Logical View)
Remote Transaction
DateTimeStampTransactionTypeAmmount
(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
ID(from Logical View)
Transaction
DateTimeStampTransactionTypeAmmount
(from Logical View)
1..n1..n
Participate
1..n1..n
EnteredOn
Hamada Ghenniwa 3/2/2006
SE203b, ECE UWO 10
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 19
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
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 20
Class Model: Class Model: The ProcessThe Process
Identify Potential ClassesClasses
Identify Associations
Identify AttributesOrganize Classes
Group Classes Into Packages
Hamada Ghenniwa 3/2/2006
SE203b, ECE UWO 11
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 21
Identify Potential Classes Identify Potential Classes
• Extract nouns from the requirements statement/Use case
• Keep the right classes
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 22
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.
The EnvironmentThe Environment
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.
Hamada Ghenniwa 3/2/2006
SE203b, ECE UWO 12
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 23
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
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 24
ATM: ATM: Potential ClassesPotential Classes
Software
Bank Computer
RecordkeepingProvision
CentralComputer
DebitCard
Account
CashUser
Transaction TellerStation
BankingNetwork
Teller ATM Consortium
AccountData
System
Customer
Receipt
CostAccessSecurityProvision
Bank
TransactionData
Hamada Ghenniwa 3/2/2006
SE203b, ECE UWO 13
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 25
Revisit the SRSRevisit the SRS
• Possibly expand the problem statementclient
users
domain knowledge, etc.
• Identify additional classeso e.g. Transaction Log, Communication Line
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 26
ATM: ATM: Expanded ClassesExpanded Classes
Software
Bank Computer
RecordkeepingProvision
CentralComputer
DebitCard
Account
CashUser
Transaction Teller Station
BankingNetwork
Teller ATM Consortium
AccountData
System
Customer
Receipt
CostAccessSecurityProvision
Bank
TransactionData
CommunicationLines
TransactionLog
Hamada Ghenniwa 3/2/2006
SE203b, ECE UWO 14
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 27
Identify Potential Classes Identify Potential Classes
Extract nouns from the requirements statement
• Keep the right classes
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 28
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
Hamada Ghenniwa 3/2/2006
SE203b, ECE UWO 15
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 29
ATM:ATM:Expanded ClassesExpanded Classes
Software
Bank Computer
RecordkeepingProvision
CentralComputer
DebitCard
Account
CashUser
Transaction Teller Station
BankingNetwork
Teller ATM Consortium
AccountData
System
Customer
Receipt
CostAccessSecurityProvision
Bank
TransactionData
CommunicationLines
TransactionLog
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 30
ATM Classes:ATM Classes:RevisionRevision--II
Software
Bank Computer
RecordkeepingProvision
CentralComputer
DebitCard
Account
CashUser
Transaction TellerStation
BankingNetwork
Teller ATM Consortium
AccountData
System
Customer
Receipt
CostAccessSecurityProvision
Bank
TransactionData
CommunicationLines
TransactionLog
Hamada Ghenniwa 3/2/2006
SE203b, ECE UWO 16
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 31
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
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 32
ATM Classes:ATM Classes:RevisionRevision--IIII
Software
Bank Computer
CentralComputer
DebitCard
Account
Cash
Transaction TellerStation
Teller ATM Consortium
AccountData
Customer
Receipt
Access
Bank
TransactionData
CommunicationLines
TransactionLog
Hamada Ghenniwa 3/2/2006
SE203b, ECE UWO 17
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 33
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
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 34
ATM Classes:ATM Classes:RevisionRevision--IIIIII
Software
Bank Computer
CentralComputer
DebitCard
Account Transaction TellerStation
Teller ATM Consortium
CustomerAccess
Bank
CommunicationLines
TransactionLog
Hamada Ghenniwa 3/2/2006
SE203b, ECE UWO 18
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 35
ATM Classes:ATM Classes:V1.0V1.0
Bank Computer
CentralComputer
DebitCard
Account Transaction TellerStation
Teller ATM Consortium
Customer
Bank
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 36
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
Hamada Ghenniwa 3/2/2006
SE203b, ECE UWO 19
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 37
Class Model: Class Model: The ProcessThe Process
Identify Potential Classes
Identify AssociationsAssociations
Identify AttributesOrganize Classes
Group Classes Into Packages
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 38
ATM ClassesATM ClassesV1.0V1.0
Bank Computer
CentralComputer
DebitCard
Account Transaction TellerStation
Teller ATM Consortium
Customer
Bank
Hamada Ghenniwa 3/2/2006
SE203b, ECE UWO 20
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 39
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
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 40
Identifying AssociationsIdentifying Associations
• Identify potential associations among classes
• Keeping the right association
• Fill in details, such as multiplicity
• Refine associations
Hamada Ghenniwa 3/2/2006
SE203b, ECE UWO 21
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 41
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
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 42
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
The EnvironmentThe Environment
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
Hamada Ghenniwa 3/2/2006
SE203b, ECE UWO 22
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 43
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.
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 44
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
Hamada Ghenniwa 3/2/2006
SE203b, ECE UWO 23
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 45
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
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 46
Association:Association:ExampleExample
Central Computer(from Logical View)
ATM(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
Hamada Ghenniwa 3/2/2006
SE203b, ECE UWO 24
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 47
Identifying AssociationsIdentifying Associations
Identify potential associations and aggregations among classes
• Keeping the right association
• Fill in details such as multiplicity
• Refine associations
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 48
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
Hamada Ghenniwa 3/2/2006
SE203b, ECE UWO 25
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 49
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
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 50
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
Hamada Ghenniwa 3/2/2006
SE203b, ECE UWO 26
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 51
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
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 52
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
• Refine associations
Hamada Ghenniwa 3/2/2006
SE203b, ECE UWO 27
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 53
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
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 54
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
Hamada Ghenniwa 3/2/2006
SE203b, ECE UWO 28
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 55
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
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 56
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
Hamada Ghenniwa 3/2/2006
SE203b, ECE UWO 29
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 57
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
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 58
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
Hamada Ghenniwa 3/2/2006
SE203b, ECE UWO 30
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 59
ATM Classes: ATM Classes: V1.0V1.0
Bank Computer
CentralComputer
DebitCard
Account Transaction TellerStation
Teller ATM Consortium
Customer
Bank
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 60
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..nPerformed
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..nEnteredOn 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..n1Holds
1..n
1
1..n
1
Employees
BankCode+ConsistsOf
BankCode
1..n1..n
Issues
EnteredOn
1..n
Owns1..n
Hamada Ghenniwa 3/2/2006
SE203b, ECE UWO 31
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 61
Class Model: The ProcessClass Model: The Process
Identify Potential Classes
Identify Associations
Identify AttributesOrganize Objects
Group Classes Into Packages
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 62
Identify attributesIdentify attributes
• Identify potential attributes • Keeping the right attributes• Refine attributes
Hamada Ghenniwa 3/2/2006
SE203b, ECE UWO 32
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 63
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
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 64
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
Hamada Ghenniwa 3/2/2006
SE203b, ECE UWO 33
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 65
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}
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 66
Class Model: The ProcessClass Model: The Process
Identify Potential Classes
Identify Associations
Identify AttributesOrganize Objects
Group Classes Into Packages
Hamada Ghenniwa 3/2/2006
SE203b, ECE UWO 34
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 67
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.
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
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 68
ATM Classes: ATM Classes: V1.0V1.0
Bank Computer
CentralComputer
DebitCard
Account Transaction TellerStation
Teller ATM Consortium
Customer
Bank
Hamada Ghenniwa 3/2/2006
SE203b, ECE UWO 35
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 69
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..nPerformed
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..nEnteredOn 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..n1Holds
1..n
1
1..n
1
Employees
BankCode+ConsistsOf
BankCode
1..n1..n
Issues
EnteredOn
1..n
Owns1..n
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 70
Class ModelClass ModelATM System V2.0ATM System V2.0
TellerStation
ID(from Logical View)
Central Computer(from Logical View)
TellerTransaction
DateTimeStampTransactionTypeAmmount
(from Logical View)
1..n1..n
EnteredOn
ATM
IDCashOnHandDispensed
(from Logical View)
1..n1..n
<<communicate>>
Customer
NameAddress
(from Logical View)
Remote Transaction
DateTimeStampTransactionTypeAmmount
(from Logical View)
1..n1..n
EnteredOn
Bank Computer(from Logical View)
1..n1..n
<<communicate>>
1..n1..n
<<communicate>>
Account
AccountNoTypeBalanceATMCreditLimit
(from Logical View)
nn
Participate
1..n1..n
Owns
nn
Participate
Teller(from Logical View)
1..n1..nPerformed
Consortium(from Logical View)
1..n1..nOwns
Cash Card(from Logical View)
1..n1..n
Access
Owns
1..n1..n
AuthorizedBy
Bank
Code : StringBankName
(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
Hamada Ghenniwa 3/2/2006
SE203b, ECE UWO 36
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 71
Class Model: The ProcessClass Model: The Process
Identify Potential Classes
Identify Associations
Identify AttributesOrganize Objects
Group Classes Into Packages
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 72
Organize ObjectsOrganize Objects
• Organize the classes using inheritance mechanism, and
generalization/specialization notation
• Objectiveo achieve a common structure
o improve understandability
o simplify associations
Hamada Ghenniwa 3/2/2006
SE203b, ECE UWO 37
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 73
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
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 74
Class ModelClass ModelATM System V2.0ATM System V2.0
TellerStation
ID(from Logical View)
Central Computer(from Logical View)
TellerTransaction
DateTimeStampTransactionTypeAmmount
(from Logical View)
1..n1..n
EnteredOn
ATM
IDCashOnHandDispensed
(from Logical View)
1..n1..n
<<communicate>>
Customer
NameAddress
(from Logical View)
Remote Transaction
DateTimeStampTransactionTypeAmmount
(from Logical View)
1..n1..n
EnteredOn
Bank Computer(from Logical View)
1..n1..n
<<communicate>>
1..n1..n
<<communicate>>
Account
AccountNoTypeBalanceATMCreditLimit
(from Logical View)
nn
Participate
1..n1..n
Owns
nn
Participate
Teller(from Logical View)
1..n1..nPerformed
Consortium(from Logical View)
1..n1..nOwns
Cash Card(from Logical View)
1..n1..n
Access
Owns
1..n1..n
AuthorizedBy
Bank
Code : StringBankName
(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
Hamada Ghenniwa 3/2/2006
SE203b, ECE UWO 38
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 75
Class ModelClass ModelATM System V2.0ATM System V2.0
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
Consortium(from Logical View)
1 ..n1..n
Ow ns
Cash Card(from Logical View)
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
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 76
Class ModelClass ModelATM System V3.0ATM System V3.0
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
(from L og ical Vi ew)
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
Hamada Ghenniwa 3/2/2006
SE203b, ECE UWO 39
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 77
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
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 78
Class Model: The ProcessClass Model: The Process
Identify Potential Classes
Identify Associations
Identify AttributesOrganize Objects
Group Classes Into Packages
Hamada Ghenniwa 3/2/2006
SE203b, ECE UWO 40
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 79
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
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 80
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
Hamada Ghenniwa 3/2/2006
SE203b, ECE UWO 41
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 81
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
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 82
PackagePackage
A package is a grouping of model elements
Hamada Ghenniwa 3/2/2006
SE203b, ECE UWO 42
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 83
WarehouseWarehouse
Package Package –– ExampleExample
SalesSales
OrderCustomer
Location Item
Stock Item Order Item
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 84
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
Hamada Ghenniwa 3/2/2006
SE203b, ECE UWO 43
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 85
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
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 86
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
Hamada Ghenniwa 3/2/2006
SE203b, ECE UWO 44
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 87
A
B +C-D
+E
X Y«access»
AccessAccess
The associations are owned by package XThe associations are owned by package X
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 88
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
Hamada Ghenniwa 3/2/2006
SE203b, ECE UWO 45
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 89
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»
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 90
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
Hamada Ghenniwa 3/2/2006
SE203b, ECE UWO 46
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 91
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
(from L og ical Vi ew)
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
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 92
Class ModelClass ModelATM SystemATM System
TransactionEntrySystem
Access Dependency
Hamada Ghenniwa 3/2/2006
SE203b, ECE UWO 47
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 93
Class Model: The ProcessClass Model: The Process
Identify Potential Classes
Identify Associations
Identify AttributesOrganize Objects
Group Classes Into Packages
Feb 22, 2005 SE203b, ECE UWO, Hamada Ghenniwa 94
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