System Design Overview

1. Introduction to Design

1.1 Introduction

Design is an iterative process of transforming the requirements specification into a design specification.

Consider an example where Mrs. & Mr. XYZ want a new house. Their requirements include,

• a room for two children to play and sleep

• a room for Mrs. & Mr. XYZ to sleep
• a room for cooking
• a room for dining
• a room for general activities

and so on. An architect takes these requirements and designs a house. The architectural design specifies a
particular solution. In fact, the architect may produce several designs to meet this requirement. For
example, one may maximize children’s room, and other minimizes it to have large living room. In
addition, the style of the proposed houses may differ: traditional, modern and two-storied. All of the
proposed designs solve the problem, and there may not be a best design.

Software design can be viewed in the same way. We use requirements specification to define the
problem and transform this to a solution that satisfies all the requirements in the specification.

Some definitions for Design:

Devising artifacts to attain goals [H.A. Simon, 1981].

The process of defining the architecture, component, interfaces and other characteristics of a system or
component [IEEE 160.12].

The process of applying various techniques and principles for the purpose of defining a device, a process
or a system in sufficient detail to permit its physical realization [Webster Dictionary].

Without Design, System will be

- unmanageable since there is no concrete output until coding. Therefore it is difficult to monitor &
control.

- inflexible since planning for long term changes was not given due emphasis.

- unmaintainable since standards & guidelines for design & construction are not used. No reusability
consideration. Poor design may result in tightly coupled modules with low cohesion. Data disintegrity may
also result.

- inefficient due to possible data redundancy and untuned code.

- not portable to various hardware / software platforms.

Design is different from programming. Design brings out a representation for the program not the
program or any component of it. The difference is tabulated below.
 Design Programming

Abstractions of operations and data("What to do") Device algorithms and data representations

Establishes interfaces Consider run-time environments

Choose between design alternatives

Choose functions, syntax of language
Make trade-offs w.r.t.constraints etc

Devices representation of program Construction of program

1.2 Qualities of a Good Design

Functional: It is a very basic quality attribute. Any design solution should work, and should be
constructable.

Efficiency: This can be measured through

• run time (time taken to undertake whole of processing task or transaction)

• response time (time taken to respond to a request for information)
• throughput (no. of transactions / unit time)
• memory usage, size of executable, size of source, etc

Flexibility: It is another basic and important attribute. The very purpose of doing design activities is to
build systems that are modifiable in the event of any changes in the requirements.

Portability & Security: These are to be addressed during design - so that such needs are not hard-coded
later.

Reliability: It tells the goodness of the design - how it work successfully (More important for real-time
and mission critical and on-line systems).

Economy: This can be achieved by identifying re-usable components.

Usability: Usability is in terms of how the interfaces are designed (clarity, aesthetics, directness,
forgiveness, user control, ergonomics, etc) and how much time it takes to master the system.

1.3 Design Constraints

Typical Design Constraints are:

• Budget
• Time
• Integration with other systems
• Skills
• Standards
• Hardware and software platforms

Budget and Time cannot be changed. The problems with respect to integrating to other systems (typically
client may ask to use a proprietary database that he is using) has to be studied & solution(s) are to be
found. Skills are alterable (for example, by arranging appropriate training for the team). Mutually agreed
upon standards has to be adhered to. Hardware and software platforms may remain a constraint.
Designer try answer the How part of what is raised during the requirement phase. As such the solution
proposed should be contemporary. To that extent a designer should know what is happening in
technology. Large, central computer systems with proprietary architecture are being replaced by
distributed network of low cost computers in an open systems environment We are moving away from
conventional software development based on hand generation of code (COBOL, C) to Integrated
programming environments. Typical applications today are internet based.

1.4 Popular Design Methods

Popular Design Methods (Wasserman, 1995) include

1) Modular decomposition

• Based on assigning functions to components.

• It starts from functions that are to be implemented and explain how each component will be
organized and related to other components.

