SOFTWARE DESIGN TECHNIQUES

Software design is the process which translates requirements into a detailed design
representation of a software system. It is argued that good software design is the
key to reliable and understandable software. Important techniques for software
design, including architectural and detailed design stages, are surveyed. To ensure
software quality, various design verification and validation techniques are
discussed. In addition, current software metrics and error-resistant software design
methodologies are considered. .

It is a plan for converting specification into executable codes. i.e the means a
problem description is turned to a problem solution.

Software design is the process by which an agent creates a specification of

a software artefact intended to accomplish goals, using a set of primitive
components and subject to constraints.[1] Software design may refer to either "all
the activity involved in conceptualizing, framing, implementing, commissioning,
and ultimately modifying complex systems" or "the activity
following requirements specification and before programming

Software design involves;

1. Structural design which involves the components of a software systems in

terms of their required functionality and links to one another
2. Algorithmic design which determines how each structural components
delivers its required functionality

1
Structural design may involve many levels of decomposition before components
are ready for algorithm design. All software are information-processing systems.
They accept data as input manipulate that data and provide data as input.

Hence design must therefore address three issues:

1. Definition of data to be held by the system

2. Definition of the process by which inputs are manipulated
3. Definition of the states the system can assume and what transformations
are permitted between states or definition of the flow of data or control.

DATA DESIGN

Data design is the first design activity, which results in fewer complexes,
modular and efficient program structure. The information domain model
developed during analysis phase is transformed into data structures needed for
implementing the software. The data objects, attributes, and relationships depicted
in entity relationship diagrams and the information stored in data dictionary
provide a base for data design activity. During the data design process, data types
are specified along with the integrity rules required for the data. For specifying
and designing efficient data structures, some principles should be followed. These
principles are listed below.

1. The data structures needed for implementing the software as well-as the
operations that can be applied on them should be identified.

2
 2. A data dictionary should be developed to depict how different data objects
interact with each other and what constraints are to be imposed on the
elements of data structure.

3. Stepwise refinement should be used in data design process and detailed

design decisions should be made later in the process.

4. Only those modules that need to access data stored in a data structure
directly should be aware of the representation of the data structure.

5. A library containing the set of useful data structures along with the
operations that can be performed on them should be maintained.

6. Language used for developing the system

The structure of data can be viewed at three levels, namely, program component
level, application level, and business level.

At the program component level, the design of data structures and the algorithms
required to manipulate them is necessary, if high-quality software is desired.

At the application level, it is crucial to convert the data model into a database so
that the specific business objectives of a system could be achieved.

At the business level, the collection of information stored in different databases

should be reorganized into data warehouse, which enables data mining that has an
influential impact on the business

The primary activity during data design is to select logical representations of data
objects (data structures). The selection process may include algorithmic analysis of
alternative structures in other to determine the most efficient design or may simply

3
involve the use of modules that provide the desired operations upon some
representation of an object.

Data design elements

 The data design element produced a model of data that represent a high level
of abstraction.
 This model is then more refined into more implementation specific
representation which is processed by the computer based system.
 The structure of data is the most important part of the software design.

4
 SOFTWARE PROCESS

Software process (also known as software methodology) is a set of related activities

that leads to the production of the software. These activities may involve the
development of the software from the scratch, or, modifying an existing system.

1. Software specification (or requirements engineering): Define the main

functionalities of the software and the constrains around them.

2. Software design and implementation: The software is to be designed and

programmed.

3. Software verification and validation: The software must conforms to it’s

specification and meets the customer needs.

4. Software evolution (software maintenance): The software is being modified

to meet customer and market requirements changes.

SOFTWARE PROCESS MODELS

A software process model is a simplified representation of a software process. Each

model represents processes from a specific perspective.We’re going to take a quick
glance about very general process models. These generic models are abstractions of
the process that can be used to explain different approaches to the software
development. They can be adapted and extended to create more specific processes.

Some methodologies are sometimes known as software development life

cycle (SDLC) methodologies, though this term could also be used more generally to
refer to any methodology.

5
WATERFALL MODEL

The waterfall model is a sequential approach, where each fundamental activity of a

process represented as a separate phase, arranged in linear order.

In the waterfall model, you must plan and schedule all of the activities before
starting working on them (plan-driven process).

