CIA-3

SOFTWARE
ENGINEERING

Name : Derin ben Roberts

Reg. No. : 1740136
Topic : software design
 INTRODUCTION AND EVOLUTION OF SOFTWARE DESIGN

Software design is the process of envisioning and defining software solutions to

one or more sets of problems. One of the main components of software design
is the software requirement analysis (SRA). The main difference between
software analysis and design is that the output of a software analysis consists of
smaller problems to solve. Additionally, the analysis should not be designed
very differently across different team members or groups. In contrast, the design
focuses on capabilities, and thus multiple designs for the same problem can and
will exist.

The term 'software engineering and design' was suggested at conferences

organized by NATO in 1968 and 1969 to discuss the 'software crisis'. The
software crisis was the name given to the difficulties encountered in developing
large, complex systems in the 1960s. It was proposed that the adoption of an
engineering approach to software development would reduce the costs of
software development and lead to more reliable software.

Key dates in the history of software engineering are:

1968: Nato conference on software engineering. Publication of Dijkstra's note

on the dangers of the goto statement in programs.

Early 1970s: Development of the notions of structured programming.

Publication of Parnas's paper on information hiding. Development of Pascal
programming language. Development of Smalltalk languages which introduced
notions of object-oriented development.

Late 1970s: Early use of software design methods such as Yourdon and
Constantine's structured design. Development of first programming
environments.
Early 1980s: Development of the Ada programming language which included
notions of structured programming and information hiding. Proposals for
software engineering environments. CASE tools introduced to support design
methods. Development of algorithmic approaches to software costing and
estimation. Publication of the 1st edition of this book as the first student
textbook on software engineering.

Late 1980s: Increased use of object-oriented programming through languages

such as C++ and Objective-C. Introduction of object-oriented design methods.
Extensive use of CASE tools.

Early 1990s: Object-oriented development becomes a mainstream development

technique. Commercial tools to support requirements engineering become
available.

Late 1990s: Java is developed and released in the mid-1990s. Increasing

attention paid to notions of software architecture. Client-server distributed
architectures are increasingly used. Notion of component-based software
engineering is proposed. The UML is proposed, integrating several separately
developed notations for representing object-oriented systems.

Early 2000s: Use of integrated development environments becomes more

common. Use of stand-alone CASE tools declines. Use of the UML becomes
widespread. Increasing use of scripting languages such as Python and PERL for
software development. C# developed as a competitor to Java.

To conclude, we can say that, Software design usually involves problem solving
and planning a software solution. This includes both a low-level component
and algorithm design and a high-level architectural design.
 SOFTWARE DESIGN

Software design is a process to transform user requirements into some suitable

form, which helps the programmer in software coding and implementation.

For assessing user requirements, an SRS (Software Requirement Specification)

document is created whereas for coding and implementation, there is a need of
more specific and detailed requirements in software terms. The output of this
process can directly be used into implementation in programming languages.

Software design is the first step in SDLC (Software Design Life Cycle), which
moves the concentration from problem domain to solution domain. It tries to
specify how to fulfil the requirements mentioned in SRS.

The general set of principles for software design, which have been adapted and
extended in the following list:

 The design process should not suffer from "tunnel vision."

A good designer should consider alternative approaches, judging each based

on the requirements of the problem, the resources available to do the job.

 The design should be traceable to the analysis model.

Because a single element of the design model can often be traced back to
multiple requirements, it is necessary to have a means for tracking how
requirements have been satisfied by the design model.

 The design should not reinvent the wheel.

Systems are constructed using a set of design patterns, many of which have
likely been encountered before. These patterns should always be chosen as
an alternative to reinvention. Time is short and resources are limited; design
 time should be invested in representing (truly new) ideas by integrating
patterns that already exist (when applicable).

 The design should "minimize the intellectual distance" between the

software and the problem as it exists in the real world.

That is, the structure of the software design should, whenever possible,
mimic the structure of the problem domain.

 The design should exhibit uniformity and integration.

A design is uniform if it appears fully coherent. In order to achieve this

outcome, rules of style and format should be defined for a design team
before design work begins. A design is integrated if care is taken in defining
interfaces between design components.

 The design should be structured to accommodate change.

The design concepts discussed in the next section enable a design to achieve
this principle.

 The design should be structured to degrade gently, even when aberrant

data, events, or operating conditions are encountered.

Well- designed software should never "bomb"; it should be designed to

accommodate unusual circumstances, and if it must terminate processing, it
should do so in a graceful manner.

 Design is not coding, coding is not design.

