UNIT 3

UNIT III Software Design Concepts

Design Concepts and Principles - Modular design - Design heuristic -

S/W architecture - Data design - Architectural design - Transform &
Transaction mapping - Introduction to SCM process - Software
Configuration Items
DESIGN ENGINEERING

- Introduction
- Design quality
- Design concepts
- The design model
 Five Notable Design Quotes
• "Questions about whether design is necessary or affordable are quite beside the
point; design is inevitable. The alternative to good design is bad design, [rather
than] no design at all." Douglas Martin
• "You can use an eraser on the drafting table or a sledge hammer on the
construction site." Frank Lloyd Wright
• "The public is more familiar with bad design than good design. If is, in effect,
conditioned to prefer bad design, because that is what it lives with; the new
[design] becomes threatening, the old reassuring." Paul Rand
• "A common mistake that people make when trying to design something
completely foolproof was to underestimate the ingenuity of complete fools."
Douglas Adams
• "Every now and then go away, have a little relaxation, for when you come back
to your work your judgment will be surer. Go some distance away because then
the work appears smaller and more of it can be taken in at a glance and a lack of
harmony and proportion is more readily seen." Leonardo DaVinci
4
 Purpose of Design
• Design is where customer requirements, business needs, and technical
considerations all come together in the formulation of a product or system.
• The design model provides detail about the software data structures,
architecture, interfaces, and components.
• The design model can be assessed for quality and be improved before code
is generated and tests are conducted
• Does the design contain errors, inconsistencies, or omissions?
• Are there better design alternatives?
• Can the design be implemented within the constraints, schedule, and cost
that have been established?

5
 Purpose of Design (continued)
• A designer must practice diversification and convergence
• The designer selects from design components, component solutions, and
knowledge available through catalogues , textbooks, and experience
• The designer then chooses the elements from this collection that meet the
Requirements defined by Requirements Engineering and Analysis Modelling.
• Convergence occurs as alternatives are considered and rejected until one
particular configuration of components is chosen
• Software design is an iterative process through which requirements are
translated into a blueprint for constructing the software
• Design begins at a high level of abstraction that can be directly traced back to
the data, functional, and behavioral requirements
• As design iteration occurs, subsequent refinement leads to design
representations at much lower levels of abstraction. 6
 From Analysis Model to Design Model
• Each element of the analysis model provides information that is necessary to create the
four design models
• The Data/Class design transforms analysis classes into Design classes along with the
data structures required to implement the software(Class and Collaboration
Diagram )
• The Architectural design defines the relationship between major structural elements
of the software; architectural styles and design patterns help achieve the
requirements defined for the system(Use Case Diagram & Sequence Diagram)
• The Interface design describes how the software communicates with systems that
interoperate with it and with humans that use it.(Use Case Diagram, Sequence
Diagram, Activity Diagram )
• The Component-level design transforms Structural elements of the software
architecture into a Procedural description of software components(Activity Diagram
& State Diagram)

(More on next slide) 7

 From Analysis Model to
Design Model (continued)
Component-level Design

(Class-based model, Flow-oriented model

Behavioral model)

Interface Design

(Scenario-based model, Flow-oriented model

Behavioral model)

Architectural Design

(Class-based model, Flow-oriented model)

Data/Class Design

(Class-based model, Behavioral model) 9

 Task Set for Software Design
1) Examine the information domain model and Design appropriate data
structures for data objects and their attributes
2) Using the analysis model, Select an architectural style (and design
patterns) that are appropriate for the software
3) Partition the analysis model into design subsystems and allocate these
subsystems within the architecture
a) Design the subsystem interfaces
b) Allocate analysis classes or functions to each subsystem
4) Create a set of design classes or components
a) Translate each analysis class description into a design class
b) Check each design class against design criteria; consider inheritance
issues
c) Define methods associated with each design class
d) Evaluate and select design patterns for a design class or subsystem
10
(More on next slide)
Task Set for Software Design (continued)

5) Design any interface required with external systems or devices

6) Design the user interface
7) Conduct component-level design
a) Specify all algorithms at a relatively low level of abstraction
b) Refine the interface of each component
c) Define component-level data structures
d) Review each component and correct all errors uncovered
8) Develop a deployment model
▪ Show a physical layout of the system, revealing which components will be
located where in the physical computing environment
11
Design Quality
 Quality's Role
• The importance of design is quality
• Design is the place where quality is promoted
• Provides representations of software that can be assessed for quality
• Accurately translates a customer's requirements into a finished software
product or system
• Serves as the foundation for all software engineering activities that follow
• Without design, we risk building an unstable system that
• Will fail when small changes are made
• May be difficult to test
• Cannot be assessed for quality later in the software process when time is
short and most of the budget has been spent
• The quality of the design is assessed through a series of formal technical
13
reviews or design walkthroughs
 Goals of a Good Design
• The design must implement all of the explicit requirements contained in the
analysis model
• It must also accommodate all of the implicit requirements desired by the
customer
• The design must be a readable and understandable guide for those who
generate code, and for those who test and support the software
• The design should provide a complete picture of the software, addressing the
data, functional, and behavioral domains from an implementation perspective

"Writing a clever piece of code that works is one thing; designing something
that can support a long-lasting business is quite another."
14
Design Quality Guidelines

1) A design should exhibit an architecture that

a) Has been created using recognizable architectural styles or patterns
b) Is composed of components that exhibit good design characteristics
c) Can be implemented in an evolutionary fashion, thereby facilitating
implementation and testing
2) A design should be modular; that is, the software should be logically
partitioned into elements or subsystems
3) A design should contain distinct representations of data, architecture,
interfaces, and components
4) A design should lead to data structures that are appropriate for the
classes to be implemented and are drawn from recognizable data
patterns (more on next slide) 15
Quality Guidelines (continued)
5) A design should lead to components that exhibit independent functional
characteristics
6) A design should lead to interfaces that reduce the complexity of
connections between components and with the external environment
7) A design should be derived using a repeatable method that is driven by
information obtained during software requirements analysis
8) A design should be represented using a notation that effectively
communicates its meaning

