SWE 621:
Software Modeling and Architectural
Design
Lecture 3
Static Modeling
Hassan Gomaa
Dept of Computer Science
George Mason University
Fairfax, VA
Copyright © 2011 Hassan Gomaa
All rights reserved. No part of this document may be reproduced in any form or by any means,
without the prior written permission of the author.
This electronic course material may not be distributed by e-mail or posted on any other World
Wide Web site without the prior written permission of the author.
Copyright 2011 H. Gomaa
Steps in Using COMET/UML
1 Develop Software Requirements Model
– Develop Use Case Model (Chapter 6)
2 Develop Software Analysis Model
– Develop static model of problem domain (Chapter 7)
– Structure system into objects (Chapter 8)
– Develop statecharts for state dependent objects (Chapter 10)
– Develop object interaction diagrams for each use case (Chapter 9, 11)
3 Develop Software Design Model
User
1
Requirements 2
Modeling
Analysis
Modeling
4 3 5
Design
Modeling 6
Throwaway Incremental
Prototyping Software
Construction 7
Incremental
Software
Integration 8
Customer
10
11 System
12 Incremental 9 Testing
13 Prototyping
15
14 2
Copyright 2011 H. Gomaa
A-1
Static Modeling
Section 4
Hassan Gomaa
References: H. Gomaa,, Chapter
p 7 - Software
f Modelingg and Design,
g ,
Cambridge University Press, February 2011
H. Gomaa, “Chapter 8 - Designing Concurrent, Distributed, and
Real-Time Applications with UML”, Addison Wesley Object
Technology Series, July, 2000
Copyright © 2011 Hassan Gomaa
All rights reserved. No part of this document may be reproduced in any form or by any means,
without the prior written permission of the author.
3
Copyright 2011 H. Gomaa
Static Modeling
• Originated with Rumbaugh Object Modeling Technique
(OMT)
• Represents static structure of system
• Based on information (Entity-Relationship) modeling
• Static Modeling
– In OO Analysis Modeling
• Define classes in system
• Defines attributes of classes
• Defines
D fi relationships
l ti hi between
b t classes
l
– In OO Design Modeling
• Defines operations of each class
4
Copyright 2011 H. Gomaa
A-2
Design Concepts
Objects and Classes
• Objects represent “things” in real world
– Provide understandingg of real world
– Form basis for a computer solution
• An Object (object instance) is a single “thing”
– E.g., an account, an employee
• A Class (object class) is a collection of objects with the
same characteristics
– E.g., account, employee
• Attribute
– Data value held by object in class
– E.g., account number, balance
5
Copyright 2011 H. Gomaa
Figure 2.2 UML notation for objects & classes
Class Class
Class
attributes attributes
operations
Class Class with attributes Class with attributes and operations
anotherObject
anObject :Class
:Class
Objects
6
Copyright 2011 H. Gomaa
A-3
Figure 4.1 Example of classes and objects
Class
Customer Account
Objects
anotherCustomer
aCustomer:Customer
:Customer
anAccount :Account
7
Copyright 2011 H. Gomaa
Figure 4.2 Example of class with attributes
Class with attributes
Account
accountNumber : Integer
balance : Real
Objects with values
anAccount: anotherAccount:
Account Account
accountNumber = 1234 accountNumber = 5678
balance = 525.36 balance = 1,897.44
8
Copyright 2011 H. Gomaa
A-4
Static Modeling
• Define structural relationships between classes
– Depict classes and their relationships on class diagrams
• Relationships between classes
– Associations
– Composition / Aggregation
– Generalization / Specialization
• Stat
Staticc Modeling
ode g during
du g Analysis
a ys s
• System Context Class Diagram
– Depict external classes and system boundary
• Static Modeling of Entity classes
– Persistent classes that store data
9
Copyright 2011 H. Gomaa
Figure 2.3 UML notation for relationship on class diagram
ClassA 1 Exactly one
Class
1 0..1 Class Optional (zero or one)
Association Association
* Class Many (zero or more)
0..1
*
1..*
ClassB ClassC Class Manyy ((one or more))
Association Association m..n Class Numerically specified
(with direction in which (with direction of
association name is read) navigability)
Superclass
ClassWhole ClassWhole
Subclass1 SubclassA2
ClassPart1 ClassPart2 ClassPart1 ClassPart2
Generalization/specialization Aggregation hierarchy Composition hierarchy
10
Copyright 2011 H. Gomaa
A-5
Associations
• Association is
– static, structural relationshipp between classes
– E.g, Employee works in Department
• Multiplicity of Associations
– Specifies how many instances of one class may relate to
a single instance of another class
11
Copyright 2011 H. Gomaa
Multiplicity of Associations
• 1-to-1 association
– Company has President
• 1-to-many association
– Bank manages Account
• Numerically specified association
– Car has 2,4 Door
• Optional association (0 or 1)
– Customer owns Debit Card
• Optional association (0, 1, or many)
– Customer owns Credit Card
• Many-to-Many association
– Course has Student
– Student attends Course
Copyright 2011 H. Gomaa
A-6
Figure 7.1 Example of one-to-one association
Company
name: String
address: String
businessSector: String
Is led by
CEO
name: String
employeeId: String
address: String
phoneNumber: Integer
Direction of Association
Copyright 2011 H. Gomaa
Figure 7.2 Example of one-to-many association
Bank
bbankName:
kN St
String
i
bankAddress: String
1
Administers
1 *
1..*
Account
accountNumber: Integer
balance: Real
Copyright 2011 H. Gomaa
A-7
Figure 7.3 Numerically specified association
Car
modelName: String
manufacture: String
modelYear:
d lY D
Date
Is entered through
2,4
,
Door
height: Real
width: Real
depth: Real
windowArea: Real
material: String
Copyright 2011 H. Gomaa
Figure 7.4 Optional (zero-or-one) association
Customer
customerName: String
customerId: Stringg
customerAddress: String
1
Owns
0..1
DebitCard
cardId: Integer
PIN: String
startDate: Date
expirationDate: Date
status: Integer
limit: Real
total: Real
Copyright 2011 H. Gomaa
A-8
Figure 7.5 Optional (zero,one, or many) association
Customer
customerName: String
customerId: Stringg
customerAddress: String
1
Owns
0..*
C ditC d
CreditCard
cardType: String
cardId: Integer
startDate: Date
expirationDate: Date
status: Integer
Copyright 2011 H. Gomaa
Figure 7.6 Many-to-many association
Course
courseId: String
courseName: String
section#: Integer
semester:
t String
St i
Enrolls in Is attended by
1..*
Student
studentName: String
studentId: String
studentAddress: String
studentType: String
Copyright 2011 H. Gomaa
A-9
Association Class
• Class to model association between two or more classes
– Usually for many- to- many associations
– Attributes of Association Class
• Attributes of association
• E.g., Many-to-many association between
– Project and Employee classes
• Project has Employee
• Employee
l works
k on project
j
– Association Class - Hours
• Attribute - Hours Worked
Copyright 2011 H. Gomaa
Figure 7.11 Example of association class
Employee Project
* *
projectId: String
employeeName: String projectName: String
employeeId: String startDate:Date
employeeAddress: String endDate:Date
level: String customer: String
Hours
hoursWorked :Real
Copyright 2011 H. Gomaa
A-10
Composition/Aggregation Hierarchy
• Whole/Part Relationships
– Show parts of more complex class
– Co
Composition
pos o iss stronger
s o ge relationship
e o s p than aggregation
gg eg o
• IS PART OF Relationship
– Between part classes and whole (composite or
aggregate) class
• Composition is stronger relationship than aggregation
Copyright 2011 H. Gomaa
Composition Hierarchy
• Composition Hierarchy
– Whole and part objects are created, live, die together
– Often also has a physical association
– Association between instances
• E.g., Composite class
• ATM
– Part classes
Copyright 2011 H. Gomaa
A-11
Figure 7.12 Example of composition hierarchy
Copyright 2011 H. Gomaa
Composition/Aggregation Hierarchy
• Aggregation Hierarchy
– Part objects of aggregate object may be created and
deleted independently of aggregate object
– E.g., Aggregate class
• College
– Part classes
• Admin Office IS PART OF College
• Department
D IS PART OF C College
ll
• Research Center IS PART OF College
Copyright 2011 H. Gomaa
A-12
Figure 7.13 Example of aggregation hierarchy
College
collegeName: String
dean: String
1..*
1 1..*
Admin Office D
Department
t t Research Center
name: String
location: String deptName: String location: String
phone#: String deptLocation: String phone#: String
administrator: String deptPhone#: String head: String
chairPerson: String funding: Real
secretary: String foundingDate: Date
renewalDate: Date
Copyright 2011 H. Gomaa
Generalization / Specialization Hierarchy
• Some classes are similar but not identical
– Have some attributes in common,
common others different
• Common attributes abstracted into generalized class
(superclass)
– E.g., Account (Account number, Balance)
• Different attributes are properties of specialized class
(subclass)
– E.g., Savings Account (Interest)
• IS A relationship between subclass and superclass
– Savings Account IS A Account
Copyright 2011 H. Gomaa
A-13
Figure 7.14 Generalization / specialization hierarchy
Account
accountNumber: Integer
balance: Real
CheckingAccount SavingsAccount
lastDepositAmount: Real interest: Real
Copyright 2011 H. Gomaa
Static Modeling of Problem Domain
• During Analysis Modeling
– Conceptual static model
– Emphasizes real-world classes in the problem domain
– Does not initially address software classes
– Emphasis on
y
• Physical classes
– Have physical characteristics (can see, touch)
• Entity classes
– Data intensive classes
28
Copyright 2011 H. Gomaa
A-14
Figure 7.18 Conceptual static model for Banking System
Bank
1
Provides service for
1..*
Maintains
ATM
1 1
Operator
1 1 1
1
ATMCustomer
CardReader CashDispenser ReceiptPrinter
KeypadDisplay
1 1 1 1
Inserts card into Dispenses
p cash to
Prints receipt for
Interacts through
1 1
1
1
ATM Customer
29
Copyright 2011 H. Gomaa
Software System Context Class Diagram
• Defines boundary between system and external environment
– Mayy be depicted
p on Software System
y Context Class
Diagram
• System
– Depicted as one aggregate «software system» class
• External environment
– External classes that software system interfaces to
• Categories of external classes
– «external I/O device»
– «external user»
– «external system»
– «external timer» 30
Copyright 2011 H. Gomaa
A-15
Associations on
Software System Context Class Diagram
• Software System Context Class Diagram shows
– Association between software system and external class
– Multiplicity of association (1 to 1, 1..* to 1, etc.)
• Associations have standard names
– «external input device» Inputs to «software system»
y
– «software system» Outputs
p to «external output p device»
– «external user» Interacts with «software system»
– «external system» Communicates with «software system»
– «external timer» Signals «software system»
31
Copyright 2011 H. Gomaa
Figure 7.23 Banking System software context class diagram
32
Copyright 2011 H. Gomaa
A-16
Figure 7.24 Factory Automation System software context class diagram
Copyright 2011 H. Gomaa
Static Modeling of Entity Classes
• Entity classes
– Data intensive classes
– Store long-living (persistent) data
– Especially important for Information Systems
• Many are database intensive
– Also important for many real-time and distributed
applications
• During analysis modeling
– Model entity classes in the problem domain
– Attributes
– Relationships
34
Copyright 2011 H. Gomaa
A-17
Figure 21.4 Conceptual static model
for Banking System - entity classes
1 Provides service for 1..*
«entity» «entity»
Bank ATMInfo
1 1 1
Provides service for
Administers
Identifies
1..*
«entity»
Owns Customer
Provides 1..* Owns
1..* 0..1 Access to *
1..*
«entity» * 1 *
1..* *
«entity» «entity»
DebitCard
Account 0,2 Modifies ATMTransaction
«entity»
CardAccount
«entity» «entity»
Checking Savings «entity» «entity» «entity» «entity»
Account Account Withdrawal Query Transfer PINValidation
Transaction Transaction Transaction Transaction
35
Copyright 2011 H. Gomaa
Figure 21.5 Conceptual static model for Banking System
«entity» «entity» «entity»
Bank Customer DebitCard
cardId: String
bankName: String customerName: String PIN: String
bankAddress: String customerId: String startDate: Date
customerAddress: String expirationDate: Date
status:Integer
limit: Real
total: Real
«entity» «entity» «entity»
Account CheckingAccount SavingsAccount
accountNumber: String
accountType: String lastDepositAmount: Real interest: Real
balance: Real
36
Copyright 2011 H. Gomaa
A-18
Figure 21.6 Conceptual static model for Banking System
«entity»
«entity»
ATMTransaction
PINValidationTransaction
bankId: String
ATMId: String
date: Date
time: Time startDate: Date
transactionType: String
cardId: String
expirationDate: Date
PIN: String
status: Integer
«entity» «entity» «entity»
WithdrawalTransaction QueryTransaction TransferTransaction
accountNumber: String accountNumber: String fromAccountNumber: String
amount: Real balance: Real toAccountNumber: String
balance: Real lastDepositAmount: Real amount: Real
37
Copyright 2011 H. Gomaa
Figure 21.7 Conceptual static model for Banking System
«entity» «entity»
CardAccount ATMInfo
cardId: String bankId: String
accountNumber: String ATMId: String
accountType: String ATMLocation: String
ATMAddress: String
«entity» «entity»
ATMCash ATMCard
cashAvailable: Integer
cardId: String
fives: Integer
startDate: Date
tens: Integer
expirationDate: Date
twenties: Integer
38
Copyright 2011 H. Gomaa
A-19
Steps in Using COMET/UML
1 Develop Software Requirements Model
– Develop Use Case Model (Chapter 6)
2 Develop Software Analysis Model
– Develop static model of problem domain (Chapter 7)
– Structure system into objects (Chapter 8)
– Develop statecharts for state dependent objects (Chapter 10)
– Develop object interaction diagrams for each use case (Chapter 9, 11)
3 Develop Software Design Model
User
1
Requirements 2
Modeling
Analysis
Modeling
4 3 5
Design
Modeling 6
Throwaway Incremental
Prototyping Software
Construction 7
Incremental
Software
Integration 8
Customer
10
11 System
12 Incremental 9 Testing
13 Prototyping
15
14 39
Copyright 2011 H. Gomaa
A-20