2) Event-oriented decomposition

• Based on events that the system must handle.

• It starts with cataloging various states and then describes how transformations take place.

3) Object-oriented design

• Based on objects and their interrelationships

• It starts with object types and then explores object attributes and actions.

Structured Design - uses modular decomposition.

1.5 Transition from Analysis to Design

(Source: Pressman, R.S. Software Engineering: A Practitioners Approach, fifth edition, McGraw-Hill, 2001)
The data design transforms the data model created during analysis into the data structures that will be
required to implement the software.

The architectural design defines the relationship between major structural elements of the software, the
design patterns that can be used to achieve the requirements and the constraints that affect the
implementation.

The interface design describes how the software communicates within itself, and with humans who use
it.

The Procedural design (typically, Low Level Design) elaborates structural elements of the software into
procedural (algorithmic) description.

2. High Level Design Activities

Broadly, High Level Design include Architectural Design, Interface Design and Data Design.

2.1 Architectural Design

Shaw and Garlan (1996) suggest that software architecture is the first step in producing a software
design. Architecture design associates the system capabilities with the system components (like modules)
that will implement them. The architecture of a system is a comprehensive framework that describes its
form and structure, its components and how they interact together. Generally, a complete architecture
plan addresses the functions that the system provides, the hardware and network that are used to
develop and operate it, and the software that is used to develop and operate it. An architecture style
involves its components, connectors, and constraints on combining components. Shaw and Garlan (1996)
describe seven architectural styles. Commonly used styles include

• Pipes and Filters

• Call-and-return systems
o Main program / subprogram architecture
• Object-oriented systems
• Layered systems
• Data-centered systems
• Distributed systems
o Client/Server architecture

In Pipes and Filters, each component (filter) reads streams of data on its inputs and produces streams
of data on its output. Pipes are the connectors that transmit output from one filter to another.

e.g. Programs written in UNIX shell

In Call-and-return systems, the program structure decomposes function into a control hierarchy where
a main program invokes (via procedure calls) a number of program components, which in turn may invoke
still other components.

e.g. Structure Chart is a hierarchical representation of main program and subprograms.

In Object-oriented systems, component is an encapsulation of data and operations that must be

applied to manipulate the data. Communication and coordination between components is accomplished via
message calls.

In Layered systems, each layer provides service to the one outside it, and acts as a client to the layer
inside it. They are arranged like an onion ring.

e.g. OSI ISO model.

Data-centered systems use repositories. Repository includes a central data structure representing
current state, and a collection of independent components that operate on the central data store. In a
traditional database, the transactions, in the form of an input stream, trigger process execution.

e.g. Database

A popular form of distributed system architecture is the Client/Server where a server system responds
to the requests for actions / services made by client systems. Clients access server by remote procedure
call.

The following issues are also addressed during architecture design:

• Security
• Data Processing: Centralized / Distributed / Stand-alone
• Audit Trails
• Restart / Recovery
• User Interface
• Other software interfaces

2.2 User Interface Design

The design of user interfaces draws heavily on the experience of the designer. Pressman [2] (Refer
Chapter 15) presents a set of Human-Computer Interaction (HCI) design guidelines that will result in a
"friendly," efficient interface.

Three categories of HCI design guidelines are

1. General interaction
2. Information display
3. Data entry

• General Interaction

Guidelines for general interaction often cross the boundary into information display, data entry and
overall system control. They are, therefore, all-encompassing and are ignored at great risk. The
following guidelines focus on general interaction.
o Be consistent

Use a consistent format for menu selection, command input, data display and the
myriad other functions that occur in a HCI.
o Offer meaningful feedback

Provide the user with visual and auditory feedback to ensure that two way
communication (between user and interface) is established.
o Ask for verification of any nontrivial destructive action

If a user requests the deletion of a file, indicates that substantial information is to be
overwritten, or asks for the termination of a program, an "Are you sure ..." message
should appear.
o Permit easy reversal of most actions

