Presentation on theme: "Use Case Analysis – continued"— Presentation transcript:
1 Use Case Analysis – continued Control ClassesBuilding Analysis ClassesModified considerably by your Instructor
2 Control ClassesA Control Class is a class used to model control behavior specific to one or more use cases.Control classes encapsulate use-case-specific behavior.The behavior of a control object is closely related to the realization of a specific use case.In many scenarios, you might even say that the control objects "run" the use-case realizations.Some control objects can participate in more than one use-case realization if the use-case tasks are strongly related.
3 OOADv4.2 Instructor Notes What is a Control Class?Use-case behavior coordinatorOne control class per use caseOne recommendation for the initial identification of control classes is one control class per use-case. This may be refined as a more detailed analysis is performed.Control classes are to be used to isolate use-case-specific responsibilities/behavior, not to be “do-all, be-all” classes. Control classes contain behavior that doesn’t belong in entity and boundary classes.Stress that the control classes know how to “orchestrate and delegate”. They don’t do everything, but they know the order in which things should be done. In many cases, these control classes are “designed away” in Class Design (e.g., may become methods in UI classes). In analysis, however, they allow the analyst to allocate that use-case-specific behavior and move on.<<control>>Analysis class stereotypeUse CaseUse-case dependent, Environment independentModule 7 - Use-Case Analysis
4 Control Classes – not always needed Control classes provide coordinating behavior in the system.The system sometimes can perform some use cases without control classes (just using entity and boundary classes) – particularly use cases that involve only the simple manipulation of stored information.Complex use cases generally require one or more control classes to coordinate the behavior of other objects in the system.Examples of control classes include transaction managers, resource coordinators and error handlers.
5 Control Classes decouple: Control classes effectively decouple boundary and entity objects from one another, making the system more tolerant of changes in the system boundary.They also decouple the use-case specific behavior from the entity objects, making them more reusable across use cases and systems.Reverse engineer existing GUI components??Note: we are in the initial stages of ‘design’Decoupling affects some of the non-functional requirements (that are addressed in design in considerable detail), such as maintainability, performance, reusability.Discuss: (contradictory in places…)
6 Control Class provided behavior: Is surroundings-independent (does not change when the surroundings change)Defines control logic (order between events) and transactions within a use case.Changes little if the internal structure or behavior of the entity classes changesUses or sets the contents of several entity classes, and therefore needs to coordinate the behavior of these entity classesIs not performed in the same way every time it is activated (flow of events features several states)One recommendation for the initial identification of control classes is one control class per use case.
7 The Role of a Control Class OOADv4.2 Instructor NotesThe Role of a Control ClassCoordinate the use-case behaviorCustomer<<boundary>><<control>><<entity>>Several control objects of different control classes can participate in one use case.As stated, not all use cases require a control object.Example: if the flow of events in a use case is related to one entity object,a boundary object may realize the use case in cooperation with the entity object.You can start by identifying one control class per use case realization, and then refinethis as more use-case realizations are identified and commonality is discovered.Module 7 - Use-Case Analysis
8 Role of Control ClassControl classes can contribute to understanding the system because they represent the dynamics of the system, handling the main tasks and control flows.When the system performs the use case, a control object is created. Control objects usually die when their corresponding use case has been performed.(Normally NOT persistent)
9 Example: Finding Control Classes OOADv4.2 Instructor NotesExample: Finding Control ClassesRecommend: Identify one control class per use caseCourse Catalog SystemRegister for CoursesStudent<<control>>RegistrationControllerEach control class is responsible for orchestrating/controlling the processing thatimplements the functionality described in the associated use case.Here, the RegistrationController <<control>> class has been defined to orchestratethe Register for Courses processing within the system.Module 7 - Use-Case Analysis
10 Summary of Analysis Classes: View of Participating Classes (VOPC) For each use-case realization there is one or more class diagrams depicting its participating classes, along with their relationships.These diagrams show consistency in the use-case implementation across subsystem boundaries.Such class diagrams have been called “View of Participating Classes” diagrams (VOPC, for short) – next overhead…
11 Example: Summary: Analysis Classes OOADv4.2 Instructor NotesExample: Summary: Analysis ClassesThe diagram here shows the classes participating in the Register for Courses use caseThe part-time student and full-time student classes have been omitted for brevity (theyboth inherit from Student. Class relationships will be discussed later.Note: This slide is a summary of all of the other example slides for this step.The Part-Time Student and Full-Time Student classes have been omitted from the diagram for clarity.StudentRegister for CoursesCourse Catalog SystemUse-Case ModelDesign Model (classes only listed – no relationships shown here…)<<boundary>>RegisterForCoursesForm<<control>>RegistrationController<<boundary>>CourseCatalogSystem<<entity>>Student<<entity>>Schedule<<entity>>CourseOfferingModule 7 - Use-Case Analysis
12 Use-Case Analysis Steps – Next Major Step… OOADv4.2 Instructor NotesUse-Case Analysis Steps – Next Major Step…Supplement the Use-Case DescriptionsFor each use-case realizationFind Classes from Use-Case Behavior - DONE! But nothing in them!Distribute Use-Case Behavior to ClassesNow we need to allocate responsibilities of the use cases to the analysis classes and model this allocation by describing the way the class instances collaborate to perform the use case in use-case realizations.Purpose of this task (Distributing Use Case Behavior to Classes) is to:Express the use-case behavior in terms of collaborating classes, andDetermine the responsibilities of analysis classes.For each resulting analysis class, do:Describe ResponsibilitiesDescribe Attributes and Associations (lectures ahead and following…)Qualify Analysis MechanismsModule 7 - Use-Case Analysis
13 Distribute Use-Case Behavior to Classes OOADv4.2 Instructor NotesDistribute Use-Case Behavior to ClassesFor each use-case flow of events:Identify analysis classes (Step thru flow of events)We have identified classes. Now, see where they are applied in the use case flow of events.Allocate use-case responsibilities to analysis classesModel analysis class interactions in interaction diagrams = we need to show interactions of the system with its actors.Interactions all begin with an actor, who invokes the use caseThis is where the initial use-case realizations are developed.When identifying analysis classes and allocating use-case responsibilities, keep in mind the recommendations: One control class per use case, one boundary class per actor/use-case pair.You can create an interaction diagram for each variant of a use case's flow of events.The Rational Unified Process recommends the use of Collaboration Diagrams in Analysis. This is discussed in more detail on a later slide.Business Modeling is addressed in the Rational Unified Process in the “Business Modeling” workflow.You are done with Use-Case Analysis when you have allocated all the use-case responsibilities to something (e.g., analysis classes).Sequence DiagramsCollaboration DiagramsUse CaseUse-Case RealizationModule 7 - Use-Case Analysis
14 Distributing Use Case behavior to Analysis Classes Interactions BETWEEN actors should NOT be modeled. (Can show inheritance, surrogates, etc. but no ‘interactions.’)By definition, actors are external, and are out of scope of the system being developed.Thus, you do not include interactions between actors in your system model.Let’s look at how to distribute behavior to classes:
15 Guidelines: Allocating Responsibilities to Classes OOADv4.2 Instructor NotesGuidelines: Allocating Responsibilities to ClassesThis allocation of responsibilities is crucial!Stereotypes assist in that they provide a set of canned responsibilities that we can use.Use analysis class stereotypes as a guideBoundary Classes (the Interface)Behavior that involves communication with an actorEntity Classes (Persistent Data)Behavior that involves the data encapsulated within the abstractionControl Classes (the Use Case flow of events)Behavior specific to a use case or part of a very important flow of events(continued)Module 7 - Use-Case Analysis
16 Guidelines: Allocating Responsibilities to Classes (cont.) OOADv4.2 Instructor NotesGuidelines: Allocating Responsibilities to Classes (cont.)A driving influence on where a responsibility should go is the location of the data needed to perform the operation.Who has the data needed to perform the responsibility? Design options:One class has the data, put the responsibility with the data – best case!!!Multiple classes have the data:Put the responsibility with one class and add a relationship to the other (a dependency relationship)Create a new class, put the responsibility in the new class, and add relationships to classes needed to perform the responsibilityPut the responsibility in the control class, and add relationships to classes needed to perform the responsibilityModule 7 - Use-Case Analysis
17 Guidelines: Allocating Responsibilities to Classes (cont.) Be careful when adding relationships -- all relationships should be consistent with the abstractions they connect.Don’t just add relationships to support the implementation without considering the overall affect on the model.When a new behavior is identified, check to see if there is an existing class that has similar responsibilities, reusing classes where possible.Only when sure that there is not an existing object that can perform the behavior should you create new classes.