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


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


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


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


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


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


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


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


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



(Cont.)

• Communication diagrams

– Objects

• Modeled as rectangles

• Contain names in the form objectName : className

– Objects are connected with solid lines

43



(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



(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



(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



(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


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


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


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)





5

6 class Withdrawal

7 {

8 private:

9 // attributes

10 int accountNumber; // account to withdraw funds from

11 double amount; // amount to withdraw


13


Data members are based on

the attributes in the middle

compartment of the class

diagram

58

Outline

Withdrawal.h

(1 of 1)





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



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


24


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)





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



17







24


Forward declarations of

classes for which this

class has references

60

Outline

Withdrawal.h

(1 of 1)





5





10

11 class Withdrawal

12 {

13 public:

14 // operations

15 void execute(); // perform the transaction

16 private:

17 // attributes



20







27


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


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


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





5

6 #include "Transaction.h" // Transaction class definition

7

8 // class Withdrawal derives from base class Transaction

9 class Withdrawal : public Transaction

10 {


12


Outline

Withdrawal.h

(1 of 1)

Class

Withdrawal

inherits from Transaction

69





5

6 #include "Transaction.h" // Transaction class definition

7



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





23


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



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


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

unified modeling language (uml) · pdf file · 2017-12-27(ooad) –analyze...

Documents