 The designer needs ways to represent abstract ideas about

problem and design objects, and about the various relationships

that will exist between these.

 A representation is used to provide a particular abstraction of the

characteristics of a system, and is typically needed for such
purposes as:

1. capturing the designer’s ideas for a solution;

2. explaining the designer’s ideas to others (such as customers,

fellow designers, implementors, managers);

3. checking for consistency and completeness in a solution.

Example:

Above Figure provides a ‘sketch’ of a building, which might be

considered to provide a good example of a ‘black box’ description,
providing only a (partial) description of the external appearance of
the building
Example:

Above figure provides a very different representation of a specific

property of the same building( a small part of the internal electrical
circuitry). Its clearly a ‘white box’ description, it is still an
abstraction from the final physical realization of the cables,
switches and sockets which will be used in the circuits.
 Software designers similarly use a range of levels of abstraction,
although the invisible nature of software provides a particular
problem in terms of how to describe the properties involved.

 Software design techniques tend to make extensive use of

various forms of box and line notations to provide visual
descriptions that are intended to represent the various properties
of software

 Representations provide particular abstractions of a system; they

are closely linked to the concept of a viewpoint.
Viewpoint
 The ‘plan’ diagrams capture the attributes that are
concerned with spatial dimensions, accessibility, and the
like.

 A wiring diagram captures the attributes that are

concerned with the logical organization of the distribution
of electrical power and its control
Viewpoint
 Since each representation describes a set of design
properties, there is frequently some intersection between
the different sets of properties, and hence some means of
checking for consistency between the corresponding forms
of representation.
 In order to describe system-oriented properties, the designer usually needs
forms that describe the dynamic behaviour of the system. Such forms tend to
emphasize features such as the flow of data or information around a system,
or the sequencing of operations.

 For more detailed solution-oriented design needs, which are often concerned
with describing ‘constructional’ issues such as packaging, procedure
hierarchy, and data organization, the chosen forms will generally focus on
static design attributes.
 The nature of software and the many paradigms that exist for developing software
systems, based on different structuring criteria, has led to the use of a large
number of design representations. These can be broadly classified as follows:

1. Constructional forms, in which the viewpoint is concerned with essentially static

aspects of the system;

2. Behavioural forms, a set of viewpoints that seek to describe the causal links
between events and system responses during execution;

3. Functional forms, viewpoints that seek to describe what the system does in terms
of its tasks;

4. Data-modelling forms, concerned with the data objects used within the system,
and the relationships between these.
 The above representations can all be classified as ‘direct’ viewpoints, in that
they are created directly by the designer.

 A further class of viewpoints can be described as ‘derived’ viewpoints; in

these some transformation is applied to the design model in order to generate
a ‘new’ representation form.
1. Constructional forms
 Concerned with describing how the various software-structuring forms provided in
programming languages, mark-up languages, etc. are to be used in the final system.

 Some of the constructional forms described by this viewpoint include:

1. Data specification, which may include files of data, files containing information about the
organization of a program (such as a .h header file), and data in the form of mark-up
languages such as HTML (HyperText Markup Language) and XML (Extended Markup
Language);

2. Threads of execution, usually in the form of sub-program organization, but also

including constructs for handling parallel threads of execution;

3. packaging constructs, such as the Java class or the Ada package, where such con structs
may be used to construct some form of ‘scope wall’ around sections of the system, or to
create inheritance hierarchies.);
1. Constructional forms

An important part of the description involves specifying the relationships

and dependencies that will exist between the elements of the system.
Typically, these are such forms as:

1. data flow, concerning the sources and forms of data;

2. invocation, describing how the ‘flow of control’ is managed between

program elements;

3. uses hierarchy, describing the dependencies that exist between classes

2. Behavioural forms
➢ Concerned with causal issues, connecting an ‘event’ to a ‘response’ via any
necessary conditions.

➢ Most of these forms can be considered as examples of finite-state machines, being

concerned with the transitions that occur between different states of a system
(waiting, processing, output and so on), and the conditions (events) that are
required to make them occur.

