Chapter 5 Software Design - PowerPoint PPT Presentation

Loading...

PPT – Chapter 5 Software Design PowerPoint presentation | free to view - id: 67f709-ZmJiM



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Chapter 5 Software Design

Description:

Chapter 5 Software Design * – PowerPoint PPT presentation

Number of Views:58
Avg rating:3.0/5.0
Slides: 100
Provided by: RogerPr4
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Chapter 5 Software Design


1
Chapter 5Software Design
2
Analysis Model -gt Design Model
3
Design and Quality
  • the design must implement all of the explicit
    requirements contained in the analysis model,
  • ... and it must accommodate all of the implicit
    requirements desired by the customer.
  • the design must be a readable, understandable
    guide for those who generate code and for those
    who test and subsequently support the software.
  • the design should provide a complete picture of
    the software, addressing the data, functional and
    behavioral domains from an implementation
    perspective.

4
Quality Guidelines
  • A design should exhibit an architecture that
  • (1) has been created using recognizable
    architectural styles or patterns,
  • (2) is composed of components that exhibit good
    design characteristics
  • (3) can be implemented in an evolutionary fashion
  • A design should be modular that is, the software
    should be logically partitioned into elements or
    subsystems
  • A design should contain distinct representations
    of data, architecture, interfaces, and
    components.
  • A design should lead to components that exhibit
    independent functional characteristics.
  • A design should be represented using a notation
    that effectively communicates its meaning.

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

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

7
Data Abstraction
door
Manufacturer model number type swing
direction inserts lights type
number weight opening mechanism
implemented as a data structure
8
Procedural Abstraction
open
details of enter algorithm
implemented with a "knowledge" of the object that
is associated with enter
9
Architecture
  • The overall structure of the software and the
    ways in which that structure provides conceptual
    integrity for a system. SHA95a
  • Structural properties. This aspect of the
    architectural design representation defines the
    components of a system (e.g., modules, objects,
    filters) and the manner in which those components
    are packaged and interact with one another. For
    example, objects are packaged to encapsulate both
    data and the processing that manipulates the data
    and interact via the invocation of methods
  • Extra-functional properties. The architectural
    design description should address how the design
    architecture achieves requirements for
    performance, capacity, reliability, security,
    adaptability, and other system characteristics.
  • Families of related systems. The architectural
    design should draw upon repeatable patterns that
    are commonly encountered in the design of
    families of similar systems. In essence, the
    design should have the ability to reuse
    architectural building blocks.

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

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

controlled interface
data structure

details of external interface

resource allocation policy
clients
"secret"
a specific design decision
14
Why Information Hiding?
  • reduces the likelihood of side effects
  • limits the global impact of local design
    decisions
  • emphasizes communication through controlled
    interfaces
  • discourages the use of global data
  • leads to encapsulationan attribute of high
    quality design
  • results in higher quality software

15
Stepwise Refinement
open
walk to door
reach for knob

open door
repeat until door opens

turn knob clockwise
walk through
if knob doesn't turn, then
close door.
take key out
find correct key
insert in lock
endif
pull/push door move out of way
end repeat
16
Functional Independence
17
Sizing Modules Two Views
18
Refactoring
  • Fowler FOW99 defines refactoring in the
    following manner
  • "Refactoring is the process of changing a
    software system in such a way that it does not
    alter the external behavior of the code design
    yet improves its internal structure.
  • When software is refactored, the existing design
    is examined for
  • redundancy
  • unused design elements
  • inefficient or unnecessary algorithms
  • poorly constructed or inappropriate data
    structures
  • or any other design failure that can be corrected
    to yield a better design.

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

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

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

23
Example Software Architecture Diagrams
23
24
Why Architecture?
  • The architecture is not the operational software.
    Rather, it is a representation that enables a
    software engineer to
  • (1) analyze the effectiveness of the design in
    meeting its stated requirements,
  • (2) consider architectural alternatives at a
    stage when making design changes is still
    relatively easy, and
  • (3) reduce the risks associated with the
    construction of the software.