"Quality isn't something you lay on top of subjects and objects

like tinsel on a Christmas tree."
16
Design Concepts
 Design Concepts
• Abstraction
• Procedural abstraction – a sequence of instructions that have a specific and
limited function
• Data abstraction – a named collection of data that describes a data object
• Architecture
• The overall structure of the software and the ways in which the structure
provides conceptual integrity for a system
• Consists of components, connectors, and the relationship between them
• Patterns
• A design structure that solves a particular design problem within a specific
context
• It provides a description that enables a designer to determine whether the
pattern is applicable, whether the pattern can be reused, and whether the
pattern can serve as a guide for developing similar patterns 18
Design Concepts (continued)
• Modularity
• Separately named and addressable components (i.e., modules) that are
integrated to satisfy requirements (divide and conquer principle)
• Makes software intellectually manageable so as to grasp the control paths,
span of reference, number of variables, and overall complexity
• Information hiding
• The designing of modules so that the algorithms and local data contained within
them are inaccessible to other modules
• This enforces access constraints to both procedural (i.e., implementation) detail
and local data structures
• Functional independence
• Modules that have a "single-minded" function and an dislike to excessive
interaction with other modules
• High cohesion – a module performs only a single task
• Low coupling – a module has the lowest amount of connection needed
19 with
 Design Concepts (continued)
• Stepwise refinement
• Development of a program by successively refining levels of procedure detail
• Complements abstraction, which enables a designer to specify procedure and
data and yet suppress low-level details
• Refactoring
• A reorganization technique that simplifies the design (or internal code
structure) of a component without changing its function or external behavior
• Removes redundancy, unused design elements, inefficient or unnecessary
algorithms, poorly constructed or inappropriate data structures, or any other
design failures
• Design classes
• Refines the analysis classes by providing design detail that will enable the
classes to be implemented.
• Creates a new set of design classes that implement a software infrastructure to
support the business solution. 20
Types of Design Classes
• User interface classes – define all abstractions necessary for human-computer
interaction (usually via metaphors of real-world objects)
• Business domain classes – refined from analysis classes; identify attributes and
services (methods) that are required to implement some element of the
business domain
• Process classes – implement business abstractions required to fully manage the
business domain classes
• Persistent classes – represent data stores (e.g., a database) that will stick at
beyond the execution of the software
• System classes – implement software management and control functions that
enable the system to operate and communicate within its computing
environment and the outside world .
21
Characteristics of a Well-Formed Design Class
• Complete and sufficient
• Contains the complete encapsulation of all attributes and methods that exist for
the class
• Contains only those methods that are sufficient to achieve the intent of the class
• Primitiveness
• Each method of a class focuses on accomplishing one service for the class
• High cohesion
• The class has a small, focused set of responsibilities and single-mindedly applies
attributes and methods to implement those responsibilities.
• Low coupling
• Collaboration of the class with other classes is kept to an acceptable minimum
• Each class should have limited knowledge of other classes in other subsystems
22
The Design Model

Component-level Design

Interface Design

Architectural Design

Data/Class Design
 Dimensions of the Design Model
High

Analysis model
Abstraction Dimension

Design model

Data/Class Architectural Interface Component-level Deployment-level

Low Elements Elements Elements Elements Elements

Process Dimension (Progression)

Introduction
• The design model can be viewed in two different dimensions
• (Horizontally) The process dimension indicates the evolution of the parts of
the design model as each design task is executed.
• (Vertically) The abstraction dimension represents the level of detail as each
element of the analysis model is transformed into the design model and then
iteratively refined
• Elements of the design model use many of the same UML diagrams used in the
analysis model
• The diagrams are refined and elaborated as part of the design
• More implementation-specific detail is provided
• Importance is placed on
• Architectural structure and style
• Interfaces between components and the outside world
• Components that reside within the architecture
25
(More on next slide)
Introduction (continued)
• Design model elements are not always developed in a sequential fashion
• Preliminary architectural design sets the stage
• It is followed by interface design and component-level design, which
often occur in parallel
• The design model has the following layered elements
• Data/class design
• Architectural design
• Interface design Component-level Design

• Component-level design Interface Design

• A fifth element that follows all of Architectural Design

the others is deployment-level design Data/Class Design

26
Design Elements
• Data/class design
• Creates a model of data and objects that is represented at a high level of
abstraction
• Architectural design
• Depicts the overall layout of the software
• Interface design
• Tells how information flows into and out of the system and how it is
communicated among the components defined as part of the architecture
• Includes the user interface, external interfaces, and internal interfaces
• Component-level design elements
• Describes the internal detail of each software component by way of data
structure definitions, algorithms, and interface specifications
• Deployment-level design elements
• Indicates how software functionality and subsystems will be allocated
27
within the physical computing environment that will support the software
Pattern-based Software Design(Design Pattern)
• Mature engineering disciplines make use of thousands of design patterns for such
things as buildings, highways, electrical circuits, factories, weapon systems, vehicles,
and computers
• Design patterns also serve a purpose in software engineering
• Architectural patterns
• Define the overall structure of software.
• Indicate the relationships among subsystems and software components.
• Define the rules for specifying relationships among software elements.

28
☺
Cont…
• Design patterns
• Address a specific element of the design such as an aggregation of
components or solve some design problem, relationships among
components, or the mechanisms for effecting inter-component
communication.
• Consist of creational, structural, and behavioral patterns
• Coding patterns
• Describe language-specific patterns that implement an algorithmic or
data structure element of a component, a specific interface protocol,
or a mechanism for communication among components .
Design documentation
1. The Design Specification addresses different aspects of the design model
and is completed as the designer refines his representation of the software.
First, the overall scope of the design effort is described. Much of the
information presented here is derived from the System Specification and the
analysis model (Software Requirements Specification).
2. Next, the data design is specified. Database structure, any external file
structures, internal data structures, and a cross reference that connects data
objects to specific files are all defined.
3. The architectural design indicates how the program architecture has been
derived from the analysis model. In addition, structure charts are used to
represent the module hierarchy (if applicable).
 Cont…
