Chapter 5 Software Design

1
Chapter 5Software Design
2
Analysis Model -gt Design Model
3
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.

4
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
• (3) can be implemented in an evolutionary fashion
• 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 components that exhibit
  independent functional characteristics.
• A design should be represented using a notation
  that effectively communicates its meaning.

5
Quality Attributes

• Functionality assess features capabilities,
  generality of functions, security of overall
  system
• Usability assess human factors, consistency, and
  documentation
• Performance processing speed, response time,
  resource consumption
• Supportability maintainability, compatibility,
  ease of configuration, ease of installation

6
Fundamental Design Concepts

• abstractiondata, procedure, control
• architecturethe overall structure of the
  software
• patternsconveys the essence of a proven design
  solution
• modularitycompartmentalization of data and
  function
• hidingcontrolled interfaces
• Functional independencesingle-minded function
  and low coupling
• refinementelaboration of detail for all
  abstractions
• Refactoringa reorganization technique that
  simplifies the design

7
Data Abstraction
door
Manufacturer model number type swing
direction inserts lights type
number weight opening mechanism
implemented as a data structure
8
Procedural Abstraction
open
details of enter algorithm
implemented with a "knowledge" of the object that
is associated with enter
9
Architecture

• The overall structure of the software and the
  ways in which that structure provides conceptual
  integrity for a system. SHA95a
• 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
• 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.
• 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.

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

11
Modular Design
12
Modularity Trade-offs
What is the "right" number of modules for a
specific software design?
module development cost
cost of software
module integration cost
number of modules
optimal number of modules
13
Information Hiding
module
algorithm

controlled interface
data structure

details of external interface

resource allocation policy
clients
"secret"
a specific design decision
14
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

15
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
16
Functional Independence
17
Sizing Modules Two Views
18
Refactoring

• Fowler FOW99 defines refactoring in the
  following manner
• "Refactoring is the process of changing a
  software system in such a way that it does not
  alter the external behavior of the code design
  yet improves its internal structure.
• When software is refactored, the existing design
  is examined for
• redundancy
• unused design elements
• inefficient or unnecessary algorithms
• poorly constructed or inappropriate data
  structures
• or any other design failure that can be corrected
  to yield a better design.

19
The Design Model
20
Design Model Elements

• Data elements
• Data model --gt data structures
• Data model --gt database architecture
• Architectural elements
• Application domain
• Analysis classes, their relationships,
  collaborations and behaviors are transformed into
  design realizations
• Patterns and styles (Chapter 10)
• Interface elements
• the user interface (UI)
• external interfaces to other systems, devices,
  networks or other producers or consumers of
  information
• internal interfaces between various design
  components.
• Component elements
• Deployment elements

21
Data Design

• Data design translates data objects defined as
  part of the analysis model into
• Data structures at the software component level
• A possible database architecture at the
  application level
• It focuses on the representation of data
  structures that are directly accessed by one or
  more software components
• The challenge is to store and retrieve the data
  in such way that useful information can be
  extracted from the data environment
• "Data quality is the difference between a data
  warehouse and a data garbage dump"

22
Software Architecture

• The software architecture of a program or
  computing system is the structure or structures
  of the system which comprise
• The software components
• The externally visible properties of those
  components
• The relationships among the components
• Software architectural design represents the
  structure of the data and program components that
  are required to build a computer-based system
• An architectural design model is transferable
• It can be applied to the design of other systems
• It represents a set of abstractions that enable
  software engineers to describe architecture in
  predictable ways

23
Example Software Architecture Diagrams
23
24
Why 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.

25
Architectural Styles

• Each style describes a system category that
  encompasses
• a set of components (e.g., a database,
  computational modules) that perform a function
  required by a system,
• a set of connectors (subroutine call, remote
  procedure call, data stream, socket) that enable
  communication, coordination and cooperation
  among components,
• semantic constraints that define how components
  can be integrated to form the system, and

• Data flow architectures
• Call and return architectures
• Data-centered architectures
• Virtual Machine architectures
• Independent Component architectures

26
A Taxonomy of Architectural Styles
27
Data Flow Architecture
28
Data Flow Architecture

• Has the goal of modifiability
• Characterized by viewing the system as a series
  of transformations on successive pieces of input
  data
• Data enters the system and then flows through the
  components one at a time until they are assigned
  to output or a data store
• Batch sequential style
• The processing steps are independent components
• Each step runs to completion before the next step
  begins
• Pipe-and-filter style
• Emphasizes the incremental transformation of data
  by successive components
• The filters incrementally transform the data
  (entering and exiting via streams)
• The filters use little contextual information and
  retain no state between instantiations
• The pipes are stateless and simply exist to move
  data between filters
• Use this style when it makes sense to view your
  system as one that produces a well-defined easily
  identified output
• The output should be a direct result of
  sequentially transforming a well-defined easily
  identified input in a time-independent fashion

29
Call and Return Architecture
29
30
Call and Return Architecture

• Has the goal of modifiability and scalability
• Has been the dominant architecture since the
  start of software development
• Main program and subroutine style
• Decomposes a program hierarchically into small
  pieces (i.e., modules)
• Typically has a single thread of control that
  travels through various components in the
  hierarchy
• Remote procedure call style
• Consists of main program and subroutine style of
  system that is decomposed into parts that are
  resident on computers connected via a network
• Strives to increase performance by distributing
  the computations and taking advantage of multiple
  processors
• Incurs a finite communication time between
  subroutine call and response

31
Call and Return Architecture

• Object-oriented or abstract data type system
• Emphasizes the bundling of data and how to
  manipulate and access data
• Keeps the internal data representation hidden and
  allows access to the object only through provided
  operations
• Permits inheritance and polymorphism
• Layered system
• Assigns components to layers in order to control
  inter-component interaction
• Only allows a layer to communicate with its
  immediate neighbor
• Assigns core functionality such as hardware
  interfacing or system kernel operations to the
  lowest layer
• Builds each successive layer on its predecessor,
  hiding the lower layer and providing services for
  the upper layer
• Is compromised by layer bridging that skips one
  or more layers to improve runtime performance
• Use this style when the order of computation is
  fixed, when interfaces are specific, and when
  components can make no useful progress while
  awaiting the results of request to other
  components

32
Data-Centered Architecture
33
Data-Centered Architecture

• Has the goal of integrating the data
• Refers to systems in which the access and update
  of a widely accessed data store occur
• A client runs on an independent thread of control
• The shared data may be a passive repository or an
  active blackboard
• A blackboard notifies subscriber clients when
  changes occur in data of interest
• At its heart is a centralized data store that
  communicates with a number of clients
• Clients are relatively independent of each other
  so they can be added, removed, or changed in
  functionality
• The data store is independent of the clients
• Use this style when a central issue is the
  storage, representation, management, and
  retrieval of a large amount of related persistent
  data
• Note that this style becomes client/server if the
  clients are modeled as independent processes

34
Virtual Machine Architecture
Program Data
Program Instructions
Interpretation Engine
Program Internal State
35
Virtual Machine Architecture

• Has the goal of portability
• Software systems in this style simulate some
  functionality that is not native to the hardware
  and/or software on which it is implemented
• Can simulate and test hardware platforms that
  have not yet been built
• Can simulate "disaster modes" as in flight
  simulators or safety-critical systems that would
  be too complex, costly, or dangerous to test with
  the real system
• Examples include interpreters, rule-based
  systems, and command language processors
• Interpreters
• Add flexibility through the ability to interrupt
  and query the program and introduce modifications
  at runtime
• Incur a performance cost because of the
  additional computation involved in execution
• Use this style when you have developed a program
  or some form of computation but have no make of
  machine to directly run it on

36
Independent Component Architecture
Client A
Client B
Server
Client D
Client C
Peer X
Peer W
Peer Z
Peer Y
37
Independent Component Architecture

• Consists of a number of independent processes
  that communicate through messages
• Has the goal of modifiability by decoupling
  various portions of the computation
• Sends data between processes but the processes do
  not directly control each other
• Event systems style
• Individual components announce data that they
  wish to share (publish) with their environment
• The other components may register an interest in
  this class of data (subscribe)
• Makes use of a message component that manages
  communication among the other components
• Components publish information by sending it to
  the message manager
• When the data appears, the subscriber is invoked
  and receives the data
• Decouples component implementation from knowing
  the names and locations of other components

38
Independent Component Architecture

• Communicating processes style
• These are classic multi-processing systems
• Well-know subtypes are client/server and
  peer-to-peer
• The goal is to achieve scalability
• A server exists to provide data and/or services
  to one or more clients
• The client originates a call to the server which
  services the request
• Use this style when
• Your system has a graphical user interface
• Your system runs on a multiprocessor platform
• Your system can be structured as a set of loosely
  coupled components
• Performance tuning by reallocating work among
  processes is important
• Message passing is sufficient as an interaction
  mechanism among components

39
Architectural Design Steps

1. Represent the system in context
2. Define archetypes
3. Refine the architecture into components
4. Describe instantiations of the system

40
Architectural Context

• Use an architectural context diagram (ACD) that
  shows
• The identification and flow of all information
  into and out of a system
• The specification of all interfaces
• Any relevant support processing from/by other
  systems
• An ACD models the manner in which software
  interacts with entities external to its
  boundaries
• An ACD identifies systems that interoperate with
  the target system
• Super-ordinate systems
• Use target system as part of some higher level
  processing scheme
• Sub-ordinate systems
• Used by target system and provide necessary data
  or processing
• Peer-level systems
• Interact on a peer-to-peer basis with target
  system to produce or consume data
• Actors
• People or devices that interact with target
  system to produce or consume data

41
Architectural Context Diagram
42
SafeHome ACD
43
Archetypes

• Archetypes indicate the important abstractions
  within the problem domain (i.e., they model
  information)
• An archetype is a class or pattern that
  represents a core abstraction that is critical to
  the design of an architecture for the target
  system
• It is also an abstraction from a class of
  programs with a common structure and includes
  class-specific design strategies and a collection
  of example program designs and implementations
• Only a relatively small set of archetypes is
  required in order to design even relatively
  complex systems
• The target system architecture is composed of
  these archetypes
• They represent stable elements of the
  architecture
• They may be instantiated in different ways based
  on the behavior of the system
• They can be derived from the analysis class model
• The archetypes and their relationships can be
  illustrated in a UML class diagram

44
Example Archetypes in Humanity

• Addict/Gambler
• Amateur
• Beggar
• Clown
• Companion
• Damsel in distress
• Destroyer
• Detective
• Don Juan
• Drunk
• Engineer
• Father
• Gossip
• Guide
• Healer
• Hero
• Judge
• King
• Knight

• Lover/Devotee
• Martyr
• Mediator
• Mentor/Teacher
• Messiah/Savior
• Monk/Nun
• Mother
• Mystic/Hermit
• Networker
• Pioneer
• Poet
• Priest/Minister
• Prince
• Prostitute
• Queen
• Rebel/Pirate
• Saboteur
• Samaritan
• Scribe/Journalist

• Seeker/Wanderer
• Servant/Slave
• Storyteller
• Student
• Trickster/Thief
• Vampire
• Victim
• Virgin
• Visionary/Prophet
• Warrior/Soldier

(Source http//www.myss.com/ThreeArchs.asp)
45
Example Archetypes in Software Architecture

• Node
• Detector/Sensor
• Indicator
• Controller
• Manager

• Moment-Interval
• Role
• Description
• Party, Place or Thing

(Source Archetypes, Color, and the Domain
Neutral Component)
(Source Pressman)
46
Archetypes their attributes
47
Archetypes their methods
48
Components

• Based on the archetypes, the architectural
  designer refines the software architecture into
  components to illustrate the overall structure
  and architectural style of the system
• These components are derived from various sources
• The application domain provides application
  components, which are the domain classes in the
  analysis model that represent entities in the
  real world
• The infrastructure domain provides design
  components (i.e., design classes) that enable
  application components but have no business
  connection
• Examples memory management, communication,
  database, and task management
• The interfaces in the ACD imply one or more
  specialized components that process the data that
  flow across the interface
• A UML class diagram can represent the classes of
  the refined architecture and their relationships

49
Instantiations of the System

• An actual instantiation of the architecture is
  developed by applying it to a specific problem
• This demonstrates that the architectural
  structure, style and components are appropriate
• A UML component diagram can be used to represent
  this instantiation

50
Component Structure
51
Refined Component Structure
Instantiations of the System
52
Analyzing Architectural Design

• Describe the architectural styles/patterns that
  have been chosen to address the scenarios and
  requirements
• module view
• process view
• data flow view
• Evaluate quality attributes by considering each
  attribute in isolation.

• easier to test
• easier to maintain
• propagation of fewer side effects
• easier to extend

53
Deriving Program Architecture
Program Architecture
54
Partitioning the Architecture

• horizontal and vertical partitioning are
  required

55
Horizontal Partitioning

• define separate branches of the module hierarchy
  for each major function
• use control modules to coordinate communication
  between functions

function 3
function 1
function 2
56
Vertical Partitioning Factoring

• design so that decision making and work are
  stratified
• decision making modules should reside at the top
  of the architecture

decision-makers
workers
57
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

58
Structured Design

• objective to derive a program architecture that
  is partitioned
• approach
• the DFD is mapped into a program architecture
• the PSPEC and STD (state transition diagram) are
  used to indicate the content of each module
• notation structure chart

59
Flow Characteristics

• Transform flow
• Incoming flow
• Transform center
• Outgoing flow

• Transaction flow
• A single data item

60
General Mapping Approach

• isolate incoming and outgoing flow boundaries
  for transaction flows, isolate the transaction
  center
• working from the boundary outward, map DFD
  transforms into corresponding modules
• add control modules as required
• refine the resultant program structure using
  effective modularity concepts

61
Transform Mapping
62
Factoring
63
First Level Factoring
main
program
controller
output
input
processing
controller
controller
controller
64
Second Level Mapping
65
Transaction Flow
incoming flow
action path
T
66
Transaction Example
Control panel display
Display information
commands
Control panel
Alarm Type
SafeHome Software
Alarm
Telephone number tones
Sensor status
Telephone Line
Sensors
67
Transaction Mapping Principles

• isolate the incoming flow path
• define each of the action paths by looking for
  the "spokes of the wheel
• assess the flow on each action path
• define the dispatch and control structure
• map each action path flow individually

68
Transaction Mapping
Data flow model
f
e
a
d
mapping
b
x1
t
i
g
program structure
h
l
k
t
b
j
m
a
x2
x3
x4
n
n
f
g
h
x3.1
l
m
d
e
i
j
k
69
Isolate Flow Paths
error msg
produce error msg
command
read command
fixture setting
format setting
status
determine setting
validate command
read fixture status
invalid command
raw setting
command
combined status
determine type
valid command
read record
robot control
record
calculate output values
send control value
values
format report
report
assembly record
start/stop
70
Map the Flow Model
71
Refining the Structure Chart
72
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 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.

73
OO Component
What are the differences?
Interfacemethod?
OO view a component contains a set of
collaborating classes
74
Conventional Component

• Conventional view
• 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.

75
Cohesion and Coupling

• Cohesion
• Conventional view
• the single-mindedness of a module
• OO view
• a component or class encapsulates only attributes
  and operations that are closely related to one
  another Levels of cohesion
• Functional, Layer, Communicational, Sequential,
  Procedural, Temporal, utility
• Coupling
• Conventional view
• The degree to which a component is connected to
  other components and to the external world
• OO view
• a qualitative measure of the degree to which
  classes are connected to one another
• Level of coupling
• Content, Common, Control, Stamp, Data, Routine
  call, Type use, Inclusion or import, External

76
Component Level Design

• Step 1. Identify all design classes that
  correspond to the problem domain, infrastructure
  domain.
• Step 2. Elaborate all design classes (not
  acquired as reusable components).
• Step 2a. Specify message details when classes or
  component collaborate.
• Step 2b. Identify appropriate interfaces for
  each component.
• Step 2c. Elaborate attributes and define data
  types and data structures.
• Step 2d. Describe processing flow within each
  operation in detail.
• Step 3. Describe persistent data sources
  (databases and files) and identify the classes
  required to manage them.
• Step 4. Develop and elaborate behavioral
  representations for a class or component.
• Step 5. Elaborate deployment diagrams to provide
  additional implementation detail.
• Step 6. Factor every component-level design
  representation and always consider alternatives.

77
Activity Diagram

• What is this about wrt.
• Component-level design?

• What would be behavioral wrt.
• Component-level design?

78
Statechart

• What is this about wrt.
• Component-level design?

• How does this differ from AD wrt.
• Component-level design?

79
Collaboration Diagram

• What is this about wrt.
• Component-level design?

80
Refactoring
81
Algorithm Design

• the closest design activity to coding
• the approach
• review the design description for the component
• use stepwise refinement to develop algorithm
• use structured programming to implement
  procedural logic
• use formal methods to prove logic

82
Stepwise Refinement
Recall
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
83
Algorithm Design Model

• represents the algorithm at a level of detail
  that can be reviewed for quality
• options
• graphical (e.g. flowchart, box diagram)
• pseudo code (e.g., PDL) ... choice of many
• programming language(?)
• decision table
• conduct walkthrough to assess quality

• At which level?
• Component or Class?

At which level?
84
Structured Programmingfor Procedural Design

• uses a limited set of logical constructs
• Sequence
• Conditional if-then-else, select-case
• Loops do-while, repeat until
• leads to more readable, testable code
• can be used in conjunction with proof of
  correctness

go-to considered ???
Whats more to Structured Programming than the
above?
85
A Structured Procedural Design
Can you add something to make this unstructured??
86
Decision TablesAnother Ambiguity Test

• Natural Language
• The system shall report to the operator all
  faults that originate in
• critical functions or that occur during
  execution of a critical
• sequence and for which there is no fault
  recovery response.
• (adapted from the specifications for the
  international space station)
• A decision table

originate in critical functions F T F T F T F T
Occur during critical sequence F F T T F F T T
No fault recovery response F F F F T T T T
Report to operator???
87
Decision Table
88
Program Design Language (PDL)
89
Interface Design
Easy to learn?
Easy to use?
Easy to understand?
Typical Design Errors

• lack of consistency
• too much memorization
• no guidance / help
• no context sensitivity
• poor response
• Arcane/unfriendly

Any examples? How about your remote
controls? How about fighter airplanes? How
are Windows OS and MS applications? How about
UTD web sites? Vending machines?
90
Golden Rules

• Place the user in control instead of ?
• Reduce the users memory load dos vs. windows?
• Make the interface consistent for the user

but, whos the user? Should the user work with
the designer, then, during UI design?
91
Place the User in Control

• Define interaction modes in a way that does not
  force a user into unnecessary or undesired
  actions.
• Allow user interaction to be interruptible and
  undoable.
• Streamline interaction as skill levels advance
  and allow the interaction to be customized.
  linear text vs. pie chart?
• Design for direct interaction with objects that
  appear on the screen. how? any examples?

92
Reduce the Users Memory Load

• Reduce demand on short-term memory. how many?
• Establish meaningful defaults.
• Define shortcuts that are intuitive.
• The visual layout of the interface should be
  based on a real world metaphor.
• Disclose information in a progressive fashion.

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

94
User Interface Design Process
95
Interface Analysis

• Interface analysis means understanding
• (1) the users who will interact with the system
  through the interface
• (2) the tasks that end-users must perform to do
  their work,
• (3) the content that is presented as part of the
  interface
• (4) the environment in which these tasks will be
  conducted

96
User Analysis

• Are users trained professionals, technician,
  clerical, or manufacturing workers?
• Are the users capable of learning from written
  materials or have they expressed a desire for
  classroom training?
• Are users expert typists or keyboard phobic?
• What is the age range, gender, primary spoken
  language of the user community?
• Is the software to be an integral part of the
  work users do or will it be used only
  occasionally?
• Are users experts in the subject matter that is
  addressed by the system?

97
Task Analysis and Modeling

• Answers the following questions
• What work will the user perform in specific
  circumstances?
• What tasks and subtasks will be performed as the
  user does the work?
• What specific problem domain objects will the
  user manipulate as work is performed?
• What is the sequence of work tasksthe workflow?
• Use-cases define basic interaction
• Task elaboration refines interactive tasks
• Object elaboration identifies interface objects
  (classes)
• Workflow analysis defines how a work process is
  completed when several people (and roles) are
  involved

98
Swimlane Diagram
What kind of diagram is this? What does this have
to do with UI design?
99
Analysis of Display Content

• Are different types of data assigned to
  consistent geographic locations on the screen
  (e.g., photos always appear in the upper right
  hand corner)?
• Can the user customize the screen location for
  content?
• Will graphical output be scaled to fit within the
  bounds of the display device that is used?
• How will color to be used to enhance
  understanding?
• How will error messages and warning be presented
  to the user?