Unit-3 OBJECT ORIENTED ANALYSIS

Transcription

1 Unit-3 OBJECT ORIENTED ANALYSIS SYLLABUS: Extracting entity classes Initial dynamic model-extracting control classes-refining use cases - Incrementing the class diagram-initial dynamic model-msg Foundation case study revising the entity classes-extracting-use case realization-msg Foundation case study incrementing the class diagram- more on use cases- risk INTRODUCTION To obtain a deeper understanding of the requirements To describe the requirements in a way that is o Easy to maintain, and o Provides insights into the structure of the target information system Classes The three class types in the Unified Process are o Entity classes o Boundary classes o Control classes UML notation Entity Classes An entity class models information that is long lived Examples: o Account Class in a banking information system o Painting Class in the Osbert Oglesby information system o Mortgage Class and Investment Class in the MSG Foundation information system Instances of all these classes remain in the information system for years Boundary Classes A boundary class models the interaction between the information system and its actors Boundary classes are generally associated with input and output Examples: Purchases Report Class and Sales Report Class in the Osbert Oglesby information system 1

2 Mortgage Listing Class and Investment Listing Class in the MSG Foundation information system Control Classes A control class models complex computations and algorithms Examples: o Compute Masterpiece Price Class, o Compute Masterwork Price Class, and o Compute Other Painting Price Class in the Osbert Oglesby information system 3.1 EXTRACTING ENTITY CLASSES Entity class extraction consists of three steps that are carried out iteratively and incrementally: o Functional modeling Present scenarios of all the use cases (a scenario is an instance of a use case) o Class modeling Determine the entity classes and their attributes Determine the interrelationships and interactions between the entity classes Present this information in the form of a class diagram o Dynamic modeling Determine the operations performed by or to each entity class Present this information in the form of a statechart Flowchart for Extracting Entity Classes 2

3 3.1.1 Initial Functional Model: Osbert Oglesby Recall the Osbert Oglesby use-case diagram: Use Case and Scenario A use case depicts all possible interactions of a specific kind A scenario is an instance of a use case o (Just as an object is an instance of a class) Scenario of Use Case Buy a Painting This is a normal scenario There are six paragraphs in the scenario o Only four of them are numbered o The two unnumbered sentences Osbert wishes to buy a masterpiece and Osbert makes an offer below the maximum purchase price the offer is accepted by the seller have nothing to do with the interaction between Osbert and the information system o These unnumbered paragraphs are essentially comments 3

4 Second Scenario of Use Case Buy a Painting This is an exception scenario o It models an interaction that is not normal Third Scenario of Use Case Buy a Painting This is another exception scenario Normal and Exception Scenarios Normal and exception scenarios can be combined into an extended scenario 4

5 The systems analysis team investigates as many normal and exception scenarios of each use case as time permits o To get the deepest possible understanding of The domain The business model, and The use cases Initial Class Diagram : Osbert Oglesby Case Study The second step in extracting the entity classes is class modeling o The aim of this step is to extract the entity classes, determine their interrelationships, and find their attributes Usually, the best way to begin this step is to use the two-stage noun extraction method o Stage 1: Describe the information system in a single paragraph o Stage 2: Identify the nouns in this paragraph, then select the entity classes from those nouns Noun Extraction: Osbert Oglesby Case Study Stage 1: Describe the information system in one paragraph: o Reports are to be generated in order to improve the effectiveness of the decisionmaking process for buying works of art. The reports contain buying and selling information about paintings, which are classified as masterpieces, masterworks, and other paintings Stage 2: Identify the nouns in this paragraph o Reports are to be generated in order to improve the effectiveness of the decisionmaking process for buying works of art. The reports contain buying and selling information about paintings, which are classified as masterpieces, masterworks, and other paintings The nouns are report, effectiveness, process, buying, work of art, selling, information, painting, masterpiece, and masterwork effectiveness, process and information are abstract nouns and are therefore unlikely to be entity classes o Abstract nouns identify things that have no physical existence Nouns buying and selling are derived from the verbs buy and sell o They will probably be operations of some class Noun report is unlikely to be an entity class, because a report is not long lived o A report is much more likely to be a boundary class Noun work of art is just a synonym for painting First Iteration of the Initial Class Diagram This leaves four candidate entity classes: o Painting Class, Masterpiece Class, Masterwork Class, and Other Painting Class 5

