Designing the Problem Area

One of the first diagrams to be created may not find its way into the formal specifications since it is designed to aid the understanding between client, developer, designers, and end users. From this general understanding, the formal specifications will be created, so it is an important, if informal, diagram.

The best way to construct the diagram is in the guise of a brainstorming session, with all parties mentioned in the preceding section present or at least represented. The reason for this is that they will each have a different way of looking at the system, and each should contribute his view of the problem area to the initial diagram that represents a collation of all the separate views.

If one draws a series of bubbles on a piece of paper, each with a specific aspect of the system in it, suggested by representatives of the various groups (end users, client, management, project team, and so on), it will quickly become apparent that there are many different ways to look at the problem, and solutions to it.

The result will be a reasonably chaotic collection of ideas, which will need to be organized into clusters of ideas that belong together. It is possible to short-circuit the process in the interest of trying to establish different areas of the system and reduce the need to spend a lot of time writing on white boards. The following groups of ideas crop up repeatedly:

Data: The abstract objects in the system.

User: Representation of different user groups.

Function: Required features and processes within the system.

Commercial: Concerns such as price, size, and equipment required.

Service: Maintenance, diagnostics, etc.

If a sheet of paper is prepared to contain these five areas, perhaps in five columns, it will be faster to fill the various categories. However, this level of prompting might lead to undesirable effects, such as individuals trying to suggest ideas that are outside their own areas of expertise. In addition, those who are responsible for a given area might try to fabricate items so their column seems fuller, or worse, ignore key problems in the interest of having fewer entries in their column.

The idea of a more freehand approach is that, since nobody knows what will happen to the collection of ideas, those involved will be more likely to come up with anything that is on their minds, within their area of expertise, without the element of competition that can creep in by trying to streamline the process.

There are some loose rules, or principles, that should be adhered to when creating the list of viewpoints. There will need to be a member of the brainstorming session, with a good grasp of viewpoint analysis, who decides what a valid viewpoint is, and is not, using these principles.

Viewpoints represent functions, or collections of functions, that are a feature or service that the system needs to offer. Each function must be completely contained within a viewpoint. Any information that flows around the system must do so between two viewpoints, such that only viewpoints can provide a source of input information, or a point at which information leaves the system.

As such, each viewpoint that information visits should perform some kind of operation on that data. In fact, we can take this a step further and say that the purpose of each functional viewpoint is to perform some kind of operation on the information that exists within the system.

This is different from the nonfunctional viewpoints that usually represent the boundary conditions, or constraints, of the system, and can include items such as cost, performance, and resource requirements. Each of these can be considered a separate viewpoint, but should be grouped under the appropriate heading.

With the various contributions in hand, they need to be organized further into those parts of the system that define what it is supposed to do, those that define other systems with which it will need to interact, and the abstract concepts, such as price, that identify the constraints within which the system has to be built.

In the Procedures for the 5th International Workshop on Software Specification and Design, [Finklestein&Fuks89] suggest a name for this—viewpoint analysis. They begin in the same way, and take the process further by creating a structured diagram for each of the viewpoints that are proposed by the people involved in creating the initial description of the problem domain.

[Somerville92] suggests that a mixed object- and function-oriented approach is appropriate when taking this last step, known as viewpoint structuring. The aim is to create a diagram in which all the viewpoints proposed are linked together in a hierarchical diagram of different levels of related functionality. Figure 3.1 shows part of the viewpoint structure diagram for a simple accounting system.

Constructing the diagram serves two purposes: to have a working pictorial description of the system that needs to be constructed, and as an input to the creation of diagrams that describe exactly what functions the system needs to support. The act of creating the diagram also helps to provide input to the creation of these subsidiary diagrams, which will make up the bulk of the specifications.

Large systems, potentially containing hundreds of viewpoints, will need to he spread across multiple diagrams. It will not be possible to fit all the viewpoints on a single page, either because of the physical size of the paper, or simply because the resulting diagram cannot be absorbed or understood by the reader.

It is much more effective to layer the diagrams such that they only show a collection of viewpoints that are contextually related. During the structuring process that leads to the diagrams such as that in Figure 3.1, each collection of viewpoints will be grouped according to the level at which they appear in the diagram.

Ç Invoice Generation )

Ç Invoice Generation )

Tax Return

FIGURE 3.1 Viewpoint structure for a basic accounting system.

This means that the higher up the diagram the viewpoint appears, the more likely it is to be an object within the system, and the lower down the viewpoint appears, the more it will tend toward an actual function of the system. In performing this analysis, it may become necessary to split up viewpoints so that the diagram can be constructed in the most efficient way possible, in terms of communicating the required information.

Data Design Diagrams

At the base of the system will be the information that the system is designed to manipulate, and part of the system specification needs to deal with a complete description of this data. This process is known as data modeling, and the result should be a set of diagrams that show the structure of the information that the system will need to process.

This is different from the diagrams that will show the actual design of the data within the software system, but the difference between the two is admittedly slight.

The aim of putting data models in the system specification is to try to impose restrictions on the problem domain, but when the actual design is done, the aim is to create actual data objects that can be implemented by programmers.

These data diagrams will be a result of looking at the various viewpoints that were collected under the heading of Data in the viewpoint analysis. The titles within the Data collection will be abstract concepts such as log files, databases, and documents. For example, if one is defining an accounting package, we might expect a document such as the Invoice to be specified as part of the data collection of viewpoints.

When we try to convert the abstract notion of an Invoice into something more concrete in the specifications, we should model it as having various attributes: customer, amount, tax, due date, description of products or services rendered, and so on.

The diagram that we construct for use in the specifications that form a part of the contract between the client and developer will show an Invoice object, and the various attributes that it will need, with the emphasis on the what and not the how.

Once the specifications are accepted, and the whole system moves into a less abstract design phase, these diagrams will be enhanced to show how the system is to store and manipulate the various objects and attributes.

The viewpoint technique that we looked at in the previous section was built around the premise that each functional viewpoint operated on system data in some way, but we did not actually define what that data was, or how it should be represented.

Therefore, the data design diagrams complement the viewpoint diagrams in a description of the entire system. Without the data design diagrams, the specification of the system is not complete; by themselves they do not offer enough information to build the final system.

Figure 3.2 shows a typical data design diagram for a customer object, which will be needed by the accounting system for which we constructed a viewpoint diagram in Figure 3.1.

We have chosen an easy to understand notation for the data design, showing that the object in question (customer) has a collection of attributes. The central object, the customer, is shown as a box, with further boxes connected to it by lines that indicate the attributes (name, address, telephone number).

These attributes are then broken down further, and the final pieces of data are represented by ovals connected to the attributes by lines. Therefore, the address attribute has several components that refine it—number, street, town, and zip code.

We could go into even further detail, by defining each of the address components; however, this would begin to take us into the "how" area of the design, and the point behind the specifications is that they define "what" it is that we are trying to achieve.

FIGURE 3.2 Data design for a customer object.
Brainstorming

Brainstorming

Tap Directly Into Your Creative Mind... And Easily Access YOUR Million-Dollar Ideas Ideas are the lifeblood of success... and the best ideas originate with brainstorming. Brainstorming can help you successfully fix any problem, build any business, generate any plan, or develop any story. But the problem is that most people have no clue how to effectively brainstorm - either by themselves or with groups. You can waste a lot of time coming up with old, boring ideas that won't work... and the whole time you actually believe that you are brainstorming.

Get My Free Ebook


Post a comment