Chapter 3_Software Design sunorganisedASE_BW_finalised.ppt

1
Chapter 3
Software Design
M.Sc(CS)

2
Design
• Mitch Kapor, the creator of Lotus 1-2-3,
presented a “software design manifesto” in
Dr. Dobbs Journal. He said:
– Good software design should exhibit:
– Firmness: A program should not have any
bugs that inhibit its function.
– Commodity: A program should be suitable for
the purposes for which it was intended.
– Delight: The experience of using the program
should be pleasurable one.

3
Analysis Model -> Design Model
Analysis Model
use-cases - text
use-case diagrams
activity diagrams
swim lane diagrams
data flow diagrams
control-flow diagrams
processing narratives
f low- or ient ed
element s
behavior al
element s
class- based
element s
scenar io- based
element s
class diagrams
analysis packages
CRC models
collaboration diagrams
state diagrams
sequence diagrams
Da t a / Cla ss De sign
Arc hit e c t ura l De sign
Int e rfa c e De sign
Com pone nt -
Le v e l De sign
Design Model

4
Design and Quality
• 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.
• 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 behavioral domains from an implementation
perspective.

5
Quality Guidelines
• A design should exhibit an architecture that (1) has been created using
recognizable architectural styles or patterns, (2) is composed of
components that exhibit good design characteristics and (3) can be
implemented in an evolutionary fashion
– For smaller systems, design can sometimes be developed linearly.
• A design should be modular; that is, the software should be logically
partitioned into elements or subsystems
• A design should contain distinct representations of data, architecture,
interfaces, and components.
• A design should lead to data structures that are appropriate for the classes
to be implemented and are drawn from recognizable data patterns.
• A design should lead to components that exhibit independent functional
characteristics.
• A design should lead to interfaces that reduce the complexity of connections
between components and with the external environment.
• A design should be derived using a repeatable method that is driven by
information obtained during software requirements analysis.
• A design should be represented using a notation that effectively
communicates its meaning.

6
Design Principles
• The design process should not suffer from ‘tunnel vision.’
• The design should be traceable to the analysis model.
• The design should not reinvent the wheel.
• The design should “minimize the intellectual distance”
[DAV95] between the software and the problem as it exists
in the real world.
• The design should exhibit uniformity and integration.
• The design should be structured to accommodate change.
• The design should be structured to degrade gently, even
when aberrant data, events, or operating conditions are
encountered.
• Design is not coding, coding is not design.
• The design should be assessed for quality as it is being
created, not after the fact.
• The design should be reviewed to minimize conceptual
(semantic) errors. From Davis [DAV95]

7
Fundamental Concepts of Design
• Abstraction—data, procedure,
control
• Architecture—the overall structure
of the software
• Patterns—”conveys the essence” of
a proven design solution
• Separation of concerns—any
complex problem can be more
easily handled if it is subdivided into
pieces

8
Data Abstraction
door
implemented as a data structure
manufacturer
model number
type
swing direction
inserts
lights
type
number
weight
opening mechanism

9
Procedural Abstraction
open
implemented with a "knowledge" of the
object that is associated with enter
details of enter
algorithm

10
Architectural Design
“The overall structure of the software and the ways in
which that structure provides conceptual integrity for a
system.” [SHA95a]
1. Structural properties. This aspect of the architectural design
representation defines the components of a system (e.g., modules,
objects, filters) and the manner in which those components are
packaged and interact with one another. For example, objects are
packaged to encapsulate both data and the processing that
manipulates the data and interact via the invocation of methods
2. Extra-functional properties. The architectural design description
should address how the design architecture achieves requirements
for performance, capacity, reliability, security, adaptability, and other
system characteristics.
3. Families of related systems. The architectural design should draw
upon repeatable patterns that are commonly encountered in the
design of families of similar systems. In essence, the design should
have the ability to reuse architectural building blocks.

11
Why you need to follow Architecture?
The architecture is not the operational
software. Rather, it is a representation that
enables a software engineer to:
(1) analyze the effectiveness of the design in
meeting its stated requirements,
(2) consider architectural alternatives at a
stage when making design changes is still
relatively easy, and
(3) reduce the risks associated with the
construction of the software.