6 Second Iteration of the Initial Class Diagram Consider the interrelationships between the entity classes A masterpiece is a specific type of painting, and so is a masterwork and an other painting o Painting Class is therefore the base class o Masterpiece Class, Masterwork Class, and Other Painting Class are subclasses of that base class Third Iteration of the Initial Class Diagram The class diagram does not reflect aspects of the pricing algorithm When dealing with a masterwork o The information system first computes the maximum purchase price as if it were a masterpiece by the same artist That is, a masterwork has to have all the attributes of a masterpiece (so that its maximum purchase price can be computed as if it were a masterpiece) and, in addition, it may have attributes of its own Fourth Iteration of the Initial Class Diagram Another aspect of the pricing algorithm that is not reflected in the current class diagram is o The information system computes the coefficient of similarity between each painting for which there is an auction record and the painting under consideration for purchase 6

7 Auctioned Painting Class is needed to make these comparisons o An auctioned painting must be a subclass of Painting Class o But a painting previously been sold at an auction somewhere in the world has nothing to do with paintings currently on display for sale in Osbert s gallery An instance of Painting Class is either o A painting that Osbert has bought (an instance of Gallery Painting Class), or o A painting sold at some auction (an instance of Auctioned Painting Class) Fifth Iteration of the Initial Class Diagram A third aspect of the maximum price algorithm that has not yet been modeled is fashionability o The information system computes the maximum purchase price from the formula F A, where F is a constant for that artist (fashionability coefficient) Fashionability Class is needed o A painting of Other Painting Class can then use the instance of Fashionability Class for that artist to compute the maximum price that Osbert should offer to pay 7

8 Finally, we add the attributes of each class to the class diagram o For the Osbert Oglesby case study, the result is shown on the next slide The empty rectangle at the bottom of each box will later be filled with the operations of that class Osbert Oglesby Application Class will contain the operation that starts execution of the whole software product the fifth iteration of the initial class diagram, without the attributes, but explicitly reflecting the stereotypes o All eight classes in that figure are entity classes This is also a class diagram o A class diagram depicts classes and their interrelationships; attributes and operations are optional 8

9 3.2 INITIAL DYNAMIC MODEL Dynamic modeling is the third step in extracting the entity classes A statechart is constructed that reflects all the operations performed by or to the software product The operations are determined from the scenarios Initial state-chart 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 In state Osbert Oglesby Event Loop, one of five events can occur: o buy painting selected o sell painting selected o print report selected o update fissionability selected o quit selected 9

10 Initial Main Menu: Osbert Oglesby Graphical user interface (GUI) o Point and click In the object-oriented paradigm, there is a dynamic model for each class, rather than for the system as a whole, as in this case study o However, objects in this software product never move from one class to another class Accordingly, a dynamic model for the software product as a whole is appropriate 3.3 EXTRACTING CONTROL CLASSES It is also usually easy to extract control classes o Each nontrivial computation is generally modeled by a control class In the case study there are four computations o Determining the maximum price that Osbert should offer for a Masterpiece Masterwork, or Other painting o Determining if there is a new trend in art purchases Initial Control Classes: Osbert Oglesby There are therefore four initial control classes 10

11 3.4 REFINING USE CASES The pricing algorithm treats the three types of paintings differently Use case Buy a Painting must therefore be refined into three separate use cases o Buy a Masterpiece o Buy a Masterwork o Buy Other Painting Use case Produce a Report also needs to be refined o The purchases report and the sales report use simple data extraction the future trends report involves computation o All three reports use their own boundary classes For both these reasons, the Produce a Report use case must be refined into three use cases o Produce a Purchases Report o Produce a Sales Report o Produce a Future Trends Report Third Iteration of the Use-Case Diagram Implications for the remaining UML diagrams include: o The description of the new Buy a Painting use case (see over) must be split into three separate descriptions o The description of the Produce a Report use case must be split into three separate descriptions Use Case Buy a Masterpiece 11

