OO Development 5 - Analysis

  • 11,551 views
Uploaded on

Course material from my Object-Oriented Development course.This presentation covers the analysis phases and focuses on class discovery, domain modeling, activity diagrams, and sequence diagrams.

Course material from my Object-Oriented Development course.This presentation covers the analysis phases and focuses on class discovery, domain modeling, activity diagrams, and sequence diagrams.

More in: Technology , Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
  • thanks and very useful for us....
    Are you sure you want to
    Your message goes here
  • This is very useful. I take it there are other presentations available on the toic...are they shared as well on this site?
    Are you sure you want to
    Your message goes here
  • analysis
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
11,551
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
371
Comments
3
Likes
8

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. 5 ANALYSIS Examining the analysis workflow
  • 2. 1 INTRODUCTION 2 METHODOLOGIES 3 MODELS AND UML 4 OBJECT CONCEPTS 5 ANALYSIS2 6 SOFTWARE DESIGN
  • 3. Our Process3  Reminder of object-oriented development process we are following in this course is that there are four phases:  Inception  Elaboration  Construction  Transition  Each phase consists of one or more iterations of the following workflows:  Requirements  Analysis  Design  Implementation  Test  In this section, we are going to examine the analysis workflow principally in the context of the Elaboration phase.
  • 4. Analysis Workflow4  In the requirements workflow, use case model and other artifacts (screen prototypes, glossary, etc) are used to build an initial model based on the users’ requirements.  In the analysis workflow, the requirements are analyzed in more detail, so as to begin the description of the internal structure and behavior of the proposed system. Use Case Realizations Use Case Model message() Glossary Prototypes message2() Requirements Model Analysis Model
  • 5. Analysis versus Design5  The boundary between analysis and design can be quite vague; they often overlap.  Rules of thumb for analysis modeling:  Analysis model is always in the language of the business  Concentrate on capturing the big picture (don’t get bogged down in details).  Focus on the problem domain (business requirements), not the solution domain (detailed design considerations).  e.g., don’t worry about implementation classes such as database access or user interface classes.  Keep the model simple. Source: Arlow and Neustadt, UML and the Unified Process (Addison-Wesley, 2002), p. 101.
  • 6. Analysis Model6  The aim of the analysis workflow is to produce an analysis model.  This is a logical model that is technology- independent (i.e., unconcerned with how it is to be implemented).  Itallows developers to focus on the problems to be solved.  Ignoring technology makes it less likely that old ways of doing things will be carried forward into the design of the new system.
  • 7. Analysis is Use Case Driven7  The use cases defined in the requirements model are the basis for the entire analysis and design workflows. Use Case Realizations message() message2() Use Case Model Analysis and Design Models
  • 8. Use Case Realizations8  Use cases are realized in subsequent analysis and design.  That is, use-case realizations describe how a use-case is performed ("realized") in terms of interacting objects in the design model (that is, in terms of how objects collaborate).  Use case realizations tie together the use cases with the classes and relationships of the domain model.  That is, a use case realization specifies which classes must be built to implement each use case.  Development of use case realizations is the main goal of analysis; refining these use case realizations is the main goal of design. Use Case realizations show «realize» how classes PlaceOrder PlaceOrder collaborate to realize system functionality Source: Object-Oriented Analysis with UML (Rational Software Corporation, 2001), p. 3-18.
  • 9. Use Case Realizations9  Use case realizations consists of the following elements:  Analysis class diagrams  Show the analysis classes that interact to realize the use case  Interaction diagrams  Show collaborations and interactions between objects that realize the use case.  Use Case refinement  New info may be discovered that requires the original use case to be updated.  Activity diagrams may be used to illustrate scenarios in the use case.  Use case realization is a process of refinement.  Take a use case and then model how the behavior specified in the use case will be realized by collaborations and interactions between instances of domain classes you have identified. Source: Arlow and Neustadt, UML and the Unified Process (Addison-Wesley, 2002), p. 200-1.
  • 10. Analysis Model10  The two key artifacts are produced in analysis model:  Use case realizations  These illustrate how instances of the analysis classes can interact to realize system behavior specified by a use case.  Analysis class diagram  Integrates the classes discovered in the use case realizations into a single diagram that shows methods and attributes uncovered in the realizations.
  • 11. Analysis Class11  Analysis classes are classes that:  Representa clear and concise abstraction in the problem domain.  i.e., these classes represent the real-world things and concepts related to the problem the system is being design to solve.  Should map directly onto real-world business concepts.  Should NOT be concerned with design considerations such as performance, patterns, best practices, etc.  Also referred to as domain classes.
  • 12. Finding Classes12  There is no simple algorithm for finding the right analysis classes.  Yet, there are techniques which can help you discover these classes. They are:  Noun/verb analysis  CRC analysis Source: Meyer, Object Oriented Software Construction (Prentice Hall, 1997), p. Source: Arlow and Neustadt, UML and the Unified Process (Addison-Wesley, 2002), p. 134-5.
  • 13. Discovering Domain Classes13  The best source for discovering these basic classes is a high-level (100-300 words) problem statement or system definition.  Ifyou dont have this system definition, then you will have to write one, in conjunction with the client/users.  You can also use other requirements model artifacts as sources of information, in particular:  the use case model  the glossary of terms.
  • 14. Noun/verb analysis14  You can use the grammatical inspection technique of circling/highlighting/underling all the noun and noun phrases (compound nouns or adjective+noun) in the text.  This is sometimes called noun phrase identification.  You will probably find that:  noun and noun phrases become classes and attributes  verbs and verb phrases become methods and relations  possessive phrases indicate nouns should be attributes rather than classes.
  • 15. Step 1. Noun Phrase Identification15 The Portfolio Manager shall be able to roll up portfolios on several levels. A Trader shall be able to place orders, on behalf of a portfolio, that generate one or more trades. A Portfolio Manager shall be able to select a pairoff method in conjunction with placing a sell order. The entry of a trade shall generate forecasted cashflows associated with the given trade lot. The system shall match up actual cashflows with forecasted cashflows. The system shall automatically generate appropriate postings to the General Ledger. The system shall allow an Assistant Trader to modify trade data and propagate the results accordingly. Identify the nouns and noun phrases in this example system definition. Source: Doug Rosenberg, Use Case Driven Object Modeling with UML (Addison Wesley, 1999), p. 18
  • 16. Noun Phrase Identification16 The Portfolio Manager shall be able to roll up portfolios on several levels. A Trader shall be able to place orders, on behalf of a portfolio, that generate one or more trades. A Portfolio Manager shall be able to select a pairoff method in conjunction with placing a sell order. The entry of a trade shall generate forecasted cashflows associated with the given trade lot. The system shall match up actual cashflows with forecasted cashflows. The system shall automatically generate appropriate postings to the General Ledger. The system shall allow an Assistant Trader to modify trade data and propagate the results accordingly. Identify the nouns and noun phrases in this example system definition. Source: Doug Rosenberg, Use Case Driven Object Modeling with UML (Addison Wesley, 1999), p. 18
  • 17. Step 2. Noun Phrase17 Consolidation  After identifying nouns and noun phrases,  make plural terms singular  eliminate duplicate terms  consolidate synonyms into single term  place list in alphabetic order
  • 18. Noun Phrase Consolidation18 actual cashflow order sell order Assistant Trader pairoff method system entry portfolio trade forecasted cashflow Portfolio Manager trade data General Ledger posting trade lot level results Trader After the consolidating noun phrases
  • 19. Step 3. Noun Phrase Analysis19  Now, remove:  references to the system itself or to its context  nouns which appear out of the scope of the project  nouns which are too vague  nouns which represent actions.  Actors might be removed from our list of candidate classes, and placed instead on the use case diagrams. actual cashflow order sell order Assistant Trader pairoff method system entry portfolio trade forecasted cashflow Portfolio Manager trade data General Ledger posting trade lot level results Trader Analyze the list
  • 20. Noun Phrase Analysis20 actual cashflow order sell order Assistant Trader pairoff method system entry portfolio trade forecasted cashflow Portfolio Manager trade data General Ledger posting trade lot level results Trader actors actions out of the scope of the project too vague
  • 21. Step 4. Draw Initial Analysis Class Model21  If you can, draw an initial analysis class model showing just class names, generalizations, associations, and aggregation.  At this stage, dont worry especially about multiplicity or composition, since further analysis is often required to address questions about multiplicity and composition.  The classes in your analysis class model are sometimes referred to as entity classes.  Just as noun phrase analysis helped identify candidate classes, verb phrase analysis can help identify class relationships.  The result can be a table showing each candidate associations with your candidate classes.  e.g., Student enrolls in Course Professor teaches Course
  • 22. CRC Cards22  Another way of discovering your analysis classes is to use CRC (Class Responsibility Collaboration) cards.  CRC cards are often used within a team to brainstorm the allocation of responsibilities to domain classes as well as for the discovery of relationship for domain classes. Class Name: Class name here Responsibilities Collaborations Responsibilities of a class Collaborations with other are listed in this section. classes are listed here, together with a brief description of the purpose of the collaboration.
  • 23. CRC Cards Class Name Client23 Responsibilities Collaborations Provide client information. Provide list of Campaign provides campaigns. campaign details. Class Name Campaign Responsibilities Collaborations Provide campaign information. Provide list of adverts. Advert provides advert details. Add a new advert. Advert constructs new object. Class Name Advert Responsibilities Collaborations Provide advert details. Construct adverts. Source: Bennett, McRobb, and Farmer, Object-Oriented Systems Analysis and Design (McGraw Hill, 2002), p. 193.
  • 24. Digression on UML Class & Object Notation24 Customer Customer Customer Name compartment m_name m_name m_address m_phone m_address Attribute compartment m_phone getName() getPhone() Operation compartment «entity» stereotype Customer fred:Customer fred:Customer m_name=Randy m_address=123 Any Ave Objects m_phone=123-4567
  • 25. UML Attribute Compartment25 visibility name multiplicity: type=initialValue optional mandatory optional Customer -m_name -m_address -m_phone: String -m_age:int=0 +Children[] #salary +numCustomers static attribute + public visibility - private visibility # protected visibility
  • 26. UML Operation Compartment26 visibility name ( parameterName: parameterType, ...): returnType optional mandatory optional optional Customer m_name m_address m_phone numCustomers getName() Customer getPhone(): String setName(name: String) setPhone(phone: String): void Customer() getNumCustomers(): int Customer(name: String) constructors Note: at the analysis level, you should not be worried about details like constructors, parameters, data types, etc. These will show up in the design stage.
  • 27. Reflexive Associations27  A reflexive association is one in which a class has an association with itself.  This means that a class has links to other objects of the same class. -subfolder 0..* Directory File 1 0..* -parent 1 Directory -m_parent[1] : Directory -m_subfolders[0..*] : Directory Source: Arlow and Neustadt, UML and the Unified Process (Addison-Wesley, 2002), p. 152.
  • 28. Navigability28  Navigability refers to ability to traverse from object of one class to an object of another class.  Means messages can only be sent in the direction of the arrow. Thus, a Product not navigable object does not 1 * contain an Order link, Order Product but an Order object does contain a collection of Product navigable links. 1 * If no arrows, then Order Product the relationship is bidirectional. Source: Arlow and Neustadt, UML and the Unified Process (Addison-Wesley, 2002), p. 154-5.
  • 29. Dependency29  A dependency is a relationship between two elements where a change in one, affects the other.  Typically used to indicate that one class uses another, but the usage is not really an association.  Dependencies generated (in class diagrams) by:  An operation of class A needs a parameter of class B  An operation of class A returns a value of class B  An operation of class A uses an object of class B somewhere in its implementation, but not as an attribute. A B +someMethod(in value : B) +otherMethod() : B +doSomething() void doSomething() { ... B myB = new B(); // use myB in some way ... } Source: Arlow and Neustadt, UML and the Unified Process (Addison-Wesley, 2002), p. 162-3.
  • 30. Scenarios30  The process of realization often begins by looking at use case scenarios.  A scenario is an instance of a use case.  It is one flow through a use case  It is some combination of basic and alternate flows.  "this happened, then this, then this …"  Some people even write scenarios first, then write the use cases.  Written scenarios can also be a way of documenting test behaviors for the testing phase.
  • 31. Scenarios31  Ways of describing (not realizing) scenarios:  using textual descriptions  using activity diagrams
  • 32. Activity Diagram32  Scenarios can be graphically described by using an activity diagram.  These diagrams are the UML equivalent of a flow chart.  They visually capture the step-by-step flow of a typical use case description.  Are also used in business process modeling  This is a preliminary requirements step in some methodologies. It is used to help the analysts better understand how a business operates.  Not as useful for illustrating message communication between objects (we will use interaction diagrams for that).
  • 33. Activity Diagrams33  This diagram shows:  action states, which represent the execution of a step within the flow of a use case.  Transitions between those action states  decisions for which guard conditions are defined  forks, where flow of control is split into two or more concurrent flows  joins, where separate flows are joined.
  • 34. action join state Check Schedule Select Course Check Pre- guard requisites expression initial state fork [checks completed] [checks failed] Assign to Resolve Course Conflicts [student added to the course] Update Schedule34
  • 35. Exercise35  Draw the activity diagram for the following use case scenario: Use Case: Place Order Step 1. Enter the order (includes getting info about order and payment method from customer) Step 2. Authorize the purchase (requires verification that the requirement funds can be obtained from customer using the specified payment method). Step 3. Allocate the order items from the inventory. Step 4. Ship the order. Source: Charles Richter, Designing Flexible Object-Oriented Systems with UML (Macmillan, 1999), p. 27.
  • 36. Exercise36 [pending] Enter Order [aborted] [approved] Authorize Purchase Allocate Order Items Ship Order [declined] «trace» This activity diagram is a Place Order refinement of the use case [pending] Enter Order [aborted] [approved] Authorize Purchase Allocate Order Items Ship Order [declined]
  • 37. Exercise37  Draw the activity diagram for the following use case scenario: Use Case: Cancel Order Item Step 1. Update that order item (check to see if the item is still pending, and if so, change its status to cancelled. Step 2. Credit the customers account for that item. Step 3. Release the inventory request for that item. Note: Steps two and three can happen in either order (or concurrently).
  • 38. Exercise38 Cancel Order Item [not pending] Update Order Item Credit Account [pending] Release Inventory
  • 39. Interaction Diagrams39  Interaction diagrams are a graphical representation of how objects communicate with one another in a scenario.  Static diagrams such as the class diagram and the use case diagram contain no dynamic or temporal information.  It can be quite difficult proceeding from initial static class model to designing and implementing behaviors necessary for an application.  Interaction diagrams help with this task.  Interaction diagrams are a vital part of realizing a use case (along with the class diagram).  They model the collaborations and interactions between the objects that realize a use case.
  • 40. Interaction Diagrams40  Two types  Collaboration diagrams  Emphasize structural relationships between objects.  Sequence diagrams  Emphasize the time-ordered sequence of messages sent between objects.  Both diagrams are two different representations of the same thing (i.e., the object interactions).  Thusa collaboration diagram can be converted to a sequence diagram, and vice-versa.
  • 41. Interaction Diagrams41  In these diagrams, focus is on communication between objects, not classes. Student fred fred : Student : Student class objects
  • 42. Messages42  How do objects communicate?  By sending messages (i.e., invoking a method).  A message is thus a communication between two objects (or within one) what results in some activity.  This activity usually involves one or more actions.  Actions are executable statements that change values of the attributes of an object or return a value.  Are calls to an objects methods or properties  We will make use of two actions:  Call  Return Source: Kendall Scott, UML Explained (Addison-Wesley, 2001), p. 59-62.
  • 43. UML Actions: Call and Return43 Object1 : Customer Object2 : Order action name() other action call() call action notation Object1 : Customer action name() : Customer : Order Object2 : Order action name() return value return action notation
  • 44. Call and Return Example44 : Order : Shipper calcShippingCost() lookupCost() shipping cost : Order : Shipper calcShippingCost("BC", 30) lookupZone("BC") return(15.50)
  • 45. Sequence Diagram45  A sequence diagram focuses on the time ordering of the messages.  Objects appear along the top margin, with each object having a lifeline, with an optional flow of control on the rectangle.
  • 46. Sequence Diagram Example46 :Home Page :Login Page :UserAccount : Customer clickLogin() lifeline displayLogin() enterUserID() validateLogin() login okay Focus of control displayLoginOkay()
  • 47. Collaboration Diagram47  A collaboration diagram is spatially oriented with an emphasis on the relationships between objects.  Similar to sequence diagram, except no lifeline and focus of control.
  • 48. Collaboration Diagram Example48 1: clickLogin() :Home Page : Customer 3: enterUserID() 2: displayLogin() 5: displayLoginOk() :UserAccount :Login Page 4: validateLogin()
  • 49. Collaboration vs Sequence49 Diagrams  Collaboration Diagrams  Shows relationships and interactions  Better for visualizing all of the effects on a given object  Easier to use/draw for brainstorming  Sequence Diagrams  Explicitlyshows time ordering of messages  Better for visualizing overall flow in real-time systems and complex scenarios.
  • 50. Analysis Class Model50  This is the final artifact of the analysis.  This is a revised class diagram that includes all the responsibilities (operations) and attributes for all classes discovered via the use case realizations.  You interaction diagrams indicate via the messages what should be the operations and attributes you need to add to your classes.  Remember that this is an iterative and incremental process.  The class diagram and the interaction diagrams will be modified repeatedly and in tandem as you work your work through the analysis.
  • 51. Analysis in Context51 message() « » « » realized by message2() « » « » Analysis Model refined by implemented by message() message2() Design Model Implementation Model
  • 52. Analysis in the big picture52  Recall that in the Unified Software Development Process, there are four phases; in each phase there is a analysis workflow.  What is produced during the analysis workflow varies from phase to phase.  Nonetheless,most of the analysis will occur in the elaboration phase. Inception 1 2 El aborati on 3 4 Construction 5 6 7 Transiti on 8 Requirem ents Anal y s is Des i gn Implement ation T es t
  • 53. Analysis in the phases53  Inception Phase  CRC sessions, noun phrase analysis to create domain model  Elaboration Phase  Use case realizations  Analysis class model  Construction Phase  Additionaluse case realizations for any newly discovered use cases.