Tutorial No.

Q.1) Define software design process and explain how the elements of analysis model are
translated into design model.

• Software design is an iterative process through which requirements are translated into a
“blueprint” for constructing the software. Initially, the blueprint depicts a holistic view of
software. That is, the design is represented at a high level of abstraction— a level that can
be directly traced to the specific system objective and more detailed data, functional, and
behavioural requirements. As design iterations occur, subsequent refinement leads to
design representations at much lower levels of abstraction. These can still be traced to
requirements, but the connection is more subtle.
• Each of the elements of the analysis model provides information that is necessary to create
the four design models required for a complete specification of design. The flow of
information during software design is illustrated in figure Software requirements,
manifested by the data, functional, and behavioural models, feed the design task. Using one
of a number of design methods the design task produces a data design, an architectural
design, an interface design, and a component design.

Fig. Translating the analysis model into a software design

• The data design transforms the information domain model created during analysis into the
data structures that will be required to implement the software. The data objects and
relationships defined in the entity relationship diagram and the detailed data content
depicted in the data dictionary provide the basis for the data design activity. Part of data
design may occur in conjunction with the design of software architecture. More detailed
data design occurs as each software component is designed.
• The architectural design defines the relationship between major structural elements of the
software, the “design patterns” that can be used to achieve the requirements that have
been defined for the system, and the constraints that affect the way in which architectural
design patterns can be applied [SHA96]. The architectural design representation— the
framework of a computer-based system—can be derived from the system specification, the
analysis model, and the interaction of subsystems defined within the analysis model.
• The interface design describes how the software communicates within itself, with systems
that interoperate with it, and with humans who use it. An interface implies a flow of
information (e.g. data and/or control) and a specific type of behaviour. Therefore, data and
control flow diagrams provide much of the information required for interface design.
• The component-level design transforms structural elements of the software architecture into
a procedural description of software components. Information obtained from the PSPEC,
CSPEC, and STD serve as the basis for component design. During design we make decisions
that will ultimately affect the success of software construction and, as important, the ease
with which software can be maintained.

Q.2) What is need for modular design? Explain cohesion and coupling.

• Need for modular design - Modularity has become an accepted approach in all engineering
disciplines. A modular design reduces complexity , facilitates change (a critical aspect of
software maintainability), and results in easier implementation by encouraging parallel
development of different parts of a system.
Cohesion-
• Cohesion is a natural extension of the information hiding concept. A cohesive module
performs a single task within a software procedure, requiring little interaction with
procedures being performed in other parts of a program. Stated simply, a cohesive module
should (ideally) do just one thing.
• Cohesion may be represented as a "spectrum." We always strive for high cohesion, although
the mid-range of the spectrum is often acceptable. The scale for cohesion is nonlinear. That
is, low-end cohesiveness is much "worse" than middle range, which is nearly as "good" as
high-end cohesion. In practice, a designer need not be concerned with categorizing cohesion
in a specific module. Rather, the overall concept should be understood and low levels of
cohesion should be avoided when modules are designed.
• At the low (undesirable) end of the spectrum, we encounter a module that performs a set of
tasks that relate to each other loosely, if at all. Such modules are termed coincidentally
cohesive. A module that performs tasks that are related logically (e.g., a module that
produces all output regardless of type) is logically cohesive. When a module contains tasks
that are related by the fact that all must be executed with the same span of time, the
module exhibits temporal cohesion.
• As an example of low cohesion, consider a module that performs error processing for an
engineering analysis package. The module is called when computed data exceed pre
specified bounds. It performs the following tasks:
(1) computes supplementary data based on original computed data
(2) produces an error report (with graphical content) on the user's workstation
(3) performs follow-up calculations requested by the user
(4) updates a database
(5) enables menu selection for subsequent processing. Although the preceding tasks are
loosely related, each is an independent functional entity that might best be performed as a
separate module.
• Combining the functions into a single module can serve only to increase the likelihood of
error propagation when a modification is made to one of its processing tasks.
• Moderate levels of cohesion are relatively close to one another in the degree of module
independence. When processing elements of a module are related and must be executed in
a specific order, procedural cohesion exists. When all processing elements concentrate on
one area of a data structure, communicational cohesion is present. High cohesion is
characterized by a module that performs one distinct procedural task.
• As we have already noted, it is unnecessary to determine the precise level of cohesion.
Rather it is important to strive for high cohesion and recognize low cohesion so that
software design can be modified to achieve greater functional independence.
Coupling-
• Coupling is a measure of interconnection among modules in a software structure. Coupling
depends on the interface complexity between modules, the point at which entry or
reference is made to a module, and what data pass across the interface.
• In software design, we strive for lowest possible coupling. Simple connectivity among
modules results in software that is easier to understand and less prone to a "ripple effect"
[STE74], caused when errors occur at one location and propagate through a system.
• Figure provides examples of different types of module coupling. Modules a and d are
subordinate to different modules. Each is unrelated and therefore no direct coupling occurs.
Module c is subordinate to module a and is accessed via a conventional argument list,
through which data are passed. As long as a simple argument list is present (i.e., simple data
are passed; a one-to-one correspondence of items exists), low coupling (called data
coupling) is exhibited in this portion of structure. A variation of data coupling, called stamp
coupling, is found when a portion of a data structure (rather than simple arguments) is
passed via a module interface. This occurs between modules b and a.