12 Description of Use Case Buy a Masterpiece The verb The process of extending and refining use cases is called use-case realization realize is used at least 3 different ways: o Understand ( Harvey slowly began to realize that he was in the wrong classroom ); o Receive ( Ingrid will realize a profit of $45,000 on the stock transaction ); and o 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 The realization of a specific scenario of a use case is depicted using an interaction diagram o Either a sequence diagram or collaboration diagram Consider use case Buy a Masterpiece We have previously seen o The use case o The description of the use case 12

13 Buy a Masterpiece Use Case The Four Classes That Enter into This Use Case User Interface Class o This class models the user interface Compute Masterpiece Price Class o This class models the computation of the price Osbert should offer Masterpiece Class o The computation involves comparing the masterpiece being considered with the masterpieces that have been previously auctioned Auctioned Painting Class o These masterpieces are all instances of Auctioned Painting Class Buy a Masterpiece Use Case The Seller does not interact directly with the software product o Instead, the Seller provides data that Osbert enters into the software product This is indicated in the note (the rectangle with the top right-hand corner turned over) o There is a dashed line from the note to the item to which it refers, the Seller in this case Scenario (one possible instance of the use case) 13

14 An executing software product uses objects, not classes Example: o 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 in UML by : Masterpiece Class A class diagram shows the classes in the use case and their relationships o It does not show the objects nor the sequence of messages as they are sent from object to object Something more is needed A collaboration diagram (of the realization of the scenario of the use case) Osbert will not approve the specification document unless he understands it Accordingly, a written description of the collaboration diagram is needed o The flow of events The flow of events of the collaboration diagram of the realization of the scenario of the use case Osbert will not approve the specification document unless he understands it Accordingly, a written description of the collaboration diagram is needed o The flow of events UML supports two different types of interaction diagram Collaboration diagram Sequence diagram Both contain exactly the same information, but displayed in different ways 14

15 Sequence diagram equivalent to the collaboration diagram (of the realization of the scenario of the use case) The narrow rectangle on a lifeline (dashed vertical line) shows when the relevant object is active In the collaboration diagram, the [new] is inside the : Masterpiece Class object o In the sequence diagram, the object is shifted down so that its lifeline starts where the object is created The sequence diagram shows that every message of the scenario involves either o The instance of the user interface class : User Interface Class or o The instance of the control class : Compute Masterpiece Price Class It also shows that every transfer of information from object A to object B is eventually followed by a transfer in the reverse direction These two facts are also true in the fully equivalent collaboration diagram, but are not as obvious in that format It also shows that every transfer of information from object A to object B is eventually followed by a transfer in the reverse direction These two facts are also true in the fully equivalent collaboration diagram, but are not as obvious in that format Interaction Diagrams Software engineers can choose whether to use o A sequence diagram, or o A collaboration diagram, or o Both for each scenario The strength of a sequence diagram is that it shows the flow of messages and their order unambiguously When transfer of information is the focus of attention, a sequence diagram is superior to a collaboration diagram 15

16 A collaboration diagram is similar to a class diagram When the developers are concentrating on the classes, a collaboration diagram is more useful than the equivalent sequence diagram The seven previous figures depict different aspects of the use case Buy a Masterpiece They use different notations and provide different levels of detail of the same activity Why do we construct so many related artifacts? We examine this one activity from a variety of different perspectives to learn enough about it to ensure that the analysis workflow will be correct The maximum price of a masterwork is computed by first treating the painting as if it were a masterpiece, and then adjusting the result The Five Classes That Enter into This Use Case User Interface Class Compute Masterwork Price Class This class models the computation of the price Osbert should offer It creates a masterwork object and passes it to Compute Masterpiece Price Class as if it were a masterpiece Compute Masterpiece Price Class Masterpiece Class Auctioned Painting Class Class diagram (classes that enter into the use case) One possible scenario of the use case 16

17 Buy Other Painting Use Case Modifying the Main Menu. The main menu must reflect buying the three different types of painting explicitly Buy a Painting must be replaced by o Buy a Masterpiece, o Buy a Masterwork, and o Buy Other Painting The revised screen is generated by : User Interface Class SELL A PAINTING USE CASE CLASS DIAGRAM 17