4. The design of external and internal program interfaces is represented
and a detailed design of the human/machine interface is described. In
some cases, a detailed prototype of a GUI may be represented.
5. Components—separately addressable elements of software such as
subroutines, functions, or procedures—are initially described with an
English-language processing narrative. The processing narrative explains
the procedural function of a component (module). Later, a procedural
design tool is used to translate the narrative into a structured description.
6. The Design Specification contains a requirements cross reference. The
purpose of this cross reference (usually represented as a simple matrix) is
(a) to establish that all requirements are satisfied by the software design
and (b) to indicate which components are critical to the implementation of
specific requirements.
7. The first stage in the development of test documentation is also
contained in the design document. Once program structure and
interfaces have been established, we can develop guidelines for
testing of individual modules and integration of the entire package. In
some cases, a detailed specification of test procedures occurs in
parallel with design. In such cases, this section may be deleted from
the Design Specification.
8. Design constraints, such as physical memory limitations or the
necessity for a specialized external interface, may dictate special
requirements for assembling or packaging of software. Special
considerations caused by the necessity for program overlay, virtual
memory management, high-speed processing, or other factors may
cause modification in design derived from information flow or
structure. In addition, this section describes the approach that will be
used to transfer software to a customer site.
9. The final section of the Design Specification contains
supplementary data.
Algorithm descriptions, alternative procedures, tabular data,
excerpts from other documents, and other relevant information are
presented as a special note or as a separate appendix.
It may be advisable to develop a Preliminary
Operations/Installation Manual and include it as an appendix to the
design document.
Modular Design
Cohesion
• Cohesion is the measure of strength of the association of elements
within a module. Modules whose elements are strongly and
genuinely related to each other are desired. A module should be
highly cohesive.
Types of Cohesion
• There are 7 types of cohesion in a module
• Coincidental Cohesion – A module has coincidental cohesion if its elements
have no meaningful relationship to one another. It happens when a module is
created by grouping unrelated instructions that appear repeatedly in other
modules.
• Logical Cohesion – A logically cohesive module is one whose elements
perform similar activities and in which the activities to be executed are
chosen from outside the module. Here the control parameters are passed
between those functions. For example, Instructions grouped together due to
certain activities, like a switch statement. For ex. A module that performs all
input & output operations.
• Temporal Cohesion – A temporally cohesive module is one whose elements
are functions that are related in time. It occurs when all the elements are
interrelated to each other in such a way that they are executed a single time.
For ex. A module performing program initialization.
• Procedural Cohesion – A procedurally cohesive module is one whose elements
are involved in different activities, but the activities are sequential. Procedural
cohesion exists when processing elements of a module are related and must be
executed in a specified order. For example, Do-while loops.
• Communication Cohesion – A communicationally cohesive module is one
whose elements perform different functions, but each function references the
same input information or output. For example, Error handling modules.
• Sequential Cohesion – A sequentially cohesive module is one whose functions are
related such that output data from one function serves as input data to the next
function. For example, deleting a file and updating the master record or function
calling another function.
• Functional Cohesion – A functionally cohesive module is one in which all of the
elements contribute to a single, well-defined task. Object-oriented languages tend
to support this level of cohesion better than earlier languages do. For example,
When a module consists of several other modules.
Coupling
• Coupling is the measure of the interdependence of one module to
another. Modules should have low coupling. Low coupling minimizes
the "ripple effect" where changes in one module cause errors in
other modules.
 Types of Coupling
• There are 6 types of coupling in the modules are
• No direct Coupling – These are independent modules and so are not
really components of a single system. For e.g., this occurs between
modules a and d.
• Data Coupling – Two modules are data coupled if they communicate
by passing parameters. This has been told to you as a "good design
principle" since day one of your programming instruction. For e.g.,
this occurs between module a and c.
• Stamp Coupling – Two modules are stamp coupled if they
communicate via a passed data structure that contains more
information than necessary for them to perform their functions. For
e.g., this occurs between modules b and a.
Cont…
• Control Coupling – Two modules are control coupled if they
communicate using at least one "control flag". For e.g., this occurs
between modules d and e.
• Common Coupling – Two modules are common coupled if they both
share the same global data area. Another design principle you have
been taught since day one: don't use global data. For e.g., this occurs
between modules c, g and k.
• Content Coupling – Two modules are content coupled if:
• One module changes a statement in another (Lisp was famous for this ability).
• One module references or alters data contained inside another module.
• One module branches into another module.
Difference between Cohesion and Coupling
No Cohesion Coupling

Cohesion is the measure of strength of the Coupling is the measure of the interdependence
1.
association of elements within a module. Of one module to another.
2. A module should be highly cohesive. Modules should have low coupling.
Cohesion is a property or characteristics Coupling is a property of a collection of
3.
of an individual module. modules.

The advantage of cohesion is the ability to The advantage of coupling is the ability to bind
4. avoid changing source and target systems systems by sharing behavior, and bound data,
just to facilitate integration. versus simple sharing information.
The fact that systems coupled could cease to
5. The fact that a single system failure won’t function if one or more of the coupled systems
bring down all connected systems. go down.
Design Heuristics
• Once program structure has been developed, effective modularity can be
achieved by applying the design concepts. The program structure can be
manipulated according to the following set of heuristics:
1. Evaluate the "first iteration" of the program structure to Reduce coupling and
Improve cohesion.
Once the program structure has been developed, modules may be exploded or
imploded with an eye toward improving module independence. An exploded
module becomes two or more modules in the final program structure. An imploded
module is the result of combining the processing implied by two or more modules.
An exploded module often results when common processing exists in two or more
modules and can be redefined as a separate cohesive module. When high coupling
is expected, modules can sometimes be imploded to reduce passage of control,
reference to global data, and interface complexity.
2. Attempt to minimize structures with high fan-out; strive for fan-in as depth
increases.