1. sequencing aspects can be described fairly well;

2. fixed-interval descriptions are also fairly tractable, although their use is mainly
restricted to particular features of real-time systems;

3. constraint effects are very difficult to capture and describe using existing forms of
description
3. Functional forms
➢ One of the hardest tasks for the designer is to describe exactly what it is that a
system does.

➢ The initial problem specification, and the algorithmic aspects in particular may be
better specified than other features.

➢ At the detailed design level such forms are generally needed to describe the run
time behaviour of program elements such as subprograms
4. Data Modelling forms
➢ Description of data structures is often a critical aspect of a detailed design.

➢ Again, there are a number of relationships that may need to be captured. These
include such dependencies as: type (classes); sequence (in terms of structures such
as trees and lists); and form.
➢ Different forms of notation for constructing representations are used, the
three basic components that can be used in a representation are:
1. text
Diagram Form
2. diagrams

3. mathematical expressions
➢ Software design method could be described in terms of the following principal
components:
➢ representation part

➢ process part

➢ set of heuristics, or clichés.

➢ The process part of a method is closely entwined with the representation part, since
it provides ‘procedural’ guidelines on how the models should be developed.
➢ Figure shows this procedural model of the software design process in a symbolic
fashion. The basic symbols it uses to describe a design method are:
➢ a rectangle to denote a representation form;

➢ an oval to denote a procedural step;

➢ an arc to denote the sequence of steps

➢ These two forms have quite distinctive roles and characteristics, which can be
described as below.
1. A transformation step is one where the designer modifies the structuring for their
model of the ‘system’ in some way. Typically this consists of reinterpreting it using a
different viewpoint. Such a step will require the designer to make some fairly major
design decisions and is clearly a strongly creative one.

2. An elaboration step is one which does not usually involve any change of viewpoint but
is more concerned with restructuring or reorganizing the design model within the
current viewpoint. The purpose of an elaboration step is usually either to add further
information to the model, or to obtain greater insight into the current state of the
design plan through restructuring, and as such it may be an essential preliminary to a
successful transformation step.
➢ The following broad groupings discuss how strategy is incorporated into a design
method:

1. Decompositional methods, which generally take a ‘top-down’ view of the design

process, developing the design model through a process of sub-division;

2. Compositional methods, whereby the basic design model is built up from the
identification of ‘entities’ of some form;

3. Organizational methods, for which the structure of the design process is strongly
influenced by the requirement that it should conform to non-technical
requirements that are based on the form of the organization;

4. Template-based methods, where a specific problem domain provides a class of

problems that can be tackled using a fairly standard strategy.
➢ The main task of a program was subdivided into smaller tasks, with this subdivision being
continued until the resultant subtasks were considered sufficiently elemental to be
implemented as subprograms.

➢ The term ‘stepwise refinement’ is used for this strategy; the phrase ‘divide and conquer’
has also sometimes been used.

➢ In its most basic form, the success of this approach of finding a good solution will be
highly dependent on the way in which the original problem is described, since this forms
the model that is the basis for the designer’s initial choice of subtasks (Solution1)

➢ Indeed, it can be argued that this approach is therefore inherently unstable, in that small
differences in the decomposition of a task can lead to solutions that are functionally
equivalent, but structurally very different (Solution2)
➢ This instability in turn may lead to significant problems at a later stage of design,
and even to the need to totally redesign a system.

➢ When using a top-down strategy, it is particularly important to explore the design

options as fully as possible at each stage of decomposition.

➢ The top-down strategy also illustrates one of the characteristic features of the
design process itself. When discussing Rittel’s definition of a ‘wicked problem’, we
identified one of the characteristics of such a problem as being the lack of a
‘stopping rule’ that the designer can use to determine that the design process is
complete. This feature of the design process is particularly evident in functional
decomposition, since there are no generally applicable criteria that can be used to
determine how small a task should be to be considered as suitably elemental.
➢ One other consequence of using this strategy that should also be mentioned is the
problem of duplication.

➢ Because the strategy consists of a sequence of refinements, there is potential for