18 PRODUCE A PURCHASES REPORT USE CASE- CLASS DIAGRAM PRODUCE A SALES REPORT USE CASE PRODUCE A FUTURE TRENDS REPORT USE CASE MODIFY A FASHIONABILITY COEFFICIENT USE CASE 18

19 3.5 INCREMENTING THE CLASS DIAGRAM In the course of realizing the various use cases o Interrelationships between classes become apparent Accordingly, we now combine the realization class diagrams Combining the Realization Class Diagrams Sixth Iteration of the Class Diagrams 19

20 3.6 INITIAL DYNAMIC MODEL - MSG Dynamic modeling is the third step in extracting the entity classes A statechart is constructed that reflects all the operations performed by or to the software product The operations are determined from the scenarios The statechart reflects the operations of the complete MSG Foundation information system o The solid circle on the top left represents the initial state, the starting point of the statechart o The white circle containing the small black circle on the top right represents the final state o States other than the initial and final states are represented by rectangles with rounded corners o The arrows represent possible transitions from state to state In state MSG Foundation Information System Loop, one of five events can occur An MSG staff member can issue one of five commands: o estimate funds for the week o manage an asset o update estimated annual operating expenses o produce a report, or o quit These possibilities are indicated by the five events o estimate funds for the week selected o manage an asset selected o update estimated annual operating expenses selected o produce a report selected, and o quit selected An event causes a transition between states An MSG staff member selects an option by clicking on the menu 20

21 This graphical user interface (GUI) requires special software Equivalent textual user interface that can run on any computer 3.7 MSG FOUNDATION CASE STUDY REVISING THE ENTITY CLASSES The initial functional model, the initial class diagram, and the initial dynamic model are completed o Checking them reveals a fault In the initial statechart, consider state Update Estimated Annual Operating Expenses with operation Update the estimated annual operating expenses o This operation has to be performed on the current value of the estimated annual operating expense But where is the value of the estimated annual operating expenses to be found? Currently there is only one class (Asset Class) and its two subclasses o Neither is appropriate for storing the estimated annual operating expenses The only way a value can be stored on a long-term basis is as an attribute of an instance of that class or its subclasses Another entity class is needed for storing the estimated annual operating expenses o MSG Application Class Third Iteration of the Initial Class Diagram: MSG Foundation MSG Application Class has other attributes as well o Attributes that do not appertain to the assets 21

22 The class diagram redrawn to show the prototypes 22

23 Extracting the Boundary Classes: MSG Foundation It is usually easy to extract boundary classes o Each input screen, output screen, and printed report is generally modeled by a boundary class o One screen should be adequate for all four MSG Foundation use cases Estimate Funds Available for Week Manage an Asset Update Estimated Annual Operating Expenses Produce a Report o Accordingly there is one initial boundary class o User Interface Class Three reports have to be printed o The estimated funds for the week report o The listing of all mortgages o The listing of all investments Each of these has to be modeled by a separate boundary class o Estimated Funds Report Class o Mortgages Report Class o Investments Report Class Here are the four initial boundary classes There are three reports: o The purchases report o The sales report o The future trends report The content of each report is different o Each report therefore has to be modeled by a separate boundary class 3.8 USE CASE REALIZATION : THE MSG FOUNDATION CASE STUDY The process of extending and refining use cases is called use-case realization The verb realize is used at least 3 different ways: o Understand ( Harvey slowly began to realize that he was in the wrong classroom ); o Receive ( Ingrid will realize a profit of $45,000 on the stock transaction ); and o 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 The realization of a specific scenario of a use case is depicted using an interaction diagram o Either a sequence diagram or collaboration diagram Consider use case Estimate Funds Available for Week 23

24 We have previously seen o The use case o The description of the use case Estimate Funds Available for Week Use Case Use-case diagram Description of use case 24

25 Class diagram (classes that enter into the use case) The six classes that enter into this use case are: o User Interface Class This class models the user interface o Estimate Funds for Week Class This control class models the computation of the estimate of the funds that are available to fund mortgages during that week o Mortgage Class This class models the estimated grants and payments for the week o Investment Class This class models the estimated return on investments for the week o MSG Application Class This class models the estimated return on investments for the week o Estimated Funds Report Class This class models the printing of the report 25

