Structural Analysis

Jump to: navigation, search


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


The Dish

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


Documentation from

i.e. the General Analysis specification.

Add, for reference, documentation from

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


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


  • 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 also works 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. UML class diagrams are well understood by most developers/programmers, and a large variety of tools enabling the developer to draw solid diagrams exist.

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. During the analysis, the developer should define exactly what makes the object(s) unique from each other; this will lead to some of the attributes contained in the class.


Attributes can also be identified by looking at the events in which the class is found. 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 a State Machine Diagram is attached to the class. On the other hand, events are often accompanied by 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 at 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 with which the class collaborates. 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 in that s/he can describe its responsibilities, i.e. describe what information it contains as well as other objects with which it collaborates. The customer may not think about collaboration at first, 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' responsibilities:

Tx oodocs 75e5035214.gif

If a class' 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 to other responsibilities in the class. Consequently, the CRC card may end up as follows:

Tx oodocs e6592fd285.gif

From the above, the below 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, these methods can provide 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 at the description of the associations where you can find detailed information on 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 General Architecture Design 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 are essential to support the design partitioning into functional blocks as shown in Block Diagram.


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 large variety of tools enable the developer to draw several views. Thereby, the same module can be represented in different views.

Some tools only enable the developer to include selected attributes and methods in the different views; i.e. in some cases, the developer can only include the necessary information for a specific view.