• The structure shown inside the cloud in Figure below does not make effective use
of factoring. All modules are “pancaked” below a single control module. In
general, a more reasonable distribution of control is shown in the upper
structure. The structure takes an oval shape, indicating a number of layers of
control and highly utilitarian modules at lower levels.
3. Keep the scope of effect of a module within the scope of control of that
module.
• The scope of effect of module e is defined as all other modules that are affected
by a decision made in module e. The scope of control of module e is all modules
that are subordinate and ultimately subordinate to module e. Referring to Figure
above, if module e makes a decision that affects module r, we have a violation
of this heuristic, because module r lies outside the scope of control of module e.
4. Evaluate module interfaces to reduce complexity and redundancy and improve
consistency.

• Module interface complexity is a prime cause of software errors. Interfaces

should be designed to pass information simply and should be consistent with
the function of a module. Interface inconsistency (i.e., seemingly unrelated data
passed via an argument list or other technique) is an indication of low cohesion.
The module in question should be reevaluated.
5. Define modules whose function is predictable, but avoid modules that are
overly restrictive.
• A module is predictable when it can be treated as a black box; that is, the same
external data will be produced regardless of internal processing details. Modules
that have internal "memory" can be unpredictable unless care is taken in their
use. A module that restricts processing to a single sub-function exhibits high
cohesion and is viewed with favor by a designer. However, a module that
arbitrarily restricts the size of a local data structure, options within control flow,
or modes of external interface will invariably require maintenance to remove
such restrictions.
6. Strive for “controlled entry” modules by avoiding "pathological connections."
• This design heuristic warns against content coupling. Software is easier to
understand and therefore easier to maintain when module interfaces are
constrained and controlled. Pathological connection refers to branches or
references into the middle of a module.
 Architectural Design
• The software architecture of a program or computing system is the
structure or structures of the system, which comprise software
components, the externally visible properties of those components
and the relationships among them.
• So, architecture is not the operational software. Rather, it is a
representation that enables a software engineer to:
1. Analyze the effectiveness of the design in meeting its stated requirements.
2. Consider architectural alternatives at a stage when making design changes
is still relatively easy, and
3. Reducing the risks associated with the construction of the software.
Why is architecture important? 3 reasons are:
1. Representations of software architecture are an enabler for communication
between all parties interested in the development of a computer – based
system.
2. Architecture highlights early design decisions that will have a profound
impact on all software engineering work that follows.
3. Architecture constitutes a relatively small, intellectually graspable model
of how the system is structured and how its components work together.
Software Architecture

• It covers the overall structure of the software and the ways in which that
structure provides conceptual integrity for a system.
• So, architecture is the hierarchical structure of program components
(modules), the manner in which these components interact and the structure
of data that are used by the components.
• An architectural design can be represented using any of the 5 – models given
below:
• Structural Models – They represent architecture as an organized collection of program
components.
• Framework Models – They increase the level of design abstraction by attempting to
identify repeatable architectural design frameworks.
• Dynamic Models – They address the behavioral aspects of the program architecture
(states).
• Process Models – They focus on the design of the business or technical process that the
system must accommodate.
• Functional Models – They can be used to represent the functional hierarchy of a system.
• A number of different architectural description languages (ADLs) have been
developed to represent these models.
Control Hierarchy

• It is also called as program structure.

• It 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 repetitions of operations nor is
it necessarily applicable to all architectural styles.
• The most commonly used notation to represent control hierarchy is the tree–
like diagram that represents hierarchical control for call and return
architectures.
Cont..
• ‘Depth’ and ‘Width’ provide an indication of the number of levels of control
and overall span control respectively.
• ‘Fan-out’ is a measure of the number of modules that are directly controlled
by another module. For e.g. Fan-out of M is 3.
• ‘Fan-in’ indicates how many modules directly control a given module. For e.g.
Fan-in of r is 4.
• 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. For e.g. 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.
Design Notations
• In software design the representation schemes are of fundamental
importance.
• A good design can clarify the interrelationships and actions of
interest, while poor notation can compliance and interfere with good
practice.
• At least three levels of design specifications exist:
• External design specifications, which describe the external
characteristics of a software system;
• Architectural design specifications, which describe the structure of
the system;
• Detailed design specifications, which describe control flow, data
representation, and other algorithmic details within the modules.
Some common design notations are as follows:
• Data flow diagrams (Bubble chart)
• These are directed graphs in which the nodes specify processing
activities and arcs (lines with arrow heads) specify the data items
transmitted between the processing nodes.
• Like flowcharts, data flow diagrams can be used at any desired level
of abstraction.
• Unlike flowcharts, data flow diagrams do not indicate decision logic
or conditions under which various processing nodes in the diagram
might be activated.
• They might represent data flow :-
• Between individual statements or blocks of statements in a routine,
• Between sequential routines,
• Between concurrent processes,
• Between geographically remote processing units.
• The DFDs have basic two levels of development, they are as follows –
• A Level 0 DFD, also known as Fundamental System Model or Context
Model, represents the entire system as a single bubble with incoming
arrowed lines as the input data and outgoing arrowed lines as
output.
• A Level 1 DFD might contain 5 or 6 bubbles with interconnecting
arrows. Each process represented here is the detailed view of the
functions shown in the level 0 DFD.
• Here the rectangular boxes are used to represent the external entities that
may act as input or output outside the system.
• Round Circles are used to represent any kind of transformation process
inside the system.
• Arrow headed lines are used to represent the data object and its direction of
flow.
Following are some guidelines for developing a DFD:-
• Level 0 DFD should depict the entire software system as a single bubble.
• Primary input and output should be carefully noted.
• For the next level of DFD the candidate processes, data objects and stores
should be recognized distinctively.
• All the arrows and bubbles should be labeled with meaningful names.
• Information flow continuity should be maintained in all the levels.
• One bubble should be refined at a time.
• Example: Let us consider a software system called the root mean
square (RMS) calculating system which reads 3 integers in the range
from – 1000 to + 1000 and calculate their RMS value and then display
it.
Structure Charts
• They are used during architectural design for documenting
hierarchical structure, parameters and interconnections in a system.
• In a structure chart a module is represented by a box with the
module name written in the box.
• An arrow from a module A to a module B represents that the module
A invokes module B. the arrow is labeled by the parameters received
by B as input and the parameters returned by B.
• It differs from a flow chart in two ways –
• A structure chart has no decision boxes and
• The elements need not be shown in a sequential order.
• Structure chart are useful to represent the model of the system
however it is not useful for representing the final design as it does not
give all the information needed about the design.
HIPO (Hierarchy – Process – input – Output) Diagrams:

