Q)
EXPLAIN SOFTWARE DESIGN MODEL PROCESS.
Software
design sits at the technical kernel of software engineering. Beginning once
software requirements have been analyzed and specified, software design is the
first of three technical Activities (design, code generation, and test).
The
flow of information during software design is illustrated in Figure.
Using
one of design methods (Software requirements, manifested by the data,
functional, and behavioral models, feed the design task), the design task
produces a data design, an architectural design, an interface design, and a
component design.
The
data design transforms the information domain model
created during analysis into the data structures that will be required
to implement the software.
The
architectural design defines the relationship between major
structural elements of the software. The architectural design representation— the
framework of a computer-based system—can be derived from the system
specification, the analysis model, and the interaction of subsystems defined within
the analysis model.
The
interface design describes how the software communicates
within itself, with systems that interoperate with it, and with humans who use
it. An interface implies a flow of information (e.g., data and/or control) and
a specific type of behavior. Therefore, data and control flow diagrams provide
much of the information required for interface design.
The
component-level design transforms structural elements of the
software architecture into a procedural description of software
components. Information obtained from the class-based models, Flow models and behavior
models serve as the basis for component design.
Design
is the only way that we can accurately translate a customer's requirements into
a finished software product or system. Software design serves as the foundation
for all the software engineering and software support steps that follow.
Without design, we risk building an unstable system—one that will fail when
small changes are made;
one
that may be difficult to test; one whose quality cannot be assessed until late
in the software process, when time is short and many rupees have already been
spent
Q)
EXPLAIN THE SOFTWARE DESIGN AND SOFTWARE QUALITY.
Software
design is an iterative process through which requirements are translated into a
“blueprint” for constructing the software. Initially, the blueprint depicts a
holistic view of software. That is, the design is represented at a high level
of abstraction—a level that can be directly traced to the specific system
objective and more detailed data, functional, and behavioral requirements.
Design and Software Quality
The
importance of software design can be stated with a single word—quality. Design
is the place where quality is fostered in software engineering.
Throughout
the design process, the quality of the evolving design is assessed with a
series of formal technical reviews or design walkthroughs suggests three
characteristics that serve as a guide for the evaluation of a good design:
•
The design must implement all of the explicit requirements contained in the
analysis model, and it must accommodate all of the implicit requirements
desired by the customer.
•
The design must be a readable, understandable guide for those who generate code
and for those who test and subsequently support the software.
•
The design should provide a complete picture of the software, addressing the
data, functional, and behavioral domains from an implementation perspective.
Q)
EXPLAIN THE FUNDAMENTAL SOFTWARE DESIGN CONCEPTS.
Fundamental
software design concepts provide the necessary framework for "getting it
right."
1. Abstraction
2. Refinement
3. Modularity
4. Architecture
5. Control Hierarchy
6. Structural Partitioning
7. Data structures
8. Procedure
9. Information Hiding.
1. Abstraction:
Each
step in the software process is a refinement in the level of abstraction
of the software solution. During system engineering, software is
allocated as an element of a computer-based system. During software
requirements analysis, the software solution is stated in terms
"that are familiar in the problem environment." As we move through
the design process, the level of abstraction is reduced. Finally, the lowest
level of abstraction is reached when source code is generated.
Two
Typesof abstraction are 1. Procedural abstractions and 2. data abstractions.
A
procedural abstraction is a named sequence of instructions that has
a specific and limited function. An example of a procedural abstraction would be
the word open for a door. Open implies a long sequence of procedural steps (e.g.,walk to the
door, reach out and grasp knob, turn knob and pull door, step away from moving
door, etc.).
A
data abstraction is a named collection of data that describes a data object. In
the context of the procedural abstraction open, we can define a data abstraction called door. Like any data object, the data abstraction
for door would
encompass a set of attributes that describe the door (e.g., door type, swing
direction, opening mechanism, weight, dimensions). It follows that the
procedural abstraction open would make use of information contained in the attributes of the
data abstraction door.
2. Refinement
·
Refinement is a top-down design approach.
·
It is a process of elaboration.
·
A program is established for refining levels
of procedural details.
·
A hierarchy is established by decomposing a
statement of function in a stepwise manner till the programming language
statement are reached.
3. Modularity: Modularity is the most common manifestation of separation of
concerns. Software is divided into separately named and addressable components,
sometimes called modules that are integrated to satisfy problem requirements.
It has been stated that “modularity is the single attribute of software that
allows a program to be intellectually manageable”
4. Architecture: 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.
5. Control Hierarchy: Control
hierarchy, also called program structure, represents
the organization of program components (modules) and implies a hierarchy of
control. It does not represent procedural aspects of software such as sequence of
processes, occurrence or order of decisions, or repetition of operations; nor
is it necessarily applicable to all architectural styles.
Different
notations are used to represent control hierarchy for those architectural styles
that are amenable to this representation. The most common is the treelike
diagram (Figure) that represents hierarchical control for call and return
architectures.
Fan-out is a
measure of the number of modules that are directly controlled by another
module. Fan-in indicates how many modules directly control a given module.
6. Structural Partitioning:
If the architectural style of a system is
hierarchical, the program structure can be partitioned both horizontally and
vertically.
Horizontal Partitioning defines separate branches of the modular
hierarchy for each major program function. Control
modules, represented in a darker shade are used to
coordinate communication between and execution of the functions. The simplest
approach to horizontal partitioning defines three partitions—input, data
transformation (often called
processing) and
output.
Vertical Partitioning often called factoring, suggests
that control (decision making) and work should be distributed top-down in the
program structure. Top level modules should perform control functions and do
little actual processing work.
Modules
that reside low in the structure should be the workers, performing all input,
computation,
and output tasks.
7. Data Structure: Data
structure is a representation of the logical
relationship among individual elements of data. Because the structure of
information will invariably affect the final procedural design, data structure
is as important as program structure to the representation of software
architecture
8. Software Procedure: Program
structure defines control hierarchy without regard to
the sequence of processing and decisions. Software procedure focuses on the
processing details of each module individually. Procedure must provide a
precise specification of processing, including sequence of events, exact
decision points, repetitive operations, and even data organization and
structure.
9. Information Hiding: The
principle of information hiding suggests that modules be "characterized by design decisions
that (each) hides from all others." In other words, modules should be
specified and designed so that information (procedure and data) contained
within a module is inaccessible to other modules that have no need for such
information
Q) EXPLIN EFFECTIVE
MODULAR DESIGN IN SOFTWARE OR EXPLAIN COUPLING AND COHESION MODELING
Modularity
has become an accepted approach in all engineering disciplines. A modular
design reduces complexity, facilitates change (a critical aspect of software
maintainability), and results in easier implementation by encouraging parallel
development of different parts of a system.
1. Functional
Independence
The
concept of functional independence is a direct outgrowth of modularity and the concepts
of abstraction and information hiding. Functional independence is a key to good
design, and design is the key to
software quality. Independence is measured using two qualitative criteria: cohesion
and coupling.
Cohesion is a measure of the
relative functional strength of a module.
Coupling is a measure of the
relative interdependence among modules.
Classification
of cohesion The different classes of cohesion that a
module may possess are depicted in fig.
Coincidental
cohesion:
A module is said to have coincidental cohesion, if it performs a set of tasks
that relate to each other very loosely, if at all. In this case, the module
contains a random collection of functions. It is likely that the
functions have been
put in the
module out of
pure coincidence without any
thought or design.
For example, in
a transaction processing
system (TPS), the
get-input, print-error, and
summarize-members functions are
grouped into one
module. The grouping does
not have any
relevance to the structure of the problem.
Logical cohesion:
A module is
said to be
logically cohesive, if all elements
of the module
perform similar operations,
e.g. error handling, data
input, data output,
etc. An example
of logical cohesion
is the case
where a set
of print functions
generating different output
reports are arranged into a single module.
Temporal cohesion:
When a module
contains functions that
are related by the fact that all the functions must be
executed in the same time span, the
module is said
to exhibit temporal
cohesion. The set
of functions responsible
for initialization, start-up,
shutdown of some
process, etc. exhibit temporal cohesion.
Procedural
cohesion:
A module is said to possess procedural cohesion, if the set of functions of the
module are all part of a procedure
(algorithm) in which certain sequence of steps have to be carried out for
achieving an objective, e.g. the algorithm for decoding a message.
Communicational
cohesion: A module is said to have communicational cohesion, if
all functions of
the module refer
to or update
the same data
structure, e.g. the set of functions defined on an array or a stack.
Sequential
cohesion:
A module is said to possess sequential cohesion, if the elements
of a module
form the parts
of sequence, where
the output from one element of the sequence is input to
the next. For example, in a TPS,
the get-input, validate-input, sort-input
functions are grouped
into one module.
Functional cohesion:
Functional cohesion is
said to exist,
if different elements
of a module
cooperate to achieve
a single function.
For example, a
module containing all
the functions required
to manage employees’
pay-roll exhibits functional
cohesion. Suppose a
module exhibits functional cohesion
and we are
asked to describe
what the module
does, then we
would be able
to describe it
using a single
sentence.
Coupling
:- Coupling
between two modules is a measure of the degree of interdependence or
interaction between the two modules. A
module having high cohesion and low coupling is said to be functionally
independent of other modules.The lower coupling, better the program.
Five
types of coupling can occur between any two modules. This is shown in fig.
Data
coupling :-
Two modules are data coupled, if they communicate through a parameter.
E.g.
an integer, a float, a character, etc.
Stamp
coupling :- When
multiple modules share common data structure and work on different part of
it,it is called stamp coupling. (OR)
Two modules are
stamp coupled, if
they communicate using a composite data item such as a record
in PASCAL or a structure in C
Control
coupling :-
Two modules are called control-coupled if one of them decides the function of
the other module or changes its flow of execution.
An
example a flag set in one module and tested in another module.
Common
coupling :-Two
modules are common coupled, if they share data through some global data items.
Content
coupling :- Content
coupling exists between two modules, if they share code.
E.g.
a branch from one module into another module.
Example:
Cohesion
refers to what the class (or module) will do. Low cohesion would mean that the
class does a great variety of actions and is not focused on what it should do.
High cohesion would then mean that the class is focused on what it should be
doing, i.e. only methods relating to the intention of the class.
Example
of Low Cohesion:
As
for coupling, it refers to how related are two classes / modules and how
dependent they are on each other. Being low coupling would mean that changing
something major in one class should not affect the other. High coupling would
make your code difficult to make changes as well as to maintain it, as classes
are coupled closely together, making a change could mean an entire system
revamp.
All
good software design will go for high cohesion and low coupling
Q) Write a note on Functional
independence
A module having high cohesion and
low coupling is said to be functionally independent of other modules. By the
term functional independence, we mean that a cohesive module performs a single
task or function. A functionally independent module has minimal interaction
with other modules
Need for functional independence
Functional independence is a key
to any good design due to the following reasons:
•Error isolation: Functional independence reduces error propagation.
The reason behind this is that if a module is functionally independent, its
degree of interaction with the other modules is less. Therefore, any error
existing in a module would not directly effect the other modules.
•Scope of reuse: Reuse of a module becomes possible. Because each
module does some well-defined and precise function, and the interaction of the
module with the other modules is simple and minimal. Therefore, a cohesive
module can be easily taken out and reused in a different program.
•Understandability: Complexity of the design is reduced, because
different modules can be understood in isolation as modules are more or less
independent of each other
Q) Explain Architectural
design.
Architectural
design -defines the relationships among the major structural elements of the
software, it
is derived from the system specification, the analysis model, the subsystem
interactions
defined in the analysis model (dfd).
As architectural
design begins, the software to be developed must be put into context—that is, the design should define the
external entities (other systems, devices, people) that the software interacts
with and the nature of the interaction. This information can generally be
acquired from the requirements model and all other information gathered during
requirements engineering. Once context is modeled and all external software
interfaces have been described, you can identify a set of architectural
archetypes. An archetype is
an abstraction (similar to a class) that represents one element of system
behavior. The set of archetypes provides a collection of abstractions that must
be modeled architecturally if the system is to be constructed, but the
archetypes themselves do not provide enough implementation detail. Therefore,
the designer specifies the structure of the system by defining and refining
software components that implement each archetype. This process continues iteratively
until a complete architectural structure has been derived
At
the architectural design level, a software architect uses an architectural context diagram
(ACD)
to model the manner in which software interacts with entities external to its
boundaries. The generic structure of the architectural context diagram is
illustrated in Figure 9.5.
Referring
to the figure, systems that interoperate with the target system (the system for which an
architectural design is to be developed) are represented as • Superordinate systems—those systems that use the target system as part of some
higher-level processing scheme.• Subordinate
systems—those systems that are used by
the target system and provide data or processing that are necessary to complete
target system functionality.
• Peer-level systems—those systems that interact on
a peer-to-peer basis (i.e., information is either produced or consumed by the
peers and the target system.
• Actors—entities (people, devices) that
interact with the target system by producing or consuming information that is
necessary for requisite processing. Each of these external entities
communicates with the target system through an interface (the small shaded
rectangles).
To
illustrate the use of the ACD, consider the home security function of the SafeHome product. The overall SafeHome product controller and the
Internet-based system are both superordinate to the security function and are
shown
Q)
WRITE A NOTE ON ARCHITECTURAL DESIGN:
Requirements
of the software should be transformed into an architecture that describes the
software's top-level structure and identifies its components. This is
accomplished through architectural design
Functions:
1. It defines an abstraction level
at which the designers can specify the functional and performance behaviour of
the system.
2. It acts as a guideline for
enhancing the system (when ever required) by describing those features of the
system that can be modified easily without affecting the system integrity.
3. It evaluates all top-level
designs.
4. It develops and documents
top-level design for the external and internal interfaces.
5. It develops preliminary
versions of user documentation.
6. It defines and documents
preliminary test requirements and the schedule for software integration.
7. The sources of architectural
design are listed below.
8. Information regarding the
application domain for the software to be developed
9. Using data-flow diagrams
10. Availability of architectural
patterns and architectural styles.
Architectural
design can be represented using the following models.
i.
Structural
model: Illustrates
architecture as an ordered collection of program components
ii.
Dynamic
model: Specifies
the behavioral aspect of the software architecture and indicates how the
structure or system configuration changes as the function changes due to change
in the external environment
iii.
Process
model: Focuses
on the design of the business or technical process, which must be implemented
in the system
iv.
Functional
model: Represents
the functional hierarchy of a system
v.
Framework
model: Attempts
to identify repeatable architectural design patterns encountered in similar
types of application. This leads to an increase in the level of abstraction.
Q)
WRITE A NOTE ON PROCEDURAL DESIGN:
1. Procedural
design is when the programmer specifies what must be done and in what sequence.
It is based on the concept of the modularity and scope of program code.
2. Transforms structural elements
of the program architecture into a procedural description of software
components.
3. Information obtained from the
Process and Control Specifications and the State Transition Diagrams serve as a
basis for procedural design.
4. The two major diagramming tools
used in procedural design are data flow diagrams and structure charts.
5. A data flow diagram (or DFD) is
a tool to help you discover and document the program’s major processes. The DFD
is a conceptual model – it doesn’t represent the computer program, it
represents what the program must accomplish.
A structure chart is a tool to help you derive and
document the program’s architecture. It is similar to an organization chart. A
structure chart can be used to show the relationship between conceptual tasks.
Q)
EXPLAIN DATA FLOW DESIGN IN SOFTWARE DESIGN.
A mapping
technique, called structured design ,
is often characterized as a data flow-oriented design method because it
provides a convenient transition from a data flow diagram to software
architecture. The transition from information flow (represented as a DFD) to
program structure is accomplished as part of a six step process:
(1) the type of
information flow is established,
(2) flow
boundaries are indicated,
(3) the DFD is
mapped into the program structure,
(4) control
hierarchy is defined,
(5) the resultant structure is refined using
design measures and heuristics, and
(6) the
architectural description is refined and elaborated.
As a brief
example of data flow mapping, I present a step-by-step “transform” mapping for
a small part of the SafeHome security
function. In order to perform the mapping, the type of information flow must be
determined.
Step 1. Review the fundamental system model. The fundamental system model or context diagram depicts the
security function as a single transformation, representing the external
producers and consumers of data that flow into and out of the function. Figure
9.10 depicts a level 0 context model, and Figure.
Step 2. Review and refine data flow diagrams
for the software. Information
obtained
from the requirements model is refined to produce greater detail. For
example,
the level 2 DFD for monitor sensors (Figure 9.12) is examined, and a level 3
data
flow diagram is derived as shown in Figure 9.13.
No comments:
Post a Comment