Phase 2 - Analysis

• Tasks
• Tips

The goal in this phase is to produce first version of the class diagram, provide descriptions of the domain classes, and sketch the collaborations between classes using high-level collaboration or robustness diagrams.

Tasks

1. Draw analysis class diagram of the classes in the domain (i.e. a domain model - boundary and control classes do not need to be marked to the class diagram at this phase) containing at least the most important attributes and realation between classes.
2. Draw a high-level collaboration diagram (UML- or ICONIX-style) for each use case selected for more detailed modeling (2-4 diagrams, depending on project size). Collaboration diagrams should reflect use cases, focusing on the classes found in the use case descriptions. The steps in colleboration diagrams do not need to be numbered.
3. Write short descriptions of the most essential (i.e. non-trivial) classes and attributes as a data dictionary.
   

Tips

• Example process for modeling classes (see also: Bennett, Chapter 7)
  
• 1. Identify classes
     • review the use cases and domain description, seek potential classes and evaluate their suitability
       
     • model the domain classes - analysis class diagram should reflect the general business domain where the system is supposed to work - not technical details yet.
  2. Identify associations
     • think about the possible structural relations between the classes
     • represent the relations as associations if possible
     • use other relations (generalization, aggregation, composition) when needed
       
     • add cardinalities
     • check the result
       
  3. Identify attributes
     • consider about the attributes essential to the domain and system to be developed - i.e. what the objects "need to know" and what kind of information they should communicate to other objects
  4. Reorganize (or refactor) classes
     • Iterate! Find about additional generalization structures, attributes, methods... Try to simplify the diagram without losing any essential information
       
• Example process for high-level collaboration/robustness diagrams (note: ICONIX-style robustness diagrams can be drawn with StarUML - there is no direct support for them in BOUML or ArgoUML). See also: Bennett, Chapter 7 and Successful Robustness Analysis.
  
• 1. Select use case
     
  2. Find out the classes (see the class diagram) and actors related to the use case.
     
  3. Depending on the tool to be used, represent the classes as rectangles (or as domain stereotype symbols)  and actors as "stick men".
  4. Add a general user interface (boundary) class, responsible for interfactions between user and the system. This class represents (possibly large number of) all the concrete user interface elements.
     
  5. Add essential controller classes; with small systems a single controller class could be used, with more complex systems the control could be distributed to multiple classes. The purpose of the controller class(es) is to refer to the domain classes (or collection of them) and direct (i.e. use) the services (i.e. operations) offered by domain classes. In addition, controller separates user interface from the data storage, modelling (with considerable simplification) a three-tier architecture. Note that with ICONIX-style robustness diagrams the number of controllers (=not necessarily implemented as classes) can be higher, especially if the connection rules are applied.
     
  6. By using the use case description as a base, consider the messages that must be delivered between objects/actors such that the system can be used. How the activity is carried out? What phases are needed to search, view, or modify an object?
  7. Express the messages with lines or arrows and name them with verbs.
  8. First describe the main scenario. If the exceptions or alternate flows fit to the same diagram easily, add them. If the diagram gets too large and, nonessential exceptions can be omitted at this phase (leave out comments about the omitted exceptions).
     
  9. Check that all the classes corresponding to the objects in collaboration diagram exist in the class diagram (with the exception of ICONIX-style multiple controllers). If not, supplement the class diagram. Consider the relations between classes - e.g. could any of the associative relations be more naturally modeled as aggregations. Are all necessary (esp. domain) classes known, e.g. can a controller object call a domain object? In object oriented programming objects can call each other if the caller has retrieved a reference to the object to be called (modeled in this phase most commonly as an association). For example, there should be multiple references from controller classes to domain classes.
     
  10. Add operations found in collaboration diagrams to class diagram. Täydennä luokkakaavion luokkien operaatiolista vastaavasti yhteistoimintakaavioissa esiintyvillä operaatioilla. Add other operations as needed.
      
• About the detail level in collaboration diagrams see also: Robustness Diagrams and Robustness Analysis.
  
• Data dictionary should contain only such classes and attributes that are not "obvious" (both to users and developers of the system) based on their naming  nimestä ilmi. For example - if you use generalization, pay attention to documentation of top-level classes (possibly abstract). If necessary, you can define associations as well. You can use the following data dictionary template: (html, doc, odt).
• Class diagram, data dictionary and collaboration diagrams should be modelled in parallel. Ensure that the information in models is consistent both internally and in relation to the use cases modelled in Phase 1.