• It was developed at IBM labs as design representation schemes for

top-down software development, and as external documentation
aids for released products.
• It contains
• A visual table of contents – it’s a directory referencing the set of diagrams in
the package, it contains a tree-structured directory, a summary of contents of
each over view diagram and a legend of symbol definitions.
• A set of overview diagrams – they specify the functional processes in a
system. Each overview diagram describes the inputs, processing steps and
output for the explained function.
• A set of detail diagrams – which has the same format as over view diagrams.
Structured English
• Structured English can be used to provide a step-by step specification
for an algorithm. It can be used at any desirable level of detail.
• A rigid subset of the English language omitting adjectives, adverbs,
compound and complex sentences, all verb modes except
imperative and most punctuation.
• Result: A language containing a limited set of conditional and logic
statements with nouns and strong verbs Standards vary between
organizations –
• objectives of: conciseness, preciseness and lack of ambiguity apply to
all variants.
 Structured Flowcharts:
• Flowcharts are the traditional means of specifying and documenting
algorithmic details in a software system.
• They are graphical representation to show the flow of information
and control from element to element in a system.
• The information flow represented here is sequential.
• It is a pictorial representation of an algorithm that uses symbols to
show the operations and decisions to be followed.
• They incorporate - Rectangular boxes representing some action,
Diamond shaped boxes for decisions, directed arcs (arrow headed
lines) for specifying interconnection and information flow between
the boxes and various other graphical shapes for the representation
of data stores, input, output etc.
• Decision tables
• Decision tables can be used to specify complex decision logic in a high level software
specification. They are also useful for specifying algorithm logic during detailed design.
• At this level of usage, decision tables can be specified and translated into source code
logic.
• Pseudocode
• Pseudocode notation can be used in both the architectural and detailed design.
• It can be used at any desired level of abstraction.
• Using pseudocode the designer describes system characteristics using short, concise,
English language phrases that are structured by key words such as If- Then-Else, While-
Do and End.
• Key words and indentation describes the flow of control, while the English phrases
describe processing actions.
• Pseudocode can replace flowcharts and reduce the amount of external documentation
required to describe a system.
• Converting pseudocode to a programming language is much easier as compared to
converting a flowchart.
 Procedure Templates:
• The format of procedure interface specification is shown below.
• In the early stages of architectural design, only the information in level 1 need be
supplied.
• As design progress, the information on levels 2, 3 and 4 can be included in successive
steps.
• The term “side effect” in fig shown below means any effect a procedure can exert on
the processing environment that is not obvious from the procedure name and
parameters.
• Modifications to global variables, reading or writing a file, opening or closing a file,
or calling a procedure that in turn exhibits side effects are all examples of side
effects.
• It is recommended that only the information on level 1 in fig shown below be provided
during initial architectural design, because detailed specification of side effects,
exception handling, processing algorithms, and concrete data representations will
sidetrack the designer into inappropriate levels of detail too soon.
PROCEDURE NAME:
PART OF: (sub-system name & number) Level 1
CALLED BY:
PURPOSE:
DESIGNER/DATE(s):
PARAMETERS: (names, modes, attributes, purposes)
INPUT ASSERTION: (preconditions) Level 2
OUTPUT ASSERTION: (postconditions)
GLOBALS: (names, modes, attributes, purposes, shared with)
SIDE EFFECTS:
LOCAL DATA STRUCTURES: (names, attributes, purposes)
EXCEPTIONS: (conditions, responses) Level 3
TIMING CONSTRAINTS:
OTHER LIMITATIONS:
PROCEDURE BODY: (pseudocode, structured English, structured flowchart, decision table) Level 4
Mapping Requirements into Software Architecture
• There are two types of information flow which are the drivers for the
mapping approach:
• Transform Flow.
• Transaction Flow.
• Transform Flow – Information must enter and exit software in an
“external world” form.
• External data (like data typed on keyboard, tones on a telephone line
and video images in multimedia application) must be converted into
an internal form for processing.
• Information enters the system along paths that transform external
data into an internal form.
• These paths are identified as. At the kernel of the software, a
transition occurs. incoming flow
• Incoming data are passed through a ‘transform center’ and begin to move along
paths that now lead “out” of the software.
• Data moving along these paths are called outgoing flow.
• The overall flow of data occurs in a sequential manner and follows straight line
paths. When a segment of a DFD exhibits these characteristics, ‘transform flow’ is
present.
Key Characteristics of Transform Flow:
• Sequential Data Flow: Data moves through the system in a linear, step-by-step
manner.
• Incoming Flow: Data enters the system along specific paths, which are identified as
incoming flow.
• Transform Center: At the core of the software, data is transformed or processed.
• Outgoing Flow: After transformation, data exits the system along outgoing paths.
• External World Form: Information must enter and exit software in an "external
world" form, meaning external data (like data typed on a keyboard) must be
converted into an internal form for processing, and then converted back to external
form for output.
Transaction Flow
• The fundamental system model implies transaction flow; therefore, it is
possible to characterize all data flow by a single data item, called a
transaction that triggers other data flow along one of the many paths.
• So, when DFD takes the form as shown below, transaction flow is present.
• Transaction flow is characterized by data moving along an incoming path that
converts external world information into a transaction.
• The transaction is evaluated and based on its value; flow along one of many
action paths is initiated.
• “The hub of information flow from which many actions path originate is
called a transaction center”.
• It should be note that, within a DFD for a large system, both transform flow
and transaction flow may be present.
• For example, in a transaction – oriented flow, information flow along an
action path may have transform flow characteristics.
Transform Mapping
• “Transform Mapping is a set of design steps that allow a DFD with
transform flow characteristics to be mapped into a specific
architectural style”.
• Structural design provides 2 strategies to guide transformation of a
DFD into a structure chart:
• Transform Analysis
• Transaction Analysis
The SafeHome security system
 Transform Analysis (Transaction mapping) –