25
Architectural Styles
  • Each style describes a system category that
    encompasses
  • a set of components (e.g., a database,
    computational modules) that perform a function
    required by a system,
  • a set of connectors (subroutine call, remote
    procedure call, data stream, socket) that enable
    communication, coordination and cooperation
    among components,
  • semantic constraints that define how components
    can be integrated to form the system, and
  • Data flow architectures
  • Call and return architectures
  • Data-centered architectures
  • Virtual Machine architectures
  • Independent Component architectures

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

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

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

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

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

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

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

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

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

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

44
Example Archetypes in Humanity
  • Addict/Gambler
  • Amateur
  • Beggar
  • Clown
  • Companion
  • Damsel in distress
  • Destroyer
  • Detective
  • Don Juan
  • Drunk
  • Engineer
  • Father
  • Gossip
  • Guide
  • Healer
  • Hero
  • Judge
  • King
  • Knight
  • Lover/Devotee
  • Martyr
  • Mediator
  • Mentor/Teacher
  • Messiah/Savior
  • Monk/Nun
  • Mother
  • Mystic/Hermit
  • Networker
  • Pioneer
  • Poet
  • Priest/Minister
  • Prince
  • Prostitute
  • Queen
  • Rebel/Pirate
  • Saboteur
  • Samaritan
  • Scribe/Journalist
  • Seeker/Wanderer
  • Servant/Slave
  • Storyteller
  • Student
  • Trickster/Thief
  • Vampire
  • Victim
  • Virgin
  • Visionary/Prophet
  • Warrior/Soldier