full or partial duplication of functionality when the low-level operations are defined.
So, the use of a refinement process implies the need to explicitly check for, and
resolve, any such duplications. Following Figure shows a simple example of how
such duplication can easily arise during such a process of decomposition
Top Down
 Systems with hierarchical structures easily lend themselves to top-down and
bottom-up approaches to design

 In a hierarchical system, there is a first top-level module which is decomposed into

a few second-level modules. Some of the second-level modules may be further
decomposed into third-level modules

 In the Figure, module A is the topmost module; module A has been decomposed
into modules B, C, and D. Modules B, D, E, F, and G are terminal modules, as
these have not been further decomposed
Top Down

Module hierarchy with three levels and seven modules.

Top Down

1. Top-down integration of modules A and B.

2. Top-down integration of modules A, B, and D

Top Down
3. Top-down integration of modules A, B, D and C.

4. Top-down integration of modules A, B, C, D, and E

Top Down
5. Top-down integration of modules A, B, C, D, E, and F.

6. Top-down integration of modules A, B, C, D, E, F and G

Bottom Up
 In the bottom-up approach, design begins with the design of lowest level modules.
A module is said to be at the lowest level if it does not invoke another module
Bottom Up

1. Bottom-Up integration of modules E, F, G.

2. Bottom-Up integration of modules B,C,D with E, F, G

Bottom Up

3. Bottom-Up integration of modules A with all others.

➢ The reverse of top-down approach is to use a compositional strategy for building
the designer’s model.

➢ In this, a model of the problem is constructed by developing descriptions of a set of

particular entities or objects that can be recognized in the problem itself, together
with a description of the relationships that link these entities.
➢ In compositional strategy, the relevant entities are normally identified by analysing
an initial description of the problem.

➢ A complete and detailed model of the solution is then developed by elaborating the
descriptions of the entities and the interactions occurring between them.

➢ While the type and form of entity and interaction may differ considerably, the overall
strategy of composing the design model by grouping elements together is the
same.
➢ If compositional methods are more complex and less directly intuitive than those
methods that are based on a top-down approach, and so perhaps require more
discipline in their use, it can be argued that they are also
➢ more stable, in that their use will tend to lead to similar solutions for a problem, regardless of
the user, since the design strategy relates the structure of the solution to the structure of the
problem

➢ more even in terms of the transformation steps involved, with a more gradual progression of
design development than is common for top-down methods;

➢ better able to provide a good verification process between the design and the original
specification, since there is usually an explicit ‘audit trail’ between solution objects and
problem objects.
➢ A particular benefit of the compositional strategy is that it gives more opportunity
for using multiple viewpoints to exploit the use of such important design concepts
as modularity and information-hiding in the structuring of a designer’s solution.
➢ An organizational design method can be considered as one in which the form of the
process part of the method is strongly influenced by a set of non technical factors,
arising from the nature and structure of the organization using the method.

➢ While these factors do not usually affect the representational part so directly, their
influence may still have the effect of extending or formalizing it in some way.

➢ International agencies, as well as central and local government bodies, are major
customers for software-based systems. These range from specialized defence real-
time systems to applications for stock control or taxation. Many of these systems
are very large; they are difficult to specify; the requirements may change with
technology, legislation or internal reorganization; and they may be produced by in-
house teams or by outside contracting agencies.
➢ The use of a standard method or strategy within an organization has a number of
benefits
➢ there is minimum disruption of a project when staff changes occur;

➢ a change of project manager should not lead to a change of technical direction;

➢ standardization of documentation allows for better management of maintenance;

➢ there is scope for better planning, costing and control of projects, based on the use of past
experience, which can be related directly to current practices.

➢ The major negative aspect is that they tend to be overly bureaucratic, with the
attendant risk that creative options may not be adequately explored, and also that
the overall technical direction can be lost.
There are a number of methods that can be classified as having an organizational
element. These include:

➢ SSADM (Structured Systems Analysis and Design Method), which has been produced
for use with data-processing projects by central and local government agencies in
the UK;

➢ MERISE, which is a French equivalent to SSADM;