UNDO or REVERSE functions have saved tens of thousands of end users from millions
of hours of frustration. Reversal should be available in every interactive application.
o Reduce the amount of information that must be memorized between actions

The user should not be expected to remember a list of numbers or names so that he
or she can re-use them in a subsequent function. Memory load should be minimized.
o Seek efficiency in dialog, motion, and thought

Keystrokes should be minimized, the distance a mouse must travel between picks
should be considered in designing screen layout, the user should rarely encounter a
situation where he or she asks, "Now what does this mean."
 o Forgive mistakes

The system should protect itself from errors that might cause it to fail (defensive
programming)
o Categorize activities by functions and organize screen geography accordingly

One of the key benefits of the pull down menu is the ability to organize commands
by type. In essence, the designer should strive for "cohesive" placement of
commands and actions.
o Provide help facilities that are context sensitive
o Use simple action verbs or short verb phrases to name commands

A lengthy command name is more difficult to recognize and recall. It may also take
up unnecessary space in menu lists.

• Information Display

If information presented by the HCI is incomplete, ambiguous or unintelligible, the application will
fail to satisfy the needs of a user. Information is "displayed" in many different ways with text,
pictures and sound, by placement, motion and size, using color, resolution, and even omission. The
following guidelines focus on information display.
o Display only information that is relevant to the current context

The user should not have to wade through extraneous data, menus and graphics to
obtain information relevant to a specific system function.
o Dont bury the user with data, use a presentation format that enables rapid assimilation of
information

Graphs or charts should replace voluminous tables.
o Use consistent labels, standard abbreviations, and predictable colors

The meaning of a display should be obvious without reference to some outside
source of information.
o Allow the user to maintain visual context

If computer graphics displays are scaled up and down, the original image should be
displayed constantly (in reduced form at the corner of the display) so that the user
understands the relative location of the portion of the image that is currently being
viewed.
o Produce meaningful error messages
o Use upper and lower case, indentation, and text grouping to aid in understanding

Much of the information imparted by a HCI is textual, yet, the layout and form of the
text has a significant impact on the ease with which information is assimilated by the
user.
o Use windows to compartmentalize different types of information

Windows enable the user to "keep" many different types of information within easy
reach.
o Use analog displays to represent information that is more easily assimilated with this form
of representation

For example, a display of holding tank pressure in an oil refinery would have little
impact if a numeric representation were used. However, a thermometer-like display
was used; vertical motion and color changes could be used to indicate dangerous
pressure conditions. This would provide the user with both absolute and relative
information.
o Consider the available geography of the display screen and use it efficiently