Fig. Types of coupling

• At moderate levels, coupling is characterized by passage of control between modules.

Control coupling is very common in most software designs and is shown in Figure where a
“control flag” (a variable that controls decisions in a subordinate or super ordinate module)
is passed between modules d and e.
• Relatively high levels of coupling occur when modules are tied to an environment external to
software. For example, I/O couples a module to specific devices, formats, and
communication protocols. External coupling is essential, but should be limited to a small
number of modules with a structure. High coupling also occurs when a number of modules
reference a global data area. Common coupling, as this mode is called, is shown in Figure.
Modules c, g, and k each access a data item in a global data area (e.g., a disk file or a globally
accessible memory area). Module c initializes the item. Later module g re-computes and
updates the item.
• Let's assume that an error occurs and g updates the item incorrectly. Much later in
processing module, k reads the item, attempts to process it, and fails, causing the software
to abort. The apparent cause of abort is module k; the actual cause, module g. Diagnosing
problems in structures with considerable common coupling is time consuming and difficult.
However, this does not mean that the use of global data is necessarily "bad." It does mean
 that a software designer must be aware of potential consequences of common coupling and
take special care to guard against them.
• The highest degree of coupling, content coupling, occurs when one module makes use of
data or control information maintained within the boundary of another module. Secondarily,
content coupling occurs when branches are made into the middle of a module. This mode of
coupling can and should be avoided.
• The coupling modes just discussed occur because of design decisions made when structure
was developed. Variants of external coupling, however, may be introduced during coding.
For example, compiler coupling ties source code to specific (and often nonstandard)
attributes of a compiler; operating system (OS) coupling ties design and resultant code to
operating system "hooks" that can create havoc when OS changes occur.

Q.3) Explain following concepts.

Control hierarchy-
• Control hierarchy, also called program structure, represents the organization of program
components (modules) and implies a hierarchy of control. It does not represent procedural
aspects of software such as sequence of processes, occurrence or order of decisions, or
repetition of operations; nor is it necessarily applicable to all architectural styles.
• Different notations are used to represent control hierarchy for those architectural styles that
are amenable to this representation. The most common is the treelike diagram (below
diagram) that represents hierarchical control for call and return architectures. However,
other notations, such as Warnier-Orr [ORR77] and Jackson diagrams [JAC83] may also be
used with equal effectiveness. In order to facilitate later discussions of structure, we define a
few simple measures and terms. Referring to Figure, depth and width provide an indication
of the number of levels of control and overall span of control, respectively. Fan-out is a
measure of the number of modules that are directly controlled by another module. Fan-in
indicates how many modules directly control a given module.

• The control relationship among modules is expressed in the following way: A module that
controls another module is said to be super ordinate to it, and conversely, a module
controlled by another is said to be subordinate to the controller [YOU79]. For example,
referring to Figure, module M is super ordinate to modules a, b, and c. Module h is
subordinate to module e and is ultimately subordinate to module M. Width-oriented
relationships (e.g., between modules d and e) although possible to express in practice, need
not be defined with explicit terminology.
• The control hierarchy also represents two subtly different characteristics of the software
architecture: visibility and connectivity. Visibility indicates the set of program components
 that may be invoked or used as data by a given component, even when this is accomplished
indirectly. For example, a module in an object-oriented system may have access to a wide
array of data objects that it has inherited, but makes use of only a small number of these
data objects. All of the objects are visible to the module. Connectivity indicates the set of
components that are directly invoked or used as data by a given component. For example, a
module that directly causes another module to begin execution is connected to it.