➢ HOOD (Hierarchical Object-Oriented Design), which has been developed on behalf

of the European Space Agency for use in designing Ada-based systems;

➢ MASCOT (Modular Approach to Software Construction, Operation and Test) is

intended for use in real-time systems, and originated in the UK defence sector.
➢ Black box notation is one that is concerned with the external properties of the
elements of a design model. That is, it is used to describe what an element will do,
rather than how it is to do it.

The Data-Flow Diagram

➢ The DFD provides a description based on modelling the flow of information around
a network of operational elements, with each element making use of or modifying
the information flowing into that element.

➢ The DFD has been widely used for software design purposes over many years, and a
number of variations in the exact forms of the symbols used for drawing DFDs are
to be found in the literature
The Data-Flow Diagram (The form of the DFD)

➢ The DFD is a graphical representation, and it makes use of only four basic symbols.

➢ Because of its highly abstract nature, in terms of the level of description provided, it
is chiefly used during the early design stages that are often termed ‘analysis’ – at a
time when the designer is likely to be making major architectural design decisions.

➢ The four basic elements that are used in the diagram are:
➢ the circle (or, as it is popularly termed, the bubble), which is used to denote an operation, and is labelled with a
brief description of the operation;

➢ the box, used to denote an external source or sink of information;

➢ the parallel bars, used to denote a data store or file;

➢ the arc, used to denote the flow of information between the other three components.
The Data-Flow Diagram (The form of the DFD)

➢ Below figure shows an example of the use of a DFD to describe the operation of a
bank autoteller (cashpoint) system.

➢ DFD provides a top-level ‘model’ of how the designer intends the autoteller to
operate. It is expressed in terms that are part of the problem domain (customer,
PIN, transaction), rather than of the solution, and as such it identifies the main
architectural tasks for the autoteller system.
The Data-Flow Diagram (The form of the DFD)

➢ An important characteristic of the DFD is that it can be expanded in a hierarchical

fashion, with the operation of any bubble being described by means of a further
DFD.

➢ The following figure shows an expansion of bubble 1 (Validate Customer Access)

using the same symbols.
The DFD Viewpoint

➢ Data-Flow Diagrams are primarily concerned with describing the architecture of a

system in terms of its functions, in that they identify the operations that need to be
performed by the system, using an abstract level for the description.

➢ The data-flow element is used to identify the information that is needed for the
appropriate operations to be performed, as well as that which is generated by them.
Using the DFD

➢ The physical DFD is used to model a system in terms of the physical entities
concerned, rather than their functions.

➢ For example, following figure shows a physical DFD that is used to model the
workings of the booking system in a travel office. The labels on the bubbles in this
diagram indicate who does a job, rather than describing the job in any detail
Using the DFD
➢ The Logical DFD shows the equivalent logical DFD, in which the bubbles are now
labelled to show what is being done to the data, rather than who is doing it. This is
a more abstract and more structured view of the system

➢ Both of these forms are important: the physical DFD helps with initial modelling
tasks and with communication with the customer, while the logical DFD is necessary
when the designer begins to build up the architectural model required in order to
build the system.
The Entity–Relationship Diagram

➢ This form of diagram is principally used to capture the relationships that exist
between static data objects in a problem model or a design model.

➢ In particular, the Entity Relationship Model has provided an essential foundation for
the development of the relational models that are used in many database systems

➢ Figure shows the three principal symbols that are used in these diagrams, together
with their meanings.
The Entity–Relationship Diagram

➢ entities are real-world objects with common properties.

➢ a relationship is a class of elementary facts relating two or more entities;

➢ attributes are classes of values that represent atomic properties of either entities or
relationships

➢ Relationships are also classified by their ‘n-ary’ properties.

➢ Binary relationships link two entities, such as the relationship ‘married to’ occurring
between the entities ‘husband’ and ‘wife’.

➢ Relationships may also be ‘one to many’ (1 to n) and ‘many to many’ (m to n)

The Entity–Relationship Diagram
The ERD Viewpoint

