Class Analysis - realisation

From EUDP
Revision as of 10:44, 24 August 2009 by Ellyk (Talk)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

What

Detailed analysis of selected classes.

How

The dish

Detailed analysis of selected classes.

Ingredients

  • Class Diagram
  • Use Cases
  • Functions

Process

From the canonical class diagram select the classes that should have attention in this timebox.

Identify the essential attributes that the classes should maintain.

Identify the datatype of each attribute (i.e. Integer, String, etc.).

Identify the essential methods that the class should offer (essential methods do not include basic methods that access attributes such as set metods or get methods, basic event handlers, constructors, destructors, etc. - they are left for the developer to implement implicitly).

Identify the return datatype and parameter datatypes of the methods.

Draw a new class diagram (or extend the canonical class diagram if your tool allows it) and fill in the attributes and methods for each class included in the analysis. See an example below:

Tx oodocs ee5b8a375e.gif

Identify any new associations that may occur during the analysis. Find out whether the association should be unidirectional or bidirectional. Determine the multiplicity for the association.

In order to avoid one single class diagram with a multitude of associative connections between classes, draw the necessary number of views showing for instance how one or a few closely related classes associate.

Why

From the Launch Phase we have a general class diagram - a canonical class diagram (where the classes are drawn as boxes with a name) - which shows the general view of the system-to-be. In the early analysis we did not detail the diagram with attributes and methods. In the Realisation Phase it is time to do in-depth analysis and find the data and methods for each class.

Likewise, more associations may be discovered when going into more details about each class. But be careful not to over-detail the class diagram with associative connections between classes. Sometimes it might be a better solution to add extra views - i.e. class diagrams - that show the details for a smaller amount of classes. A lot of tools enable the developer to draw several views. Thereby the same class can be represented in different views.

Some tools enable the developer only to include selected attributes and methods in the different views. This enables the developer only to include the necessary information for a specific view.