The Object-Oriented Approach to Design: Use Case Realization

1. The Object-Oriented Approach to Design: Use Case Realization

2. Overview • Primary focus of this chapter and the next is how to develop detailed object-oriented design models • Programmers use models to code the system • Two most important models are design class diagrams and interaction diagrams (sequence diagrams and collaboration diagrams) • Class diagrams are developed for domain, view, and data access layers • Interaction diagrams extend system sequence diagrams

3. Object-Oriented Design – The Bridge Between Analysis and Programming • Bridge between user’s requirements and new system’s programming • Object-oriented design is process by which detailed object-oriented models are built • Programmers use design to write code and test new system • User-interface, network, controls, security, and database requires design tasks and models

4. Overview of Object-Oriented Programs • Set of objects that cooperate to accomplish result • Object contains program logic and necessary attributes in a single unit • Objects send each other messages and collaborate to support functions of main program • OO system designer provides detail for programmers • Design class diagrams, interaction diagrams, (some) statechart diagrams

5. Object-Oriented Event-Driven Program Flow

6. Simplified Design Class for Student Class

7. Object-Oriented Design Processes and Models • Diagrams developed during analysis • Use case diagrams, use case descriptions and activity diagrams, domain model class diagrams, and system sequence diagrams • Diagrams developed during design • Design class diagrams – set of object-oriented classes needed for programming, navigation between classes, attribute names and properties and method names and properties • Interaction diagrams, package diagrams

8. Design Models with Their Respective Input Models

9. Iterative Process of OO Design • Create preliminary design class diagrams model • Develop interaction diagrams for each use case or scenario (realization of use cases) • Return to design class diagram • Develop method names based design of interaction diagrams • Update navigation visibility and attributes • Partition design class diagram into related functions using package diagrams (subsystems or layers)

10. Design Classes and Design Class Diagrams • Design class diagrams and detailed interaction diagrams • Use each other as inputs and developed in parallel • Design class diagram first-cut is from domain model and engineering design principles • Preliminary design class diagram used to develop interaction diagrams • Design decisions are made during development of interaction diagrams • Design class diagram is refined

11. Design Classes and Design Class Diagrams (continued) • Design class diagram extends domain model class diagram developed during OO analysis • Shows set of problem domain classes and their association relationships • Describes design components within the classes • When developers build design class diagrams, more classes are added

12. Design Class Symbols • UML does not distinguish between design class notation and domain model notation • Domain modeling shows users’ work environment • Design class design specifically defines software classes • UML uses stereotype notation to categorize a model element by its characteristics

13. Standard Stereotypes Found in Design Models

14. Standard Design Classes • Entity – design identifier for problem domain class • Persistent class – exists after system is shut down • Boundary – designed to live on system’s automation boundary • User interface and windows classes • Control – mediates between boundary and entity classes, between the view layer and domain layer • Data access – retrieve from and send data to database

15. Design Class Notation • Name – class name and stereotype information • Attributes – visibility (private or public), attribute name, type-expression, initial-value, property • Method signature – information needed to invoke (or call) the method • Method visibility, method name, type-expression (return parameter), method parameter list (incoming arguments) • Overloaded method – method with same name but two or more different parameter lists

16. Internal Symbols Used to Define a Design Class

17. Student Class Examples for the Domain Diagram and the Design Class Diagram

18. Some Fundamental Design Principles • Encapsulation – each object is self-contained unit that includes data and methods that access data • Object reuse – designers often reuse same classes for windows components • Information hiding – data associated with object is not visible to outside world • Navigation visibility – object is able to view and interact with another object

19. Navigation Visibility Between Customer and Order

20. Coupling and Cohesion • Coupling – qualitative measure of how closely classes in a design class diagram are linked • Number of navigation arrows on design class diagram • Low: system is easier to understand and maintain • Cohesion – qualitative measure of consistency of functions within a single class • Separation of responsibility – divide low cohesive class into several highly cohesive classes

21. Developing the First-Cut Design Class Diagram • Extend domain model class diagram: • Elaborate attributes with type and initial value information • Add navigation visibility arrows • Detailed design proceeds, use case by use case: • Interaction diagrams implement navigation • Navigation arrows are updated to be consistent • Method signatures are added to each class