➢ ERDs are purely and simply concerned with providing a data-modelling viewpoint of
a system.

➢ As with many notations, they can be used both during the analysis of the problem
and during the development of the solution (design).

Use of ERD

➢ ERDs are widely used for developing the schema used in relational database
modelling.
The State Transition Diagram

➢ Some classes of problem (and solution) can usefully be described by considering

them as ‘finite-state automata’.

➢ Such a system can be considered as existing in a finite set of possible ‘states’, with
external events being the triggers that can lead to transitions between the states.

➢ As an example, the popular Unix screen editor vi (pronounced ‘vee eye’) has two
basic states of operation, which are termed its current ‘modes’. These are:
➢ command mode, in which keystrokes are interpreted as commands to the editor to perform such operations as
opening a file, moving the position of the screen cursor, or beginning to insert text at some point;

➢ insert mode, in which any keystrokes are interpreted as data to be stored in the editor’s buffer

➢ Transitions occur between these modes according to certain forms of ‘escape’ command.

➢ Line command mode can be considered as a substate of command mode.

The State Transition Diagram
Form of the State Transition Diagram

➢ There are four principal components to this representation of an STD.

1. The state represents an externally observable mode of behaviour, and is represented by a box, with a text label
that describes its behaviour.

2. The transition is described by an arrow, and identifies a ‘legal’ change of state that can occur within the system

3. The transition condition identifies the condition that will cause the transition to occur – usually in terms of the
event that causes the transition – but is not concerned with the actual mechanism. It is written next to the
transition arrow, above a horizontal line

4. The transition action describes the actions that arise as a result of the transition. These are written below the
horizontal line and the details of the transition conditions.
Form of the State Transition Diagram

➢ To complete the diagram, we also need to identify a default initial state (which has
an arrow pointing into it, with no source state attached), and may (possibly) need to
identify a final state (which will have transitions into it, but none out from it).

The STD Viewpoint

➢ The STD is our first example of a representation that is used to capture a

behavioural viewpoint of a system, and so it is concerned with modelling dynamic
attributes of the system in terms of entities such as states, events and conditions.

➢ It only identifies the possibility that particular transitions will occur, with no
indication as to how these will be sequenced.
Use of STD

➢ A major role for the STD is in modelling problem entities: although it can have a
role in building models of solutions, this is less significant.

➢ It is also particularly useful in modelling some of the real-time needs of a system,

hence its popularity in real-time variants of design methods.

➢ The STD is a useful modelling tool, but as with all diagrammatical forms, it has
limitations. As the example of the vi editor has shown, if there are a lot of
transitions between a small number of states, the diagram can become very
tangled.
The Statechart
➢ The Statechart is concerned with describing the behaviour of a system as a form of
finite-state automaton, or finite state machine.

➢ Like the STD, it is a form that is particularly well suited for use in describing reactive
systems, in which the main functions arise in response to particular events.

➢ It provides a rather more abstract form of description than the STD, and in
particular it adds to the state-oriented viewpoint the ability to create a hierarchy of
abstraction in the description, as well as permitting the designer to describe
transitions that are ‘orthogonal’ in that they are completely independent of each
other – so making it possible for the transitions to occur in parallel
Form of the Statechart

➢ In this notation, a state is denoted by a box with rounded corners, labelled in the
upper left corner. Hierarchy is represented by encapsulation, and directed arcs are
used to denote a transformation between states.

➢ The arcs are also labelled with a description of the event and, optionally, with a
parenthesized condition
Form of the Statechart

➢ The major feature of the Statechart is orthogonality. Following Figure shows an

example of a state A that can be described as a superstate of two orthogonal states
B and C. B and C can in turn be described in terms of further states, but these are
essentially independent groupings.
Use of the Statechart

➢ The Statechart is clearly a powerful and useful tool, and like the STD it has an
important role in modelling reactive systems. Both forms are generally used to
support other design viewpoints such as data flow.
The Jackson Structure Diagram

➢ The Structure Diagram describes a very different set of attributes, and performs a
very different set of roles.

