Software Engineering Software Design Study Material – Software Engineering Software Design Software – Studocu
Mục lục bài viết
Software Engineering
Software Design
Software Design and its Activities
Software design deals with transforming the client requirements, as described in
the SRS document, into a form (set of documents) that is suitable for
implementation in a programming language. A good software design is rarely
arrived by using a single step procedure but rather through several iterations
through a series of steps.
3 Software Design Levels
- Architectural Design
- Preliminary (High-Level) Design
- Detailed Design
Architectural Design
The architectural design is the highest summarize version of the system. This
determines the software or application as a method with many components
interacting with each. At this level, the designers get the idea or thought of a
suggested clarification domain or province.
Preliminary (High-Level) Design
High-level design means identification of different modules and the control
relationships among them and the definition of the interfaces among these
modules. The outcome of the high-level design is called software architecture or
the program structure. Many different types of notations have been used to
represent a high-level design. A popular way is to use a tree-like diagram called
the Structure Chart to represent the control hierarchy in the high-level design.
Detailed Design
During detailed design, the data structure and the algorithms of the different
modules are designed. The outcome of the detailed design stage is usually known
as the module-specification document.
Difference between Analysis and Design
The aim of analysis is to understand the problem with a view to eliminate any
deficiencies in the requirement specification such as incompleteness,
inconsistencies, etc.
The aim of design is to produce a model that will provide a seamless transition
to the coding phase, i. once the requirements are analyzed and found to be
satisfactory, a design model is created which can be easily implemented.
Items developed during Software
Design Phase
For a design to be easily implemented in a conventional programming language,
the following items must be designed during the design phase.
Different modules required to implement the design solution.
Control relationship among the identified modules. The relationship is also
known as the invocation relationship or the call relationship among modules.
Interface among different modules. The interface among different modules
identifies the exact data items exchanged among the modules.
Data structures of the individual modules.
Algorithms required to implement each individual module.
Characteristics of a Good Software
Design
For a design to be easily implemented in a conventional programming language,
the following items must be designed during the design phase.
The definition of “ a good software design ” can vary depending on the application
being designed. Most researchers and software engineers agree on a few
desirable characteristics that every good software design for a general application
must possess. The characteristics are listed below:
Correctness : A good design should correctly implement all the functionalities
identified in the SRS document.
Understandability : A good design is easily understandable.
Efficiency : It should be efficient.
Maintainability : It should be easily amenable to change.
Types of Cohesion
The different classes of cohesion that a module may possess are shown in Fig. 4.
Types of Cohesion
Coincidental Cohesion : A module is said to have coincidental cohesion if it
performs a set of function or tasks that relate to each other very loosely. 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
design or thought. 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. 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, a 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.
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. 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 the 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 shows functional cohesion and we are
asked to tell what the module does, then we would be able to tell it using a
single sentence.
Coupling
Coupling between two modules is a measure of the degree of interaction or
interdependence between the two modules. A module having low coupling and
high cohesion is said to be functionally independent of other modules.
If two modules interchange huge amounts of data/information, then they
are highly interdependent. The degree of coupling between two modules
depends on their interface complexity, which is basically determined by the
number of types of parameters that are interchanged while invoking the functions
of the module.
Types of Coupling
The classification of the different types of coupling helps to quantitatively
estimate the degree of coupling between two modules. Five types of coupling can
occur between any two modules. This is shown in Fig. 4.
