Finding Analysis Classes

1. Finding Analysis Classes Written by Zvika Gutterman Adam Carmi

2. Agenda • Objective • What are Analysis Classes? • Types of Analysis Classes • Boundary classes • Entity classes • Control classes • Finding Analysis Classes • Example: TVRS Analysis Classes

3. Objective • Identify a candidate set of (analysis) classes which are capable of performing the behavior described in the use cases. • The complete behavior of a use case has to be distributed to analysis classes.

4. What are analysis classes? • The technique for finding analysis classes uses three different perspectives of the system: • The boundary between the system and its actors. • The information the system uses. • The control logic of the system.

5. <<boundary>> <<entity>> <<control>> What are analysis classes? (cont.) A stereotype defines a new model element in terms of another model element. = = =

6. <<boundary>> <<boundary>> <<entity>> <<control>> <<entity>> <<boundary>> Actor1 Actor2 Types of Analysis Classes Coordinates the use case behavior Model interaction between the system and its environment Store and manage information in the system

7. Boundary Classes • Models the interaction between the system’s surroundings and its inner workings • User interface classes • Concentrate on what information is presented to the user. Don’t concentrate on user interface details. • Example: ViolationsDialog • System / Device interface classes • Concentrate on what protocols must be defined. Don’t concentrate on how the protocols are implemented. • Example: OffendersDBProxy

8. Boundary Classes (cont.) • Boundary classes are environment dependent: • UI dependent • Communication protocol dependent.

9. Entity Classes • Models the key concepts of the system. • Usually models information that is persistent. • Contains the logic that solves the system problem. • Is environment independent. • Can be used in multiple use cases.

10. Control Classes • Controls and coordinates the behavior of a use case. • Delegates the work of the use case to classes. • A control class should tell other classes to do something and should never do anything except for directing. • Control classes decouple boundary and entity classes. • Often, there is one control class per use case.

11. Control Classes (cont.) • Use case and environment dependent • Example: • ViolationsController

12. Finding Analysis Classes • For each use case: • Supplement the use case description. • Identify Boundary, Entity and Control classes. • For each class identified • Find attributes • Find relationships • Validate model, repeat process if necessary.

13. Supplement Use Case description • The description of each use case is not always sufficient for finding analysis classes and their objects. • Capture additional information needed in order to understand the required internal behavior of the system that may be missing from the use-case description written for the costumer. • Focus on enhancing current flow with internal details that realize the external behavior.

14. Identifying Classes • Classes may be hidden in: • Requirements document • Use case model • Stakeholder’s Request • Problem domain • Any project documentation • Boundary classes • There should be at least one boundary class for each actor / use-case pair.

15. Identifying Classes (Cont.) • Control classes • Often, there is one control class per use case. • If two control classes are similar, their corresponding use cases may need to be merged. • Example: “manage traffic report” may replace “edit/add/remove traffic report” use cases.

16. Identifying Classes (cont.) • Entity Classes • Identified by examining the nouns and noun phrases in problem description, requirements document, use cases and other documentation. • Nouns found may be: • Objects • Description of an object’s state (attributes) • Actors • None of the above

17. Identifying Classes (Cont.) • Some of the potential classes can be eliminated: • Duplicate classes • Differ only in name: “System”, “TVRS”... • Irrelevant classes • Classes that have nothing to do with the system (solution): “police headquarters”... • Attributes / Operations • Some nouns are likely to be modeled as attributes or operations rather than classes: “ID”, “name”, “Report Lookup”...

18. Identifying Classes (Cont.) • Roles • Some nouns are roles of objects involved in associations rather than classes: “Teaching Assistant” and “Student” may be different roles of a “Person” class. • Abstract nouns • “Identify ideas or quantities that have no physical existence” • Rarely end up corresponding to classes, but rather as attributes: “Request”, “Opinion”

19. Finding Class Attributes • Properties or characteristics of identified classes. • Information retained by identified classes. • Nouns that did not become classes. • Information whose value is important for the solution. • Information that is uniquely owned by an object.

20. Finding Relationships • Associations often correspond to verbs or verb phrases. • Physical locations: next to, above, inside... • Direct actions: drives, creates, manages... • Communication: talks to, listens, notifies... • Ownership: has, part of, belongs to, contained... • Others: works for, married to, studies at... • Eliminate associations that don’t relate to the problem / solution • More association may be discovered using interaction diagrams (introduced later...).

21. Example: TVRS Analysis Classes • Partial noun list from TVRS requirements and use cases (Entity classes candidates): Traffic report Supervisor Report lookup Confirmation TVRS Offender Details Form Traffic report addition System Offender Policeman Vehicle number License number Fault Traffic policeman Commander Violation ID Password Police headquarters Shutdown Date Speed Traffic Violation Clerk

22. Example: TVRS Analysis Classes (cont.) • Eliminate duplicate classes: Traffic report Supervisor Report lookup Confirmation TVRS Offender Details Form Traffic report addition System Offender Policeman Vehicle number License number Fault Traffic policeman Commander Violation ID Password Police headquarters Shutdown Date Speed Traffic Violation Clerk Clerk and Supervisor are replaced by User

23. Example: TVRS Analysis Classes (cont.) • Eliminate irrelevant classes Traffic report User Report lookup Confirmation TVRS Offender Details Form Traffic report addition Offender Policeman Vehicle number License number Traffic policeman Commander Violation ID Password Police headquarters Shutdown Date Speed

24. Example: TVRS Analysis Classes (cont.) • Eliminate attributes / operations Traffic report User Report lookup Confirmation TVRS Offender Details Form Traffic report addition Offender Policeman Vehicle number License number Traffic policeman Commander Violation ID Password Shutdown Date Speed

25. Example: TVRS Analysis Classes (cont.) • Eliminate abstract nouns Traffic report User Confirmation TVRS Offender Details Form Offender Policeman Traffic policeman Violation Date

26. Example: TVRS Analysis Classes (cont.) • Final class list (partial) Traffic report User TVRS Offender Details Form Offender Policeman TrafficPoliceman Violation Date The remaining list will often contain classes that are not entity classes, such as “Offender Details Form”. Boundary and control classes are easier to find by analyzing use cases directly.

27. Example: TVRS Analysis Classes (cont.) • Boundary Classes • ReportDetailsForm • PolicemanDetailsForm • LookupReportForm • ConfirmationDialog • OffendersDBProxy • PolicemanDBProxy • ... A Database proxy, provides a friendly interface and encapsulated the details of communication with the actual database.

28. Example: TVRS Analysis Classes (cont.) • Control Classes • AddReportController • RemoveReportController • LookupReportController • EditReportController • AuthenticationController • ...

29. Example: TVRS Analysis Classes (cont.)

30. Example: TVRS Analysis Classes (cont.)