Supplementary Information on Analysis Modeling

1. Supplementary Information on Analysis Modeling Taken from: Use Case Driven Object Modeling with UML – A Practical Approach by Doug Rosenberg Much of these materials is taken word by word or paraphrased. This is a good book to have in your library on OOSE!

2. 1. Introduction to Robust Analysis • Comes from analyzing the narrative text of each use case and identifying a first-guess set of objects that participate in the Use Cases, and then classifying them as one of three types of objects: • Boundary Objects – which actors use in communicating with the system • Entity Objects – which are usually objects from the domain model • Control Objects – which serve as the glue between boundary objects and control objects.

3. Introduction – continued • Used to call boundary objects – interface objects, but conflicts with Java and COM… • Analysis modeling is critical link between the what (use cases) and the how (interaction diagrams) • Not considered a part of UML – proper • Will use stereotypes to define these objects – as they behave in ways that UML doesn’t formally define. • Many do not use this type of Preliminary Design. But it is so critical.

4. 2. Key Roles in Robust Analysis • Sanity Check – helps to ensure your use case text is correct and that you have not specified behavior that are unreasonable or impossible. • Completeness Check – helps to ensure that your use cases address ALL the necessary alternate courses of action. • Ongoing Discovery of Objects – You may have missed some during domain modeling. • Preliminary Design – first step in bridging gap between analysis and design.

5. 2A. Sanity Check • Replace generic nouns in use case text with proper names of objects that appear in your analysis diagram. • Can be done in parallel with writing Use Case text.

6. 2B. Completeness Check • Iterating through your use cases helps produce use case text that adheres to well-defined guidelines, such as that actors should be connected ONLY to boundary objects. • Can refer to GUI objects (common form of boundary objedcts) by name and describe how the actors use each element. • Leads to identification of various windows or screens ‘by name’ – useful for later activities. • Will greatly assist in creation of Sequence Diagrams!! • Skipping this step makes you run the risk of not discovering all the objects you may need!

7. 2B. Completeness Check • Control objects occasionally end up as objects in the static model, but more often, you may end up converting them into operations on entity objects and/or boundary objects. • This means that you can use your sequence diagrams to get the designers focused on doing a very clean allocation of behavior (deciding which methods belong to which objects). • Key here is to identify these behaviors as part of this analysis. (use case analysis, robust analysis, preliminary design, or whatever you wish to term it).

8. 2C. Object Identification • Identify the correct ‘names’ for objects. • Heuristic: use the names from domain model for your entity objects. • Build an ‘object glossary’ • First look in the domain model • May identify missing objects in our domain model. • Continuous refinement of Domain Model! • Very helpful to have a near complete set of entity objects (domain classes) before the first sequence diagram is developed, because allocating behaviors across an incomplete set of objects is likely to be messy (that is, more rework and more rework …translates into missed schedules….)

9. 2D. Preliminary Design • Sequence Diagrams capture the dynamics of communicating objects (with responsibilities) that shows the ‘how’ (implementation) of your application – just above the coding activity. • Spending time on these analysis diagrams is a useful investment of time – but not too much time... • “Looking down the road at partitioning, the Boundary-Entity-Control trio maps well to the Model-View-Controller construct that comes from Smalltalk, and it also lends itself handsomely to traditional client/server implementation in the form of GUI-Repository-Logic.”

10. Warning • It is likely that some of the work products of this analysis will be thrown away later… • This concept of a throwaway artifact is useful in connection with preliminary design; not useful when it comes to detail design. • Sequence Diagrams (and collaboration diagrams) are examples of detail design). • Don’t try to do detail design on these analysis model diagrams. Merely identify objects, attributes, and general responsibilities…. Detail design will address details such as parameters….loops, etc.

11. 3. Most About Analysis Object Types • Boundary Objects – objects in the new system with which the actors (users) will be interacting. • Usually screen,s windows, dialogs, and menus • The PROTOTYPE will provide many of your primary boundary objects… • Validation with boundary objects – includes any kind of initial checking…. • For NOW, these should take the form of Control Objects associated with the Boundary Objects.

12. 3. Most About Analysis Object Types • Some boundary objects are needed in addressing alternate courses of actions within use cases, such as warnings or error dialog boxes that might appear separate from entry window… • Initially, start with a single boundary class that serves as a placeholder for the interface. You may likely have more boundary classes constituting the interface or reverse engineer some existing GUI. For now, a single boundary class is a placeholder… • CHECK AGAIN: DO YOU HAVE all the required behaviors identified?

13. 3. Most About Analysis Object Types • Entity Objects – often map to database tables and files that outlive the use case execution. • Many entity objects first come from Domain Model. • Kind of like ‘dumb servers’ – store, fetch, and perform fundamental kinds of computations.

14. 3. Most About Analysis Object Types • Control Objects – ‘controllers’ embody much of the application’s ‘logic.’. • Serve to connect the users and stored data. • Here is where we capture business rules and policies. • Can thus localize change w/o changing the user interface or database schema down the line. • Unlike boundary and entity objects, control objects are not meant to ‘endure’ as stand alone classes. • Likely that control classes will convert into methods associated with interface objects or entity objects. • Control objects serve as placeholders to ensure you don’t miss any functionality and system behavior required by the user cases.

15. 4. Developing the Analysis • Should normally have between two and five controllers per average use case. • If you have one controller, you likely have too many small use cases; too many? Split up. • NOTE: Arrows connecting these analysis objects do NOT represent software messages; rather, they imply logical associations. • Note also, we will NOT code from these. So focus is on logical flow of the use case. • Sequence diagrams will address the dynamics…

16. 4. Developing the Analysis • Capturing the Essence of analysis modeling: • Actors can talk only to boundary objects • Boundary objects can talk only to controllers and actors • Entity objects can also talk only to controllers (and other entity objects) • Controllers can talk to both boundary objects and controllers, but not to actors. • Recognize that Use Cases (and prototypes) are our best source for boundary objects. The text is a rich source of Entity objects, which we will associate with our Domain Model (and update it too). • We will also be able to identify some controllers…

17. 4. Developing the Analysis Model •  Very Likely that in going through the Use Case text, you will identify other boundary objects and some additional controls needed. May also very likely identify additional entity objects, such as lists, tables, etc. •  Very Likely may become attributes later and control objects identified here for expediency may become methods later…. •  Very Essential that you rewrite the Use Case after identifying these additional entity objects!!!

18. 4. Developing the Analysis Model • Strongly urge a robust Peer Review take place to review ALL your Use Cases and the analysis diagrams. Each reviewer should be able to do the following for each use case: • 1. Read the Course of Action • 2. Trace his/her finger along the associations on the analysis model • 3. See the clear match between text and diagram! • We are NOT DONE with writing a Use Case until you can pass this simple test!!!! • When we have reached this point for the entire set of use cases, the next step – developing the Sequence Diagrams – will be much easier than if you started from Use Cases alone!

19. 5. Updating the Domain (Static) Model • MUST update the Domain Model prior to moving onto detail design. • Recall: We are continuously refining the static model (domain model). • New objects were likely discovered while developing the analysis class diagrams. • Add these to the domain model NOW not later. • Also, you may add some key attributes to the more significant classes in this model too.

20. 5. Updating the Domain (Static) Model • We have usually found more entity objects • Add to Domain Model. • As we introduce windows and screens – in the form of boundary objects – we begin to trace data associated with those objects back to the entity objects from which the data comes/goes. • Result: additional attributes added to classes in domain model. • We have now itemized all the required behaviors of the use cases in the form of Control Objects. • Have identified all logical functions that must occur

21. Last Thoughts (1 of 2) • Analysis Modeling is a tool that helps us discover objects, allocate attributes, and check the use case text for completeness and correctness. • It is not an ‘end’ product. It is used to GET to the end. So: • Don’t waste a lot of time perfecting the analysis diagrams….

22. Last Thoughts (2 of 2) • So, we have performed our robustness analysis. For each use case we have identified a first cut of objects that accomplish the stated scenario. We have used the stereotypes to model. • We have updated the Domain Model class diagram to reflect new objects and additional attributes as discovered. • We are done with the Analysis Phase of the Project. • Milestone: Preliminary Design Review.

23. Top 10 Benefits of Robustness Analysis (Preliminary Design) • 10. forces you to write use cases using a consistent style • 9. forces you to write your use cases in correct voice • 8. provides sanity and completeness checks for use cases • 7. allows you to apply syntax rules – actors only talk to boundary objects, …. • 6. These diagrams are quicker to draw and easier to read than sequence diagrams • Serve to ‘bridge the gap’ between Use Cases and design (Use Case Realizations)

24. Top 10 Benefits of Robustness Analysis • 5. Helps to partition objects within the Model-View-Controller paradigm • 4. helps to layer objects in a GUI-Logic-Repository framework for client/server systems. • 3. Allows a reuse pass across all your use cases before you begin design • 2. provides traceability between what the system does (use case) and how the system works (sequence diagrams) using a conceptual object view. • 1. Plugs the semantic gap between analysis (use cases) and design (sequence diagrams).