(Source http//www.myss.com/ThreeArchs.asp)
45
Example Archetypes in Software Architecture
  • Node
  • Detector/Sensor
  • Indicator
  • Controller
  • Manager
  • Moment-Interval
  • Role
  • Description
  • Party, Place or Thing

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

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

50
Component Structure
51
Refined Component Structure
Instantiations of the System
52
Analyzing Architectural Design
  • Describe the architectural styles/patterns that
    have been chosen to address the scenarios and
    requirements
  • module view
  • process view
  • data flow view
  • Evaluate quality attributes by considering each
    attribute in isolation.
  • easier to test
  • easier to maintain
  • propagation of fewer side effects
  • easier to extend

53
Deriving Program Architecture
Program Architecture
54
Partitioning the Architecture
  • horizontal and vertical partitioning are
    required

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

function 3
function 1
function 2
56
Vertical Partitioning Factoring
  • design so that decision making and work are
    stratified
  • decision making modules should reside at the top
    of the architecture

decision-makers
workers
57
Why Partitioned Architecture?
  • results in software that is easier to test
  • leads to software that is easier to maintain
  • results in propagation of fewer side effects
  • results in software that is easier to extend

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

59
Flow Characteristics
  • Transform flow
  • Incoming flow
  • Transform center
  • Outgoing flow
  • Transaction flow
  • A single data item

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

61
Transform Mapping
62
Factoring
63
First Level Factoring
main
program
controller
output
input
processing
controller
controller
controller
64
Second Level Mapping
65
Transaction Flow
incoming flow
action path
T
66
Transaction Example
Control panel display
Display information
commands
Control panel
Alarm Type
SafeHome Software
Alarm
Telephone number tones
Sensor status
Telephone Line
Sensors
67
Transaction Mapping Principles
  • isolate the incoming flow path
  • define each of the action paths by looking for
    the "spokes of the wheel
  • assess the flow on each action path
  • define the dispatch and control structure
  • map each action path flow individually

68
Transaction Mapping
Data flow model
f
e
a
d
mapping
b
x1
t
i
g
program structure
h
l
k
t
b
j
m
a
x2
x3
x4
n
n
f
g
h
x3.1
l
m
d
e
i
j
k
69
Isolate Flow Paths
error msg
produce error msg
command
read command
fixture setting
format setting
status
determine setting
validate command
read fixture status
invalid command
raw setting
command
combined status
determine type
valid command
read record
robot control
record
calculate output values
send control value
values
format report
report
assembly record
start/stop
70
Map the Flow Model
71
Refining the Structure Chart
72
What is a Component?
  • OMG Unified Modeling Language Specification
    OMG01 defines a component as
  • a modular, deployable, and replaceable part of
    a system that encapsulates implementation and
    exposes a set of interfaces.
  • OO view a component contains a set of
    collaborating classes
  • Conventional view logic, the internal data
    structures that are required to implement the
    processing logic, and an interface that enables
    the component to be invoked and data to be passed
    to it.

73
OO Component
What are the differences?
Interfacemethod?
OO view a component contains a set of
collaborating classes
74
Conventional Component
  • Conventional view
  • logic, the internal data structures that are
    required to implement the processing logic, and
  • an interface that enables the component to be
    invoked and data to be passed to it.

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

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

77
Activity Diagram
  • What is this about wrt.
  • Component-level design?
  • What would be behavioral wrt.
  • Component-level design?

78
Statechart
  • What is this about wrt.
  • Component-level design?
  • How does this differ from AD wrt.
  • Component-level design?

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

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

82
Stepwise Refinement
Recall
open
walk to door
reach for knob

open door
repeat until door opens

turn knob clockwise
walk through
if knob doesn't turn, then
close door.
take key out
find correct key
insert in lock
endif
pull/push door move out of way
end repeat
83
Algorithm Design Model
  • represents the algorithm at a level of detail
    that can be reviewed for quality
  • options
  • graphical (e.g. flowchart, box diagram)
  • pseudo code (e.g., PDL) ... choice of many
  • programming language(?)
  • decision table
  • conduct walkthrough to assess quality
  • At which level?
  • Component or Class?

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

go-to considered ???
Whats more to Structured Programming than the
above?
85
A Structured Procedural Design
Can you add something to make this unstructured??
86
Decision TablesAnother Ambiguity Test
  • Natural Language
  • The system shall report to the operator all
    faults that originate in
  • critical functions or that occur during
    execution of a critical
  • sequence and for which there is no fault
    recovery response.
  • (adapted from the specifications for the
    international space station)
  • A decision table

originate in critical functions F T F T F T F T
Occur during critical sequence F F T T F F T T
No fault recovery response F F F F T T T T
Report to operator???
87
Decision Table
88
Program Design Language (PDL)
89
Interface Design
Easy to learn?
Easy to use?
Easy to understand?
Typical Design Errors
  • lack of consistency
  • too much memorization
  • no guidance / help
  • no context sensitivity
  • poor response
  • Arcane/unfriendly

Any examples? How about your remote
controls? How about fighter airplanes? How
are Windows OS and MS applications? How about
UTD web sites? Vending machines?
90
Golden Rules
  • Place the user in control instead of ?
  • Reduce the users memory load dos vs. windows?
  • Make the interface consistent for the user

but, whos the user? Should the user work with
the designer, then, during UI design?
91
Place the User in Control
  • Define interaction modes in a way that does not
    force a user into unnecessary or undesired
    actions.
  • Allow user interaction to be interruptible and
    undoable.
  • Streamline interaction as skill levels advance
    and allow the interaction to be customized.
    linear text vs. pie chart?
  • Design for direct interaction with objects that
    appear on the screen. how? any examples?

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

93
Make the Interface Consistent
  • Allow the user to put the current task into a
    meaningful context.
  • Maintain consistency across a family of
    applications.
  • If past interactive models have created user
    expectations, do not make changes unless there is
    a compelling reason to do so.

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

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

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

98
Swimlane Diagram
What kind of diagram is this? What does this have
to do with UI design?
99
Analysis of Display Content
  • Are different types of data assigned to
    consistent geographic locations on the screen
    (e.g., photos always appear in the upper right
    hand corner)?
  • Can the user customize the screen location for
    content?
  • Will graphical output be scaled to fit within the
    bounds of the display device that is used?
  • How will color to be used to enhance
    understanding?
  • How will error messages and warning be presented
    to the user?
About PowerShow.com