1 / 36

Chapter 4 Dynamic Modeling and Analysis (Part II)

Chapter 4 Dynamic Modeling and Analysis (Part II). Object-Oriented Technology From Diagram to Code with Visual Paradigm for UML Curtis H.K. Tsang, Clarence S.W. Lau and Y.K. Leung McGraw-Hill Education (Asia), 2005. Dynamic Analysis Techniques.

aaronmiller
Download Presentation

Chapter 4 Dynamic Modeling and Analysis (Part II)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Chapter 4Dynamic Modeling and Analysis (Part II) Object-Oriented Technology From Diagram to Code with Visual Paradigm for UML Curtis H.K. Tsang, Clarence S.W. Lau and Y.K. Leung McGraw-Hill Education (Asia), 2005

  2. Dynamic Analysis Techniques • How can we transform from “what the system does” (requirements) to “how the system is implemented”? (implementation) • Use case captures the external observable behaviors of the system. • Need to know what objects are involved. • Source of hints: • User interactions with the system •  Boundary objects • Information retrieval/updated •  Entity objects • Management of control flow and transaction •  control objects • Data transformation, algorithm, etc. •  other utility objects

  3. Dynamic Analysis Techniques (cont’d) • Three steps for developing sequence diagram: • Modeling External System Behaviors • Modeling Communication among the Subsystems • Developing Reusable Model/View/Control (MVC) Software Framework

  4. Modeling External System Behaviors • As the flow of events in the use case description only records the external behaviors of the system and identifies the user inputs and system responses from the flow of events of a scenario, it is a straightforward process to map the scenario to a system-level sequence diagram. • In fact, this mapping process can be automated by a UML CASE tool.

  5. Modeling Communication among the Subsystems • Modeling and analyzing complex systems often involve many objects even for the realization of a single use case. • To develop a detailed sequence diagram based on the system-level sequence diagram with sufficient information for implementation in one go generally requires a lot of effort. • In order to manage the complexity associated with large and complex systems, it is advantageous to package objects into several subsystems. • For example, an ATM system may be organized as a number of subsystems like the ATM, the bank consortium and the bank. Such an organization also reflects how the real-world hardware and software systems are configured, since the ATMs are connected to the bank consortium’s system which is in turn connected to the systems of individual banks.

  6. Modeling Communication among the Subsystems (cont’d)

  7. Modeling Communication among the Subsystems (cont’d)

  8. Developing Reusable Model/View/Control (MVC) Software Framework • At this point you will have developed the system-level sequence diagram and may have also developed a subsystem-level sequence diagram. • We should then develop a detailed sequence diagram in three tiers, involving three types of objects: boundary, control and entity objects.

  9. The Dynamic Modeling and Analysis Process • Developing use case scenarios • Developing system-level sequence diagrams • Developing subsystem-level sequence diagrams (optional for simple system) • Developing subsystem-level statechart diagrams (optional for simple system) • Developing three-tier sequence diagrams • Developing three-tier collaboration diagrams (optional) • Developing a statechart diagram for each of these active (control) objects

  10. The Dynamic Modeling and Analysis Process (cont’d)

  11. The Dynamic Modeling and Analysis Process (cont’d)

  12. The Dynamic Modeling and Analysis Process (cont’d)

  13. Developing Use Case Scenarios • Example – ATM System • Flow of Events • User inserts card • System prompts user to enter PIN • User enters PIN • System prompts user to select services • User selects service - withdraw money • System prompts user to enter withdrawal amount • User enters withdrawal amount • System displays “withdrawal successful” message, ejects card and dispenses money • User collects card and money

  14. Developing System-level Sequence Diagrams

  15. Developing System-level Sequence Diagrams (cont’d)

  16. Developing Subsystem-level Sequence Diagrams (optional)

  17. Developing Subsystem-level Statechart diagram • With the subsystem-level sequence diagram created in Step 2, we can develop the subsystem-level statechart diagram for the scenario. • Let us again use the ATM as an example. When the ATM is idle, it shows a main screen, for example, the welcome screen. • If the user inserts a valid ATM card, it will display a “wait for input PIN” screen.

  18. Developing Subsystem-level Statechart diagram (cont’d)

  19. Developing Three-tier Sequence Diagrams • Identify Boundary, Control and Entity Objects • Message to and from the actor => boundary objects, e.g. insert card => card reader • Information retrieval/ update => entity object, e.g. verify card => account • Management of transaction => control objects, e.g. ATM controller

  20. Developing Three-tier Sequence Diagrams (cont’d)

  21. Developing Three-tier Sequence Diagrams (cont’d)

  22. Developing Three-tier Sequence Diagrams (cont’d)

  23. Developing Three-tier Sequence Diagrams (cont’d)

  24. Developing Three-tier Collaboration Diagram

  25. Developing Statechart Diagrams for Control Objects Statechart diagram of the Card Controller

  26. Tricks and Tips • Creating Cohesive and Self-sufficient Subsystems • Subsystems may be considered as the next level of abstraction down from the entire system. • Ideally, a subsystem should be a cohesive and independent part of the complex system, so as to bring out the benefits of portability, reusability and maintainability. • A cohesive and independent subsystem is loosely coupled with other subsystems, and data coupling is the most loosely-coupled communication method between entities.

  27. Tricks and Tips (cont’d) • Refining Class Diagrams Using MVC-level Scenario Analysis

  28. Tricks and Tips (cont’d)

  29. Tricks and Tips (cont’d)

  30. Tricks and Tips (cont’d)

  31. Tricks and Tips (cont’d) • Understanding System Reusability for Different Types of Objects

  32. Tricks and Tips (cont’d) • Do Not Create Giant Control Objects • the control sequence of messages in the scenario; • information about the sessions in relation to the use case scenario, e.g. session ID, session status, etc.; • control logic of the run-time session, e.g. transaction management, error recovery, etc.

  33. Tricks and Tips (cont’d) • Checking Consistency between Use Case and Sequence Diagrams

  34. Tricks and Tips (cont’d)

  35. View Alignment between Sequence Diagram and State Diagram

  36. View Alignment between Sequence Diagram and State Diagram

More Related