University of Southern California Center for Systems and Software Engineering CS577a: Use-Case Analysis and Workshop 10/12/2009© USC-CSSE David Klappholz, Nupul Kukreja

University of Southern California Center for Systems and Software Engineering Roadmap We shall a discuss a technique called “Robustness Analysis” –To help analyze the use-case descriptions –as well as help identify classes that may have not been captured in the domain model (as well as those are required in the design/implementation) There will be a workshop in the latter half of the lecture – each team should have their use-case descriptions. We shall be applying this for at least 14 use-cases – one per team! 10/12/2009© USC-CSSE

University of Southern California Center for Systems and Software Engineering Robustness Analysis This term is a misnomer!! It is not intended for analyzing the robustness of a system but for analyzing the accuracy of use- case descriptions to help in software design/implementation It was ‘invented’ by Ivar Jacobson, but never made it into the UML specification – it was then furthered by Doug Rosenberg et al. We may use the term “Initial Design Diagram” to mean “Robustness Diagrams” at times 10/12/2009© USC-CSSE

University of Southern California Center for Systems and Software Engineering Robustness Analysis - Purpose Its purpose is to discover the necessary: –Interface objects: What various actors use to interact with the system e.g., Pages, Dialog boxes, etc., –Entity objects: Both temporary and persistent data that are used/generated by the system, e.g., temporary data structures, DB tables, etc. –Control objects: – To state loosely the ones that facilitate interactions between the above! It will be clarified further when we’ll see examples on later slides. 10/12/2009© USC-CSSE

University of Southern California Center for Systems and Software Engineering Robustness Analysis - Process‏ Performed one use-case at a time; its result is one “robustness diagram” per use-case. The first use-case for which we’ll create a robustness diagram is the Log In use-case from the Internet Bookstore system that we have been following The text of the Log In use-case is repeated on the following slides after which the Log In use-case’s initial design diagram (i.e., robustness diagram) is shown –Some of the symbols may be unfamiliar, but most of which you’ll be able to figure out if you spend a bit of time looking at the diagram. We explain them in detail in today’s lecture. 10/12/2009© USC-CSSE

University of Southern California Center for Systems and Software Engineering Basic Course 1.The Customer clicks the Log In button on the Home Page. 2.The system displays the Login Page. 3.The Customer enters his or her user ID and password and then clicks the Log In button. 4.The system validates the login information against the persistent Account data and then returns the Customer to the Home Page. Log In Use Case 10/12/2009© USC-CSSE

University of Southern California Center for Systems and Software Engineering If the Customer clicks the New Account button on the Login Page, the system invokes the Open Account use case. If the Customer clicks the Reminder Word button on the Login Page, the system displays the reminder word stored for that Customer, in a separate dialog box. When the Customer clicks the OK button, the system returns the Customer to the Login Page. If the Customer enters a user ID that the system does not recognize, the system displays a message to that effect and prompts the Customer to either enter a different ID or click the New Account button. If the Customer enters an incorrect password, the system displays a message to that effect and prompts the Customer to reenter his or her password. If the Customer enters an incorrect password three times, the system displays a page telling the Customer that he or she should contact customer service, and also freezes the Login Page. Log In Use Case: Alternate Courses 10/12/2009© USC-CSSE

University of Southern California Center for Systems and Software Engineering Robustness Diagram for Log In 10/12/2009© USC-CSSE

University of Southern California Center for Systems and Software Engineering New Symbols: Interface Object 10/12/2009© USC-CSSE The symbolrepresents an “interface object.” That is, an object with which an actor interacts. Some examples from Log-In’s Initial Design Diagram are: Home PageLogin PageReminder Word Dialog Box

University of Southern California Center for Systems and Software Engineering New Symbols: Entity Object 10/12/2009© USC-CSSE The symbolrepresents an “entity object.” The only example from Log In’s Initial Design Diagram is: which represents customer account data that the Log In use-case needs to refer to. Account

University of Southern California Center for Systems and Software Engineering New Symbols: Control Object 10/12/2009© USC-CSSE The standard symbol for a “control object” is: i.e., a circle with a left-pointing arrow head on top. We will see instances of this symbol, later, in the initial design diagram for the Open New Account use-case. An alternative symbol for a “control object,” and the one used in Log In’s Initial Design Diagram is: The small arrow head on the oval is a bit hard to see, but it’s there – pointed to by the red arrow.

University of Southern California Center for Systems and Software Engineering New Symbols: Control Object (cont.)‏ 10/12/2009© USC-CSSE The two instances of control objects in Log-In’s Initial Design Diagram are named “Display” and “Validate.” DisplayValidate