Plan-driven process is a process where all the activities are planned first, and the
progress is measured against the plan. While the agile process, planning is
incremental and it’s easier to change the process to reflect requirement changes.

The phases of the waterfall model are: Requirements, Design, Implementation,

Testing, and Maintenance.

6
SPIRAL MODEL

The spiral model is a risk-driven where the process is represented as spiral rather
than a sequence of activities.

It was designed to include the best features from the waterfall and prototyping
models, and introduces a new component; risk-assessment.

Each loop (from review till service — see figure below) in the spiral represents a
phase. Thus the first loop might be concerned with system feasibility, the next loop
might be concerned with the requirements definition, the next loop with system
design, and so on.

AGILE

Agility is flexibility; it is a state of dynamic, adapted to the specific circumstances.

The agile methods refers to a group of software development models based on the
incremental and iterative approach, in which the increments are small and typically,
new releases of the system are created and made available to customers every few
weeks.

7
 FLOW

Flow-Design is a comprehensive eclectic approach to systematically move through

the process of transforming requirements into working software –

It’s about visualizing solutions before implementation as well as mapping them to

code. It invites collaboration at the whiteboard as well as in the IDE.

Flow-Design has its roots in many existing methods and paradigms but does not
simply rehash them. It’s a pragmatic mixture to bring to your mind and to your
fingertips what works.

Flow allows data-integration specialists to connect disparate systems (whether on-

premises, hosted or in the cloud); transforming and restructuring data as required
between environments. Flow functionality can be utilised for data
integration projects, for EDI and for data-conversion activities. Flow can access
and read from, or write to various file types. Flow transports generated data and
files

control flow (or flow of control) is the order in which

individual statements, instructions or function calls of
an imperative program are executed or evaluated. Within an
imperative programming language, a control flow statement is a statement that
results in a choice being made as to which of two or more paths to follow.

FLOW ENABLES DATA MANAGEMENT:

 Transformation of data, within and between sets

 Generation and consumption of data, accessioning from specified sets
within structures

8
  Transportation of data files, using various transport formats, including
secure
 Specification of task work-flows
 Notification of transactions and formats via reports

DATA FLOW DIAGRAM (DFD)

A Data Flow Diagram (DFD) is a traditional visual representation of the

information flows within a system. A neat and clear DFD can depict the right
amount of the system requirement graphically. It can be manual, automated, or a
combination of both.

It shows how data enters and leaves the system, what changes the information, and
where data is stored.

The objective of a DFD is to show the scope and boundaries of a system as a

whole. It may be used as a communication tool between a system analyst and any
person who plays a part in the order that acts as a starting point for redesigning a
system

9
 REFERENCES

G. J. Pottie and W. J. Kaiser, ‘‘software engineering,’’ Comm. ACM, 43(5): 51–

58, 2000

D. Estrin, Embedded Everywhere: A Research Agenda for Networked Systems of

Embedded Computers. National Academy Press, 2001.

www.jamesreserve.edu.

Hierons, R. M.; Bogdanov, K.; Bowen, J. P.; Cleaveland, R.; Derrick, J.; Dick, J.;
Gheorghe, M.; Harman, M.; Kapoor, K.; Krause, P.; Lüttgen, G.; Simons,
A. J. H.; Vilkomir, S. A.; Woodward, M. R.; Zedan, H. (2009). "Using
formal specifications to support testing". ACM Computing Surveys. 41 (2):
1. CiteSeerX 10.1.1.144.3320. doi:10.1145/1459352.1459354.

Gaudel, M.-C. (1994). "Formal specification techniques". Proceedings of 16th

International Conference on Software Engineering. pp. 223–
227. doi:10.1109/ICSE.1994.296781. ISBN 978-0-8186-5855-6. S2CID 6074
0848.

Lamsweerde, A. V. (2000). "Formal specification". Proceedings of the conference

on the future of Software engineering - ICSE '00. pp. 147–
159. doi:10.1145/336512.336546. ISBN 978-1581132533. S2CID 4657483.

"Formal Specification" (PDF). Software Engineering. Retrieved 3 February 2013.

W. Durant and A. Durant, The Story of Civilization, Vols. I–XI. Simon and
Shuster, 1954.

10