Structural Partitioning-
• If the architectural style of a system is hierarchical, the program structure can be partitioned
both horizontally and vertically. Referring to below figure a, horizontal partitioning defines
separate branches of the modular hierarchy for each major program function. Control
modules, represented in a darker shade are used to coordinate communication between and
execution of the functions. The simplest approach to horizontal partitioning defines three
partitions—input, data transformation (often called processing) and output.
• Partitioning the architecture horizontally provides a number of distinct benefits:
a) software that is easier to test
b) software that is easier to maintain
c) propagation of fewer side effects
d) software that is easier to extend
• Because major functions are decoupled from one another, change tends to be less complex
and extensions to the system (a common occurrence) tend to be easier to accomplish
without side effects. On the negative side, horizontal partitioning often causes more data to
be passed across module interfaces and can complicate the overall control of program flow
(if processing requires rapid movement from one function to another).

Fig. Structural partitioning

• Vertical partitioning Figure b, often called factoring, suggests that control (decision making)
and work should be distributed top-down in the program structure. Top level modules
should perform control functions and do little actual processing work. Modules that reside
low in the structure should be the workers, performing all input, computation, and output
tasks.
• The nature of change in program structures justifies the need for vertical partitioning.
Referring to Figure b, it can be seen that a change in a control module (high in the structure)
will have a higher probability of propagating side effects to modules that are subordinate to
it. A change to a worker module, given its low level in the structure, is less likely to cause the
propagation of side effects. In general, changes to computer programs revolve around
 changes to input, computation or transformation, and output. The overall control structure
of the program (i.e., its basic behaviour is far less likely to change). For this reason vertically
partitioned structures are less likely to be susceptible to side effects when changes are made
and will therefore be more maintainable—a key quality factor.

Abstraction-
• When we consider a modular solution to any problem, many levels of abstraction can be
posed. At the highest level of abstraction, a solution is stated in broad terms using the
language of the problem environment. At lower levels of abstraction, a more procedural
orientation is taken. Problem-oriented terminology is coupled with implementation-
oriented terminology in an effort to state a solution. Finally, at the lowest level of
abstraction, the solution is stated in a manner that can be directly implemented. Wasserman
[WAS83] provides a useful definition:
• The psychological notion of "abstraction" permits one to concentrate on a problem at some
level of generalization without regard to irrelevant low level details; use of abstraction also
permits one to work with concepts and terms that are familiar in the problem environment
without having to transform them to an unfamiliar structure.
• Each step in the software process is a refinement in the level of abstraction of the software
solution. During system engineering, software is allocated as an element of a computer-
based system. During software requirements analysis, the software solution is stated in
terms "that are familiar in the problem environment." As we move through the design
process, the level of abstraction is reduced. Finally, the lowest level of abstraction is reached
when source code is generated.
• As we move through different levels of abstraction, we work to create procedural and data
abstractions. A procedural abstraction is a named sequence of instructions that has a
specific and limited function. An example of a procedural abstraction would be the word
open for a door. Open implies a long sequence of procedural steps (e.g., walk to the door,
reach out and grasp knob, turn knob and pull door, step away from moving door, etc.)
• A data abstraction is a named collection of data that describes a data object. In the context
of the procedural abstraction open, we can define a data abstraction called door. Like any
data object, the data abstraction for door would encompass a set of attributes that describe
the door (e.g., door type, swing direction, opening mechanism, weight, dimensions). It
follows that the procedural abstraction open would make use of information contained in
the attributes of the data abstraction door.
• Many modern programming languages provide mechanisms for creating abstract data types.
For example, the Ada package is a programming language mechanism that provides support
for both data and procedural abstraction. The original abstract data type is used as a
template or generic data structure from which other data structures can be instantiated.
• Control abstraction is the third form of abstraction used in software design. Like procedural
and data abstraction, control abstraction implies a program control mechanism without
specifying internal details. An example of a control abstraction is the synchronization
semaphore [KAI83] used to coordinate activities in an operating system.

Software procedure-
• Program structure defines control hierarchy without regard to the sequence of processing
and decisions. Software procedure focuses on the processing details of each module
individually. Procedure must provide a precise specification of processing, including
sequence of events, exact decision points, repetitive operations, and even data organization
and structure.
• There is, of course, a relationship between structure and procedure. The processing
indicated for each module must include a reference to all modules subordinate to the
module being described.