• It identifies the primary functional components (modules) and the high level
input and output for these components.
• First step in transform analysis is to divide the DFD into three parts:
• Input
• Logical processing
• Output
• The input portion in the DFD includes processes that transform input data
from physical (e.g., character from terminal) to logical form (e.g., internal
tables, lists etc).
• Each input portion is called ‘afferent branch’(Arrival -bringing signals to the
brain). There may be more than one afferent branch in a DFD.
• The output portion of a DFD transforms output data from logical to physical
form. Each output portion is called on ‘efferent branch’( Exit -sending signals
from the brain). The remaining portion of a DFD is called central transform.
• In second step of transform analysis, the structure chart is derived by
drawing one functional component for each central transform, for
each afferent and efferent branch.
• Identifying the highest level input and output transforms requires
experience and skill.
• One possible approach is to trace the inputs until a bubble is found
whose output cannot be deduced from its inputs alone.
• Processes which validate input or add information to them are not
central transforms. Processes which sort input of filter data from it
are central transforms.
• The first level of structure chart is produced by representing each
input and output unit as boxes and each transform as a single box.
• In the third step of transform analysis, the structure chart is refined by
adding sub– functions required by each of the high level functional
components.
• Many levels of functional components may be added.
• This process of breaking functional components into subcomponents is
called ‘factoring’. Factoring includes adding, read and write modules,
error handling modules, initialization and termination processes.
• The factoring process is continued until all bubbles in the DFD are
represented in the structure chart.
Example: Let us consider a software system called the root mean square
(RMS) calculating system which reads 3 integers in the range from – 1000
to + 1000 and calculate their RMS value and then display it. Apply
transform analysis to design its structure chart.
Sol:Structure chart for RMS calculator
 Transaction analysis (Transaction mapping)
• It is an alternative to transform analysis and is useful while designing
transaction processing programs.
• A transform centered system is characterized by similar processing steps for
each data item processed by input, process and output systems.
• In a transaction driven system, one of several possible paths through the
DFD is traversed depending upon the input data item.
• A transaction is any element of data that triggers an action. Every transaction
carries a tag identifying its type.
• Transaction analysis uses this tag to divide the system into transaction
modules and a transaction center module. This is an architectural design.
User Interface Design
• Interface design focuses on three areas of concern:
1. The design of interfaces between software components,
2. The design of interfaces between the software and other nonhuman
producers and consumers of information (i.e., other external entities), and
3. The design of the interface between a human (i.e., the user) and the
computer.
User Interface Design Principles

Theo Mandel(Senior User Experience Researcher) coins three “golden

rules” for user interface design:
1. Place the user in control.
2. Reduce the user’s memory load.
3. Make the interface consistent.
1. Place the user in control
• During a requirements gathering session for a major new information
system, a key user was asked about the attributes of the window
oriented graphical interface.
• Mandel defines a number of design principles that allow the user to
maintain control:
• Define interaction modes in a way that does not force a user into
unnecessary or undesired actions.
• Provide for flexible interaction.
• Allow user interaction to be interruptible and undoable.
• Streamline interaction as skill levels advance and allow the interaction to be
customized.
• Hide technical internals from the casual user.
• Design for direct interaction with objects that appear on the screen.
2. Reduce the user’s memory load
• The more a user has to remember, the more error-prone will be the
interaction with the system. It is for this reason that a well-designed
user interface does not tax the user’s memory.
• Whenever possible, the system should “remember” pertinent
information and assist the user with an interaction scenario that
assists recall.
• Mandel defines design principles that enable an interface to reduce
the user’s memory load:
• Reduce demand on short – term memory.
• Establish meaningful defaults.
• Define shortcuts that are in-built.
• The visual layout of the interface should be based on a real world metaphor.
• Reveal information in a progressive fashion.
3. Make the interface consistent
• The interface should present and acquire information in a consistent
fashion. This implies that
• All visual information is organized according to a design standard that is
maintained throughout all screen displays,
• Input mechanisms are constrained to a limited set that are used consistently
throughout the application, and
• Mechanisms for navigating from task to task are consistently defined and
implemented.
• Mandel defines a set of design principles that help make the
interface consistent:
• Allow the user to put the current task into a meaningful context.
• Maintain consistency across a family of applications.
• If past interactive models have created user expectations, do not make
changes unless there is a compelling reason to do so.
The User Interface Design Process
• The design process for user interfaces is iterative and can be
represented using a spiral model. Referring to Figure below, the user
interface design process encompasses four distinct framework
activities:
• User, task, and environment analysis and modeling
• Interface design
• Interface construction
• Interface validation
• The spiral shown in Figure below implies that each of these tasks will
occur more than once, with each pass around the spiral representing
additional elaboration of requirements and the resultant design. In
most cases, the implementation activity involves prototyping—the
only practical way to validate what has been designed.
Fig User Interface Design Process
a. User, task, and environment analysis and modeling