University of Southern California Center for Systems and Software Engineering Constructing the Robustness Diagram - I Remember: There will be one robustness diagram for each use-case. This diagram for a use-case is created (sort of) sentence-by-sentence from the text of the use-case, starting with the text of the basic course. What we mean by “sort of” is illustrated, on the next slide, by the break-down of Log-In’s basic course into “(sort of) sentences.” 10/12/2009© USC-CSSE

University of Southern California Center for Systems and Software Engineering Constructing the Robustness Diagram II ‏ 10/12/2009© USC-CSSE The Customer clicks the Log In button on the Home Page. 2.The system displays the Login Page. 3.The Customer enters his or her user ID and password and then clicks the Log In button. 4.The system validates the login information against the persistent Account data and then returns the Customer to the Home Page. That is, for the purpose of constructing an initial robustness diagram, a sentence with no “and” or “or” is treated as an individual unit, but a sentence with an “and” or an “or” is broken into its constituent parts. NOTE: THIS MEANS THAT USE-CASE TEXT MUST BE WRITTEN AS COHERENT, UNAMBIGUOUS, SENTENCES!!!

University of Southern California Center for Systems and Software Engineering Constructing the Robustness Diagram III ‏ 10/12/2009© USC-CSSE If you look carefully at Log-In’s basic course’s decomposition, on the previous slide, into five components or “sentences,” you’ll find two apparent violations of the “break at an ‘and’ or an ‘or’ “ rule. See if you can find the two apparent violations before you go to the next slide.

University of Southern California Center for Systems and Software Engineering Constructing the Robustness Diagram IV The two apparent violations are the two “and”s and one “or” in the following “sentence” that didn’t cause us to break it up into separate parts as we said we’d do when we saw instances of “and” and “or”: The Customer enters his or her user ID and password and then clicks the Log In button. The reason we didn’t break the sentence at each “and” and “or” is that in constructing the initial design diagram we’re trying to figure out the interface objects, entity objects, control objects that will have to be parts of the system, and actions that the system will have to perform, so the rule actually should have been “a sentence with an “and” or an “or” that describes a system (application) activity is broken into its constituent parts; a sentence describing an actor’s activity isn’t broken down.” 10/12/2009© USC-CSSE

University of Southern California Center for Systems and Software Engineering Constructing the Robustness Diagram IV Since Log-In’s basic course consists of five “sentences” – Log-In’s initial design diagram will be constructed in five steps Log-In’s initial design diagram starts out as an empty/blank diagram, and additions are made to it for each “sentence.” The next five slides show the step-by-step construction of Log-In’s initial design diagram. 10/12/2009© USC-CSSE

University of Southern California Center for Systems and Software Engineering Constructing the Robustness Diagram V There are four basic ‘rules’* to follow: –Actors can only talk to boundary objects. –Boundary objects can only talk to controllers and actors. –Entity objects can only talk to controllers. –Controllers can talk to boundary objects, entity objects, and other controllers, but not to actors 10/12/2009© USC-CSSE *Use Case Driven Object Modeling with UML – Doug Rosenberg et al.

University of Southern California Center for Systems and Software Engineering 10/12/2009© USC-CSSE Figure 5-5. Robustness Diagram Rules Source: Use Case Driven Object Modeling with UML – Doug Rosenberg et al.

University of Southern California Center for Systems and Software Engineering STEP 1 The Customer clicks the Log In button on the Home Page. 10/12/2009© USC-CSSE Note that the Log In button is an interface item; if it were any more complex than just being a button to click on, the author of Log In’s initial design diagram might have modeled it as a separate interface object. Note, further, that just as was the case in deciding what the use-cases are for the Internet Bookstore, deciding on what’s an “object” worthy of going into an initial design diagram is a judgment call. IN SOFTWARE DEVELOPMENT THERE IS OFTEN NO SINGLE RIGHT ANSWER OR RIGHT ANALYSIS OR DESIGN DECISION.

University of Southern California Center for Systems and Software Engineering STEP 2 The system displays the Login Page 10/12/2009© USC-CSSE It wouldn’t be much of a stretch to guess that oval-shaped control objects in initial design diagrams later turn into “methods” (or independent ‘controller classes’)

University of Southern California Center for Systems and Software Engineering STEP 3 The Customer enters his or her user ID and password and then clicks the Log In button. 10/12/2009© USC-CSSE

University of Southern California Center for Systems and Software Engineering STEP 4 The system validates the login information against the persistent Account data 10/12/2009© USC-CSSE

University of Southern California Center for Systems and Software Engineering STEP 5...and then returns the Customer to the Home Page 10/12/2009© USC-CSSE

