Class Analysis - realisation

From EUDP
(Redirected from Class Analysis - real)
Jump to: navigation, search

What

Detailed analysis of selected classes.

How

The dish

Detailed analysis of selected classes.

Ingredients

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.

How in details

Identifying attributes

There are several ways to identify the attributes of a class.

  • The role or responsibilities of the class or the object(s)
  • Events
  • CRC cards (Class Responsibility Collaborator)

Role or responsibilities

Remember that a class is an abstract description that describes the behaviour of concrete object(s). Every object is unique - e.g. a person is unique, but identified uniquely by the name and address or by other means depending on the situation where you want to identify a specific person. In system development we also need to identify each object in the system. Through the analysis the developer should define exactly what makes the object(s) unique from each other; this will lead to some of the attributes the class should contain.

Events

Attributes can also be identified by looking at the events the class is involved in. Typically, events cause the class to change state. Please note: There is no need to add a state attribute - it is implicitly implemented by the developer when there is a State Machine Diagram attached to the class. On the other hand events are often accompanied with data that should be stored. The data can be included in the event itself, or it can be implicit data like a timestamp or a counter that should be updated. Take a close look on all events in the State Machine Diagram and define the kind of data that may accompany the event.

CRC cards

CRC cards are often made in cooperation with the customer. A CRC card is a simplified description of a class. It contains the name of the class, the responsibilities of the class and the names of the other classes the class collaborates with. Below is an example of a general CRC card:

Tx oodocs 7bdb884f63.gif

The customer can give information about the responsibilities of an object when the object is clearly identified. An Invoice, for instance, is a well-known object in the customer's universe which she/he can describe the responsibilities for - i.e. describe what information it contains - and with which other objects it collaborates. The customer may not think collaboration immediately, but if the developer explains the abstract thinking of system development, the customer may get the idea and tell that the invoice is always connected to an order and a payment (hopefully). Below is an example of a class's responsibilities:

Tx oodocs 75e5035214.gif

If a class's responsibilities are not well defined, it may lead to collaboration with other classes. In the above example the responsibility Customer may not be clear, but through a collaboration with a customer object, enough details can be obtained - through a request the Invoice class can retrieve the necessary information about a customer. The same applies for other responsibilities in the class. Consequently, the CRC card may end up like this:

Tx oodocs e6592fd285.gif

From the above the following canonical class diagram can be drawn (extract):

Tx oodocs 37e779462c.gif

The collaboration leads to associate the class with other classes. Determine the type of association needed (association, aggregation, composition) and whether it should be unidirectional (only knowledge about and access from one class to another) rather than bidirectional (with knowledge about and access from both involved classes).

Identifying methods

Methods are the things an object or class do. We will only note those methods that extend the class beyond ordinary data manipulation; trivial methods like constructors, destructors, setters and getters or event handlers should not be included at this time of work. Identify the methods by analysing:

  • Collaborations with other objects
  • General system functions found in earlier analysis

Methods in Collaboration

Ask yourself: Which structured information should this class provide and maintain? Do the default setters and getters offer enough facilities or should the data be provided in a more compound form enabling the calling object to set or get a larger chunk of data?

General system functions

In the analysis of system functions we identified some general functions that made the data in the data model available to an actor. Some of those functions collect data from several objects. Consider if the class should make some methods available that help the general functions do the job. Like the methods found by analysing collaboration, the methods can be methods providing access to data in a more compound way.

Identifying Associations

Associations as a general term covers the three types of associations in UML: association, aggregation and composition. Please take a closer look on the description of the associations. There you will find some detailed information describing how to identify the different types.

From the collaborations mentioned above associations can be identified as the links between the collaborating classes.

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.

The Class Analysis can be accompanied by a Use Case Analysis - realisation or even run in parallel.