12
Architectural Descriptions
• The IEEE Computer Society has proposed IEEE-Std-
1471-2000, Recommended Practice for Architectural
Description of Software-Intensive System, [IEE00]
– to establish a conceptual framework and vocabulary for use during the
design of software architecture,
– to provide detailed guidelines for representing an architectural
description, and
– to encourage sound architectural design practices.
• The IEEE Standard defines an architectural description (AD)
as a “a collection of products to document an architecture.”
– The description itself is represented using multiple views, where each
view is “a representation of a whole system from the perspective of a
related set of [stakeholder] concerns.”

13
Architectural Styles
Example of Different Architectures
1. Data-centered architectures
2. Data flow architectures
3. Call and return architectures
4. Object-oriented architectures
5. Layered architectures
Each style describes a system category that encompasses:
(1) a set of components (e.g., a database, computational
modules) that perform a function required by a system,
(2) a set of connectors that enable “communication,
coordination and cooperation” among components,
(3) constraints that define how components can be
integrated to form the system, and
(4) semantic models that enable a designer to understand
the overall properties of a system by analyzing the known
properties of its constituent parts.

16
Call and Return Architecture

18
Architectural Patterns
• Concurrency—applications must handle multiple tasks in a
manner that simulates parallelism
– operating system process management pattern
– task scheduler pattern
• Persistence—Data persists if it survives past the execution of
the process that created it. Two patterns are common:
– a database management system pattern that applies the storage
and retrieval capability of a DBMS to the application architecture
– an application level persistence pattern that builds persistence
features into the application architecture
• Distribution— the manner in which systems or components
within systems communicate with one another in a distributed
environment
– A broker acts as a ‘middle-man’ between the client component and
a server component.

19
Architectural Design
• The software must be placed into context
– the design should define the external entities (other
systems, devices, people) that the software interacts
with and the nature of the interaction
• A set of architectural archetypes should be
identified
– An archetype is an abstraction (similar to a class) that
represents one element of system behavior
• The designer specifies the structure of the
system by defining and refining software
components that implement each archetype

20
Architectural Context
target system:
SecurityFunction
uses
uses peers
homeowner
Safehome
Product
Internet-based
system
surveillance
function
sensors
control
panel
sensors
uses

21
Archetypes
Figure 10.7 UML relat ionships f or Saf eHome securit y f unct ion archet ypes
(adapt ed f rom [ BOS00] )
Cont roller
Node
communicat es wit h
Det ect or Indicat or

22
Analyzing Architectural Design
1. Collect scenarios.
2. Elicit requirements, constraints, and environment
description.
3. Describe the architectural styles/patterns that have been
chosen to address the scenarios and requirements:
• module view
• process view
• data flow view
4. Evaluate quality attributes by considered each attribute
in isolation.
5. Identify the sensitivity of quality attributes to various
architectural attributes for a specific architectural style.
6. Critique candidate architectures (developed in step 3)
using the sensitivity analysis conducted in step 5.

23
Architectural Complexity
• The overall complexity of a proposed architecture
is assessed by considering the dependencies
between components within the architecture
[Zha98]
– Sharing dependencies represent dependence
relationships among consumers who use the same
resource or producers who produce for the same
consumers.
– Flow dependencies represent dependence relationships
between producers and consumers of resources.
– Constrained dependencies represent constraints on the
relative flow of control among a set of activities.

24
An Architectural Design Method
"four bedrooms, three baths,
lots of glass ..."
customer requirements
architectural design

25
Deriving Program Architecture
Program
Architecture

26
Partitioning the Architecture
• “horizontal” and “vertical” partitioning are
required

27
Horizontal Partitioning
• define separate branches of the module
hierarchy for each major function
• use control modules to coordinate
communication between functions
function 1 function 3
function 2

28
Vertical Partitioning:
• design so that decision making and work are
stratified
• decision making modules should reside at the top
of the architecture
workers
decision-makers

