Unified Modeling Language (UML)

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 1

1.17 Software Engineering Case Study (Cont.) Objects 2 Reusable software components that model realworld 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,

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) 3

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 4

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 5

Fig. 2.15 Automated teller machine user 6 interface.

8 Fig. 2.16 ATM main menu.

9 Fig. 2.17 ATM withdrawal menu.

2.8 (Optional) Software Engineering Case Study (Cont.) Analyzing the ATM system 11 Requirements gathering Software life cycle Waterfall model Iteractive model Use case modeling Use case diagram Model the interactions between clients and its use cases

Fig. 2.18 Use case diagram for the ATM system from the user s perspective. 12

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. 13

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 14

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 15

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 Fig.3.18 Nouns and noun phrases in the 16 requirements document.

3.11 (Optional) Software Engineering Case Study: Identifying the Classes in the ATM Requirements Document (Cont.) Modeling classes with UML class diagrams 17 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

Fig.3.19 Representing a class in the UML 18 using a class diagram.

Fig.3.20 Class diagram showing an 19 association among classes.

Fig.3.22 Class diagram showing 20 composition relationships.

Fig.3.23 Class diagram for the ATM 21 system model

Fig.3.25 Class diagram for the ATM system model including class 22 Deposit.

4.13 (Optional) Software Engineering Case Study: Identifying Class Attributes in the ATM System Identifying and modeling attributes 23 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 Boolean value and is initially false

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] Fig. 4.23 Descriptive words and phrases from the 24 ATM requirements.

25 Fig. 4.24 Classes with attributes.

5.11 (Optional) Software Engineering Case Study: Identifying Object s State and Activities in the ATM System State Machine Diagrams 26 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

Fig. 5.26 State diagram for the ATM 27 object.

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 28 Final state

Fig. 5.27 Activity diagram for a BalanceInquiry transaction. 29

Fig. 5.28 Activity diagram for a 30 Withdrawal transaction.

Fig. 5.29 Activity diagram for a Deposit 31 transaction.

6.22 (Optional) Software Engineering Case Study: Identifying Class Operations in the ATM System Operation 32 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

Class ATM BalanceInquiry Withdrawal Deposit BankDatabase Account Screen Keypad CashDispenser DepositSlot Verbs and verb phrases executes financial transactions [none in the requirements document] [none in the requirements document] [none in the requirements document] authenticates a user, retrieves an account balance, credits a deposit amount to an account, debits a withdrawal amount from an account retrieves an account balance, credits a deposit amount to an account, debits a withdrawal amount from an account displays a message to the user receives numeric input from the user dispenses cash, indicates whether it contains enough cash to satisfy a withdrawal request receives a deposit envelope Fig. 6.34 Verbs and verb phrases for each 33 class in the ATM system.

Fig. 6.35 Classes in the ATM system with 34 attributes and operations.

Fig. 6.36 Class BankDatabase with 35 operation parameters.

Fig. 6.37 Class Account with operation 36 parameters.

Fig. 6.38 Class Screen with operation 37 parameters.

Fig. 6.39 Class CashDispenser with 38 operation parameters.

7.12 (Optional) Software Engineering Case Study: Collaboration Among Objects in the ATM System Collaborations 39 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

An object of class ATM BalanceInquiry Withdrawal Deposit BankDatabase sends the message displaymessage getinput authenticateuser execute execute execute getavailablebalance gettotalbalance displaymessage displaymessage getinput getavailablebalance issufficientcashavailable debit dispensecash displaymessage getinput isenvelopereceived credit validatepin getavailablebalance gettotalbalance debit credit to an object of class Screen Keypad BankDatabase BalanceInquiry Withdrawal Deposit BankDatabase BankDatabase Screen Screen Keypad BankDatabase CashDispenser BankDatabase CashDispenser Screen Keypad DepositSlot BankDatabase Account Account Account Account Account Fig.7.27 Collaborations in the ATM 40 system.

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 41

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 42

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

Fig.7.28 Communication diagram of the ATM executing a balance inquiry. 44

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

Fig.7.29 Communication diagram of the ATM executing a balance inquiry. 46

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 Activation Represents the progression of time (top to bottom) Thin vertical rectangle on an object s lifeline Indicates that the object is executing 47

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 48

Fig.7.30 Sequence diagram that models a 49 Withdrawal executing.

Fig.7.31 Sequence diagram that models a 50 Deposit executing.

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 51

Fig. 9.20 Class diagram with visibility 52 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

Fig. 9.21 Class diagram with navigability 54 arrows.

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 55

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 Class prevent name multiple-definition is based on the errors top compartment of the class diagram Outline fig09_22.cpp (1 of 1) 56

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 Outline Withdrawal.h (1 of 1) 57

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 Outline #include preprocessor directives for classes of associated objects References are based on the associations in the class diagram Withdrawal.h (1 of 1) 58

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 Outline Withdrawal.h (1 of 1) 59

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 Outline Withdrawal.h (1 of 1) 60

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 Outline Account.h (1 of 1) 61

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 62

Fig.13.26 Attributes and operations of classes BalanceInquiry, 63 Withdrawal and Deposit.

Fig.13.27 Class diagram modeling generalization relationship between base class Transaction and derived classes BalanceInquiry, 64 Withdrawal and Deposit.

Fig.13.28 Class diagram of the ATM system (incorporating inheritance). Note that 65 abstract class name Transaction appears in italics.

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 66

67 Fig.13.29 Class diagram after incorporating inheritance into the system.

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 68

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 69

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 Transaction is an abstract class, contains a pure virtual function Outline Transaction.h (1 of 1) Declare pure virtual function execute 70

ATM Requirements Document-1

ATM Requirements Document-2

ATM Requirements Document-3