When multiple windows are to be used, space should be available to show at least
some portion of each. In addition, screen size (a system engineering issues should
be selected to accommodate the type of application that is to be implemented.

• Data Input

Much of the user's time is spent picking commands, typing data and otherwise providing system
input. In many applications, the keyboard remains the primary input medium, but the mouse,
digitizer and even voice recognition systems are rapidly becoming effective alternatives. The
following guidelines focus on data input:
 o Minimize the number of input actions required of the user

Reduce the amount of typing that is required. This can be accomplished by using the
mouse to select from pre-defined sets of input; using a "sliding scale" to specify
input data across a range of values; using "macros" that enable a single keystroke to
be transformed into a more complex collection of input data.
o Maintain consistency between information display and data input

The visual characteristics of the display (e.g., text size, color, placement) should be
carried over to the input domain.
o Allow the user to customize the input

An expert user might decide to create custom commands or dispense with some
types of warning messages and action verification. The HCI should allow this.
o Interaction should be flexible but also tuned to the users preferred mode of input

The user model will assist in determining which mode of input is preferred. A clerical
worker might be very happy with keyboard input, while a manager might be more
comfortable using a point and pick device such as a mouse.
o Deactivate commands that are inappropriate in the context of current actions.

This protects the user from attempting some action that could result in an error.
o Let the user control the interactive flow

The user should be able to jump unnecessary actions, change the order of required
actions (when possible in the context of an application), and recover from error
conditions without exiting from the program.
o Provide help to assist with all input actions
o Eliminate Mickey mouse input

Do not let the user to specify units for engineering input (unless there may be
ambiguity). Do not let the user to type .00 for whole number dollar amounts, provide
default values whenever possible, and never let the user to enter information that
can be acquired automatically or computed within the program.

3. Structured Design Methodology

The two major design methodologies are based on

• Functional decomposition
• Object-oriented approach

3.1 Structured Design

Structured design is based on functional decomposition, where the decomposition is centered around
the identification of the major system functions and their elaboration and refinement in a top-down
manner. It follows typically from dataflow diagram and associated processes descriptions created as part
of Structured Analysis. Structured design uses the following strategies

• Transformation analysis
• Transaction analysis

and a few heuristics (like fan-in / fan-out, span of effect vs. scope of control, etc.) to transform a DFD into
a software architecture (represented using a structure chart).

In structured design we functionally decompose the processes in a large system (as described in DFD) into
components (called modules) and organize these components in a hierarchical fashion (structure chart)
based on following principles:

• Abstraction (functional)
• Information Hiding
• Modularity
Abstraction

"A view of a problem that extracts the essential information relevant to a particular purpose and ignores
the remainder of the information." -- [IEEE, 1983]

"A simplified description, or specification, of a system that emphasizes some of the system's details or
properties while suppressing others. A good abstraction is one that emphasizes details that are significant
to the reader or user and suppress details that are, at least for the moment, immaterial or diversionary." -
- [Shaw, 1984]

While decomposing, we consider the top level to be the most abstract, and as we move to lower levels, we
give more details about each component. Such levels of abstraction provide flexibility to the code in the
event of any future modifications.

Information Hiding

... Every module is characterized by its knowledge of a design decision which it hides from all others. Its
interface or definition was chosen to reveal as little as possible about its inner workings." --- [Parnas,
1972]

Parnas advocates that the details of the difficult and likely-to-change decisions be hidden from the rest of
the system. Further, the rest of the system will have access to these design decisions only through well-
defined, and (to a large degree) unchanging interfaces.

This gives a greater freedom to programmers. As long as the programmer sticks to the interfaces agreed
upon, she can have flexibility in altering the component at any given point.

There are degrees of information hiding. For example, at the programming language level, C++ provides
for public, private, and protected members, and Ada has both private and limited private types. In C
language, information hiding can be done by declaring a variable static within a source file.

The difference between abstraction and information hiding is that the former (abstraction) is a technique
that is used to help identify which information is to be hidden.

The concept of encapsulation as used in an object-oriented context is essentially different from

information hiding. Encapsulation refers to building a capsule around some collection of things [Wirfs-
Brock et al, 1990]. Programming languages have long supported encapsulation. For example,
subprograms (e.g., procedures, functions, and subroutines), arrays, and record structures are common
examples of encapsulation mechanisms supported by most programming languages. Newer programming
languages support larger encapsulation mechanisms, e.g., "classes" in Simula, Smalltalk and C++,
"modules" in Modula, and "packages" in Ada.

Modularity

Modularity leads to components that have clearly defined inputs and outputs, and each component has a
clearly stated purpose. Thus, it is easy to examine each component separately from others to determine
whether the component implements its required tasks. Modularity also helps one to design different
components in different ways, if needed. For example, the user interface may be designed with object
orientation and the security design might use state-transition diagram.

3.2 Strategies for converting the DFD into Structure Chart

Steps [Page-Jones, 1988]

• Break the system into suitably tractable units by means of transaction analysis
• Convert each unit into a good structure chart by means of transform analysis
 • Link back the separate units into overall system implementation