➢ It is basically concerned with describing sequential structure, in terms of the three

‘classical’ structuring forms:
➢ sequence

➢ selection

➢ iteration
The form of the Structure Diagram
➢ The Structure Diagram takes the form of a ‘tree’, constructed from a set of boxes and
arcs. Each set of ‘child’ boxes provides an elaboration of the description contained in the
parent box, and hence the full description of a complete sequence is described by the
lowest boxes on each branch

➢ Three forms of box:

1. A simple box denotes a component of a sequence – so in figure the action of making
tea is described as a series of actions.
2. A box with a circle in the upper right corner denotes selection from an option, and so
in figure the previous description of tea-making is extended to include the possibility
of using either China tea or Indian tea.
3. A box with an asterisk in the upper right corner denotes an iteration, and so in figure
the description is further extended by including the possibility that we might put more
than one spoonful of tea into the pot.
➢ Three forms of box:
The viewpoints provided by the Structure Diagram

➢ Structure Diagrams can be used to provide a data modelling viewpoint, when used
to describe the sequential structuring of data objects. They can also be used for
describing a viewpoint that has elements of both functional and branch behavioural
viewpoints, when they are used to describe the actions of a program or an entity.
The viewpoints provided by the Structure Diagram
The viewpoints provided by the Structure Diagram
UML Modelling Forms

➢ The UML forms are classified into:

1. structural forms (relating elements of a system);

2. dynamic forms (concerned with describing system behaviour);

3. model management (concerned with the organization of the model itself).

➢ We will examine three UML notations:

1. the class diagram (structural);

2. the use case diagram (structural); and

3. the activity diagram (dynamic).

UML Modelling Forms (The Class Diagram)

➢ A core concept of the object model is centered upon the relationships that involve
classes and any objects that are created from these. Identification of candidates for
classes is one of the primary activities in object oriented design practices.

➢ The UML class diagram therefore provides a means of describing both the classes
themselves, and also the interactions between these (uses relationship and the
concept of inheritance)
UML Modelling Forms (The Class Diagram)

➢ Classes can be related in a number of ways. The UML recognizes six forms of
relationship (association, dependency, flow, generalization, realization and usage)
with appropriate distinctions in the notation
UML Modelling Forms (The Use Case Diagram)

➢ A Use Case Diagram is a visual representation that illustrates the interactions

between users (actors) and a system. It captures the functional requirements of a
system, showing how different users engage with various use cases, or specific
functionalities, within the system.

➢ Use case diagrams provide a high-level overview of a system’s behavior, making

them useful for stakeholders, developers, and analysts to understand how a system
is intended to operate from the user’s perspective, and how different processes
relate to one another.
UML Modelling Forms (The Use Case Diagram)
UML Modelling Forms (The Use Case Diagram)
UML Modelling Forms (The Activity Diagram)

➢ The activity diagram can be thought of as a variant upon the state machine. Rather
than modelling the states of the system and the events that cause transitions
between these (Statecharts), the activity diagram is rather vaguely described as
‘modelling computations and workflows’.

➢ The activity diagram is therefore useful for modelling the type of ‘coordinating’
situation where a given computation cannot proceed until certain conditions are
met.
UML Modelling Forms (The Activity Diagram)

Key elements in the notation are as follows.

1. The activity, shown as a named box with rounded sides.

2. The transition (between activities), shown as an unlabelled arrow. The lack of a label is because,
unlike the case of the Statechart, the transitions arise from the actions of the activities
themselves, not because of external events.

3. The synchronization bar is a thick horizontal line that represents the coordination of the activities.
When all of the transitions into a bar are complete (the coordinating bit) then the outward
transitions are ‘fired’.

4. A decision diamond that effectively ‘routes’ outgoing transitions (this is in preference to using a
notation that shows multiple possible outgoing transitions). When this is used, then it becomes
necessary to label the transitions to indicate which condition is employed for a particular route.
UML Modelling Forms (The Activity Diagram)
➢ A white box notation can be viewed as one that is largely concerned with describing
some aspect of the detailed realization of a design element. So, not surprisingly,
such notations tend to be associated with the constructional and functional
viewpoints.