22. RMO Domain Model Class Diagram

23. First-cut RMO Design Class Diagram

24. Interaction Diagrams – Realizing Use Case and Defining Methods • Realization of use case done through interaction diagram development • Determine what objects collaborate by sending messages to each other to carry out use case • Sequence diagrams and collaboration diagrams represent results of design decision • Use well-established design principles such as coupling, cohesion, separation of responsibilities

25. Partial Design Class Diagram for the Look Up Item Availability Use Case

26. Object Responsibility • Objects responsible for system processing • Knowing about object’s own data and other classes with which it collaborates to carry out use cases • Doing activities to assist in execution of use case • Receive and process messages • Instantiate, or create, new objects required to complete use case • CRC cards – class-responsibility-collaboration

27. A CRC Card

28. Back of CRC Card

29. Use Case Controller • System sequence diagram (SSD) shows input messages from external actors within use case • Only indicates that messages go to system • Use case controller classes are designed as collection point for incoming messages • Artifact – class invented to handle needed system function • Use case controller acts as intermediary between outside world and internal system

30. Designing with Sequence Diagrams • Sequence diagrams used to explain object interactions and document design decisions • Documents inputs to and outputs from system for single use case or scenario • Captures interactions between system and external world as represented by actors • Inputs are messages from actor to system • Outputs are return messages showing data

31. SSD for the Look Up Item AvailabilityUse Case

32. First-Cut Sequence Diagram • Start with elements from SSD • Replace :System object with use case controller • Add other objects to be included in use case • Select input message from the use case • Add all objects that must collaborate • Determine other messages to be sent • Which object is source and destination of each message?

33. Objects included in Look Up Item Availability

34. First-Cut Sequence Diagram for the Look Up Item Availability Use Case

35. Guidelines for Preliminary Sequence Diagram Development • Take each input message and determine internal messages that result from that input • For that message, determine its objective • Needed information, class destination, class source, and objects created as a result • Identify complete set of classes affected by each input message • Select objects from domain class diagram • Flesh out components for each message

36. Developing a Multilayer Design for Look up item availability • First-cut sequence diagram – classes in domain layer • Add design for user-interface classes – view layer • Forms added as windows classes to sequence diagram • Add design for data access classes – data access layer with separate classes for database • Tools build GUI and problem domain classes • Java and Visual Studio.NET

37. Look Up Item Availability Use Case with View Layer and User-Interface Object Class for input message

38. Partial Three-Layer Design forLook Up Item Availability Class for data access

39. Developing a First-Cut Sequence Diagram for RMO Telephone Order • Design for each input message in the SSD • Design components for all messages are combined to provide comprehensive sequence diagram for entire use case • Information from SSD and first-cut design class diagram used to develop sequence diagram • Which object is source and which object is destination? • Navigation visibility – destination object must be visible to source object

40. Completed Three-Layer Design forLook Up Item Availability

41. SSD for the Telephone Order Scenario of the Create New Order Use Case

42. Partial Sequence Diagram for the Telephone Order Scenario

43. Another Partial Sequence Diagram for the Telephone Order Scenario

44. Sequence Diagram for Telephone Order Scenario of Create New Order Use Case

45. Developing a Multilayer Design for the Telephone Order Scenario • To reduce complexity of diagrams, extend use case scenario one message at a time • Add user interface view layer to scenario • Add single data access class • Add each message to extend design • Sequence diagrams can become complicated • Completed design provides foundation for programming the use case

46. Telephone Order Sequence Diagram for the startOrder Message

47. Telephone Order Sequence Diagram for the addItem Message

48. Telephone Order Sequence Diagram for the final messages

49. Designing with Collaboration Diagrams • Collaboration diagrams and sequence diagrams • Both are interaction diagrams • Both capture same information • Process of designing is same for both • Model used is designer’s personal preference • Sequence diagram – because use case descriptions and dialog follow sequence of steps • Collaboration diagram – emphasizes coupling

50. The Symbols of a Collaboration Diagram