26 Scenario (one possible instance of the use case) A working information system uses objects, not classes o Example: A specific mortgage cannot be represented by Mortgage Class but rather by an object, a specific instance of Mortgage Class Such an object is denoted by : Mortgage Class A class diagram shows the classes in the use case and their relationships o It does not show the objects nor the sequence of messages as they are sent from object to object 26

27 Collaboration diagram (of the realization of the scenario of the use case) The collaboration diagram shows the objects as well as the messages, numbered in the order in which they are sent in the specific scenario Item 1: o The staff member wants to compute the funds available for the week o In the collaboration diagram, this is modeled by message 1: Request estimate of funds available for week from MSG Staff Member to : User Interface Class, an instance of User Interface Class Item 2 o This request is passed on to : Estimate Funds for Week Class, an instance of the control class that actually performs the calculation o This is modeled by message 2: Transfer request Four separate financial estimates are now determined by : Estimate Funds for Week Class 27

28 Item 3 o In Step 1 of the scenario, the estimated annual return on investments is summed for each investment and the result divided by 52 o This extraction of the estimated weekly return is modeled by message 3: Request estimated return on investments for week from : Estimate Funds for Week Class to : Investment Class followed by message 4: Return estimated weekly return on investments in the other direction Item 4 o In Step 2 of the scenario, the weekly operating expenses are estimated by taking the estimated annual operating expenses and dividing by 52 o This extraction of the weekly expenses is modeled by message 5: Request estimated operating expenses for week from : Estimate Funds for Week Class to : MSG Application Class followed by message 6: Return estimated operating expenses for week in the other direction Item 5 o In Steps 3, 4, and 5 of the scenario, two estimates are determined the estimated grants for the week, and the estimated payments for the week o This is modeled by message 7: Request estimated grants and payments for week from : Estimate Funds for Week Class to : Mortgage Class, and by message 8: Return estimated grants and payments for week in the other direction Item 6 o Now the arithmetic computation of Step 6 of the scenario is performed o This is modeled by message 9: Compute estimated amount available for week o This is a self call o : Estimate Funds for Week Class tells itself to perform the calculation o The result of the computation is stored in : MSG Application Class by message 10: Transfer estimated amount available for week Item 7 o The result is printed in Step 7 of the scenario o This is modeled by message 11: Print estimated amount available o from : MSG Application Class to : Estimated Funds Report Class Item 8 o Finally, an acknowledgment is sent to the MSG staff member that the task has been successfully completed o This is modeled by messages 12: Send successful completion message 13: Send successful completion message 14: Transfer successful completion message, and 15: Display successful completion message No client will approve the specification document without understanding it 28

29 Accordingly, a written description of the collaboration diagram is needed, the flow of events The flow of events of the collaboration diagram of the realization of the scenario of the use case Sequence diagram equivalent to the collaboration diagram (of the realization of the scenario of the use case) 3.9 MSG FOUNDATION CASE STUDY INCREMENTING THE CLASS DIAGRAM In the course of realizing the various use cases o Interrelationships between classes become apparent Accordingly, we now combine the realization class diagrams COMBINING THE REALIZATION CLASS DIAGRAMS 29

30 FIFTH ITERATION + REALIZATION CLASS DIAGRAM MANAGE AN ASSET USE CASE USE CASE 30

31 DESCRIPTION OF USE CASE CLASS DIAGRAM SHOWING THE CLASSES THAT REALIZE THE USE CASE ONE SCENARIO OF THE USE CASE 31

32 COLLABORATION DIAGRAM OF THE REALIZATION OF THE SCENARIO OF THE USE CASE Object : Investment Class does not play an active role in this collaboration diagram o This scenario does not involve an investment, only a mortgage Actor Borrowers does not play a role in this use case, either 32

33 SEQUENCE DIAGRAM EQUIVALENT TO THE COLLABORATION DIAGRAM (OF THE REALIZATION OF THE SCENARIO OF THE USE CASE) A DIFFERENT SCENARIO OF THE USE CASE At the request of the borrowers, the MSG staff member updates the weekly income of a couple The scenario is initiated by the Borrowers Their data are entered into the software product by the MSG Staff Member o This is stated in the note in the collaboration diagram 33

