Software design is a process to transform user requirements into some suitable form, which helps the programmer in software coding and implementation. Once the requirements for a system have been documented, software engineers design a software system to meet them. Thus, the purpose of design phase is to produce a solution to a problem given in SRS document. This phase is the first step in moving from the problem domain to the solution domain.
Software design is the most important phase of the software development cycle. During the software design phase, the design document is produced, based on the SRS document. Hence the aim of this phase is to transform the SRS document into the design document. The design document produced at the end of the design phase should be implemented using a programming language in the coding phase. A good design is the key to successful product. A well designed system is easy to implement, reliable, understandable and allows for smooth evolution.
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 relationships among the identified modules.
• Interfaces among different modules
• Data structures of the individual modules
• Algorithms required to implement the individual modules
Classification of design activities:
A good software design is rarely arrived by using a single step procedure but rather through several iterations through a series of steps called the design activities. Depending on the order in which various design activities are performed, we can broadly classify them into two important stages:
• Preliminary or high-level design
• Detailed design
Preliminary (High-Level) Design:
Through high-level design, a problem is decomposed into a set of modules, the control relationships among various modules identified, and also the interfaces among various modules are identified. The outcome of the high-level design is called the software architecture or the program structure. Many different types of notations have been used to represent a high-level design. A notation that is widely being used for procedural development is a tree-like diagram called the Structure Chart.
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 documented in the form of module-specification (MSPEC) document.
Following are the characteristics of a good software design:
1. Correctness: A good software design should correctly implement all the functionalities identified in the SRS document.
2. Completeness: Completeness requires that all the different components of the design should be verified i.e., all the relevant data structures, modules, external interfaces and module interconnections are specified.
3. Consistency: Consistency requires that there should not be any inconsistency in the design.
4. Efficiency: The software design must be efficient. Efficiency of any system is mainly concerned with the proper use of resources by the system. The need for efficiency arises due to cost considerations. If some resources are scarce and expensive, it is then desirable that those resources be used efficiently.
5. Understandability: A good design should be easily understandable, unless a design is easily understandable, it would be difficult to implement and maintain it.
6. Traceability: Traceability is an important property that can get design verification. It requires that all the design elements must be traceable to the requirements.
7. Maintainability: The software design must be in such a way that modifications can be easily made in it. This is because every software needs time to time modifications and maintenance. Any change made in the software design must not affect the other available features, and if the features are getting affected, then they must be handled properly.
Cohesion and Coupling:
Cohesion:
Cohesion is a measure of the functional strength of a module. It is defined as the degree to which the elements of a particular module are functionally related. Cohesion of a module represents how tightly bound the internal elements of the module are to one another.
The measure of how strongly the elements are related functionally inside a module is called cohesion. Cohesion is a measure of the degree to which the elements of the module are functionally related. It is a measure that defines the degree of intra-dependability within an element of a module. A good software design will have high cohesion.
Coupling:
Coupling
is the measure of the degree of interdependence between the modules. Coupling between
modules is the strength of interconnections between modules and a measure of
interdependence among modules. Two modules with
high coupling are strongly interconnected and thus dependent on each other. Two
modules with low coupling are not dependent on one another.
Coupling is defined
as the degree to which the two modules are dependent on each other. It measures
the strength of relationships between modules. Coupling between
any two modules is identified from the number and types of resources that the
modules share with other modules.
Highly coupled modules are joined by
strong interconnections, while loosely coupled modules have weak
interconnections. Independent modules have no interconnections. Coupling
is measured by the number of relations between the modules. A good software design will have low
coupling.
Function
and Object oriented Design:
There are two fundamentally different approaches to software design that are in use today: function-oriented design and object oriented design. The object-oriented approach is a relatively newer technology and is still evolving. For development of large programs, the object-oriented approach is becoming increasingly popular due to certain advantages that it offers. On the other hand, function-oriented designing is a mature technology and has a large following.
Function-Oriented
Design:
Function
Oriented Design is an approach to software design where the design
is decomposed into a set of interacting units or modules where each unit or
module has a clearly defined function. Basically,
the system is designed from a functional viewpoint.
A function oriented design strategy relies
on decomposing the system into a set of interacting functions with a
centralized system state shared by these functions.
In function-oriented design approach, the
system is comprised of many smaller sub-systems known as functions. These
functions are capable of performing significant task in the system.
This design mechanism divides the whole
system into smaller functions, which provides means of abstraction by
concealing the information and their operation.. These functional modules can
share information among themselves by means of information passing and using
information available globally.
Generic Procedure:
· Start with a high level description of what the software / program does.
· Refine each part of the description one by one by specifying in greater
details the functionality of each part.
· These points lead to Top-Down Structure.
Function-Oriented
Design Strategies:
The following
strategies are used to implement Function-Oriented Design:
Data
Flow Diagram (DFD):
Data
flow diagram is graphical representation of flow of data in an information
system. Data-flow design is concerned with designing a series of functional
transformations that convert system inputs into the required outputs. The
design is described as data-flow diagrams. These diagrams show how data flows
through a system and how the output is derived from the input through a series
of functional transformations. Data-flow diagrams are a useful and intuitive
way of describing a system.
Data
Dictionaries:
Data
dictionaries are simply repositories to store information about all data items
defined in DFDs. A data dictionary lists all data elements appearing in the DFD
model of a system. The data items listed contain all data flows and the
contents of all data stores looking on the DFDs in the DFD model of a system.
A
data dictionary lists the objective of all data items and the definition of all
composite data elements in terms of their component data items.
Structure Charts:
Structure
chart is a chart derived from Data Flow Diagram. It represents the system in
more detail than DFD. It breaks down the entire system into lowest functional
modules, describes functions and sub functions of each module of the system to
a greater detail than DFD. Structure chart represents hierarchical structure of
modules. At each layer a specific task is performed.
Pseudo-code
Pseudo-code
notations can be used in both the preliminary and detailed design phases. Using
pseudo-code, the designer describes system characteristics using short,
concise, English Language phases that are structured by keywords such as
If-Then-Else, While-Do, and End.
Object-Oriented
Design:
Object-oriented design
(OOD) is an approach to software design that uses a process of defining objects
and their interactions when planning code to develop software. In object
oriented design approach, instead of concentrating on function, we concentrate
upon objects. An object contains both data and function which are used to
create applications.
OOD approach is mainly
the process of using an object methodology to design a computing system or
application. This technique enables the implementation of a software solution
based on the concepts of objects.
An object-oriented
design process involves designing the object classes and the relationships
between these classes. In the object-oriented design approach, a system is
viewed as a collection of objects (i.e., entities). Each object has its own
state and behavior.
Concepts of Object Oriented Design:
The important concepts of Object Oriented Design:
· Objects: All entities involved in the solution
design are known as objects. For example, person, banks, company and customers
are treated as objects. Every entity has some attributes associated to it and
has some methods to perform on the attributes.
· Classes: A class is a generalized description of an object. An
object is an instance of a class. Class defines all the attributes, which an
object can have and methods, which defines the functionality of the object.
· Messages: Objects communicate via messages. Messages are
implemented as procedure or function calls.
· Abstraction: It is used for handling complexity. Removes
irrelevant data and shows only essential data.
· Encapsulation: It is the concept of information
hiding. In OOD, the attributes (data variables) and methods (operation on the
data) are bundled together is called encapsulation. Encapsulation not only
bundles important information of an object together, but also restricts access
of the data and methods from the outside world. This is called information
hiding.
· Inheritance: This is the ability of
a class to extend or override the functionality of another class. OOD allows
similar classes to stack up in hierarchical manner where the lower or
sub-classes can import, implement and re-use allowed variables and methods from
their immediate super classes. This property of OOD is known as inheritance.
This makes it easier to define specific class and to create generalized classes
from specific ones.
· Polymorphism: This is the
ability to define different functions or classes as having the same name, but
taking different data type. OOD languages provide a mechanism where methods
performing similar tasks but vary in arguments, can be assigned same name. This
is called polymorphism, which allows a single interface performing tasks for
different types. Depending upon how the function is invoked, respective portion
of the code gets executed.
Design Process:
Software design process can be perceived as
series of well-defined steps. Though it varies according to design approach
(function oriented or object oriented, yet It may have the following steps
involved:
· A
solution design is created from requirement or previous used system and/or
system sequence diagram.
· Objects
are identified and grouped into classes on behalf of similarity in attribute
characteristics.
· Class
hierarchy and relation among them is defined.
· Application
framework is defined
Data
Flow Diagram:
DFD (Data Flow
Diagram) is an important tool used by system analysts. The
flow of data of a system or a process is represented by DFD. A
data flow diagram (DFD) is a visual representation of the flow
of information through a process or a system.
It is a graphical
representation of flow of data in an information system. It can be used to
represent a system in terms of the input data to the system, various processing
carried out on those data, and the output data generated by the system.
In nutshell, data
flow diagrams simply provide a visual representation of how data is
handled in a system. The main merit of DFD is that it can provide an overview
of what data a system would process, what transformations of data are done,
what files are used and where the results flow. The graphical representation of
the systems makes it a good communication tool between a user and analyst. DFDs
are structured in such a way that starting from a simple diagram which provides
a broad overview at a glance, they can be expanded to hierarchy of diagrams
giving more and more detail. The data flow diagram provides
information about the process itself, outputs and inputs of each entity, and
the various sub processes the data moves through.
UML Diagrams:
UML stands for Unified Modeling Language. It is a language for creating models. UML is a rich language to model software solutions, application structures, system behavior and business processes. UML is a modern approach to modeling and documenting software. In fact, it’s one of the most popular business process modeling techniques.
A UML diagram is a diagram based on the UML with the purpose of visually representing a system along with its main actors, roles, actions, artifacts or classes, in order to better understand, alter, maintain, or document information about the system.
UML is not a programming language, it is rather a visual
language. It is a way of visualizing a
software program using a collection of diagrams. UML helps software engineers, businessmen and system architects with
modelling, design and analysis. Mainly,
UML has been used as a general-purpose modeling language in the field of
software engineering.
0 Comments
if you have any doubts plz let me know...