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 • Non-functional requirements are not taken into account • Concentrate on finding class attributes and relationships

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? 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 • TransactionsDialog from homework 2 • System / Device interface classes • Concentrate on what protocols must be defined. Don’t concentrate on how the protocols are implemented

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 • AccountTransactionsController (from homework 2)

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 its analysis classes • Entity classes in particular • 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 customer • Focus on enhancing current flow with internal details that realize the external behavior

14. Identifying Classes • Classes may be hidden in: • Requirements document • (Augmented) Use case model • Stakeholder’s Request • Problem domain • Any project documentation

15. Identifying Classes (cont.) • Boundary classes • There should be at least one boundary class for each actor / use-case pair • 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. Noun elimination • 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. Noun elimination (cont.) • Roles • Some nouns are roles of objects involved in associations rather than classes • Example: “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 analysis classes, but rather as attributes: “Request”, “Opinion” • May correspond to classes in later design stages

19. Finding class attributes • Properties or characteristics of identified classes • Information retained by identified classes • Atomic • 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 associations 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. 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

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

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

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

26. Eliminate attributes and 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

27. Eliminate attributes and 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

28. Eliminate abstract nouns Traffic report User Confirmation TVRS Offender Details Form Offender Policeman Traffic policeman Violation

29. Eliminate abstract nouns Traffic report User Confirmation TVRS Offender Details Form Offender Policeman Traffic policeman Violation

30. Entity classes (partial) • Traffic report • User • TVRS • Offender Details Form • Offender • Policeman • Traffic policeman • Violation • … 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.

31. Boundary classes • ReportDetailsForm • PolicemanDetailsForm • LookupReportForm • ConfirmationDialog • OffendersDBProxy • PolicemanDBProxy • ... A database proxy provides a high-level API and encapsulates communication and query language details

32. Control classes • AddReportController • RemoveReportController • LookupReportController • EditReportController • AuthenticationController • ...

33. TrafficReport Offender 1 issues * TrafficPoliceman 1..* 1 id : long name : String description : String id : long occuredAt : Date reports of 1..* Policeman Violation id : long name : String id : long rank : int description : String <<abstract>> Analysis classes diagram I

34. Analysis classes diagram II