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

design6

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]

• 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

PatternsDesign 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 trade-

offs that must be considered when the pattern is implemented• 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 modulesfor 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?• 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

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

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

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

34

InterpretationEngine

Program Data ProgramInstructions

ProgramInternal State

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

36

Server

Client A Client B

Client C Client D

Peer W Peer X

Peer Y Peer Z

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 Steps1) Represent the system in context2) Define archetypes3) Refine the architecture into components4) 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

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

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

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

51

sensorsensorsensorsensor

sensorsensorsensor

sensor

External Communication Management

GUI Internet Interface

Security

Control

panelprocessing

detector

managementalarm

processing

Keypad processing

CP display functions

scheduler

sensorsensorsensorsensor

phone communication

alarm

SafeHome Executive

Instantiations of the System

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.

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

61

data flow model

"Transform" mapping

ab

c

d e fg 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

D

C

B A

A

C

B

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

68

a

b

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

73

PrintJ ob

computeJ ob

init iateJ ob

numberOfPages numberOfSides paperType paperWeight

paperSize paperColor magnif icat ion 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 c lass

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

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

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 custompaperCostperPage = 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 ob

entry/ submitJ ob exit/initiateJ ob do/ place on J obQueue

behavior within the state buildingJ obData

dataInputCompleted [all data items consistent]/ displayUserOptions

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

WorkOrder

appropriate attributes

buildWorkOrder ()getJ obDescriiption

J obQueue

appropriate attributes

checkPriority ()

<<interface>> initiateJ ob

passJ obToProduction()

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

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

83

At which level?

At which level? Component or Class?

Structured Programmingfor Procedural Design

84

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

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

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 tableoriginate 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???

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

2

Rules

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

98

patient pharmacist physician

requests that a

prescription be re f illed

no refills remaining

checks patient

records

determines status o f

prescription

refills remaining

refill not allowed

approves refill

ev aluates alte rnativ e

medication

none

rece iv es request to

contact physician

alternative available

checks inv entory fo r

re f ill o r alternative

out of stockrece ives out o f stock

notif ication

rece ives t ime/ date

to p ick up

in stock

picks up prescription

f ills

prescription

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