1
z
06
Software
Design
2
z
Today’s Lesson
The Design The Specific
Design Concept Design Part
Process s Model Design
3
z
Software Design
▪ Software design encompasses the set of principles, concepts,
and practices that lead to the development of a high-quality
system or product.
▪ It allows you to model the system or product that is to be built.
▪ This model can be assessed for quality and improved before
code is generated, tests are conducted, and end users
become involved in large numbers.
4
z
Software Design
Architecture Interface Components
5
z
Software Design
▪ Software design is applied regardless of the software process
model that is used.
▪ Beginning once software requirements have been analysed and
modelled
▪ It is the last software engineering action within the modelling
activity and sets the stage for construction
6
z
Software Design
▪ The data/class design transforms class models into design
class
realizations and the requisite data structures
▪ The architectural design defines the relationship between major
structural elements of the software, the architectural styles and
design patterns that can be used to achieve the requirements of
the system
7
z
Software Design
▪ The interface design describes how the software
communicates
with systems that interoperate with it, and with humans who use
it. An interface implies a flow of information (e.g., data and/or
control) and a specific type of behaviour. for interface design.
▪ The component-level design transforms structural elements of
the software architecture into a procedural description of
software components. Information obtained from the class-
based models, flow models, and behavioural models serve as
the basis for component design.
8
z
The Essence of Software Design
▪ The of software design is quality.
importance
▪ Design provides representations of software that can be
assessed for quality.
▪ Design is the only way that you can accurately translate
stakeholder’s requirements into a finished software product or
system.
▪ Software design serves as the foundation for all the software
engineering and software support activities that follow.
9
z
The Design Process
▪ Software design is an iterative process through which
requirements are translated into a “blueprint” for constructing the
software.
▪ Initially, the blueprint depicts a holistic view of software. That is,
the design is represented at a high level of abstraction
▪ As design iterations occur, subsequent refinement leads to
design representations at much lower levels of abstraction.
10
z
The Design Process
Three characteristics that serve as a guide for the evaluation
of a good design:
▪ The design must implement all of the requirements contained in the
requirements model
▪ The design must be a readable, understandable guide for those
who
generate code and for those who test and subsequently support the
software.
▪
The design should provide a complete picture of the software,
addressing the data, functional, and behavioural domains from an
implementation perspective
11
z
Design Concepts
Abstraction Architecture Modularity
Information Functional
Refactoring
Hiding Independence
12
z
The Design Model
Architectural Design
Component-Level Design
User Interface Design
13
z
Architectural Design
▪ Architectural design represents the structure of and
data
program components that are required to build a computer-
based system.
▪ It looks at the overall organization of the system
▪ The work product is the architectural model
14
z
Some Architectural Styles
Data-centered Architectures
15
z
Some Architectural Styles
Pipe-Filter Architectures
▪ Best suited for applications
that
process data in a stream using
web services and can create
simple sequences to complex
structures.
▪ Eg: Compilers, since each filter
performs lexical analysis,
parsing, semantic analysis,
and code generation.
16
z
Some Architectural Styles
Client-Server Architectures
▪ Client makes a request
▪ Server responds with
resources
▪ Email is a prominent example
of a model that is built using
the client-server pattern.
17
z
Some Architectural Styles
Peer-to-Peer Architectures
▪ Peer can act as a client
making a request or as a
server responding with
resources
▪ Example would be file-
sharing networks like
Skype, BitTorrent
18
z
Component Level-Design
▪ A component is a modular building block for computer software
▪ Because components reside within the software architecture,
they must communicate and collaborate with other components
and with entities (e.g., other systems, devices, people) that exist
outside the boundaries of the software
19
z
Basic Component Design Principles
The Open-Closed Principle (OCP)
▪ A module [component] should be open for extension but closed
for
modification
20
z
Basic Component Design Principles
The Liskov Substitution Principle (LSP)
▪ Subclasses should be substitutable for their base
classes
21
z
Basic Component Design Principles
Dependency Inversion Principle (DIP)
▪ Depend on abstractions. Do not depend on
concretions
22
z
Basic Component Design Principles
Other Principles
The Interface Segregation Principle (ISP)
• Many client-specific interfaces are better than one general purpose
interface
The Release Reuse Equivalency Principle (REP)
• The granule of reuse is the granule of release
The Common Closure Principle (CCP)
• “Classes that change together belong
together
The Common Reuse Principle (CRP)
• Classes that aren’t reused together should not be grouped
together
23
z
User Interface Design
▪ User interface design creates an effective communication
medium between a human and a computer.
▪ Following a set of interface design principles, design identifies
interface objects and actions and then creates a screen layout
that forms the basis for a user interface prototype
▪ User scenarios are created and screen layouts are generated
▪ An interface prototype is developed and modified in an
iterative fashion
24
z
User Interface Guidelines
Reduce the
user’s
memory
load
Place the Make the
user in interface
control consistent
Golden
Rules
25
z
User Interface Guidelines
Place the user in control
▪ Define interaction modes in a way that does not force a user into
unnecessary or undesired actions
▪ Provide for flexible interaction
▪ Allow user interaction to be interruptible and undoable
▪ Hide technical internals from the casual user
▪ Design for direct interaction with objects that appear the
on
screen
26
z
User Interface Guidelines
Reduce the User’s Memory Load
▪ Reduce demand on short-term
memory
▪ Establish meaningful defaults
▪ Define shortcuts that are intuitive
be based on a real-world
▪ The visual layout of the interface should
metaphor
▪ Disclose information in a progressive
fashion
27
z
User Interface Guidelines
Make the interface consistent
▪ Allow the user to put the current task into a meaningful context
▪ Maintain consistency across a family of applications
▪ If past interactive models have created user expectations, do
not
make changes unless there is a compelling reason to do so
28
z
Interface Design Steps
1. Using information developed during interface analysis define
interface objects and actions (operations).
2 Define events (user actions) that will cause the state of the user
interface to change. Model this behavior.
3. Depict each interface state as it will actually look to the end
user.
4 Indicate how the user interprets the state of the system from
information provided through the interface.
29
z
Design Issues
Response Time Help Facilities Error Handling
Menu & Command
Accessibility Internationalization
Labelling
30
Any Questions?
z
The End
