Upload
oki
View
40
Download
0
Tags:
Embed Size (px)
DESCRIPTION
SEC 308 Yazılım Mühendisliği Software Design. Analysis Model -> Design Model. 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. - PowerPoint PPT Presentation
Citation preview
SEC 308 Yazılım MühendisliğiSEC 308 Yazılım Mühendisliği
Software Design
1
Analysis Model -> Design Model
2
Design and Quality0 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.
0 the design must be a readable, understandable guide for those who generate code and for those who test and subsequently support the software.
0 the design should provide a complete picture of the software, addressing the data, functional and behavioral domains from an implementation perspective.
3
Quality Guidelines0 A design should exhibit an architecture that
0 (1) has been created using recognizable architectural styles or patterns, 0 (2) is composed of components that exhibit good design characteristics0 (3) can be implemented in an evolutionary fashion
0 A design should be modular; that is, the software should be logically partitioned into elements or subsystems
0 A design should contain distinct representations of data, architecture, interfaces, and components.
0 A design should lead to components that exhibit independent functional characteristics.
0 A design should be represented using a notation that effectively communicates its meaning.
4
Quality Attributes0Functionality: assess features & capabilities,
generality of functions, security of overall system0Usability: assess human factors, consistency, and
documentation0Performance: processing speed, response time,
resource consumption…0Supportability: maintainability, compatibility, ease
of configuration, ease of installation
5
Fundamental Design Concepts0 abstraction—data, procedure, control0 architecture—the overall structure of the software0 patterns—”conveys the essence” of a proven design solution0 modularity—compartmentalization of data and function0 hiding—controlled interfaces0 Functional independence—single-minded function and low
coupling0 refinement—elaboration of detail for all abstractions0 Refactoring—a reorganization technique that simplifies the
design
6
Data Abstraction
7
doordoor
implemented as a data structure
ManufacturerManufacturermodel numbermodel numbertypetypeswing directionswing directioninsertsinsertslightslights typetype numbernumberweightweightopening mechanismopening mechanism
Procedural Abstraction
8
openopen
implemented with a "knowledge" of theobject that is associated with enter
details of enterdetails of enteralgorithm algorithm
Architecture“The overall structure of the software and the ways in which that structure provides conceptual integrity for a system.” [SHA95a]
0 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
0 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.
0 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
PatternsDesign Pattern Template
0 Pattern name—describes the essence of the pattern in a short but expressive name 0 Intent—describes the pattern and what it does0 Also-known-as—lists any synonyms for the pattern0 Motivation—provides an example of the problem 0 Applicability—notes specific design situations in which the pattern is applicable0 Structure—describes the classes that are required to implement the pattern0 Participants—describes the responsibilities of the classes that are required to implement
the pattern0 Collaborations—describes how the participants collaborate to carry out their
responsibilities0 Consequences—describes the “design forces” that affect the pattern and the potential
trade-offs that must be considered when the pattern is implemented0 Related patterns—cross-references related design patterns
10
Modular Design
11
easier to build, easier to change, easier to fix ...
Modularity: Trade-offs
12
What is the "right" number of modules for a specific software design?
optimal numberoptimal number of modulesof modules
cost ocost offsoftwaresoftware
number of modulesnumber of modules
modulemoduleintegrationintegration
costcost
module development cost module development cost
Information Hiding
13
modulemodulecontrolledcontrolledinterfaceinterface
"secret""secret"
• • algorithmalgorithm
• • data structuredata structure
• • details of external interfacedetails of external interface
• • resource allocation policyresource allocation policy
clientsclients
a specific design decisiona specific design decision
Why Information Hiding?0reduces the likelihood of “side effects”0limits the global impact of local design decisions0emphasizes communication through controlled
interfaces0discourages the use of global data0leads to encapsulation—an attribute of high quality
design0results in higher quality software
14
Stepwise Refinement
15
open
walk to door;reach for knob;
open door;
walk through;close door.
repeat until door opensturn knob clockwise;if knob doesn't turn, then take key out; find correct key; insert in lock;endifpull/push doormove out of way;end repeat
Functional Independence
16
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.
Sizing Modules: Two Views
17
MODULE
What's inside??
How big is it??
Refactoring0 Fowler [FOW99] defines refactoring in the following
manner: 0 "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.”
0 When software is refactored, the existing design is examined for 0 redundancy0 unused design elements0 inefficient or unnecessary algorithms0 poorly constructed or inappropriate data structures0 or any other design failure that can be corrected to yield
a better design.18
The Design Model
19process dimension
architecture elements
interface elements
component-level elements
deployment-level elements
low
high
class diagrams analysis packages CRC models collaboration diagrams
use-cases - text use-case diagrams activity diagrams swim lane diagrams collaboration diagrams data flow diagrams
control-flow diagrams processing narratives
data flow diagrams control-flow diagrams processing narratives
state diagrams sequence diagrams
state diagrams sequence diagrams
design class realizations subsystems collaboration diagrams
design class realizations subsystems collaboration diagrams
refinements to:
deployment diagrams
class diagrams analysis packages CRC models collaboration diagrams
component diagrams design classes activity diagrams sequence diagrams
refinements to:component diagrams design classes activity diagrams sequence diagrams
design class realizations subsystems collaboration diagrams component diagrams design classes activity diagrams sequence diagrams
analysis model
design model
Requirements: constraints interoperability targets and configuration
technical interface design Navigation design GUI design
Design Model Elements0 Data elements
0 Data model --> data structures0 Data model --> database architecture
0 Architectural elements0 Application domain0 Analysis classes, their relationships, collaborations and behaviors are transformed into
design realizations0 Patterns and “styles” (Chapter 10)
0 Interface elements0 the user interface (UI) 0 external interfaces to other systems, devices, networks or other producers or
consumers of information0 internal interfaces between various design components.
0 Component elements0 Deployment elements
20
Data Design0 Data design translates data objects defined as part of the
analysis model into0 Data structures at the software component level0 A possible database architecture at the application level
0 It focuses on the representation of data structures that are directly accessed by one or more software components
0 The challenge is to store and retrieve the data in such way that useful information can be extracted from the data environment
0 "Data quality is the difference between a data warehouse and a data garbage dump"
21
Software Architecture0 The software architecture of a program or computing
system is the structure or structures of the system which comprise0 The software components0 The externally visible properties of those components0 The relationships among the components
0 Software architectural design represents the structure of the data and program components that are required to build a computer-based system
0 An architectural design model is transferable0 It can be applied to the design of other systems0 It represents a set of abstractions that enable software engineers to
describe architecture in predictable ways 22
Example Software Architecture Diagrams
23
Why Architecture?0 The architecture is not the operational software. Rather,
it is a representation that enables a software engineer to:
0 (1) analyze the effectiveness of the design in meeting its stated requirements,
0 (2) consider architectural alternatives at a stage when making design changes is still relatively easy, and
0 (3) reduce the risks associated with the construction of the software.
24
Architectural StylesEach 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 …
25
• Data flow architectures• Call and return architectures• Data-centered architectures• Virtual Machine architectures• Independent Component architectures
A Taxonomy of Architectural Styles
26
Data Flow Architecture
27
Data Flow Architecture0 Has the goal of modifiability0 Characterized by viewing the system as a series of transformations on
successive pieces of input data0 Data enters the system and then flows through the components one at a time
until they are assigned to output or a data store0 Batch sequential style
0 The processing steps are independent components0 Each step runs to completion before the next step begins
0 Pipe-and-filter style0 Emphasizes the incremental transformation of data by successive components0 The filters incrementally transform the data (entering and exiting via streams)0 The filters use little contextual information and retain no state between instantiations0 The pipes are stateless and simply exist to move data between filters
0 Use this style when it makes sense to view your system as one that produces a well-defined easily identified output0 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 Architecture0 Has the goal of modifiability and scalability0 Has been the dominant architecture since the start of software
development0 Main program and subroutine style
0 Decomposes a program hierarchically into small pieces (i.e., modules)0 Typically has a single thread of control that travels through various
components in the hierarchy0 Remote procedure call style
0 Consists of main program and subroutine style of system that is decomposed into parts that are resident on computers connected via a network
0 Strives to increase performance by distributing the computations and taking advantage of multiple processors
0 Incurs a finite communication time between subroutine call and response
30
Call and Return Architecture0 Object-oriented or abstract data type system
0 Emphasizes the bundling of data and how to manipulate and access data0 Keeps the internal data representation hidden and allows access to the object only
through provided operations0 Permits inheritance and polymorphism
0 Layered system0 Assigns components to layers in order to control inter-component interaction0 Only allows a layer to communicate with its immediate neighbor0 Assigns core functionality such as hardware interfacing or system kernel operations to
the lowest layer0 Builds each successive layer on its predecessor, hiding the lower layer and providing
services for the upper layer0 Is compromised by layer bridging that skips one or more layers to improve runtime
performance0 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 Architecture0 Has the goal of integrating the data0 Refers to systems in which the access and update of a widely accessed data
store occur0 A client runs on an independent thread of control0 The shared data may be a passive repository or an active blackboard
0 A blackboard notifies subscriber clients when changes occur in data of interest0 At its heart is a centralized data store that communicates with a number of
clients0 Clients are relatively independent of each other so they can be added, removed,
or changed in functionality0 The data store is independent of the clients0 Use this style when a central issue is the storage, representation, management,
and retrieval of a large amount of related persistent data 0 Note that this style becomes client/server if the clients are modeled as
independent processes
33
Virtual Machine Architecture
34
InterpretationEngine
Program Data ProgramInstructions
ProgramInternal State
Virtual Machine Architecture0 Has the goal of portability0 Software systems in this style simulate some functionality that is not
native to the hardware and/or software on which it is implemented0 Can simulate and test hardware platforms that have not yet been built0 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
0 Examples include interpreters, rule-based systems, and command language processors
0 Interpreters0 Add flexibility through the ability to interrupt and query the program and
introduce modifications at runtime0 Incur a performance cost because of the additional computation involved in
execution0 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
36
Server
Client A Client B
Client C Client D
Peer W Peer X
Peer Y Peer Z
Independent Component Architecture0 Consists of a number of independent processes that communicate through
messages0 Has the goal of modifiability by decoupling various portions of the computation0 Sends data between processes but the processes do not directly control each other0 Event systems style
0 Individual components announce data that they wish to share (publish) with their environment
0 The other components may register an interest in this class of data (subscribe)0 Makes use of a message component that manages communication among the other
components 0 Components publish information by sending it to the message manager0 When the data appears, the subscriber is invoked and receives the data0 Decouples component implementation from knowing the names and locations of other
components
37
Independent Component Architecture0 Communicating processes style
0 These are classic multi-processing systems0 Well-know subtypes are client/server and peer-to-peer0 The goal is to achieve scalability0 A server exists to provide data and/or services to one or more clients0 The client originates a call to the server which services the request
0 Use this style when 0 Your system has a graphical user interface0 Your system runs on a multiprocessor platform0 Your system can be structured as a set of loosely coupled components0 Performance tuning by reallocating work among processes is important0 Message passing is sufficient as an interaction mechanism among components
38
Architectural Design Steps1) Represent the system in context
2) Define archetypes
3) Refine the architecture into components
4) Describe instantiations of the system
39
Architectural Context0 Use an architectural context diagram (ACD) that shows
0 The identification and flow of all information into and out of a system0 The specification of all interfaces0 Any relevant support processing from/by other systems
0 An ACD models the manner in which software interacts with entities external to its boundaries
0 An ACD identifies systems that interoperate with the target system0 Super-ordinate systems
0 Use target system as part of some higher level processing scheme0 Sub-ordinate systems
0 Used by target system and provide necessary data or processing0 Peer-level systems
0 Interact on a peer-to-peer basis with target system to produce or consume data0 Actors
0 People or devices that interact with target system to produce or consume data40
Architectural Context Diagram
41
SafeHome ACD
42
Archetypes0 Archetypes indicate the important abstractions within the problem
domain (i.e., they model information)0 An archetype is a class or pattern that represents a core abstraction that
is critical to the design of an architecture for the target system0 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
0 Only a relatively small set of archetypes is required in order to design even relatively complex systems
0 The target system architecture is composed of these archetypes0 They represent stable elements of the architecture0 They may be instantiated in different ways based on the behavior of the
system0 They can be derived from the analysis class model
0 The archetypes and their relationships can be illustrated in a UML class diagram 43
Example Archetypes in Humanity
44
• 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)
Example Archetypes in Software Architecture
45
• Node• Detector/Sensor• Indicator• Controller• Manager
• Moment-Interval• Role• Description• Party, Place or Thing
(Source: Archetypes, Color, and the Domain Neutral Component)(Source: Pressman)
Archetypes – their attributes
46
Archetypes – their methods
47
Components0 Based on the archetypes, the architectural designer refines the software
architecture into components to illustrate the overall structure and architectural style of the system
0 These components are derived from various sources0 The application domain provides application components, which are the
domain classes in the analysis model that represent entities in the real world0 The infrastructure domain provides design components (i.e., design classes)
that enable application components but have no business connection0 Examples: memory management, communication, database, and task management
0 The interfaces in the ACD imply one or more specialized components that process the data that flow across the interface
0 A UML class diagram can represent the classes of the refined architecture and their relationships
48
Instantiations of the System0 An actual instantiation of the architecture is developed by
applying it to a specific problem0 This demonstrates that the architectural structure, style
and components are appropriate0 A UML component diagram can be used to represent this
instantiation
49
Component Structure
50
SafeHome Executive
External Communication Management
GUI Internet Interface
Function selection
Security Surveillance Home management
Control panel
processing
detector management
alarm processing
Refined Component Structure
51sensorsensorsensorsensorsensorsensorsensorsensor
External Communication Management
GUI Internet Interface
Security
Control panel
processing
detector management
alarm processing
Keypad processing
CP display functions
scheduler
sensorsensorsensorsensor
phone communication
alarm
SafeHome Executive
Instantiations of the System
Analyzing Architectural Design0 Describe the architectural styles/patterns that have been chosen to
address the scenarios and requirements:0 module view0 process view0 data flow view
0 Evaluate quality attributes by considering each attribute in isolation.
52
• easier to test• easier to maintain• propagation of fewer side effects• easier to extend
Deriving Program Architecture
53
ProgramArchitecture
Partitioning the Architecture
54
• “horizontal” and “vertical” partitioning are required
Horizontal Partitioning
55
• 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
Vertical Partitioning: Factoring
56
• design so that decision making and work are stratified
• decision making modules should reside at the top of the architecture
workers
decision-makers
Why Partitioned Architecture?
57
• 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
Structured Design
58
• 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
Flow Characteristics
59
Transaction flow•A single data item
Transform flow:•Incoming flow•Transform center•Outgoing flow
General Mapping Approach0isolate incoming and outgoing flow boundaries;
for transaction flows, isolate the transaction center
0working from the boundary outward, map DFD transforms into corresponding modules
0add control modules as required0refine the resultant program structure using
effective modularity concepts
60
Transform Mapping
61
data flow model
"Transform" mapping
ab
c
d e f g h
ij
x1
x2 x3 x4
b c
a
d e f g i
h j
Factoring
62
typical "worker" modules
typical "decision making" modules
direction of increasing decision making
First Level Factoring
63
main programcontroller
inputcontroller
processingcontroller
outputcontroller
Second Level Mapping
64
DC
B A
A
CB
Dmapping from the flow boundary outward
main
control
Transaction Flow
65
T
incoming flow
action path
Transaction Example
66
commands
SafeHomeSoftware
Display information
Alarm Type
Telephone number tones
Control panel display
Alarm
Telephone Line
Control panel
SensorsSensor status
Transaction Mapping Principles
0 isolate the incoming flow path0 define each of the action paths by looking for the
"spokes of the wheel0 assess the flow on each action path0 define the dispatch and control structure0 map each action path flow individually
67
Transaction Mapping
68
ab
t
g
h
d
e
f
i
k
j
l
m
n
Data flow model
x1
b
a
t
x2 x3 x4
d e f g h x3.1 l m n
i j
k
mapping
program structure
Isolate Flow Paths
69
readcommand
validatecommand
determinetype
readrecord
calculateoutputvalues
formatreport
produceerror msg
readfixturestatus
determinesetting
formatsetting
sendcontrolvalue
command
commandinvalid command
error msg
status
combinedstatus
raw setting
fixture setting
robot control
start/stopassembly
record
record
values
report
valid command
Map the Flow Model
70
process operator
commands
command input
controller
read command
validate command
produce error
message
determine type
fixture status
controller
report generation controller
send control value
each of the action paths must be expanded further
Refining the Structure Chart
71
process operator
commands
command input
controller
read command
validate command
produce error
message
determine type
send control value
read fixture status
determine setting
format setting
read record
calculate output values
format report
fixture status
controller
report generation controller
What is a Component?0 OMG Unified Modeling Language Specification [OMG01]
defines a component as 0 “… a modular, deployable, and replaceable part of a
system that encapsulates implementation and exposes a set of interfaces.”
0 OO view: a component contains a set of collaborating classes
0 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
73
Print J ob
computeJ ob
init iateJ ob
numberOfPages numberOfSides paperType paperWeight paperSize paperColor magnif ication colorRequirements productionFeatures collat ionOptions bindingOptions coverStock bleed priority totalJ obCost WOnumber
PrintJ ob
computePageCost () computePaperCost () computeProdCost ( ) computeTotalJ obCost () buildWorkOrder() checkPriority () passJ obto Production()
elaborated design class<<interface>> computeJ ob
computePageCost () computePaperCost () computeProdCost () computeTotalJ obCost ()
<<interface>> init iateJ ob
buildWorkOrder() checkPriority ( ) passJ obto Production()
design component
numberOfPages numberOfSides paperType magnif ication productionFeatures
PrintJ ob
computeJ obCost() passJ obtoPrinter()
analysis class
What are the differences?
Interface=method?
OO view: a component contains a set of collaborating classes
Conventional Component
74
ComputePageCost
design component
accessCostsDB
getJ obData
elaborated module
PageCost
in: job size in: color=1, 2, 3, 4 in: pageSize = A, B, C, B out: BPC out: SF
in: numberPages in: numberDocs in: sides= 1, 2 in: color=1, 2, 3, 4 in: page size = A, B, C, B out: page cost
job size (J S) = numberPages * numberDocs;lookup base page cost (BPC) --> accessCostsDB (J S, color) ; lookup size factor ( SF) --> accessCostDB (J S, color, size) job complexity factor ( J CF) = 1 + [(sides-1)* sideCost + SF]pagecost = BPC * J CF
getJ obData (numberPages, numberDocs, sides, color, pageSize, pageCost)accessCostsDB (jobSize, color, pageSize, BPC, SF)computePageCost()
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.
Cohesion and CouplingCohesion0 Conventional view:
0 the “single-mindedness” of a module
0 OO view: 0 a component or class encapsulates only attributes and operations that are closely related to one another Levels
of cohesion0 Functional, Layer, Communicational, Sequential, Procedural, Temporal, utility
Coupling0 Conventional view:
0 The degree to which a component is connected to other components and to the external world0 OO view:
0 a qualitative measure of the degree to which classes are connected to one another0 Level of coupling
0 Content, Common, Control, Stamp, Data, Routine call, Type use, Inclusion or import, External
75
Component Level Design0 Step 1. Identify all design classes that correspond to the problem domain,
infrastructure domain.
0 Step 2. Elaborate all design classes (not acquired as reusable components).0 Step 2a. Specify message details when classes or component collaborate. 0 Step 2b. Identify appropriate interfaces for each component. 0 Step 2c. Elaborate attributes and define data types and data structures. 0 Step 2d. Describe processing flow within each operation in detail.
0 Step 3. Describe persistent data sources (databases and files) and identify the classes required to manage them.
0 Step 4. Develop and elaborate behavioral representations for a class or component.
0 Step 5. Elaborate deployment diagrams to provide additional implementation detail.
0 Step 6. Factor every component-level design representation and always consider alternatives.
76
Activity Diagram
77
validate attributes input
accessPaperDB(weight)
returns baseCostperPage
size = B paperCostperPage = paperCostperPage *1 .2
size = C paperCostperPage = paperCostperPage *1 .4
size = D paperCostperPage = paperCostperPage *1 .6
color is custom paperCostperPage = paperCostperPage *1 .1 4
color is standard
paperCostperPage = baseCostperPage
returns( paperCostperPage )
What is this about wrt. Component-level design?
What would be behavioral wrt. Component-level design?
Statechart
78
buildingJ obData
entry/ readJ obData() exit/displayJ obData() do/ checkConsistency() include/ dataInput
entry/ computeJ ob exit/ save totalJ obCost
formingJ ob
entry/ buildJ ob exit/ save WOnumber do/
computingJ obCost
submittingJ obentry/ submitJ ob exit/initiateJ ob do/ place on J obQueue
behavior within the state buildingJ obData
dataInputCompleted [all data items consistent]/ displayUserOpt ions
dataInputIncomplete
jobCostAccepted [customer is authorized]/ getElectronicSignature
jobSubmitted [all authorizations acquired]/ printWorkOrder
What is this about wrt. Component-level design?
How does this differ from AD wrt.Component-level design?
Collaboration Diagram
79
:ProductionJob
:WorkOrder:JobQueue
1: buildJob (WOnumber) 2: submitJob (WOnumber)
What is this about wrt. Component-level design?
Refactoring
80
PrintJ ob
computeJ ob
initiateJ ob
ProductionJ ob
buildJ ob
submitJ ob
WorkOrderappropriate attributes
buildWorkOrder ()getJ obDescriiption
J obQueueappropriate attributes
checkPriority ()
<<interface>> initiateJ ob
passJ obToProduction()
Algorithm Design0the closest design activity to coding0the approach:
0review the design description for the component
0use stepwise refinement to develop algorithm0use structured programming to implement
procedural logic0use ‘formal methods’ to prove logic
81
Stepwise Refinement
82
open
walk to door;reach for knob;
open door;
walk through;close door.
repeat until door opensturn knob clockwise;if knob doesn't turn, then take key out; find correct key; insert in lock;endifpull/push doormove out of way;end repeat
Recall:
Algorithm Design Model0represents the algorithm at a level of detail that
can be reviewed for quality0options:
0 graphical (e.g. flowchart, box diagram)0 pseudo code (e.g., PDL) ... choice of many0 programming language(?)0 decision table0 conduct walkthrough to assess quality
83At which level?
At which level? Component or Class?
Structured Programmingfor Procedural Design
0uses a limited set of logical constructs:0 Sequence0 Conditional — if-then-else, select-case0 Loops — do-while, repeat until
0leads to more readable, testable code0can be used in conjunction with ‘proof of
correctness’
84
“go-to” considered ???
What’s more to Structured Programming than the above?
A Structured Procedural Design
85
a
x1
x2b
3x
4
5
c
d
ef
g
x
x
add a condition Z, if true, exit the program
Can you add something to make this “unstructured??
Decision Tables:Another Ambiguity Test
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
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
Decision Table
87
Conditions
regular customer
silver customer
gold customer
special discount
Rules
no discount
apply 8 percent discount
apply 15 percent discount
apply additional x percent discount
T
F
T
T
T
T
T
F
1 3 5 64
F
T T
T
2Rules
Program Design Language (PDL)
88
if-then-else
if condition x then process a; else process b; endif
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
Interface Design
89
Easy to use?Easy to understand?
Easy to learn?
lack of consistencytoo much memorizationno guidance / helpno context sensitivitypoor responseArcane/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?
Typical Design Errors
Golden Rules
90
• 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?
Place the User in Control0 Define interaction modes in a way that does not force a
user into unnecessary or undesired actions.
0 Allow user interaction to be interruptible and undoable.
0 Streamline interaction as skill levels advance and allow the interaction to be customized. linear text vs. pie chart?
0 Design for direct interaction with objects that appear on the screen. how? any examples?
91
Reduce the User’s Memory Load0Reduce demand on short-term memory. how
many?
0Establish meaningful defaults.
0Define shortcuts that are intuitive.
0The visual layout of the interface should be based on a real world metaphor.
0Disclose information in a progressive fashion.
92
Make the Interface Consistent0Allow the user to put the current task into a
meaningful context.
0Maintain consistency across a family of applications.
0If 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 Analysis0Interface analysis means understanding
0(1) the users who will interact with the system through the interface;
0(2) the tasks that end-users must perform to do their work,
0(3) the content that is presented as part of the interface0 (4) the environment in which these tasks will be
conducted
95
User Analysis0 Are users trained professionals, technician, clerical, or
manufacturing workers?0 Are the users capable of learning from written materials
or have they expressed a desire for classroom training?0 Are users expert typists or keyboard phobic?0 What is the age range, gender, primary spoken language
of the user community?0 Is the software to be an integral part of the work users
do or will it be used only occasionally?0 Are users experts in the subject matter that is addressed
by the system?
96
Task Analysis and Modeling0 Answers the following questions …
0 What work will the user perform in specific circumstances?0 What tasks and subtasks will be performed as the user does the work?0 What specific problem domain objects will the user manipulate as work is
performed?0 What is the sequence of work tasks—the workflow?
0 Use-cases define basic interaction0 Task elaboration refines interactive tasks0 Object elaboration identifies interface objects (classes)0 Workflow analysis defines how a work process is completed when
several people (and roles) are involved
97
Swimlane Diagram
98
patient pharmacist physician
requests that a prescript io n be re f illed
no refills remaining
checks pat ie nt records
determine s status o f prescriptio n
refills remaining
refill not allowed
approves refill
evaluates alte rnat iv e medicat io n
none
rece iv es request to contact physician
alternative available
checks inv ento ry fo r re f ill o r alte rnative
out of stockrece ives o ut o f stock not if icat ion
rece ives t ime / date to p ick up
in stock
picks up prescript io n
f ills prescrip tion
Figure 12.2 Swimlane diagram for prescription refill function
What kind of diagram is this?What does this have to do with UI design?
Analysis of Display Content0 Are different types of data assigned to consistent
geographic locations on the screen (e.g., photos always appear in the upper right hand corner)?
0 Can the user customize the screen location for content?0 Will graphical output be scaled to fit within the bounds
of the display device that is used?0 How will color to be used to enhance understanding?0 How will error messages and warning be presented to
the user?
99