Difference between revisions of "Structural Analysis"

Revision as of 08:25, 15 January 2016

What

For the selected parts of the project, perform a detailed analysis in order to understand the task at hand.

How

The Dish

A detailed analysis of each selected task that shall be developed in the current timebox.

Ingredients

Documentation from

• Requirements Analysis
• Problem Domain Analysis
• Usage Domain Analysis
• Interface Analysis
• Functionality Analysis
• System Behaviour Analysis
• Design Constraints Analysis

i.e. the General Analysis specification.

Add, for reference, documentation from

• System Architecture Design
• Block Interface Design
• Selecting Technical Platform
• Design Partitioning

Finally, the plans for the timebox are handy to have available.

Process

Requirements from the Launch Phase may, at this point, be too widely specified. Therefore, it may be necessary to specify sub-requirements that all together will cover a selected requirement. While splitting a requirement into more detailed sub-requirements, you should also update or create verification specifications that match the newly created requirements.

Note: Not all sub-requirements may be included in a timebox; they might be split into several timeboxes.

Note: This activity may advantageously be performed during the planning activities.

The next step is to identify and describe algorithms, attributes and methods ending up with a more detailed block, module or class diagrams (depending on the programming language).

Software Analysis

Definitions

• Module: A software module (from a C module), a class or a contiguous block of code handling a specific task
• Algorithm: A step-by-step instruction on how to solve a specific problem
• Attribute: A storage space able to maintain values (typically a variable in a program or function)
• Method: A collection of statements that forms a whole (function or procedure)

For each selected module to be implemented in the current timebox, perform an analysis of the requirements attached to the module.

Identify algorithms that may solve the problem at hand. Assess each algorithm by describing it, e.g. by using pseudo code or a descriptive text, and evaluate the suitability to solve the problem by giving it weighed scores. After assessing each possible algorithm, select the one with the best score.

Identify the essential attributes that the module should maintain.

Identify the datatype of each attribute (i.e. integer, string, etc.).

Identify the essential methods that the module should offer (essential methods do not include basic methods that access attributes such as set and get methods, basic event handlers, constructors, destructors, etc.; these are left for the developer to implement implicitly).

Identify the return datatype and parameter datatypes of the methods.

Update the diagrams or create new diagrams that maintain the decisions.

How in details

The following is written with the object oriented class in mind, but it works also for modules or other blocks of code.

Class diagrams can be used to depict the structure of the code even if it is not going to be implemented in an object oriented programming language. The UML class diagram is generally understood and there exists a lot of tools enabling the developer drawing solid diagrams.

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:

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:

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:

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

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.

Hardware Analysis

The structural analysis to perform when designing hardware, is basically a parallel and/or refinement of the work to be done in the [Archtechture design phase]

As a result of the structural analysis, you should be able to point out and sketch key architectural features and support key technical requirements. Also, your notes from analysing the structure in the system-to-be, is essential to support the design partitioning into functional block, as shown in you [Block diagram]

Why

From the Launch Phase we have a general block diagram, 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 module.

Likewise, more associations may be discovered when going into more details about each module. But be careful not to over-detail the diagram with associative connections between modules. Sometimes it might be a better solution to add extra views - i.e. module diagrams - that show the details for a smaller amount of modules. A lot of tools enable the developer to draw several views. Thereby the same module 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.