Unified Modeling Language (UML) · PDF file · 2017-12-27(OOAD) –Analyze...
Transcript of Unified Modeling Language (UML) · PDF file · 2017-12-27(OOAD) –Analyze...
1
1.17 Software Engineering Case Study: Introduction to
Object Technology and the UML (Required)
• Object orientation
– A natural way of thinking about the world and
computer programs
• Unified Modeling Language (UML)
– Graphical language that uses common notation
– Allows developers to represent object-oriented
designs
2
1.17 Software Engineering Case Study (Cont.)
• Objects
– Reusable software components that model real-
world items
– Examples are all around you
• People, animals, cars, telephones, microwave ovens,
etc.
– Have attributes
• Size, shape, color, weight, etc.
– Exhibit behaviors
• Babies cry, crawl, sleep, etc.; cars accelerate, brake,
turn, etc.
3
1.17 Software Engineering Case Study (Cont.)• Object-oriented design (OOD)
– Models real-world objects in software
– Models communication among objects
– Encapsulates attributes and operations (behaviors)
• Information hiding
• Communication through well-defined interfaces
• Object-oriented language
– Programming in object oriented languages is called object-oriented
programming (OOP)
– C++ is an object-oriented language
• Programmers can create user-defined types called classes
– Contain data members (attributes) and member functions
(behaviors)
4
1.17 Software Engineering Case Study (Cont.)
• Object-Oriented Analysis and Design
(OOAD)
– Analyze program requirements, then develop
solution
– Essential for large programs
– Plan in pseudocode or UML
5
2.8 (Optional) Software Engineering Case
Study (Cont.)
• Requirements document
– New automated teller machine (ATM)
– Allows basic financial transaction
• View balance, withdraw cash, deposit funds
– User interface
• Display screen, keypad, cash dispenser, deposit slot
– ATM session
• Authenticate user, execute financial transaction
6
Fig. 2.15 | Automated teller machine user
interface.
8
Fig. 2.16 | ATM main menu.
9
Fig. 2.17 | ATM withdrawal menu.
11
2.8 (Optional) Software Engineering Case
Study (Cont.)
• Analyzing the ATM system
– Requirements gathering
– Software life cycle
• Waterfall model
• Iteractive model
– Use case modeling
• Use case diagram
– Model the interactions between clients and its
use cases
– Actor
12
Fig. 2.18 | Use case diagram for the ATM
system from the user’s perspective.
13
2.8 (Optional) Software Engineering Case
Study (Cont.)
• UML diagram types
– Model system structure
• Class diagram
– Models classes, or “building blocks” of a system
– Screen, keypad, cash dispenser, deposit slot.
14
2.8 (Optional) Software Engineering Case
Study (Cont.)
– Model system behavior• Use case diagrams
– Model interactions between user and the system
• State machine diagrams
– Model the ways in which an object changes state
• Activity diagrams
– Model an object’s activity during program execution
• Communication diagrams (collaboration diagrams)
– Model the interactions among objects
– Emphasize what interactions occur
• Sequence diagrams
– Model the interactions among objects
– Emphasize when interactions occur
15
3.11 (Optional) Software Engineering Case Study: Identifying
the Classes in the ATM Requirements Document
• Identifying the classes in a system
– Key nouns and noun phrases in requirements
document
• Some are attributes of other classes
• Some do not correspond to parts of the system
• Some are classes
– To be represented by UML class diagrams
16
Fig.3.18 | Nouns and noun phrases in the
requirements document.
Nouns and noun phrases in the requirements document
bank money / fund account number
ATM screen PIN
user keypad bank database
customer cash dispenser balance inquiry
transaction $20 bill / cash withdrawal
account deposit slot deposit
balance deposit envelope
17
3.11 (Optional) Software Engineering Case Study: Identifying
the Classes in the ATM Requirements Document (Cont.)• Modeling classes with UML class diagrams
– Top compartment contains name of the class
– Middle compartment contains attributes
– Bottom compartment contains operations
– An elided diagram
• Suppress some class attributes and operations for
readability
– An association
• Represented by a solid line that connects two classes
• Association can be named
• Numbers near end of each line are multiplicity values
• Role name identifies the role an object plays in an
18
Fig.3.19 | Representing a class in the UML
using a class diagram.
19
Fig.3.20 | Class diagram showing an
association among classes.
20
Fig.3.22 | Class diagram showing
composition relationships.
21
Fig.3.23 | Class diagram for the ATM
system model
22
Fig.3.25 | Class diagram for the ATM
system model including class
Deposit.
23
4.13 (Optional) Software Engineering Case Study:
Identifying Class Attributes in the ATM System
• Identifying and modeling attributes
– Create attributes and assign them to classes
• Look for descriptive words and phrases in the
requirements document
• Each attribute is given an attribute type
• Some attributes may have an initial value
• Example
– userAuthenticated : Boolean = false
» Attribute userAuthenticated is a Booleanvalue and is initially false
24
Fig. 4.23 | Descriptive words and phrases
from the
ATM requirements.
Class Descriptive words and phrases
ATM user is authenticated
BalanceInquiry account number
Withdrawal account number
amount
Deposit account number
amount
BankDatabase [no descriptive words or phrases]
Account account number
PIN
balance
Screen [no descriptive words or phrases]
Keypad [no descriptive words or phrases]
CashDispenser begins each day loaded with 500 $20 bills
DepositSlot [no descriptive words or phrases]
25
Fig. 4.24 | Classes with attributes.
26
5.11 (Optional) Software Engineering Case Study: Identifying
Object’s State and Activities in the ATM System
• State Machine Diagrams
– Commonly called state diagrams
– Model several states of an object
• Show under what circumstances the object changes state
• Focus on system behavior
– UML representation
• Initial state
– Solid circle
• State
– Rounded rectangle
• Transitions
– Arrows with stick arrowheads
27
Fig. 5.26 | State diagram for the ATM
object.
28
5.11 (Optional) Software Engineering Case Study : Identifying
Object’s State and Activities in the ATM System (Cont.)• Activity Diagrams
– Focus on system behavior
– Model an object’s workflow during program execution
• Actions the object will perform and in what order
– UML representation
• Initial state
– Solid circle
• Action state
– Rectangle with outward-curving sides
• Action order
– Arrow with a stick arrowhead
• Final state
– Solid circle enclosed in an open circle
29
Fig. 5.27 | Activity diagram for a
BalanceInquiry transaction.
30
Fig. 5.28 | Activity diagram for a
Withdrawal transaction.
31
Fig. 5.29 | Activity diagram for a Deposittransaction.
32
6.22 (Optional) Software Engineering Case Study:
Identifying Class Operations in the ATM System
• Operation
– A service that objects of a class provide to their
clients
• For example, a radio’s operations include setting its
station and volume
– Implemented as a member function in C++
– Identifying operations
• Examine key verbs and verb phrases in the
requirements document
33
Fig. 6.34 | Verbs and verb phrases for each
class in the ATM system.
Class Verbs and verb phrases
ATM executes financial transactions
BalanceInquiry [none in the requirements document]
Withdrawal [none in the requirements document]
Deposit [none in the requirements document]
BankDatabase authenticates a user, retrieves an account balance, credits a deposit
amount to an account, debits a withdrawal amount from an account
Account retrieves an account balance, credits a deposit amount to an account,
debits a withdrawal amount from an account
Screen displays a message to the user
Keypad receives numeric input from the user
CashDispenser dispenses cash, indicates whether it contains enough cash to satisfy a
withdrawal request
DepositSlot receives a deposit envelope
34
Fig. 6.35 | Classes in the ATM system with
attributes and operations.
35
Fig. 6.36 | Class BankDatabase with
operation parameters.
36
Fig. 6.37 | Class Account with operation
parameters.
37
Fig. 6.38 | Class Screen with operation
parameters.
38
Fig. 6.39 | Class CashDispenser with
operation parameters.
39
7.12 (Optional) Software Engineering Case Study:
Collaboration Among Objects in the ATM System• Collaborations
– When objects communicate to accomplish task
• One object sends a message to another object
• Accomplished by invoking operations (functions)
– Identifying the collaborations in a system
• Read requirements document to find
– What ATM should do to authenticate a user
– What ATM should do to perform transactions
• For each action, decide
– Which objects must interact
» Sending object
» Receiving object
40
Fig.7.27 | Collaborations in the ATM
system.
An object of class…
sends the message… to an object of class…
ATM displayMessage
getInput
authenticateUser
execute
execute
execute
Screen
Keypad
BankDatabase
BalanceInquiry
Withdrawal
Deposit
BalanceInquiry getAvailableBalance
getTotalBalance
displayMessage
BankDatabase
BankDatabase
Screen
Withdrawal displayMessage
getInput
getAvailableBalance
isSufficientCashAvailable
debit
dispenseCash
Screen
Keypad
BankDatabase
CashDispenser
BankDatabase
CashDispenser
Deposit displayMessage
getInput
isEnvelopeReceived
credit
Screen
Keypad
DepositSlot
BankDatabase
BankDatabase validatePIN
getAvailableBalance
getTotalBalance
debit
credit
Account
Account
Account
Account
Account
41
7.12 (Optional) Software Engineering Case Study:
Collaboration Among Objects in the ATM System
(Cont.)
• Interaction Diagrams
– Model interactions using UML
– Communication diagrams
• Also called collaboration diagrams
• Emphasize which objects participate in
collaborations
– Sequence diagrams
• Emphasize when messages are sent between objects
42
7.12 (Optional) Software Engineering Case Study:
Collaboration Among Objects in the ATM System
(Cont.)
• Communication diagrams
– Objects
• Modeled as rectangles
• Contain names in the form objectName : className
– Objects are connected with solid lines
43
7.12 (Optional) Software Engineering Case Study:
Collaboration Among Objects in the ATM System
(Cont.)
• Communication diagrams (Cont.)
– Messages are passed along these lines in the
direction shown by arrows
• Synchronous calls – solid arrowhead
– Sending object may not proceed until control is returned
from the receiving object
• Asynchronous calls – stick arrowhead
– Sending object does not have to wait for the receiving
object
• Name of message appears next to the arrow
44
Fig.7.28 | Communication diagram of the
ATM executing a balance inquiry.
45
7.12 (Optional) Software Engineering Case Study:
Collaboration Among Objects in the ATM System
(Cont.)
• Communication diagrams (Cont.)
– Sequence of messages in a communication
diagram
• Indicated by the number to the left of a message
name
• Indicate the order in which the messages are passed
• Process in numerical order from least to greatest
• Nested messages are indicated by decimal
numbering
– Example
» First message nested in message 1 is message 1.1
46
Fig.7.29 | Communication diagram of the
ATM executing a balance inquiry.
47
7.12 (Optional) Software Engineering Case Study:
Collaboration Among Objects in the ATM System
(Cont.)
• Sequence diagrams
– Help model the timing of collaborations
– Lifeline
• Dotted line extending down from an object’s
rectangle
– Represents the progression of time (top to bottom)
– Activation
• Thin vertical rectangle on an object’s lifeline
– Indicates that the object is executing
48
7.12 (Optional) Software Engineering Case Study:
Collaboration Among Objects in the ATM System
(Cont.)
• Sequence diagrams (Cont.)
– Sending messages
• Similar to communication diagrams
• Solid arrow with filled arrowhead indicates a
message
– Points to the beginning of an activation
• Dashed line with stick arrowhead indicates return of
control
– Extends from the end of an activation
49
Fig.7.30 | Sequence diagram that models a
Withdrawal executing.
50
Fig.7.31 | Sequence diagram that models a
Deposit executing.
51
9.12 (Optional) Software Engineering Case Study:
Starting to Program the Classes of the ATM System
• Visibility of an object’s attributes and operations
– Determined by access specifiers
– Data members normally have private visibility
– Member functions normally have public visibility
– Utility functions normally have private visibility
• UML Visibility Markers
– Placed before an operation or an attribute
– Plus sign (+) indicates public visibility
– Minus sign (–) indicates private visibility
52
Fig. 9.20 | Class diagram with visibility
markers.
53
9.12 (Optional) Software Engineering Case Study:
Starting to Program the Classes of the ATM System (Cont.)
• UML Navigability Arrows
– Arrows with stick arrowheads in a class diagram
– Indicate in which direction an association can be traversed
– Based on the collaborations modeled in communication and sequence diagrams
– Help determine which objects need references or pointers to other objects
– Bidirectional navigability
• Indicated by arrows at both ends of an association or no arrows at all
• Navigation can proceed in either direction across the association
54
Fig. 9.21 | Class diagram with navigability
arrows.
55
9.12 (Optional) Software Engineering Case Study:
Starting to Program the Classes of the ATM System (Cont.)• Implementing a class from its UML design
– Use the name located in the first compartment of a class diagram to
define the class in a header file
– Use the attributes located in the class’s second compartment to
declare the data members
– Use the associations described in the class diagram to declare
references (or pointers, where appropriate) to other objects
• Use forward declarations for references to classes (where possible)
instead of including full header files
– Helps avoid circular includes
» Preprocessor problem that occurs when header file for class A#includes header file for class B and vice versa
– Use the operations located in the class’s third compartment to write
the function prototypes of the class’s member functions
56
Outline
fig09_22.cpp
(1 of 1)
1 // Fig. 9.22: Withdrawal.h
2 // Definition of class Withdrawal that represents a withdrawal transaction
3 #ifndef WITHDRAWAL_H
4 #define WITHDRAWAL_H
5
6 class Withdrawal
7 {
8 }; // end class Withdrawal
9
10 #endif // WITHDRAWAL_H
#ifndef, #define and
#endif preprocessor directives
help prevent multiple-definition
errorsClass name is based
on the top
compartment of the
class diagram
57
Outline
Withdrawal.h
(1 of 1)
1 // Fig. 9.23: Withdrawal.h
2 // Definition of class Withdrawal that represents a withdrawal transaction
3 #ifndef WITHDRAWAL_H
4 #define WITHDRAWAL_H
5
6 class Withdrawal
7 {
8 private:
9 // attributes
10 int accountNumber; // account to withdraw funds from
11 double amount; // amount to withdraw
12 }; // end class Withdrawal
13
14 #endif // WITHDRAWAL_H
Data members are based on
the attributes in the middle
compartment of the class
diagram
58
Outline
Withdrawal.h
(1 of 1)
1 // Fig. 9.24: Withdrawal.h
2 // Definition of class Withdrawal that represents a withdrawal transaction
3 #ifndef WITHDRAWAL_H
4 #define WITHDRAWAL_H
5
6 #include "Screen.h" // include definition of class Screen
7 #include "Keypad.h" // include definition of class Keypad
8 #include "CashDispenser.h" // include definition of class CashDispenser
9 #include "BankDatabase.h" // include definition of class BankDatabase
10
11 class Withdrawal
12 {
13 private:
14 // attributes
15 int accountNumber; // account to withdraw funds from
16 double amount; // amount to withdraw
17
18 // references to associated objects
19 Screen &screen; // reference to ATM’s screen
20 Keypad &keypad; // reference to ATM's keypad
21 CashDispenser &cashDispenser; // reference to ATM's cash dispenser
22 BankDatabase &bankDatabase; // reference to the account info database
23 }; // end class Withdrawal
24
25 #endif // WITHDRAWAL_H
References are based
on the associations in
the class diagram
#include preprocessor directives for
classes of associated objects
59
Outline
Withdrawal.h
(1 of 1)
1 // Fig. 9.25: Withdrawal.h
2 // Definition of class Withdrawal that represents a withdrawal transaction
3 #ifndef WITHDRAWAL_H
4 #define WITHDRAWAL_H
5
6 class Screen; // forward declaration of class Screen
7 class Keypad; // forward declaration of class Keypad
8 class CashDispenser; // forward declaration of class CashDispenser
9 class BankDatabase; // forward declaration of class BankDatabase
10
11 class Withdrawal
12 {
13 private:
14 // attributes
15 int accountNumber; // account to withdraw funds from
16 double amount; // amount to withdraw
17
18 // references to associated objects
19 Screen &screen; // reference to ATM’s screen
20 Keypad &keypad; // reference to ATM's keypad
21 CashDispenser &cashDispenser; // reference to ATM's cash dispenser
22 BankDatabase &bankDatabase; // reference to the account info database
23 }; // end class Withdrawal
24
25 #endif // WITHDRAWAL_H
Forward declarations of
classes for which this
class has references
60
Outline
Withdrawal.h
(1 of 1)
1 // Fig. 9.26: Withdrawal.h
2 // Definition of class Withdrawal that represents a withdrawal transaction
3 #ifndef WITHDRAWAL_H
4 #define WITHDRAWAL_H
5
6 class Screen; // forward declaration of class Screen
7 class Keypad; // forward declaration of class Keypad
8 class CashDispenser; // forward declaration of class CashDispenser
9 class BankDatabase; // forward declaration of class BankDatabase
10
11 class Withdrawal
12 {
13 public:
14 // operations
15 void execute(); // perform the transaction
16 private:
17 // attributes
18 int accountNumber; // account to withdraw funds from
19 double amount; // amount to withdraw
20
21 // references to associated objects
22 Screen &screen; // reference to ATM’s screen
23 Keypad &keypad; // reference to ATM's keypad
24 CashDispenser &cashDispenser; // reference to ATM's cash dispenser
25 BankDatabase &bankDatabase; // reference to the account info database
26 }; // end class Withdrawal
27
28 #endif // WITHDRAWAL_H
Member functions are based
on operations in the bottom
compartment of the class
diagram
61
Outline
Account.h
(1 of 1)
1 // Fig. 9.27: Account.h
2 // Account class definition. Represents a bank account.
3 #ifndef ACCOUNT_H
4 #define ACCOUNT_H
5
6 class Account
7 {
8 public:
9 bool validatePIN( int ); // is user-specified PIN correct?
10 double getAvailableBalance(); // returns available balance
11 double getTotalBalance(); // returns total balance
12 void credit( double ); // adds an amount to the Account
13 void debit( double ); // subtracts an amount from the Account
14 private:
15 int accountNumber; // account number
16 int pin; // PIN for authentication
17 double availableBalance; // funds available for withdrawal
18 double totalBalance; // funds available + funds waiting to clear
19 }; // end class Account
20
21 #endif // ACCOUNT_H
62
13.10 (Optional) Software Engineering Case Study:
Incorporating Inheritance into the ATM System
• UML model for inheritance
– The generalization relationship
• The base class is a generalization of the derived classes
• The derived classes are specializations of the base class
– Pure virtual functions are abstract operations in the UML
– Generalizations and abstract operations are written in italics
• Transaction base class
– Contains the functions and data members BalanceInquiry,
Withdrawal and Deposit have in common
• execute function
• accountNumber data member
63
Fig.13.26 | Attributes and operations of
classes BalanceInquiry,
Withdrawal and Deposit.
64
Fig.13.27 | Class diagram modeling generalization relationship between
base class Transaction and derived classes BalanceInquiry,
Withdrawal and Deposit.
65
Fig.13.28 | Class diagram of the ATM system (incorporating inheritance). Note that
abstract class name Transaction appears in italics.
66
13.10 (Optional) Software Engineering Case Study:
Incorporating Inheritance into the ATM System
(Cont.)
• Incorporating inheritance into the ATM
system design
– If class A is a generalization of class B, then
class B is derived from class A
– If class A is an abstract class and class B is a
derived class of class A, then class B must
implement the pure virtual functions of
class A if class B is to be a concrete class
67
Fig.13.29 | Class diagram after incorporating inheritance into the system.
68
1 // Fig. 13.30: Withdrawal.h
2 // Definition of class Withdrawal that represents a withdrawal transaction
3 #ifndef WITHDRAWAL_H
4 #define WITHDRAWAL_H
5
6 #include "Transaction.h" // Transaction class definition
7
8 // class Withdrawal derives from base class Transaction
9 class Withdrawal : public Transaction
10 {
11 }; // end class Withdrawal
12
13 #endif // WITHDRAWAL_H
Outline
Withdrawal.h
(1 of 1)
Class
Withdrawal
inherits from Transaction
69
1 // Fig. 13.31: Withdrawal.h
2 // Definition of class Withdrawal that represents a withdrawal transaction
3 #ifndef WITHDRAWAL_H
4 #define WITHDRAWAL_H
5
6 #include "Transaction.h" // Transaction class definition
7
8 class Keypad; // forward declaration of class Keypad
9 class CashDispenser; // forward declaration of class CashDispenser
10
11 // class Withdrawal derives from base class Transaction
12 class Withdrawal : public Transaction
13 {
14 public:
15 // member function overriding execute in base class Transaction
16 virtual void execute(); // perform the transaction
17 private:
18 // attributes
19 double amount; // amount to withdraw
20 Keypad &keypad; // reference to ATM's keypad
21 CashDispenser &cashDispenser; // reference to ATM's cash dispenser
22 }; // end class Withdrawal
23
24 #endif // WITHDRAWAL_H
Outline
Withdrawal.h
(1 of 1)
Class
Withdrawal
inherits from Transaction
70
1 // Fig. 13.32: Transaction.h
2 // Transaction abstract base class definition.
3 #ifndef TRANSACTION_H
4 #define TRANSACTION_H
5
6 class Screen; // forward declaration of class Screen
7 class BankDatabase; // forward declaration of class BankDatabase
8
9 class Transaction
10 {
11 public:
12 int getAccountNumber(); // return account number
13 Screen &getScreen(); // return reference to screen
14 BankDatabase &getBankDatabase(); // return reference to bank database
15
16 // pure virtual function to perform the transaction
17 virtual void execute() = 0; // overridden in derived classes
18 private:
19 int accountNumber; // indicates account involved
20 Screen &screen; // reference to the screen of the ATM
21 BankDatabase &bankDatabase; // reference to the account info database
22 }; // end class Transaction
23
24 #endif // TRANSACTION_H
Outline
Transaction.h
(1 of 1)
Declare pure virtual
function execute
Transaction is an
abstract class, contains
a pure virtual
function
ATM Requirements Document-1
ATM Requirements Document-2
ATM Requirements Document-3