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

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 | 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
External entity

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
Emphasize when interactions occur

15. Identifying the classes in a system
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.

17. Modeling classes with UML class diagrams
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 association

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. Identifying and modeling attributes
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 Boolean value and is initially false

24. Fig. 4.23 | Descriptive words and phrases from the ATM requirements.

25. Fig. 4.24 | Classes with attributes.

26. State Machine Diagrams
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. Activity Diagrams Focus on system behavior
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 Deposit transaction.

32. Operation A service that objects of a class provide to their clients
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.

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. Collaborations When objects communicate to accomplish task
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.

41. Interaction Diagrams Model interactions using UML
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. Communication diagrams
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. Communication diagrams (Cont.)
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. Communication diagrams (Cont.)
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. Sequence diagrams Help model the timing of collaborations Lifeline
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. Sequence diagrams (Cont.)
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. Bidirectional navigability
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. Implementing a class from its UML design
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. Class name is based on the top compartment of the class diagram
Outline
#ifndef, #define and #endif preprocessor directives help prevent multiple-definition errors
fig09_22.cpp
(1 of 1)
Class name is based on the top compartment of the class diagram

57. Outline
Withdrawal.h
(1 of 1)
Data members are based on the attributes in the middle compartment of the class diagram

58. #include preprocessor directives for classes of associated objects
Outline
#include preprocessor directives for classes of associated objects
Withdrawal.h
(1 of 1)
References are based on the associations in the class diagram

59. Forward declarations of classes for which this class has references
Outline
Forward declarations of classes for which this class has references
Withdrawal.h
(1 of 1)

60. Outline
Withdrawal.h
(1 of 1)
Member functions are based on operations in the bottom compartment of the class diagram

61. Outline
Account.h
(1 of 1)

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 | Class diagram modeling generalization relationship between base class Transaction and derived classes BalanceInquiry, Withdrawal and Deposit.

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

66. Incorporating inheritance into the ATM system design
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. Class Withdrawal inherits from Transaction
Outline
Withdrawal.h
(1 of 1)
Class Withdrawal inherits from Transaction

69. Class Withdrawal inherits from Transaction
Outline
Withdrawal.h
(1 of 1)
Class Withdrawal inherits from Transaction

70. Transaction is an abstract class, contains a pure virtual function
Outline
Transaction.h
(1 of 1)
Transaction is an abstract class, contains a pure virtual function
Declare pure virtual function execute

71. ATM Requirements Document-1

72. ATM Requirements Document-2

73. ATM Requirements Document-3