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