29
Why Partitioned Architecture?
• results in software that is easier
to test
• leads to software that is easier to
maintain
• results in propagation of fewer
side effects
• results in software that is easier
to extend

30
Interface Design
Easy to use?
Easy to understand?
Easy to learn?

31
Interface Design
lack of consistency
too much memorization
no guidance / help
no context sensitivity
poor response
Arcane/unfriendly
Typical Design Errors

32
Golden Rules
• Place the user in control
• Reduce the user’s memory load
• Make the interface consistent

33
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.
Streamline interaction as skill levels advance and
allow the interaction to be customized.
Hide technical internals from the casual user.
Design for direct interaction with objects that appear
on the screen.

34
Reduce the User’s Memory
Load
1. Reduce demand on short-term memory.
2. Establish meaningful defaults.
3. Define shortcuts that are intuitive.
4. The visual layout of the interface should be
based on a real world metaphor.
5. Disclose information in a progressive fashion.

35
Make the Interface Consistent
Allow the user to put the
current task into a
meaningful context.
Maintain consistency
across a family of
applications

36
User Interface Design Models
• User model — a profile of all end users of
the system
• Design model — a design realization of the
users as a model
• Mental model (system perception) — the
user’s mental image of what the interface is
• Implementation model — the interface “look
and feel” coupled with supporting information
that describe interface syntax and semantics

37
User Interface Design Process

38
Interface Design Steps
• Using information developed during interface
analysis, define interface objects and actions
(operations).
• Define events (user actions) that will cause the
state of the user interface to change. Model this
behavior.
• Depict each interface state as it will actually look
to the end-user.
• Indicate how the user interprets the state of the
system from information provided through the
interface.

39
Design Issues
• Response time
• Help facilities
• Error handling
• Menu and command
labeling
• Application
accessibility
• Internationalization

40
What is a Component?
• OMG Unified Modeling Language Specification [OMG01]
defines a component as
– “… a modular, deployable, and replaceable part of a system that
encapsulates implementation and exposes a set of interfaces.””
• OO view: a component contains a set of collaborating
classes
• Conventional view: a component contains processing
logic, the internal data structures that are required to
implement the processing logic, and an interface that
enables the component to be invoked and data to be
passed to it.

41
Basic Design Principles
• The Open-Closed Principle (OCP). “A module [component]
should be open for extension but closed for modification.
• The Liskov Substitution Principle (LSP). “Subclasses should be
substitutable for their base classes.
• Dependency Inversion Principle (DIP). “Depend on abstractions.
Do not depend on concretions.”
• 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.”
Source: Martin, R., “Design Principles and Design Patterns,” downloaded from http:www.objectmentor.com, 2000.

42
Design Guidelines
• Components
– Naming conventions should be established for
components that are specified as part of the
architectural model and then refined and elaborated
as part of the component-level model
• Interfaces
– Interfaces provide important information about
communication and collaboration
• Dependencies and Inheritance
– it is a good idea to model dependencies from left to
right and inheritance from bottom (derived classes)
to top (base classes).

Assignment (to be turned in in 7
days)
1. Discuss the three “parts” of a design pattern and provide a
concrete example of each from some field other than software.
2. What is the difference between a nongenerative and a generative
pattern?
3. How do architectural patterns differ from component patterns?
4. What is a framework and how does it differ from a pattern? What is
an idiom and how does it differ from a pattern?
5. Discuss about the design pattern template presented in Section
12.1.3.
6. Find five patterns repositories and present an abbreviated
description of the types of patterns contained in each
43

Chapter 3_Software Design sunorganisedASE_BW_finalised.ppt

Recommended

Recommended

More Related Content

Similar to Chapter 3_Software Design sunorganisedASE_BW_finalised.ppt

Similar to Chapter 3_Software Design sunorganisedASE_BW_finalised.ppt (20)

More from Bule Hora University

More from Bule Hora University (6)

Recently uploaded

Recently uploaded (20)

Chapter 3_Software Design sunorganisedASE_BW_finalised.ppt