Transcript Transparency Masters for Software Engineering: A

Chapter 5
Software Design
1
Analysis Model -> Design Model
2
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.
3
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.
4
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
5
Fundamental Design Concepts
•
•
•
•
•
•
abstraction—data, procedure, control
architecture—the overall structure of the software
patterns—”conveys the essence” of a proven design solution
modularity—compartmentalization of data and function
hiding—controlled interfaces
Functional independence—single-minded function and low
coupling
• refinement—elaboration of detail for all abstractions
• Refactoring—a reorganization technique that simplifies the
design
6
Data Abstraction
door
Manufacturer
model number
type
swing direction
inserts
lights
type
number
weight
opening mechanism
implemented as a data structure
7
Procedural Abstraction
open
details of enter
algorithm
implemented with a "knowledge" of the
object that is associated with enter
8
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.
9
Patterns
•
•
•
•
•
•
•
•
•
•
Design Pattern Template
Pattern name—describes the essence of the pattern in a short but expressive name
Intent—describes the pattern and what it does
Also-known-as—lists any synonyms for the pattern
Motivation—provides an example of the problem
Applicability—notes specific design situations in which the pattern is applicable
Structure—describes the classes that are required to implement the pattern
Participants—describes the responsibilities of the classes that are required to implement the
pattern
Collaborations—describes how the participants collaborate to carry out their responsibilities
Consequences—describes the “design forces” that affect the pattern and the potential tradeoffs that must be considered when the pattern is implemented
Related patterns—cross-references related design patterns
10
Modular Design
easier to build, easier to change, easier to fix ...
11
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
of modules
number of modules
12
Information Hiding
module
controlled
interface
• algorithm
• data structure
• details of external interface
• resource allocation policy
clients
"secret"
a specific design decision
13
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 encapsulation—an attribute of high quality
design
• results in higher quality software
14
Stepwise Refinement
open
walk to door;
reach for knob;
open door;
walk through;
close door.
repeat until door opens
turn knob clockwise;
if knob doesn't turn, then
take key out;
find correct key;
insert in lock;
endif
pull/push door
move out of way;
end repeat
15
Functional Independence
COHESION - the degree to which a
module performs one and only one
function.
COUPLING - the degree to which a
module is "connected" to other
modules in the system.
16
Sizing Modules: Two Views
What's
inside??
How big
is it??
MODULE
17
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.
18
The Design Model
high
a na ly sis m ode l
class diagrams
analysis packages
CRC models
collaborat ion diagrams
dat a f low diagrams
cont rol-f low diagrams
processing narrat ives
design class realizat ions
subsyst ems
collaborat ion diagrams
use-cases - t ext
use-case diagrams
act ivit y diagrams
sw im lane diagrams
collaborat ion diagrams
st at e diagrams
sequence diagrams
class diagrams
analysis packages
CRC models
collaborat ion diagrams
dat a f low diagrams
cont rol-f low diagrams
processing narrat ives
st at e diagrams
sequence diagrams
t echnical int erf ace
design
Navigat ion design
GUI design
component diagrams
design classes
act ivit y diagrams
sequence diagrams
de sign m ode l
ref inement s t o:
low
ref inement s t o:
design class realizat ions
subsyst ems
collaborat ion diagrams
archit ect ure
element s
component diagrams
design classes
act ivit y diagrams
sequence diagrams
int erface
element s
component -level
element s
process dimension
Requirement s:
const raint s
int eroperabilit y
t arget s and
conf igurat ion
design class realizat ions
subsyst ems
collaborat ion diagrams
component diagrams
design classes
act ivit y diagrams
sequence diagrams
deployment diagrams
deployment -level
element s
19
Design Model Elements
•
Data elements
– Data model --> data structures
– Data model --> 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
20
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"
21
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
22
Example Software Architecture Diagrams
23
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.
24
Architectural Styles
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 (subroutine call, remote procedure call, data stream, socket)
that enable “communication, coordination and cooperation” among components,
(3) 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
25
A Taxonomy of Architectural Styles
26
Data Flow Architecture
27
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
28
Call and Return Architecture
29
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
30
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
31
Data-Centered Architecture
32
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
33
Virtual Machine Architecture
Program Data
Program
Instructions
Interpretation
Engine
Program
Internal State
34
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
35
Independent Component
Architecture
Client A
Client B
Server
Client D
Client C
Peer X
Peer W
Peer Y
Peer Z
36
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
37
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
38
Architectural Design Steps
1)
2)
3)
4)
Represent the system in context
Define archetypes
Refine the architecture into components
Describe instantiations of the system
39
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
40
Architectural Context Diagram
41
SafeHome ACD
42
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
43
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
Liberator/Rescuer
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
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)
44
Example Archetypes in Software
Architecture
•
•
•
•
•
Node
Detector/Sensor
Indicator
Controller
Manager
(Source: Pressman)
•
•
•
•
Moment-Interval
Role
Description
Party, Place or Thing
(Source: Archetypes, Color, and the Domain Neutral Component)
45
Archetypes – their attributes
46
Archetypes – their methods
47
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
48
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
49
Component Structure
SafeHome
Execut ive
Funct ion
select ion
Ext ernal
Communicat ion
Management
Securit y
GUI
Surveillance
Home
management
Int ernet
Int erface
Cont rol
panel
processing
det ect or
management
alarm
processing
50
Refined Component Structure
SafeHome
Executive
Ext ernal
Communicat ion
Management
Instantiations of the System
Securit y
GUI
Internet
Interface
Co n t ro l
p an e l
p ro ce ssin g
Ke y p ad
p ro ce ssin g
d e t e ct o r
m an ag e m e n t
sch e d u le r
CP d isp lay
fu n ct io n s
alarm
p ro ce ssin g
phone
co m m u n icat io n
alarm
sennnso
sorrr
se
se
se
soso
se
nnso
so
rr
se
se
nnso
rr
se
n
so
r
se n so r
51
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
52
Deriving Program Architecture
Program
Architecture
53
Partitioning the Architecture
• “horizontal” and “vertical” partitioning are
required
54
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
55
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
56
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
57
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
58
Flow Characteristics
Transform flow:
•Incoming flow
•Transform center
•Outgoing flow
Transaction flow
•A single data item
59
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
60
Transform Mapping
a
b
d
e
h
g
f
i
c
j
data flow model
x1
x2
b
x4
x3
c
a
"Transform" mapping
d
e
f
g
i
h
j
61
Factoring
direction of increasing
decision making
typical "decision
making" modules
typical "worker" modules
62
First Level Factoring
main
program
controller
input
controller
processing
controller
output
controller
63
Second Level Mapping
main
D
C
control
B
A
A
B
C
mapping from the
flow boundary outward
D
64
Transaction Flow
incoming flow
action path
T
65
Transaction Example
Display
information
Control
panel
Control
panel
display
commands
SafeHome
Software
Alarm Type
Alarm
Telephone
number
tones
Sensors
Sensor status
Telephone
Line
66
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
67
Transaction Mapping
Data flow model
f
e
a
d
b
mapping
t
x1
i
g
program structure
h
l
k
t
b
j
m
a
n
d
x2
e
x4
x3
f
g
l
x3.1
h
m
n
j
i
k
68
Isolate Flow Paths
error msg
command
produce
error msg
read
command
command
validate
command
invalid command
valid command
fixture setting
status
read
fixture
status
determine
type
robot control
read
record
combined
status
record
calculate
output
values
send
control
value
start/stop
determine
setting raw setting
format
setting
assembly
record
values
format
report
report
69
Map the Flow Model
process
operator
commands
command
input
controller
read
command
validate
command
determine
type
produce
error
message
fixture
status
controller
report
generation
controller
send
control
value
each of the action paths must be expanded further
70
Refining the Structure Chart
process
operator
commands
command
input
controller
read
command
validate
command
read
fixture
status
determine
type
produce
error
message
determine
setting
fixture
status
controller
format
setting
report
generation
controller
read
record
send
control
value
calculate
output
values
format
report
71
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.
72
OO Component
a n a l y si s c l a ss
Pri n t Jo b
What are the differences?
n u m b e rOf Pa g e s
n u m b e rOf Si d e s
p a p e rTy p e
m agnif ic at ion
p ro d u c t i o n Fe a t u re s
d e si g n c o m p o n e n t
c o m p u t e Jo b Co st( )
p a ssJo b t o Pri n t e r( )
c o m p u t e Jo b
Pri n t Jo b
i n i t i a t e Jo b
Interface=method?
< < in t er f ace> >
co m p u t eJo b
comput ePageCost ( )
comput ePaper Cost ( )
comput ePr odCost ( )
comput eTot alJobCost ( )
< < in t er f ace> >
in it iat eJo b
buildWor kOr der ( )
checkPr ior it y ( )
passJobt o Pr oduct ion( )
elaborat ed des ign c las s
Print J ob
number Of Pages
number Of Sides
paper Type
paper Weight
paper Size
paper Color
magnif icat ion
color Requir ement s
pr oduct ionFeat ur es
collat ionOpt ions
bindingOpt ions
cover St ock
bleed
pr ior it y
t ot alJobCost
OO view: a component
contains a set of collaborating
classes
WOnumber
comput ePageCost ( )
comput ePaper Cost ( )
comput ePr odCost ( )
comput eTot alJobCost ( )
buildWor kOr der ( )
checkPr ior it y ( )
passJobt o Pr oduct ion( )
73
Conventional Component
design component
getJobData
ComputePageCost
accessCostsDB
Conventional
elaborat ed module
PageCost
in: numberPages
in: numberDocs
in: sides= 1 , 2
in: color=1 , 2 , 3 , 4
in: page size = A, B, C, B
out : page cost
in: j ob size
in: color=1 , 2 , 3 , 4
in: pageSize = A, B, C, B
out : BPC
out : SF
g e t Jo b Dat a ( n u m b e rPag e s, n u m b e rDo cs,
sid e s, co lo r, p ag e Size , p ag e Co st )
acce ssCo st sDB (j o b Size , co lo r, p ag e Size ,
BPC, SF)
co m p u t e Pag e Co st( )
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.
j o b size ( JS) =
n u m b e rPag e s * n u m b e rDo cs;
lo o ku p b ase p ag e co st ( BPC) -->
acce ssCo st sDB ( JS, co lo r) ;
lo o ku p size fact o r ( SF) -->
acce ssCo st DB ( JS, co lo r, size )
j o b co m p le xit y fact o r ( JCF) =
1 + [ ( sid e s-1 ) * sid e Co st + SF]
p ag e co st = BPC * JCF
74
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:
–
•
OO view:
–
•
The degree to which a component is connected to other components and to the external world
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
75
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.
76
•
•
•
Activity Diagram
v alidat e at t ribut es
input
ac c es s PaperDB (weight )
ret urns bas eCos t perPage
paperCos t perPage =
bas eCos t perPage
s iz e = B
paperCos t perPage =
paperCos t perPage * 1 . 2
s iz e = C
paperCos t perPage =
paperCos t perPage * 1 . 4
s iz e = D
paperCos t perPage =
paperCos t perPage * 1 . 6
c olor is c us t om
paperCos t perPage =
paperCos t perPage * 1 . 1 4
What is this about wrt.
Component-level design?
What would be behavioral wrt.
Component-level design?
c olor is s t andard
ret urns
( paperCos t perPage )
77
Statechart
b eh avio r w it h in t h e
st at e b u ild in g Jo b Dat a
d at aIn p u t In co mp let e
buildingJobDat a
ent ry/ readJobDat a ()
exit / displayJobDat a ()
do/ checkConsist ency()
include/ dat aInput
d at aIn p u t Co mp let ed [ all d at a
it ems co n sist en t ] / d isp layUserOp t io n s
comput ingJobCost
ent ry/ comput eJob
exit / save t ot alJobCost
What is this about wrt.
Component-level design?
j o b Co st Accep t ed [ cu st o mer is au t h o rized ] /
g et Elect ro n icSig n at u re
f ormingJob
ent ry/ buildJob
exit / save WOnumber
do/
How does this differ from AD wrt.
Component-level design?
submit t ingJob
ent ry/ submit Job
exit / init iat eJob
do/ place on JobQueue
j o b Su b mit t ed[ all au t h o rizat io n s acq u ired ] /
p rin t Wo rkOrd er
78
Collaboration Diagram
:ProductionJob
1: buildJob ( WOnumber )
2: submitJob ( WOnumber )
What is this about wrt.
Component-level design?
:WorkOrder
:JobQueue
79
Refactoring
computeJob
PrintJob
initiateJob
WorkOrder
<<interface>>
initiateJob
ap p ro p riat e at t rib u t e s
getJobDescriiption
buildWorkOrder ()
buildJob
p assJo b To Pro d u ct io n ( )
ProductionJob
submitJob
JobQueue
ap p ro p riat e at t rib u t e s
checkPriority ()
80
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
81
Stepwise Refinement
Recall:
open
walk to door;
reach for knob;
open door;
walk through;
close door.
repeat until door opens
turn knob clockwise;
if knob doesn't turn, then
take key out;
find correct key;
insert in lock;
endif
pull/push door
move out of way;
end repeat
82
Algorithm Design Model
• represents the algorithm at a level of detail that can be
reviewed for quality
At which level?
Component or Class?
• 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?
83
Structured Programming
for Procedural Design
• uses a limited set of logical constructs:
– Sequence
– Conditional — if-then-else, select-case
– Loops — do-while, repeat until
“go-to” considered ???
• leads to more readable, testable code
• can be used in conjunction with ‘proof of correctness’
What’s more to Structured Programming than the above?
84
A Structured Procedural Design
add a condition Z,
if true, exit the program
a
x1
b
x2
x3
d
f
e
c
Can you add something to
make this “unstructured??
x4
g
x5
85
Decision Tables:
Another 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???
86
Decision Table
Rule s
Condit ions
regular cust omer
1
T
2
3
4
T
T
gold cust omer
F
6
T
silver cust omer
special discount
5
T
F
T
T
T
F
T
Rule s
no discount
apply 8 percent discount
apply 15 percent discount
apply addit ional x percent discount
87
Program Design Language (PDL)
if condition x
then process a;
else process b;
endif
if-then-else
PDL
easy to combine with source code
machine readable, no need for graphics input
graphics can be generated from PDL
enables declaration of data as well as procedure
easier to maintain
88
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?
89
Golden Rules
• Place the user in control
instead of ?
• Reduce the user’s memory load
dos vs. windows?
• Make the interface consistent for the user
…but, who’s the user?
Should the user work with the designer, then, during UI
design?
90
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?
91
Reduce the User’s 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.
92
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.
93
User Interface Design Process
94
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
95
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?
96
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 tasks—the 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
97
Swimlane Diagram
p at ien t
r e q u e st s t h at a
p r e scr ip t io n b e r e f ille d
p h armacist
p h ysician
d e t e r m in e s st at u s o f
p r e scr ip t io n
no ref ills
remaining
ref ills
remaining
ch e cks in v e n t o r y f o r
r e f ill o r alt e r n at iv e
ch e cks p at ie n t
r e co r d s
approv es ref ill
ref ill not
allowed
e v alu at e s alt e r n at iv e
m e d icat io n
r e ce iv e s o u t o f st o ck
n o t if icat io n
out of st ock
alt ernat iv e
av ailable
in st ock
r e ce iv e s t im e / d at e
none
t o p ick u p
p icks u p
p r e scr ip t io n
f ills
p r e scr ip t io n
r e ce iv e s r e q u e st t o
co n t act p h y sician
Fig u re 1 2 .2 Sw imlan e d iag ram fo r p rescrip t io n refill fu n ct io n
What kind of diagram is this?
What does this have to do with UI design?
98
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?
99