• The initial analysis activity focuses on the profile of the users who will
interact with the system. Skill level, business understanding, and
general receptiveness to the new system are recorded; and different
user categories are defined. For each user category, requirements are
elicited. In essence, the software engineer attempts to understand
the system perception for each class of users.
• Once general requirements have been defined, a more detailed task
analysis is conducted. Those tasks that the user performs to
accomplish the goals of the system are identified, described, and
elaborated (over a number of iterative passes through the spiral).
b. Interface design
• The information gathered as part of the analysis activity is used to create an
analysis model for the interface. Using this model as a basis, the design activity
commences. The goal of interface design is to define a set of interface objects
and actions (and their screen representations) that enable a user to perform all
defined tasks in a manner that meets every usability goal defined for the
system.
c. Interface construction
• The implementation activity normally begins with the creation of a prototype
that enables usage scenarios to be evaluated. As the iterative design process
continues, a user interface tool kit may be used to complete the construction of
the interface. Interface validation
d. Validation focuses on
• The ability of the interface to implement every user task correctly, to
accommodate all task variations, and to achieve all general user requirements;
Milestones, Walkthroughs and Inspections
• These activities help in exposing errors, provide increased project
communication, keeping the project in schedule, and verification
that the design satisfies the requirements.
• Milestones
1. These are a set of occasions in project design where the proper
progress of the project can be assessed in such a way that corrective
measures could be taken if necessary.
a. The two major milestones are –
• Preliminary Design Review (PDR) :- Its normally held near the end of architectural
design and prior to detailed design.
• Critical design Review (CDR) :- Its normally held at the end of detailed design and prior
to implementation.
b. The major goal of Preliminary Design Review(PDR) is to demonstrate the
externally observable characteristics and architectural structure of the product
which would satisfy the customer’s requirements.
• Functional characteristics,
• performance attributes,
• external interface,
• user dialogs,
• report formats,
• exception conditions and exception handling
• and future enhancements
are reviewed during PDR.
c. The Critical Design Review CDR provides a final management decision point
, to build or cancel the system.
 Walkthroughs(systematic review process)
• A structured walkthrough is an in-depth, technical review of some aspects of
a software system. Walkthroughs can be anytime , during any phase of a
software project.
• A walkthrough team consists of 4 to 6 people. The person whose material is
being reviewed is responsible for providing copies of the review materials to
the members of the walkthrough group in advance of the walkthrough
session and the team members are responsible for understanding the
reviewing material before the session.
• During the walkthrough the reviewed “walks through” the material while the
reviewers look for errors, request clarification and explore problem areas in
the material under review.
• High-level managers should not attend walkthrough sessions as the aim of
walkthroughs is error detection not corrective action. Its important to note
that the material is reviewed not the person whose material is being
reviewed.
Inspections
• Design inspections are conducted by teams of trained inspectors
who have a check list of items to be examined.
• Special forms are used to record problems encountered.
• A typical inspection team consists of a Moderator or Secretary, a
Designer, an Implementor and a Tester. The Designer, Implementor
and Tester may or may not be the people responsible for the actual
design, implementation and testing of the product being inspected.
• The team members are trained for their specific roles and typically
conduct a dual 2-hrs sessions per day.
 Software Configuration Management
1. Software configuration management (SCM) is an umbrella activity that is
applied throughout the software process, because change can occur at any
time.
2. SCM activities are developed to
1. Identify change,
2. Control change,
3. Ensure that change is being properly implemented, and
4. Report changes to others who may have an interest.
3. It is important to make a clear distinction between software support and
software configuration management.
1. Support is a set of software engineering activities that occur after software has been
delivered to the customer and put into operation.
2. Software configuration management is a set of tracking and control activities that begin
when a software engineering project begins and terminate only when the software is taken
out of operation(retired).
4. A primary goal of software engineering is to improve the ease with which changes
can be accommodated and reduce the amount of effort expended when changes must
be made.
5. The output of the software process is information that may be divided into three
broad categories:
1. Computer programs (both source level and executable forms);
2. Documents that describe the computer programs (targeted at both technical practitioners and
users), and
3. Data (contained within the program or external to it).
4. The items that comprise all information produced as part of the software process are
collectively called a software configuration.
6. As the software process progresses, the number of software configuration items
(SCIs) grows rapidly. A System Specification issues a Software Project Plan and
Software Requirements Specification (as well as hardware related documents). These
in turn issue other documents to create a hierarchy of information. If each SCI simply
spawned other SCIs, little confusion would result. Unfortunately, another variable enters
the process—change. Change may occur at any time, for any reason. In fact, the First
Law of System Engineering states: “No matter where you are in the system life cycle,
the system will change, and the desire to change it will persist throughout the life
cycle.”
7. There are four fundamental sources of change:
1. New business or market conditions dictate changes in product requirements or
business rules.
2. New customer needs demand modification of data produced by information
systems, functionality delivered by products, or services delivered by a computer-
based system.
3. Reorganization or business growth/downsizing causes changes in project priorities or
software engineering team structure.
4. Budgetary or scheduling constraints cause a redefinition of the system or product.
8. Software configuration management is a set of activities that have been
developed to manage change throughout the life cycle of computer software.
SCM can be viewed as a software quality assurance activity that is applied
throughout the software process.
 Baselines