34 SEQUENCE DIAGRAM EQUIVALENT TO THE COLLABORATION DIAGRAM (OF THE REALIZATION OF THE SCENARIO OF THE USE CASE) Two different scenarios of the same use case have been presented The use case is the same o The class diagram is therefore the same However, the collaboration (and sequence) diagrams reflect the differences between the two scenarios Boundary class User Interface Class appears in all the realizations o The same screen will be used for all commands of the information system Revised menu 34

35 Corresponding textual interface UPDATE ANNUAL OPERATING EXPENSES USE CASE Class diagram Collaboration diagram of a realization of a scenario of the use case 35

36 Equivalent sequence diagram Produce a Report Use Case Use case 36

37 Description of use case Class diagram 37

38 One scenario of the use case Collaboration diagram Mortgages (but not investments) are involved 38

39 Sequence diagram A second scenario (listing all investments) of the use case 39

40 Collaboration diagram for second scenario This time, investments (but not mortgages) are involved Sequence diagram for second scenario 40

41 3.10 MORE ON USE CASES In the Unified Process o The term worker is used to denote a role played by an individual o In the Unified Process, Applicants and Borrowers are two different workers In common parlance o The word worker usually refers to an employee Within a business context, finding the roles is easy o They are displayed within the use-case business model To find the actors o Find the subset of the use-case business model that corresponds to the use-case model of the requirements To find the actors (in more detail): o Construct the use-case business model o Consider only those parts of the business model that correspond to the proposed software product o The actors in this subset are the actors we seek Within a business context, finding use cases is easy For each role, there will be one or more use cases 3.11 RISK A major risk in developing a new information system is that the delivered information system does not meet the client s needs. In the traditional paradigm, this risk was met by constructing rapid prototype, a hurriedly thrown together working program that displays the key functionality of the target information. This type of information is not needed in the unified process, because the use cases and their scenarios take the place of the rapid prototype Rapid prototyping Many approaches have been put forward for ensuring that the client s needs are truly met by the specification document. They all reduce to the systems analysts sitting down with the client, going through the specification document line by line and asking, Are you really, really, really sure that this is what you want the proposed information system to do? none of these methods are foolproof. 1 st situation concerns Joe and Jane Johnson, who decide to build a house. They consult with an architect. Instead of showing them sketches, plans, perhaps a model, the architect gives them a 20 page, single-spaced document, describing the house in highly technical 41

42 terms. Despite the fact that both Joe and Jane have no previous architectural experience and hardly understand any of the documents, they enthusiastically sign it and say, Go right ahead; build the house! 2 nd situation concerns Mark Marberry, who buys his suits by mail order. Instead of mailing him pictures of their suits and samples of available cloths, the company sends Mark a catalog containing written description of the cut and the cloth of their products. Mark then order a suit solely based on the written description. The client use the information system for a few minutes, then turns to the system analysts and says I know that this is the information system I asked for, but it is not what I wanted. A rapid prototype is a working program that exhibits the key behavior of that information system. For example, if the target information system is to handle accounts payable, accounts receivable and warehousing, then the rapid prototype may consist of an information system that performs the screen handling for data capture and prints the reports, but does no database updating or error handling (hidden aspects). The client and users then experiment with the prototype to determine whether it indeed meets their needs. The rapid prototype can be changed until the client and users are satisfied that it encapsulates the functionality they desire. Key points: It must be rapid. That is it must be thrown together as quickly as possible. The use is to make sure, when the complete information system is delivered to the client a year or so later, the functionality of the system will be precisely what the client needs. One way of doing this is for the client to experiment with a computer program that behaves the same way the target information system will behave. After the rapid prototype has been approved by the client, it must be thrown away without any sort of specification or design document. Making changes when there is no documentation of any kind is both expensive and foolhardy Scenarios and the Client s needs Instead of constructing a rapid prototype, the use cases or more precisely, interaction diagrams reflecting the classes that realize the scenarios of the use cases as shown to the client. The client can understand how the target information system will behave just as 42

43 well from the interaction diagrams and their written flow of events as from a rapid prototype. There is a need to construct specimen screens and reports, preferably with the aid of screen generators, report generators and CASE tools that make it easy to produce the code for screens and reports. 43