440 likes | 461 Views
An Introduction to Object-Oriented Systems Analysis and Design with UML and the Unified Process McGraw-Hill, 2004 Stephen R. Schach srs@vuse.vanderbilt.edu. CHAPTER 6 — Unit B. THE ANALYSIS WORKFLOW I. Continued from Unit 6A. Fifth Iteration of the Initial Class Diagram (contd).
E N D
An Introduction toObject-Oriented Systems Analysis and Design with UML and the Unified ProcessMcGraw-Hill, 2004Stephen R. Schachsrs@vuse.vanderbilt.edu
CHAPTER 6 — Unit B THE ANALYSIS WORKFLOW I
Dynamic Modeling • Dynamic modeling is the third step in object-oriented analysis • A statechart is constructed that reflects all the operations performed by or to the information system • The operations are determined from the scenarios
The Concept of State • The state of an information system is a particular set of values of the attributes of that system • The state is often represented by a specific screen • Each event causes the system to move from state to state, that is, it causes a transition between states • Example: Microsoft Word • The state is the current screen • An event is to select (say) Font from the Format Menu • The Font screen is then the new state
Initial Dynamic Model: Osbert Oglesby • Initial statechart
Initial Dynamic Model: Osbert Oglesby (contd) • The solid circle (top left) represents the initial state • The white circle with the small black circle inside (top right) represents the final state • States other than the initial and final states are represented by rectangles with rounded corners • The arrows represent transitions from state to state • Example: The arrow from the initial state to the state labeled Osbert Oglesby Information System Loop
Initial Dynamic Model: Osbert Oglesby (contd) • In state Osbert Oglesby Information System Loop, one of five events can occur: • Osbert can choose one of five options: buy a painting, sell a painting, print a report, update a fashionability coefficient, or quit • These possibilities are indicated by the five events: • buy painting selected • sell painting selected • print report selected • update fashionability selected • quit selected
Initial Dynamic Model: Osbert Oglesby • The initial main menu in the target Osbert Oglesby information system
Initial Dynamic Model: Osbert Oglesby (contd) • Suppose that Osbert clicks on Buy a painting in the menu • The event buy painting selected has now occurred • The system moves from its current state, Osbert Oglesby Information System Loop, to the state Buying a Painting • In Buying a Painting state, Osbert can • Buy a masterpiece, masterwork, or other painting
Initial Dynamic Model: Osbert Oglesby (contd) • The Osbert Oglesby information system moves from state to state when an event occurs • In each state, Osbert performs one of the operations supported by that state • This continues until Osbert clicks on option Quit while the system is in state Oglesby Information System Loop • At this time the information system enters the final state (represented by the white circle containing the small black circle) • This terminates execution of the statechart
Dynamic Modeling (contd) • Traditionally there is a dynamic model for each class, rather than for the system as a whole, as in this case study • However, objects in information systems rarely move from one class to another class • Accordingly, a dynamic model for the information system as a whole is appropriate
Extracting Boundary Classes • It is usually easy to extract boundary classes • Each input screen, output screen, and printed report is generally modeled by a boundary class
Initial Boundary Classes: Osbert Oglesby • One screen should be adequate for all four Osbert Oglesby use cases: • Buy a Painting • Sell a Painting • Print a Report • Modify a Fashionability Coefficient • Thus there is one initial boundary class • User Interface Class
Initial Boundary Classes: Osbert Oglesby (contd) • Consider again the first iteration of the main menu of the user-interface screen • The five commands correspond precisely to the five events in the statechart
Initial Boundary Classes: Osbert Oglesby (contd) • This is a graphical interface, which needs special software
Initial Boundary Classes: Osbert Oglesby (contd) • However, a textual interface runs on all computers
Initial Boundary Classes: Osbert Oglesby (contd) • There are three reports: • The purchases report • The sales report • The future trends report • Each of these has to be modeled by a separate boundary class because the content of each report is different
Initial Boundary Classes: Osbert Oglesby (contd) • There are thus three report boundary classes • Purchases Report Class • Sales Report Class • Future Trends Report Class
Initial Boundary Classes: Osbert Oglesby (contd) • There are therefore four boundary classes
Extracting Control Classes • It is also usually easy to extract control classes • Each nontrivial computation is generally modeled by a control class
Initial Control Classes: Osbert Oglesby • In the case study there are four computations • Determining the maximum price that Osbert should offer for a • Masterpiece • Masterwork, or • Other painting • Determining if there is a new trend in art purchases
Initial Control Classes: Osbert Oglesby • There are thus four initial control classes: • Compute Masterpiece Price Class • Compute Masterwork Price Class • Compute Other Painting Price Class • Compute Future Trends Class
Initial Control Classes: Osbert Oglesby (contd) • Here are the initial control classes
Refining the Use Cases: Osbert Oglesby • The class diagram reflects that the pricing algorithm treats the three types of paintings differently • Accordingly, use case Buy a Painting needs to be refined into three separate use cases • Buy a Masterpiece • Buy a Masterwork • Buy Other Painting • Therefore, the description of the Buy a Painting use case must be split into three separate descriptions
Refining the Use Cases: Osbert Oglesby (contd) • The Produce a Report use case also needs to be refined • The purchases report and the sales report use simple data extraction— the future trends report involves computation • All three reports use their own boundary classes
Refining the Use Cases: Osbert Oglesby (contd) • For both these reasons, the Produce a Report use case must be refined into three use cases • Produce a Purchases Report • Produce a Sales Report • Produce a Future Trends Report • The description of the use case must be split into three separate descriptions
Class Extraction (contd) • The description of class extraction is complete • We now therefore return to the Unified Process
Use-Case Realization • The process of extending and refining use cases is called use-case realization
Use-Case Realization (contd) • The verb “realize” is used at least 3 different ways: • Understand (“Harvey slowly began to realize that he was in the wrong classroom”); • Receive (“Ingrid will realize a profit of $45,000 on the stock transaction”); and • Accomplish (“Janet hopes to realize her dream of starting a computer company”) • In the phrase “realize a use case,” the word “realize” is used in this last sense • It means to accomplish (or achieve) the use case
Use-Case Realization (contd) • The realization of a specific scenario of a use case is depicted using an interaction diagram • Either a sequence diagram or collaboration diagram • Various versions of the use case Buy a Masterpiece appear in the following slides
Buy a Masterpiece Use Case • Use case diagram
Buy a Masterpiece Use Case (contd) • Description of the use case
Buy a Masterpiece Use Case (contd) • Class diagram (classes that enter into the use case)
Buy a Masterpiece Use Case (contd) • The four classes that enter into this use case are: • User Interface Class • This class models the user interface • Compute Masterpiece Price Class • This class models the computation of the price Osbert should offer • Masterpiece Class • The computation involves comparing the masterpiece being considered with the masterpieces that have been previously auctioned • Auctioned Painting Class • These masterpieces are all instances of Auctioned Painting Class
Buy a Masterpiece Use Case (contd) • The Seller does not interact directly with the information system • Instead, the Seller provides data that Osbert enters into the information system • This is indicated in the note (the rectangle with the top right-hand corner turned over) • There is a dashed line from the note to the item to which it refers, the Seller in this case
Buy a Masterpiece Use Case (contd) • Scenario (one possible instance of the use case)
Buy a Masterpiece Use Case (contd) • A working information system uses objects, not classes • Example: A specific masterpiece is not represented by Masterpiece Class but rather by an object, a specific instance of Masterpiece Class • Such an object is denoted by : Masterpiece Class
Buy a Masterpiece Use Case (contd) • A class diagram shows the classes in the use case and their relationships • It does not show the objects nor the sequence of messages as they are sent from object to object • Something more is needed
Buy a Masterpiece Use Case (contd) • Collaboration diagram (of the realization of the scenario of the use case)
Buy a Masterpiece Use Case (contd) • The collaboration diagram shows the objects as well as the messages, numbered in the order in which they are sent in the specific scenario • The direction of the arrow shows the direction in which the information flows