University of Southern California Center for Systems and Software Engineering Alternate Courses If the Customer clicks the New Account button on the Login Page, the system invokes the Open Account use-case. If the Customer clicks the Reminder Word button on the Login Page, the system displays the reminder word stored for that Customer, in a separate dialog box. When the Customer clicks the OK button, the system returns the Customer to the Login Page. If the Customer enters a user ID that the system does not recognize, the system displays a message to that effect and prompts the Customer to either enter a different ID or click the New Account button. If the Customer enters an incorrect password, the system displays a message to that effect and prompts the Customer to re-enter his or her password. If the Customer enters an incorrect password three times, the system displays a page telling the Customer that he or she should contact customer service, and also freezes the Login Page. 10/12/2009© USC-CSSE

University of Southern California Center for Systems and Software Engineering If the Customer clicks the New Account button on the Login Page, the system invokes the Open Account use-case 10/12/2009© USC-CSSE

University of Southern California Center for Systems and Software Engineering If the Customer clicks the Reminder Word button on the Login Page, the system displays the reminder word stored for that Customer, in a separate dialog box. 10/12/2009© USC-CSSE

University of Southern California Center for Systems and Software Engineering When the Customer clicks the OK button, the system returns the Customer to the Login Page. 10/12/2009© USC-CSSE

University of Southern California Center for Systems and Software Engineering More on Robustness Analysis In most cases, initial design results in the realization that use-case texts are missing details, so use-case construction and initial design are iterative processes, during which both use-case texts and initial design diagrams improve iteratively until they are deemed to be adequate to go on to the next step – sequence diagram construction. In our case, however, the use-case texts are already extremely well written – in particular, they cover all/most alternate courses, the source of the largest number of problems if they aren’t done well – so we have assumed that they’re OK and have constructed initial design diagrams directly from them, i.e., without trying to improve them. You DON’T need to document this for 577ab! It is a ‘tool’ to help guide you in your system development!! 10/12/2009© USC-CSSE

University of Southern California Center for Systems and Software Engineering Next Step: Transform the Domain Model For every Interface, Boundary and Entity Object that got identified refer the Domain Model (which should have been revised a few times over by now and is relatively stable/understood!) The DM will no longer be called a ‘domain model’ henceforth – it would now be transformed into an analysis/design model The robustness analysis should give you a good idea of what classes you need to incorporate in your analysis/design model – each of the above objects should be ‘found’ in your design model! 10/12/2009© USC-CSSE

University of Southern California Center for Systems and Software Engineering Transforming the Domain Model (cont’d) The classes from the DM suggests all that the application needs to know about the business The ‘Persistent Data Classes’ (PDC) (from the artifact and information diagram) would tell you what all it is that the application needs to ‘store’ Your initial ‘Analysis Model’ would typically show associations between the DM and PDC classes (you may discover the need for additional classes or refactor existing ones!) 10/12/2009© USC-CSSE

University of Southern California Center for Systems and Software Engineering Transforming the Domain Model (cont’d) The robustness diagrams will typically show you the following: –Classes that belong to the application interface (could be simple pages or actual classes e.g., Java Swing’s JFrame etc.,) –Classes that belong to the ‘Persistent Data Classes’ – they help ‘verify’ if you captured the relevant aspects or left out in your initial analysis or if you need to refactor them –Methods (or possibly classes) that are responsible for the ‘flow of control’ to achieve the functionality put forth by the use-case description 10/12/2009© USC-CSSE

University of Southern California Center for Systems and Software Engineering Transforming the Domain Model (cont’d) Remember: There is NO MAGIC algorithm to help ‘glue’ the Domain Model, Persistent Data Classes and the Methods/Classes, identified by the Robustness Analysis, together! This comes with a lot of practice and experience (not to mention, patience!!!)– thus you have to “iterate” over this multiple times! But how do you know what methods go in which classes?? Are the ‘controller’ objects enough to help identify this? 10/12/2009© USC-CSSE

University of Southern California Center for Systems and Software Engineering Sequence Diagrams! The sequence diagrams help identify the corresponding methods that are required for each of the previously identified classes, the controller objects ‘hint’ at the possible presence of some methods We shall see this in detail in the subsequent lecture on OOA&D… …we shall now proceed into the workshop session! 10/12/2009© USC-CSSE

University of Southern California Center for Systems and Software Engineering Workshop Will help you grasp today’s concepts better Each team will ‘present’ their use-case description (only one) and we shall construct the robustness diagrams for that use-case Teams? Ready? 10/12/2009© USC-CSSE