1.17 Software Engineering Case Study: Introduction to Object Technology and the UML (Required)

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

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 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. 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. 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 Deposit transaction.

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.

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.

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.