Transaction Analysis

The transaction is identified by studying the discrete event types that drive the system. For example, with
respect to railway reservation, a customer may give the following transaction stimulus:

The three transaction types here are: Check Availability (an enquiry), Reserve Ticket (booking) and Cancel
Ticket (cancellation). On any given time we will get customers interested in giving any of the above
transaction stimuli. In a typical situation, any one stimulus may be entered through a particular terminal.
The human user would inform the system her preference by selecting a transaction type from a menu. The
first step in our strategy is to identify such transaction types and draw the first level breakup of modules
in the structure chart, by creating separate module to co-ordinate various transaction types. This is shown
as follows:

The Main ( ) which is a over-all coordinating module, gets the information about what transaction the user
prefers to do through TransChoice. The TransChoice is returned as a parameter to Main ( ). Remember,
we are following our design principles faithfully in decomposing our modules. The actual details of how
GetTransactionType ( ) is not relevant for Main ( ). It may for example, refresh and print a text menu and
prompt the user to select a choice and return this choice to Main ( ). It will not affect any other
components in our breakup, even when this module is changed later to return the same input through
graphical interface instead of textual menu. The modules Transaction1 ( ), Transaction2 ( ) and
Transaction3 ( ) are the coordinators of transactions one, two and three respectively. The details of these
transactions are to be exploded in the next levels of abstraction.

We will continue to identify more transaction centers by drawing a navigation chart of all input screens
that are needed to get various transaction stimuli from the user. These are to be factored out in the next
levels of the structure chart (in exactly the same way as seen before), for all identified transaction
centers.

Transform Analysis

Transform analysis is strategy of converting each piece of DFD (may be from level 2 or level 3, etc.) for all
the identified transaction centers. In case, the given system has only one transaction (like a payroll
system), then we can start transformation from level 1 DFD itself. Transform analysis is composed of the
following five steps [Page-Jones, 1988]:

1. Draw a DFD of a transaction type (usually done during analysis phase)

2. Find the central functions of the DFD
3. Convert the DFD into a first-cut structure chart
4. Refine the structure chart
5. Verify that the final structure chart meets the requirements of the original DFD

Let us understand these steps through a payroll system example:

• Identifying the central transform

The central transform is the portion of DFD that contains the essential functions of the system and is
independent of the particular implementation of the input and output. One way of identifying central
transform (Page-Jones, 1988) is to identify the centre of the DFD by pruning off its afferent and efferent
branches. Afferent stream is traced from outside of the DFD to a flow point inside, just before the input is
being transformed into some form of output (For example, a format or validation process only refines the
input does not transform it). Similarly an efferent stream is a flow point from where output is formatted
for better presentation. The processes between afferent and efferent stream represent the central
transform (marked within dotted lines above). In the above example, P1 is an input process, and P6 & P7
are output processes. Central transform processes are P2, P3, P4 & P5 - which transform the given input
into some form of output.
 • First-cut Structure Chart

To produce first-cut (first draft) structure chart, first we have to establish a boss module. A boss module
can be one of the central transform processes. Ideally, such process has to be more of a coordinating
process (encompassing the essence of transformation). In case we fail to find a boss module within, a
dummy coordinating module is created

In the above illustration, we have a dummy boss module Produce Payroll which is named in a way that it
indicate what the program is about. Having established the boss module, the afferent stream processes
are moved to left most side of the next level of structure chart; the efferent stream process on the right
most side and the central transform processes in the middle. Here, we moved a module to get valid
timesheet (afferent process) to the left side (indicated in yellow). The two central transform processes are
move in the middle (indicated in orange). By grouping the other two central transform processes with the
respective efferent processes, we have created two modules (in blue) essentially to print results, on the
right side.

The main advantage of hierarchical (functional) arrangement of module is that it leads to flexibility in the
software. For instance, if Calculate Deduction module is to select deduction rates from multiple rates, the
module can be split into two in the next level one to get the selection and another to calculate. Even after
this change, the Calculate Deduction module would return the same value.