• A baseline is a software configuration management concept that helps us to control
change without seriously blocking justifiable change. The IEEE defines a baseline as: “A
specification or product that has been formally reviewed and agreed upon, that
thereafter serves as the basis for further development, and that can be changed only
through formal change control procedures.
• Consider the doors to the kitchen in a large restaurant. One door is marked OUT and the other is
marked IN. The doors have stops that allow them to be opened only in the appropriate direction.
• If a waiter picks up an order in the kitchen, places it on a tray and then realizes he has selected the
wrong dish, he may change to the correct dish quickly and informally before he leaves the kitchen.
• If, however, he leaves the kitchen, gives the customer the dish and then is informed of his error, he
must follow a set procedure:
• Look at the check to determine if an error has occurred,
• Apologize profusely,
• Return to the kitchen through the IN door,
• Explain the problem, and so forth.
• A baseline is analogous to the kitchen doors in the restaurant. Before a software configuration
item becomes a baseline, change may be made quickly and informally. However, once a
baseline is established, we figuratively pass through a swinging oneway door. Changes can be
made, but a specific, formal procedure must be applied to evaluate and verify each change.
• In the context of software engineering, a baseline is a milestone in the development of
software that is marked by the delivery of one or more software configuration items and the
approval of these SCIs that is obtained through a formal technical review.
• For example, the elements of a Design Specification have been documented and reviewed. Errors are found and
corrected. Once all parts of the specification have been reviewed, corrected and then approved, the Design
Specification becomes a baseline. Further changes to the program architecture (documented in the Design
Specification) can be made only after each has been evaluated and approved. Although baselines can be
defined at any level of detail, the most common software baselines are shown in Figure below.
• The progression of events that lead to a baseline is also illustrated in Figure below.
• Software engineering tasks produce one or more SCIs. After SCIs are reviewed and approved,
they are placed in a project database (also called a project library or software repository). When
a member of a software engineering team wants to make a modification to a baselined SCI, it is
copied from the project database into the engineer's private work space. However, this
extracted SCI can be modified only if SCM controls are followed. The arrows in Figure above
illustrate the modification path for a baselined SCI.
Software Configuration Items(SCI)
• A SCI could be considered to be a single section of a large
specification or one test case in a large suite of tests.
• An SCI is a document, an entire suite of test cases, or a named
program component (e.g., a C++ function or an Ada package).
• In addition to the SCIs that are derived from software work products,
many software engineering organizations also place software tools
under configuration control. That is, specific versions of editors,
compilers, and other CASE tools are "frozen" as part of the software
configuration. Because these tools were used to produce
documentation, source code, and data, they must be available when
changes to the software configuration are to be made.
• Although problems are rare, it is possible that a new version of a tool (e.g., a
compiler) might produce different results than the original version. For this
reason, tools, like the software that they help to produce, can be baselined as
part of a comprehensive configuration management process. In reality, SCIs
are organized to form configuration objects that may be cataloged in the
project database with a single name.
• A configuration object has a name, attributes, and is "connected" to other
objects by relationships. Referring to Figure below, the configuration objects,
Design Specification, data model, component N, source code and Test
Specification are each defined separately. However, each of the objects is
related to the others as shown by the arrows. A curved arrow indicates a
• compositional relation. That is, data model and component N are part of the
object Design Specification. A double-headed straight arrow indicates an
interrelationship.
• If a change were made to the source code object, the interrelationships
enable a software engineer to determine what other objects (and SCIs) might
be affected.
SCM Process

• The five basic SCM tasks are

• Identification of objects,
• Version control,
• Change control,
• Configuration auditing and
• Reporting.
1. Identification of objects – To control and manage SCIs, each of them must be separately
named and then organized using object- oriented approach. The SCIs can be classified in to
two kinds of objects –
a. Basic objects and
b. Aggregate objects.
a. Basic object – It’s a “unit of text” created by a software engineer during analysis, design,
coding or testing phases. For example, a basic object might be a section of a requirements
specification, a source listing for a component, or a suite of test cases that are used to
exercise the code.
b. Aggregate object – It’s a collection of basic objects and other aggregate objects. For
example, Design Specification is an aggregate object.
• Each object has a set of unique features for distinct identification. Every object should have
• An unique name,
• A description of the object including its SCI type eg. Document, program or data, a project
identifier and version information,
• A list of resources, which are entities that are processed, provided or required by the object.
2. Version control – It combines various tools and procedures to manage and
control different versions of SCI objects (as a result of change) that are created
during the software engineering process. Clemm describes version control in the
context of SCM:
• “Configuration management allows a user to specify alternative configurations of
the software system through the selection of appropriate versions. This is
supported by associating attributes with each software version, and then
allowing a configuration to be specified [and constructed] by describing the set of
desired attributes”.

• These "attributes" mentioned can be as simple as a specific version number that

is attached to each object or as complex as a string of Boolean variables
(switches) that indicate specific types of functional changes that have been
applied to the system.
3. Change control – For a large system development project, uncontrolled change rapidly leads
to confusion and inconsistencies. Change control includes human procedures and automated
tools to control the reasons for change. The following processes take place when a situation of
change occurs:
i. Change request – A change request is first submitted and then it is evaluated to asses its –
• Technical merit,
• Potential side effects, subsystems and the cost for implementing the change.
ii. Change report – After the evaluation is done, a change report is created that is submitted to the
Change Control Authority/Board (CCA or CCB). CCA or CCB is a group who are responsible for
evaluating the change report and makes the final decision on the status and priority of the change.
This group generates an Engineering Change Order (ECO) for each approved change.
iii. ECO (Engineering Change Order) – It consists of
• The description of the change to be made,
• Constraints that has to be taken care of and
• Criteria for review and audit.
iv. Check out & check in – The object to be changed is “checked out” of the project database, the
decided changes are made and appropriate SQA (Software Quality Assurance) activities are
performed. The object is then “checked in” the project database and appropriate version control
mechanisms are used to create the next version of the software.
4. Formal technical reviews (FTR) & Configuration audit – These two activities are required to ensure that the
change made to the software is properly implemented.

Formal technical reviews (FTR) – It’s a part of Software Quality Assurance (SQA) procedures. The objectives of
FTR are
• To uncover errors in functions, logic or implementation,
• To verify that the software under review should meet its requirement,
• To ensure that the representation of the software is according to the standards,
• To make the project more manageable
• It consists of walkthroughs, inspections and round-robin reviews.
• Software configuration audit – It consists of the following auditing procedures
To check whether the changes specified in the ECO (Engineering Change Order) has been properly
made and to check if any additional modules are added,
To check whether formal technical reviews are conducted for the assessment of technical correctness,
To check whether SE standards are properly followed,
To check whether the change is highlighted in the SCI (Software Configuration Items) documentation
and also the attributes of the configuration object should reflect the change,
To check whether SCM (Software Configuration Management) procedures like noting change,
recording it and reporting it has been properly done,
To check whether all the related SCIs are properly updated.
5. Configuration Status reporting (CSR) – Its an SCM task which summarizes the
activities done so far which includes the following
• The report of all the activities done,
• The report on the persons involved in the above reported activities,
• The report on the time and date when the reported activities were
accomplished,
• The report on various other factors or objects that will be affected due to the
reported activity.
Following are the situations where the CSR needs updating
• Each time when a SCI is assigned a new or updated identification,
• Each time ECO is issued i.e a when a change is approved by the CCA/CCB,
• Each time a configuration audit is conducted.
• The CSR is made available online and is updated occasionally in order to keep
the management and concerned individuals updated on the changes. It
improves the communication among all the people involved.