Last updated: May. 10, 2006

Find Classes from Use-Case Behavior:

• The purpose of the Find Classes from Use-Case Behavior step is to identify a candidate set of model elements (analysis classes) that will be capable of performing the behavior described in the use case.

• During analysis activities (Use-Case Analysis), the Use-Case Realization diagrams are outlined. In subsequent design activities (Use-Case Design), these diagrams are refined and updated according to more formal class interface definitions.

• Analysis Classes: A first Step Toward Executables

• The technique for finding analysis classes described in this module uses three different perspectives of the system to drive the identification of candidate classes.

  • The boundary between the system and its actors

  • The information the system uses

  • The control logic of the system

• The use of stereotypes to represent these perspectives (for example, boundary, control, and entity) results in a more robust model because they isolate those things most likely to change in a system: the interface/environment, the control flow, and the key system entities. These stereotypes are conveniences used during Analysis that disappear in Design.

• Identification of classes means just that: They should be identified, named, and described briefly in a few sentences.

• The complete behavior of a use case has to be distributed to analysis classes.

• What Is a Boundary Class?

  • A boundary class intermediates between the interface and something outside the system. Boundary classes insulate the system from changes in the surroundings (for example, changes in interfaces to other systems and changes in user requirements), keeping these changes from affecting the rest of the system.

  • A system have several types of boundary classes:

    • User interface classes: Classes that intermediate communication with human users of the system.

    • System interface classes: Classes that intermediate communication with other systems. A boundary class that communicates with an external system is responsible for managing the dialog with the external system; it provides the interface to that system for the system being built.

    • Device interface classes: Classes that provide the interface to devices which detect external events. These boundary classes capture the responsibilities of the device or sensor.

  • One recommendation for the initial identification of boundary classes is one boundary class per actor/use-case pair.

  • The Role of a Boundary Class: A boundary class is used to model interaction between the system's surroundings and its inter workings.

  

  • Example: Finding Boundary classes

    • The RegisterForCoursesForm contains a Student's "schedule-in-progress." It displays a list of Course Offerings for the current semester from which the Student may select courses to be added to his or her Schedule.

    • The CourseCatalogSystem interfaces with the legacy system that provides the unabridged catalog of all courses offered by the university. This class replaces the Course Catalog abstraction originally identified in Architectural Analysis.

  • Guidelines: Boundary Class

    • User Interface Classes:

      • Concentrate on what information is presented to the user.

      • Do NOT concentrate on the UI details

    • System and Device Interface Classes:

      • Concentrate on what protocols must be defined

      • Do NOT concentrate on how the protocols will be implemented

    • Concentrate on the responsibilities, not the details!

• What  Is an Entity Class?

  •  Environment independent key abstractions of the system.

  

  • The Role of an Entity Class: The main responsibilities of entity classes are to store and manage information in the system.

  • Example: Finding Entity Classes

    • Use use-case flow of events as input.

    • Key abstractions of the use case.

    • Traditional, filtering nouns approach

      • Underline noun clauses in the use-case flow of events

      • Remove redundant candidates

      • Remove vague candidates

      • Remove actors (out of scope)

      • Remove implementation constructs

      • Remove attributes (save for later)

      • Remove operations

  • Example: Register for Courses (Create Schedule)

  

• What Is a Control Class?

  • Control classes provide coordinating behavior in the system. The system can perform some use cases without control classes by using just entity and boundary classes. This is particularly true for use cases that involve only the simple manipulation of stored information. More 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.

  • 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.

  • Although complex use cases may need more than one control class it is recommended, for the initial identification of control classes, that only one control class be created per use case.

  • When the system performs the use case, a control object is created. Control objects usually die when their corresponding use case has been performed.

  • Example: Finding control Classes

  

  　

• Example: Summary: Analysis Classes

  

Distribute Use-Case Behavior to classes:

• The purpose of "Distribute Use-Case Behavior to Classes" is to:

  • Express the use-case behavior in terms of collaborating analysis classes

  • Determine the responsibilities of analysis classes

• For each use-case flow of events: