ITIS 3310 Software Architecture and Design Chapter 9 Design Engineering

1
ITIS 3310 Software Architecture and Design
Chapter 9Design Engineering
2
So Far

• Process
• Development Processes
• Practice
• System Engineering
• Requirements Engineering
• Analysis Modeling
• And now

3
Introduction

• The goal of design engineering is to produce a
  model that exhibits
• Extrapolating from Roman architect Vitruvius
• Firmness
• No bugs that inhibit its function
• Commodity
• Suitable for the purpose for which it was
  intended
• Delight
• Pleasant to use
• One of my undergraduate courses Man and the
  Environment
• A well designed environment is one where it is
  obvious where to go next just by looking where
  you are now.

4
Introduction

• Accomplished by practicing
• Diversification
• Acquisition of a repertoire of alternatives
• Cutting wood table saw, radial arm, router,
  sabre saw, etc.
• What kind of cut, what do you have, etc.
• Raw material of design
• Components, knowledge
• Convergence
• Choosing the components that meet the
  requirements
• Alternatives are considered then chosen/rejected
  until one set of components is assembled

5
Design Model
C
o
m
p
o
n
e
n
t
-

L
e
v
e
l

D
e
s
i
g
n
The actual software
How the system communicates
How the components fit together
A
r
c
h
i
t
e
c
t
u
r
a
l

D
e
s
i
g
n
Data Structures
D
a
t
a
/
C
l
a
s
s

D
e
s
i
g
n
6
Analysis Model -gt Design Model
7
Design and Quality

• The design must
• Implement all of the explicit requirements
  contained in the analysis model
• Accommodate all of the implicit requirements
  desired by the customer
• Be a readable, understandable guide for those
  who
• Generate code
• Test and subsequently support the software
• Design should provide a complete picture of the
  software
• Address the data, functional, and behavioral
  domains
• From an implementation perspective

8
Quality Guidelines

• A design should exhibit an architecture that
• Has been created using recognizable architectural
  styles or patterns
• Is composed of components that exhibit good
  design characteristics
• Can be implemented in an evolutionary fashion
• For smaller systems, design can sometimes be
  developed linearly
• A design should be modular
• Logically partitioned into elements or subsystems
• A design should contain distinct representations
  of
• Data
• Architecture
• Interfaces
• Components
• A design should lead to data structures that are
• Appropriate for the classes to be implemented
• Drawn from recognizable data patterns

9
Quality Guidelines

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

10
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 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
11
Quality Attributes

• A quality design is
• Functional features, capabilities, security
• Useable considers human factors
• Reliable minimizes failure and recovers from
  failure well and produces accurate results
• High performance response time, resource
  consumption, and throughput are within bounds
• Supportable extensible, adaptable, serviceable
  maintainable
• Different systems may give different weights to
  each of these attributes
• Pacemaker software Reliability highest weight
• Search engine High performance highest weight

12
Fundamental Design Concepts

• Concepts have evolved over time
• Each level is a foundation for more sophisticated
  methods
• The difference between
• Getting it to work
• Getting it right

13
Fundamental Concepts

• Abstractiondata, procedure, control
• Architecturethe overall structure of the
  software
• Patternsconveys the essence of a proven design
• Modularitycompartmentalization of data and
  function
• Hidingcontrolled interfaces
• Functional independencesingle-minded function
  and low coupling
• Refinementelaboration of detail for all
  abstractions
• Refactoringreorganization technique to simplify
  design

14
Data Abstraction
door
manufacturer
model number
type
swing direction
inserts
lights
type
number
weight
opening mechanism
implemented as a data structure
Data abstraction describes a data object
15
Procedural Abstraction
open
details of enter
algorithm
implemented with a "knowledge" of the
object that is associated with enter
Procedural abstraction defines a feature or
function
16
Architecture
The overall structure of the software and the
ways in which that structure provides conceptual
integrity for a system

• Structure or organization of program components
• Manner in which these components interact
• Structure of data used by these components

One goal of software design is to produce an
architectural rendering of the system
17
Architecture

• Structural models
• Organized collection of program components
• Framework models
• Identify repeatable design elements encountered
  in similar architectures
• Dynamic models
• Behavioral aspects of the system
• How the system responds to external events

18
Architecture

• Process models
• Business or technical process being performed
• Functional models
• Functional hierarchy of system

19
Patterns
Design Pattern Template Pattern namedescribes
the essence of the pattern in a short but
expressive name Intentdescribes the pattern and
what it does Also-known-aslists any synonyms for
the pattern Motivationprovides an example of the
problem Applicabilitynotes specific design
situations in which the pattern is
applicable Structuredescribes the classes that
are required to implement the pattern Participants
describes the responsibilities of the classes
that are required to implement the
pattern Collaborationsdescribes how the
participants collaborate to carry out their
responsibilities Consequencesdescribes the
design forces that affect the pattern and the
potential trade-offs that must be considered when
the pattern is implemented Related
patternscross-references related design patterns
20
Patterns

• Patterns enables designers to determine if
• A particular pattern is applicable
• A pattern is reusable or not
• A pattern can be used as a template to create a
  similar but somewhat pattern

21
Modular Design

• Monolithic design
• Cannot be easily grasped by software developers
• Has too many
• Control paths
• Variables
• Complexity
• Generally easier to solve complex problems by
• Breaking them down into more less complex
  problems and
• Solving these problems individually
• Same true for software (to a point)

22
Modular Design
Easier to build, easier to change, easier to fix
...
23
Modular Design

• More modules means smaller size
• Easier (less costly) to develop
• However, larger effort to manage integration
• Where is the optimum point?

24
Modularity Trade-offs
What is the "right" number of modules
for a specific software design?
module development cost
cost of
software
module integration cost
optimal number
number of modules
of modules
25
Modularity Trade-offs

• What can we use to determine the optimum number
  of modules?
• Several basic principles
• Information Hiding
• Design decisions are hidden from other modules
• Communication is only as much as is necessary to
  enable functionality
• Errors in one modules functionality are much less
  likely to propagate to other modules

26
Information Hiding
module
algorithm

controlled
data structure
interface

details of external interface

resource allocation policy
clients
"secret"
a specific design decision
27
Why Information Hiding?

• Reduces the likelihood of side effects
• Limits the global impact of local design
  decisions
• Emphasizes communication through controlled
  interfaces
• Discourages the use of global data
• Leads to encapsulationan attribute of high
  quality design
• Results in higher quality software

28
Modularity Trade-offs

• What can we use to determine the optimum number
  of modules?
• Several basic principles
• Information Hiding
• Functional Independence
• Modules have a single-minded function
• They are averse to excessive interaction with
  other modules
• Functionality is compartmentalized
• Interfaces are simplified
• Easier to test and maintain

29
Functional Independence
Highly cohesive modules are simple
Low coupling means little interconnection
30
Modularity Trade-offs

• What can we use to determine the optimum number
  of modules?
• Several basic principles
• Information Hiding
• Functional Independence
• Stepwise Refinement
• Top-down strategy
• Process of elaboration
• Begins with abstract statement
• Drills down to actual programming statement

31
Stepwise Refinement
open
walk to door
reach for knob

open door
repeat until door opens

turn knob clockwise
walk through
if knob doesn't turn, then
close door.
take key out
find correct key
insert in lock
endif
pull/push door move out of way
end repeat
32
Modularity Trade-offs

• What can we use to determine the optimum number
  of modules?
• Several basic principles
• Information Hiding
• Functional Independence
• Stepwise Refinement
• Refactoring
• Simplifies code without changing behavior
• Improves internal structure

33
Sizing Modules Two Views
34
Refactoring

• When software is refactored, the existing design
  is examined for
• Redundancy
• Unused design elements
• Inefficient or unnecessary algorithms
• Poorly constructed or inappropriate data
  structures
• Any other design failure that can be corrected to
  yield a better design
• Can be as simple as renaming data elements or
  methods
• Existing module might be separated into smaller
  sub-modules
• Existing code might be re-written to provide more
  efficiency

35
Design Classes

• Analysis classes describe some element of the
  problem domain
• At customer level
• Highly abstract
• The analysis model leads to the design model
• Provides design detail that enables classes to be
  implemented
• Creates new design classes that can be
  implemented in software to support the business
  solution
• Five basic types of design classes
• Represent different layers of the design
  architecture

36
Design Classes

• User interface classes
• Abstractions that are necessary for
  human-computer interaction (HCI)
• May be metaphor-based
• Desktop
• Checkbook
• Order form
• Design class would visually represent some
  element of the metaphor

37
Design Classes

• Business domain classes
• Refinements of the Analysis classes
• Identify attributes and methods that implement
  some element of the business domain

38
Design Classes

• Process classes
• Implement lower-level business abstractions
  necessary to fully realize a business domain
  class
• Persistent classes
• Represent data stores data that lasts longer
  than the execution of the software
• System classes
• Implements software management and control
  functions
• How does the system interact within its own
  environment and with the outside world

39
The Design Model

• Design models evolve
• Level of abstraction reduced as models move from
  analysis towards design
• Design classes represent significant technical
  detail
• Design classes should be well-formed
• That is, they should be

40
The Design Model

• Complete and sufficient
• Complete Contains all attributes and methods
  necessary to implement the class
• Sufficient Only those attributes and methods
  necessary and no others
• Primitive
• Methods should accomplish one service for a class
• Multiple methods to accomplish the same service
  should be prohibited

41
The Design Model

• Highly cohesive
• Small, focused set of responsibilities
• Attributes and methods support those
  responsibilities only
• Low coupled
• Minimal collaboration with other classes
• Limited knowledge of methods in other classes
• In other words Dont talk to strangers

42
Resume After Break
43
The Design Model
44
Data Design Elements

• During analysis model data at customers level
• Highly abstract
• Refined towards implementation-specific model
• Something that can be represented in a real
  machine
• At program level
• Data structures, databases, data warehouses
• Algorithms to manipulate them

45
Architectural Design Elements

• Equivalent of a houses floor plan
• Location of doors, windows, walls
• Their relationship to each other
• Architecture gives us an overall view of the
  software
• Derived from
• Information about the application domain
• Analysis models
• Data flow diagrams, analysis classes, etc.
• Patterns as appropriate

46
Interface Elements

• Equivalent to drawing showing doors, windows, and
  external utilities of a house
• How data flows into or out of the system
• How software communicates between components
• Important elements
• User interface
• External interfaces
• To other systems, devices, networks
• Internal interfaces
• Between design components

47
Interface Elements
48
Component Elements

• Equivalent to a detailed drawing of each room in
  a house
• Describes internal detail of each software
  component
• Data structures for all local data objects
• Algorithmic detail for all processing
• Interfaces for access to all component operations
  (methods)

49
Component Elements
Component
Class
50
Deployment Elements

• Indicates how functionality will be allocated to
  physical computing environment

51
Deployment Elements
52
Summary

• Design is where all the previous research,
  modeling and documenting starts turning into a
  product.