• Refine the Structure Chart

Expand the structure chart further by using the different levels of DFD. Factor down till you reach to
modules that correspond to processes that access source / sink or data stores. Once this is ready, other
features of the software like error handling, security, etc. has to be added. A module name should not be
used for two different modules. If the same module is to be used in more than one place, it will be
demoted down such that fan in can be done from the higher levels. Ideally, the name should sum up the
activities done by the module and its sub-ordinates.

• Verify Structure Chart vis-Ã -vis with DFD

Because of the orientation towards the end-product, the software, the finer details of how data gets
originated and stored (as appeared in DFD) is not explicit in Structure Chart. Hence DFD may still be
needed along with Structure Chart to understand the data flow while creating low-level design.
 • Constructing Structure Chart (An illustration)

Some characteristics of the structure chart as a whole would give some clues about the quality of the
system. Page-Jones (1988) suggest following guidelines for a good decomposition of structure chart:

• Avoid decision splits - Keep span-of-effect within scope-of-control: i.e. A module can affect only
those modules which comes under its control (All sub-ordinates, immediate ones and modules
reporting to them, etc.)
• Error should be reported from the module that both detects an error and knows what the error is.
• Restrict fan-out (number of subordinates to a module) of a module to seven. Increase fan-in
(number of immediate bosses for a module). High fan-ins (in a functional way) improve reusability.

3.3 How to measure the goodness of the design

To Measure design quality, we use coupling (the degree of interdependence between two modules), and
cohesion (the measure of the strength of functional relatedness of elements within a module). Page-Jones
gives a good metaphor for understanding coupling and cohesion: Consider two cities A & B, each having a
big soda plant C & D respectively. The employees of C are predominantly in city B and employees of D in
city A. What will happen to the highway traffic between city A & B? By placing employees associated to a
plant in the city where plant is situated improves the situation (reduces the traffic). This is the basis of
cohesion (which also automatically improve coupling).

COUPLING

Coupling is the measure of strength of association established by a connection from one module to
another [Stevens et al., 1974]. Minimizing connections between modules also minimizes the paths along
which changes and errors can propagate into other parts of the system (ripple effect). The use of global
variables can result in an enormous number of connections between the modules of a program. The
degree of coupling between two modules is a function of several factors [Stevens et al., 1974]: (1) How
complicated the connection is, (2) Whether the connection refers to the module itself or something inside
it, and (3) What is being sent or received. Table 1 summarizes various types of coupling [Page-Jones,
1988].
 NORMAL Coupling (acceptable) COMMON (or CONTENT (or
GLOBAL) PATHOLOGICAL)
DATA Coupling STAMP Coupling CONTROL Coupling Coupling Coupling
(unacceptable) (forbidden)
Two modules Two modules are Two modules are Two modules are Two modules
are data coupled stamp coupled if one control coupled if common coupled exhibit content
if they passes to other a one passes to other if they refer to coupled if one
communicate by composite piece of a piece of the same global refers to the inside
parameters data (a piece of data information intended data area of the other in any
(each being an with meaningful to control the way (if one module
elementary internal structure) internal logic of the jumps inside
piece of data) other another module)
e.g. sin e.g. calc_order_amt e.g. print_report Instead of Jumping inside a
(theta)returning (PO_Details)returning (what_to_print_flag) communicating module violate all
sine value value of the order through the design
parameters, two principles like
calc_interest modules use a abstraction,
(amt, interest global data. information hiding
rate, and modularity.
term)returning
interest amt.

We aim for a loose coupling. We may come across a (rare) case of module A calling module B, but no
parameters passed between them (neither send, nor received). This is strictly should be positioned at zero
point on the scale of coupling (lower than Normal Coupling itself) [Page-Jones, 1988]. Two modules A &B
are normally coupled if A calls B, B returns to A (and) all information passed between them is by means of
parameters passed through the call mechanism. The other two types of coupling (Common and Content)
are abnormal coupling and not desired. Even in Normal Coupling we should take care of following issues
[Page-Jones, 1988]:

• Data coupling can become complex if number of parameters communicated between is large.
• In Stamp coupling there is always a danger of over-exposing irrelevant data to called module.
(Beware of the meaning of composite data. Name represented as a array of characters may not
qualify as a composite data. The meaning of composite data is the way it is used in the application
NOT as represented in a program)
• What-to-do flags are not desirable when it comes from a called module (inversion of authority): It
is alright to have calling module (by virtue of the fact, is a boss in the hierarchical arrangement)
know internals of called module and not the other way around.

In general, Page-Jones also warns of tramp data and hybrid coupling. When data is passed up and down
merely to send it to a desired module, the data will have no meaning at various levels. This will lead to
tramp data. Hybrid coupling will result when different parts of flags are used (misused?) to mean different
things in different places (Usually we may brand it as control coupling but hybrid coupling complicate
connections between modules). Page-Jones advocates a way to distinguish data from control flags (data
are named by nouns and control flags by verbs).

Two modules may be coupled in more than one way. In such cases, their coupling is defined by the worst
coupling type they exhibit [Page-Jones, 1988].

COHESION

Designers should aim for loosely coupled and highly cohesive modules. Coupling is reduced when the
relationships among elements not in the same module are minimized. Cohesion on the other hand aims to
maximize the relationships among elements in the same module. Cohesion is a good measure of the
maintainability of a module [Stevens et al., 1974]. Stevens, Myers, Constantine, and Yourdon developed a
scale of cohesion (from highest to lowest):
 1. Functional Cohesion (Best)
2. Sequential Cohesion
3. Communicational Cohesion
4. Procedural Cohesion
5. Temporal Cohesion
6. Logical Cohesion
7. Coincidental Cohesion (Worst)

Let us create a module that calculates average of marks obtained by students in a class:

calc_stat(){

// only a pseudo code

read (x[])

a = average (x)

print a

average(m){

sum=0

for i = 1 to N{

sum = sum + x[i]}

return (sum/N)

In average() above, all of the elements are related to the performance of a single function. Such a
functional binding (cohesion) is the strongest type of binding. Suppose we need to calculate standard
deviation also in the above problem, our pseudo code would look like:

calc_stat(){

// only a pseudo code

read (x[])

a = average (x)

s = sd (x, a)

print a, s

average(m){ // same as before

â ¦
}

sd (m, y){//function to calculate standard deviation

â ¦

Now, though average() and sd() are functionally cohesive, calc_stat() has a sequential binding
(cohesion). Like a factory assembly line, functions are arranged in sequence and output from average()
goes as an input to sd(). Suppose we make sd() to calculate average also, then calc_stat() has two
functions related by a reference to the same set of input. This results in communication cohesion.

Let us make calc-stat() into a procedure as below:

calc_stat(){

sum = sumsq = count = 0

for i = 1 to N

read (x[i])

sum = sum + x[i]

sumsq = sumsq + x[i]*x[i]

â ¦}

a = sum/N

s=â ¦ // formula to calculate SD

print a, s

Now, instead of binding functional units with data, calc-stat() is involved in binding activities through
control flow. calc-stat() has made two statistical functions into a procedure. Obviously, this arrangement
affects reuse of this module in a different context (for instance, when we need to calculate only average
not std. dev.). Such cohesion is called procedural.

A good design for calc_stat () could be (data not shown):

In a temporally bound (cohesion) module, the elements are related in time. The best examples of
modules in this type are the traditional initialization, termination, housekeeping, and clean-up modules.

A logically cohesive module contains a number of activities of the same kind. To use the module, we may
have to send a flag to indicate what we want (forcing various activities sharing the interface). Examples
are a module that performs all input and output operations for a program. The activities in a logically
cohesive module usually fall into same category (validate all input or edit all data) leading to sharing of
common lines of code (plate of spaghetti?). Suppose we have a module with all possible statistical
measures (like average, standard deviation, mode, etc.). If we want to calculate only average, the call to
it would look like calc_all_stat (x[], flag1, flag2, para1,). The flags are used to indicate out intent. Some
parameters will also be left blank.

When there is no meaningful relationship among the elements in a module, we have coincidental
cohesion.

Refer [Page-Jones, 1988: Chapters 5 & 6] for more illustrations and exercises on coupling and cohesion.

4. Data Design

The data design can start from ERD and Data Dictionary. The first choice the designer has to make is to
choose between file-based system or database system (DBMS). File based systems are easy to design and
implement. Processing speed may be higher. The major draw back in this arrangement is that it would
lead to isolate applications with respective data and hence high redundancy between applications. On the
other hand, a DBMS allows you to plug in your application on top of an integrated data (organization-
wide). This arrangement ensures minimum redundancy across applications. Change is easier to implement
without performance degradation. Restart/recovery feature (ability to recover from hardware/software
failures) is usually part of DBMS. On the flip side, because of all this in-built features, DBMS is quite
complex and may be slower.

A File is a logical collection of records. Typically the fields in the records are the attributes. Files can be
accessed either sequentially or randomly; Files are organized using Sequential or Indexed or Indexed
Sequential organization.

E.F. Codd introduced a technique called normalization, to minimize redundancy in a table.

Consider,

R (St#, StName, Major, {C#, CTitle, Faculty, FacLoc, Grade})

The following are the assumptions given:

• Every course is handled by only one faculty

• Each course is associated to a particular faculty
• Faculty is unique
• No student is allowed to repeat a course
This table needs to be converted to 1NF as there is more than one value in a cell. This is illustrated below:

After removing repeating groups, R becomes

R1(St#, StName, Major)

R2(St#,C#, CTitle, Faculty, FacLoc, Grade) as illustrated below:

The primary key of the parent table needs to be included in the new table so as to ensure no loss of
information.

Now, R1 is in 2NF as it has no composite key. However, R2 has a composite key of St# and C# which
determine Grade. Also C# alone determines CTitle, Faculty, FacLoc. Hence, R2 has a partial dependency
as follows:
In order to convert it into 2NF we have to remove partial dependency. R2 now becomes

R21(St#, C#, Grade)

R22(C#, CTitle, Faculty, FacLoc)

Now, R21 & R22 are in 2NF which is illustrated as below:

Now, R1 and R21 are in 3NF also. However, in R22 there exists one transitive dependency, as Faculty
determines FacLoc, shown as below:

In order to convert it into 3NF we have to remove this transitive dependency. R22 now becomes

R221(C#, CTitle, Faculty*)

R222(Faculty, FacLoc), assuming Faculty is unique.
Now R221 and R222 are in 3NF.

The final 3NF reduction for the given relation is:

Student (St#, StName, Major) R1

Mark_List (St#, C#, Grade) - R21

Course (C#, CTitle, Faculty*) R221 and

Faculty (Faculty, FacLoc) R22

De-normalization can be done for improving performance (as against flexibility)

For example, Employee (Name, Door#, StreetName, Location, Pin) may become two table during 3NF with
a separate table for maintaining Pin information. If application does not have any frequent change to Pin,
then we can de-normalize this two table back to its original form by allowing some redundancy for having
improved performance.

Guidelines for converting ERD to tables:

• Each simple entity --> Table / File

• For Super-type / Sub-type entities
o Separate / one table for all entities
o Separate table for sub & super-type
• If M: M relationship between entities, create one Table / File for relationship with primary key of
both entity forming composite key.
• Add inherited attribute (foreign key) depending on retrieval need (Typically on the ‘M’ side
of 1:M relationship)