DESIGN NOTATION AND SPECIFICATION

Unit - 4
• During the design phase there are two things of interest:

• the design of the system, the producing of which is the basic objective of this phase,
and
• the process of designing itself.

• For the latter that principles and methods are needed.

• Additionally while designing, a designer needs to record his thoughts and decisions and to
represent the design so that he can view it and play with it.

• For this, design notations are used.

• Design notations are largely meant to be used during the process of design and are used to
represent design or design decisions.

• The designer can quickly represent his decisions in a compact manner that he can
evaluate and modify.

• These notations are frequently graphical.

• Once the designer is satisfied with the design produced, the design is to be precisely
specified in the form of a document.

• Whereas a design represented using the design notation is largely to be used by the
designer, a design specification has to be so precise and complete that it can be used as a
basis of further development by other programmers.

• Often, design specification uses textual structures, with design notation helping
understanding.
• Structure Charts
• The structure of a program is made up of the modules of that program together with the
interconnections between modules.

• Every computer program has a structure, and given a program its structure can be
determined.
• The structure chart of a program is a graphic representation of its structure.

• In a structure chart a module is represented by a box with the module name written in the
box.

• An arrow from module A to module B represents that module A invokes module B.

• B is called the subordinate of A, and A is called the superordinate of B.

• The arrow is labeled by the parameters received by B as input and the parameters returned
by B as output, with the direction of flow of the input and output parameters represented
by small arrows.
• The parameters can be shown to be data (unfilled circle at the tail of the label) or control
(filled circle at the tail).
• Procedural information is not represented in a structure chart, and the focus is on
representing the hierarchy of modules.

• There are situations where the designer may wish to communicate certain procedural
information explicitly, like major loops and decisions.

• Such information can also be represented in a structure chart

• For example, let us consider a situation where module A has subordinates B, C, and D,
and A repeatedly calls the modules C and D.

• This can be represented by a looping arrow around the arrows joining the subordinates C
and D to A

• All the subordinate modules activated within a common loop are enclosed in the same
looping arrow.
• Major decisions can be represented similarly.

• For example, if the invocation of modules C and D in module A depends on the outcome
of some decision, that is represented by a small diamond in the box for A, with the arrows
joining C and D coming out of this diamond
• Modules in a system can be categorized into few classes.

• There are some modules that obtain information from their subordinates and then pass it
to their superordinate.

• This kind of module is an input module.

• Similarly, there are output modules, that take information from their superordinate and
pass it on to its subordinates.

• The input and output modules are typically used for input and output of data from and to
the environment.
• The input modules get the data from the sources and get it ready to be processed, and the output
modules take the output produced and prepare it for proper presentation to the environment.

• Then there are modules that exist solely for the sake of transforming data into some other form.

• Such a module is called a transform module. Most of the computational modules typically fall
in this category.

• Finally, there are modules whose primary concern is managing the flow of data to and from
different subordinates.

• Such modules are called coordinate modules.

Different types of modules
• A module can perform functions of more than one type of module.

• For example, the composite module is an input module from the point of view of its
superordinate, as it feeds the data Y to the superordinate.

• Internally, A is a coordinate module and views its job as getting data X from one
subordinate and passing it to another subordinate, which converts it to Y.

• Modules in actual systems are often composite modules

• A structure chart is not sufficient for representing the final design, as it does not give all
the information needed about the design.
• For example, it does not specify the scope, structure of data, specifications of each
module, etc.
• It is generally supplemented with textual specifications to convey design to the
implementer.
• once the program is written, its structure is fixed and can be done about altering the
structure.
• However, for a given set of requirements many different programs can be written to
satisfy the requirements, and each program can have a different structure.
• Although the structure of a given program is fixed, for a given set of requirements,
programs with different structures can be obtained.
• The objective of the design phase using function-oriented method is to control the
eventual structure of the system by fixing the structure during design.
• Specification
• A design specification should define the major data structures, modules and their
specifications, and design decisions.

• During system design, the major data structures for the software are identified; without
these, the system modules cannot be meaningfully defined during design.

• In the design specification, a formal definition of these data structures should be given.
• Module specification is the major part of system design specification.
• All modules in the system should be identified when the system design is complete, and
these modules should be specified in the document.
• During system design only the module specification is obtained, because the internal
details of the modules are defined later.
• To specify a module, the design document must specify
(a) the interface of the module (all data items, their types, and whether they are for input
and/or output),
(b) the abstract behavior of the module (what the module does) by specifying the module's
functionality or its input/output behavior, and
(c) all other modules used by the module being specified
this information is quite useful in maintaining and understanding the design.
• After a design is approved (using some verification mechanism), the modules will have to
be implemented in the target language.

• This requires that the module "headers“ for the target language first be created from the
design.

• This translation of the design for the target language can introduce errors if it's done
manually.

• To eliminate these translation errors, if the target language is known, it is better to have a
design specification language whose module specifications can be used almost directly in
programming.
• This not only minimizes the translation errors that may occur, but also reduces the effort
required for translating the design to programs.

• To aid the comprehensibility of the design, all major design decisions made by the
designers during the design process should be explained explicitly.

• The choices that were available and the reasons for making a particular choice should be
explained.

• This makes a design more visible and will help in understanding the design.