2. Software design is an iterative process
through which requirements are translated
into a blueprintfor constructing the software.
Initially, the blueprint depicts a holistic view of
software i.e. the design is represented at a high-
level of abstraction.
3.
4. GOALS OF THE DESIGN PROCESS:
1) 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.
2) The design must be a readable, understandable guide
for those who generate code and for those who test
and subsequently support the software.
3) The design should address the data, functional and
behavioral domains from an implementation
perspective
5. Data Design :
◦ Transforms information domain model into data structures required to
implement software
Architectural Design :
◦ Defines relationship among the major structural elements of a software
Interface Design :
◦ Describes how the software communicates with systems that interact with
it and with humans.
Procedural Design/ Component-level design :
◦ Transforms structural elements of the architecture into a procedural
description of software components.
DESIGN MODEL
6.
7. A design methodology combines a systematic set of
rules for creating a program design with
diagramming tools needed to represent it.
Procedural design is best used to model programs
that have an obvious flow of data from input to
output. It represents the architecture of a program as a
set of interacting processes that pass data from one to
another.
8. There are two component for design tool are
following:
Data Flow Diagram:
Adataflowdiagram(orDFD)isatooltohelpyoudiscoveranddocumentthe
program’smajor processes.Thefollowingtableshowsthesymbolsusedandwhat
each represents.
Structure Chart :
A structure chart is a tool to help you derive and document the program’s
architecture. It is similar to an organization chart
16. To suggest some general design principles for
user interface design
To explain different interaction styles
To introduce styles of information presentation
To describe the user support which should be
built-in to user interfaces
To introduce usability attributes and system
approaches to system evaluation
17. System users often judge a system by its
interface rather than its functionality
A poorly designed interface can cause a user to
make catastrophic errors
Poor user interface design is the reason why so
many software systems are never used
18. Most users of business systems interact with these
systems through graphical interfaces although, in
some cases, legacy text-based interfaces are still
used
19. Characteristic Description
Windows Multiple windows allow different information to be
displayed simultaneously on the user’s screen.
Icons Icons different types of information. On some systems,
icons represent files; on others, icons represent
processes.
Menus Commands are selected from a menu rather than typed
in a command language.
Pointing A pointing device such as a mouse is used for selecting
choices from a menu or indicating items of interest in a
window.
Graphics Graphical elements can be mixed with text on the same
display.
20. They are easy to learn and use.
• Users without experience can learn to use the system
quickly.
The user may switch quickly from one task to
another and can interact with several different
applications.
• Information remains visible in its own window when
attention is switched.
Fast, full-screen interaction is possible with
immediate access to anywhere on the screen
21. The aim of this chapter is to sensitise software
engineers to key issues underlying the design
rather than the implementation of user interfaces
User-centred design is an approach to UI design
where the needs of the user are paramount and
where the user is involved in the design process
UI design always involves the development of
prototype interfaces
23. UI design must take account of the needs,
experience and capabilities of the system users
Designers should be aware of people’s physical
and mental limitations (e.g. limited short-term
memory) and should recognise that people make
mistakes
UI design principles underlie interface designs
although not all principles are applicable to all
designs
24. DescriptionPrinciple
User familiarity
Consistency
The interface should use terms and concepts which are
drawn from the experience of the people who will make
most use of the system.
The interface should be consistent in that, wherever
possible, comparable operations should be activated in
the same way.
Users should never be surprised by the behaviour of a
system.
Minimal surprise
Recoverability The interface should include mechanisms to allow
users to recover from errors.
User guidance
User diversity
The interface should provide meaningful feedback
when errors occur and provide context-sensitive user
help facilities.
The interface should provide appropriate interaction
facilities for different types of system user.
25. Users feel in control of the computer and are less
likely to be intimidated by it
User learning time is relatively short
Users get immediate feedback on their actions
so mistakes can be quickly detected and
corrected
26. Users need not remember command names as
they are always presented with a list of valid
commands
Typing effort is minimal
User errors are trapped by the interface
Context-dependent help can be provided. The
user’s context is indicated by the current menu
selection
27. Concerned with techniques for displaying large
amounts of information
Visualisation can reveal relationships between
entities and trends in the data
Possible data visualisations are:
• Weather information collected from a number of sources
• The state of a telephone network as a linked set of nodes
• Chemical plant visualised by showing pressures and
temperatures in a linked set of tanks and pipes
• A model of a molecule displayed in 3 dimensions
• Web pages displayed as a hyperbolic tree
28.
29. Data design is the first design activity, which
results in less complex, 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.
30. 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) A data dictionary should be developed to depict how different data
objects interact with each other and what constraints are to be imposed o
the elements of data structure.
3) Stepwise refinement should be used in data design process and detaile
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.
31. 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
should support abstract data types.
The structure of data can be viewed at
three levels, namely, program component
level, application level, and business level.
32. 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.
33. Requirements of the software should be
transformed into an architecture that describes
the software's top-level structure and identifies
its components.
Architectural design (also called system
design), which acts as a preliminary 'blueprint'
from which software can be developed.
34. IEEE defines architectural design as 'the process of
defining a collection of hardware and software components
and their interfaces to establish the framework for the
development of a computer system.'
An architectural design performs the following
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.
35. 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.
36. 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 is of crucial
importance in software engineering during
which the essential requirements like
reliability, cost, and performance are dealt
with.
37. ARCHITECTURAL DESIGN
REPRESENTATION
Architectural design can be represented using the following
models.
Structural model: Illustrates architecture as an ordered
collection of program components
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
38. Process model: Focuses on the design of the
business or technical process, which must be
implemented in the system.
Functional model: Represents the functional
hierarchy of a system.
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.
39. The architectural design process results in an Architectural Design
Document (ADD).
Architectural design document gives the developers a solution to the
problem stated in the Software Requirements Specification (SRS).
Note that it considers only those requirements in detail that affect
the program structure.
In addition to ADD, other outputs of the architectural design are
listed below :
1. Various reports including audit report, progress report, and
configuration status accounts report
40. 2) Various plans for detailed design phase,
which include the following
3) Software verification and validation plan.
4) Software configuration management plan.
5) Software quality assurance plan.
6) Software project management plan.
41. Architectural styles define a group of interlinked
systems that share structural and semantic
properties.
In short, the objective of using architectural
styles is to establish a structure for all the
components present in a system.
42. 1. DATA-FLOW ARCHITECTURE
Data-flow architecture is mainly used in the
systems that accept some inputs and transform it
into the desired outputs by applying a series o
transformations.
Each component, known as filter, transforms the
data and sends this transformed data to other
filters for further processing using the connector,
known as pipe. Most of the times, the data-flow
architecture degenerates a batch sequential
system.
43.
44. ADVANTAGES ASSOCIATED WITH THE DATA-FLOW
ARCHITECTURE:
It supports reusability.
It is maintainable and modifiable.
It supports concurrent execution.
DISADVANTAGES ASSOCIATED WITH THE DATA-
FLOW ARCHITECTURE:
It often degenerates to batch sequential system.
It does not provide enough support for applications
requires user interaction.
It is difficult to synchronize two different but related
streams.
45. In object-oriented architectural style, components of a
system encapsulate data and operations, which are
applied to manipulate the data. In this style, components
are represented as objects and they interact with each
other through methods (connectors).
Two important characteristics:
1) Objects maintain the integrity of the system.
2) An object is not aware of the representation of other
objects.
46. ADVANTAGES OBJECT-ORIENTED
ARCHITECTURE
It allows designers to decompose a
problem into a collection of independent
objects.
The implementation detail of objects is
hidden from each other and hence, they can
be changed without affecting other objects.
47. One common example of this architectural style is
OSI-ISO (Open Systems Interconnection-International
Organization for Standardization) communication system.
48. A data-centered architecture has two distinct
components: a central data structure or data
store (central repository) and a collection of
client software.
The data store (for example, a database or a file)
represents the current state of the data and the
client software performs several operations like
add, delete, update, etc., on the data stored in
the data store.
49. ADVANTAGES OF THE DATA-
CENTERED ARCHITECTURE
1) Clients operate independently of one another.
2) Data repository is independent of the clients.
3) It adds scalability (that is, new clients can be
added easily).
4) It supports modifiability.
5) It achieves data integration in component-based
development using blackboard.