The Sequence Diagram

➢ The purpose of this notation is to detail the interactive message-passing sequences

that occur between a set of elements (which can be objects, actors, remote
processes, client and server, etc.), when they collaborate to perform a given task.
The Sequence Diagram Notation

➢ The organization of a sequence diagram is dominated by the need for a timeline,

which conventionally runs from the top of the page downwards.

➢ Each processing element, usually an object, but also possibly some other system
‘actor’, is allocated a column, and messages are shown by arrows between the
columns.
Uses of Sequence Diagram

➢ Sequence diagrams are essentially concerned with modelling the detailed sequence
of actions taken by a set of collaborating elements, and with the messages that they
use to coordinate these actions. downwards.

➢ A sequence diagram can also be used to describe a use case

The Structure Chart

➢ The Structure Chart provides a visual ‘index’ to the hierarchy of procedures within a
program, using a treelike format.

➢ It is therefore very much a solution-oriented form of description and, when allied

with an algorithmic form such as pseudocode, can be used to provide a fairly
comprehensive implementation plan for the programmer.

➢ The Structure Chart provides a means of recording the details of a program’s

structure in a form that is of great value to anyone who is trying to understand its
operation. It is particularly useful to the maintainer, who needs to understand the
general architecture of someone else’s design, in order to make changes that are
consistent with its form.
Form of Structure Chart
➢ The Structure Chart uses a treelike notation to describe the hierarchy of procedures
(subprograms) in terms of the invocation relationship between them (sometimes
termed a call graph).

➢ It therefore highlights the dependence of a procedure on the lower-level procedures

that it invokes.

➢ The three main components of Structure Chart are:

the box, which denotes a procedure (subprogram);
the arc, which denotes invocation;
the side-arrows, which provide information about information flow in terms
of parameter-passing (sometimes termed couples).
Form of Structure Chart
Form of Structure Chart

1. Procedures are drawn below the level of

the lowest calling unit. PrintString is drawn
at the lowest level, because it is called by
procedures
in both the top (first) and second levels

2. Double side-lines (again using PrintString

as the example) are used to indicate where
the designer expects to be able to use a
standard ‘library’ unit. There will therefore
be no further design details for such a unit.

3. The use of recursion can be indicated in a

fairly simple manner. For example, in the
procedure MatchNode, the recursive calling
is indicated by the closed invocation arc.

The procedure ReadNextToken is likely to

call a number of other procedures in
performing its task
Structure Chart Viewpoint

➢ The principal role of the Structure Chart is to describe the way in which a
program is assembled from a set of procedures.

➢ The Structure Chart contains some information about the organization of a

program and can therefore be regarded as also providing a certain amount of
constructional information.

Use of Structure Chart

➢ The Structure Chart provides a relatively low degree of abstraction from the
final implementation of a solution and, as was observed earlier, it can form a
useful index to the structure of a program
Pseudocode

➢ The Pseudocode is used very widely. It sometimes appears under other titles such as
PDL (program description language).

Pseudocode Form
Pseudocode

➢ To be effective, there are some useful rules of thumb for writing pseudocode. The
principal ones are:

a. Use indentation to emphasize structure (it aids the eye in following the form of a
sequence and finding other nodes in a branch).

b. Pull out ‘language keywords’ in some manner, perhaps by typing them in

uppercase or underlined.

c. Try to ‘bracket’ executable blocks such as the body of a loop, or a branch clause in
a conditional structure, by using such paired keywords as LOOP and ENDLOOP or IF
and ENDIF.

d. Avoid referring to the identifiers of program variables or the values of constants.

Pseudocode

➢ This is basically a functional one, based upon the sequencing of operations,

expressed at quite a detailed level. There is also a small constructional element, but
this is relatively minor in terms of importance.

Uses for pseudocode

➢ Pseudocode can be used to complement the Structure Chart by providing the details
and sequencing information that elaborates on the boxes in the diagram. It can
ofcourse be generated directly from a Structure Diagram.
THANK YOU