Even when detailed procedural designs are created for program components,
the level of abstraction of the design model is higher than the source code.
 The only design decisions made at the coding level should address the small
implementation details that enable the procedural design to be coded.

 The design should be assessed for quality as it is being created, not after
the fact.

A variety of design concepts and design measures are available to assist the
designer in assessing quality throughout the development process.

 The design should be reviewed to minimize conceptual (semantic)

errors.

There is sometimes a tendency to focus on minutiae when the design is

reviewed, missing the forest for the trees. A design team should ensure that
major conceptual elements of the design (omissions, ambiguity,
inconsistency) have been addressed before worrying about the syntax of the
design model.

Design concepts:

1. Abstraction

 A solution is stated in large terms using the language of the problem

environment at the highest-level abstraction.
 The lower level of abstraction provides a more detail description of the
solution.
 A sequence of instruction that contain a specific and limited function refers in a
procedural abstraction.
 A collection of data that describes a data object is a data abstraction.

2. Architecture
 The complete structure of the software is known as software architecture.
 Structure provides conceptual integrity for a system in a number of ways.
 The architecture is the structure of program modules where they interact with
each other in a specialized way.
 The components use the structure of data.
 The aim of the software design is to obtain an architectural framework of a
system.
 The more detailed design activities are conducted from the framework.

3. Patterns
A design pattern describes a design structure and that structure solves a
particular design problem in a specified content.

4. Modularity
 A software is separately divided into name and addressable components.
Sometime they are called as modules which integrate to satisfy the problem
requirements.
 Modularity is the single attribute of a software that permits a program to be
managed easily.

5. Information hiding
Modules must be specified and designed so that the information like algorithm
and data presented in a module is not accessible for other modules not requiring
that information.

6. Functional independence
 The functional independence is the concept of separation and related to the
concept of modularity, abstraction and information hiding.
 The functional independence is accessed using two criteria i.e Cohesion and
coupling.

Cohesion
 Cohesion is an extension of the information hiding concept.
 A cohesive module performs a single task and it requires a small interaction
with the other components in other parts of the program.

Coupling
Coupling is an indication of interconnection between modules in a structure of
software.

7. 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.

8. Refactoring
 It is a reorganization technique which simplifies the design of components
without changing its function behaviour.
 Refactoring is the process of changing the software system in a way that it does
not change the external behaviour of the code still improves its internal
structure.

9. Design classes
 The model of software is defined as a set of design classes.
 Every class describes the elements of problem domain and that focus on
features of the problem which are user visible.

SOFTWARE DESIGN MODEL ELEMENTS

There are two dimensions in which a design model can be illustrated: process
and abstraction dimension. Process dimension points the changes in the design
model as the design tasks are implemented as part of software process.
Abstraction dimension represents the level of detail as each element of analysis
model is transformed into design equivalent and refined iteratively.
The design model has four major elements. Design model elements are not
developed in a sequential fashion.:
- Data
- Architecture
- Components
- Interface
 Data design focuses on files or databases at an architectural level and on a
component level, data design considers the data structures that are required to
implement local data objects.

 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.

Architectural model
The architectural model is derived from the application domain, the analysis
model and available styles and patterns.
 The architecture design elements provides us overall view of the system.
 The architectural design element is generally represented as a set of
interconnected subsystem that are derived from analysis packages in the
requirement model.
The architecture model is derived from following sources:
 The information about the application domain to built the software.
 Requirement model elements like data flow diagram or analysis classes,
relationship and collaboration between them.
 The architectural style and pattern as per availability.

Interface design
The interface design elements for software tells us how the information flows
in and out of the system and how it is communicated among the components.
There are three parts to interface design elements: the user interface, interfaces
to systems external to application and interfaces to components within the
application.
 User interface elements include aesthetic elements, ergonomic elements and
technical elements. External interface design requires information about entity
to which information is sent or received. Internal interface design is closely
related to component level design.

 The interface design elements for software represents the information flow
within it and out of the system.
 They communicate between the components defined as part of architecture.

Component design
The component level design elements describes the internal detail of software
component. The component level design defines data structures for all local
data objects and algorithmic detail processing that occurs within a component
and an interface that allows access to all behaviours.
 The component level design for software is similar to the set of detailed
specification of each room in a house.
 The component level design for the software completely describes the internal
details of the each software component.
 The processing of data structure occurs in a component and an interface which
allows all the component operations.

CONCLUSION
Hence, the concepts of the design within the context of software engineering
are briefly discussed.