Chapter 4
Product Design
Objectives of Design

As all other aspects of object-oriented system
development, design can be deployed in an
iterative or top-down development context

The design phase takes the results of the
analysis phase and evolves these results
further

The results of the design phase feeds directly
into the implementation phase
Product Design versus
Class Design

Product design concerns itself with creating
effective interactions




Between the system and human users
Between distributed elements of the system
Between software system and solutions for data
persistence (e.g. database management systems)
Class design concerns itself with determining
class definitions:



Attributes
Method signatures
Class semantics
Product Design Overview

Product design addresses the external
structure of the software
 External structure includes all software
components that interact with external
resources, such as



Solutions to data or object persistence
Means by which distributed processes interact
over a network (process architecture)
User Interfaces
Object Persistence

Object persistence seeks to retain object
information on some persistent storage
medium as a file or through a DBMS
 Object streaming solutions work for situations
were all object information can reside in
memory at once
 Because most commercial DBMSs are
relational in contrast to object-oriented, some
translation between the object and relational
representations must be made
Evaluating Object Persistence

Security



Information growth


Hacker proof
Allows reconstruction in face of malicious use
Solution still works with increased data volume
Concurrency

Concurrency solution allows for increased users
LMS Case Study: Object
Persistence

LMS may contain hundreds of thousands of
book entries as well as thousands of other
library resources
 Large volumes of data are not well suited to
object streaming
 A DBMS is called for to provide



Concurrent access by multiple users
Security enforcement of different access levels for
various user categories
Allow for increased data capacity
LMS Case Study: Relational
Representation of Data
Book
Relational Tables
Resource List
Patron Address
Patron
Process Architecture

Software systems may consist of processes
interacting over a network

Process architecture lays out the machines
(nodes) that will host the processes making
up the system

Process architecture determines the behavior
of the distributed processes

Deployment diagrams are used to model
distributed processes
Sample Deployment Diagram
Game
Client
Internet
Game
Client
Game
Client
Game
Server
Modeling Interprocess
Communication

Deployment diagrams show the distribution of
process over multiple nodes but do not
indicate how these processes communicate
 State machines may be used to model
communication between processes
 The idea behind using state machines for
modeling interprocess communication is that
the system enters a new state when
messages are exchanged between
processes
UML Notation for State
Machines
Initial State
State with substates
State Name
Final State
State Name
Intermediate State
Trigger
State transition
with event trigger
Sample State Machine Showing
Interprocess Communication
{ Server State}
Player Joining Game
Communicate
remaining tokens
player name
available
tokens
Get player
name
Select token
{ Client States}
selected
token
Modeling Multiple Threads of
Control
 Classes
that consist of a separate
thread of control are modeled as active
classes
 Active classes are rendered with thick
rectangles as shown below
Regular class
Active class
User Interfaces

The user interface enables users to interact
with the software system to accomplish some
set of tasks
 The user interface consists of interaction
techniques that facilitate this human-machine
communication
 It is a good idea to keep the design for the
user interface and the design of the
functionality of the remaining system
separate
User
External Representation
User Interface
Internal Representation
Application Functionality
The Role of the User Interface
User Interface Design
 Five
factors related to user interface
quality
 Ease
of learning
 Speed of use
 Frequency of user errors
 User satisfaction
 Knowledge retention
Guidelines for User-Friendly
Interfaces
 Use
easy to learn instructions
 Make help functions context-sensitive
 Present logically related functions
together and consistently
 Create graphical interfaces whenever
possible
 Allow actions to be activated quickly
Know the User
 There
are three broad categories of
users
 Novice

Rarely uses the computer
 Knowledgeable

Has sporadic experience with computer
systems
 Frequent

intermittent user
user
Comfortable with computer systems in general
Rules for Interface Design
 Be
consistent
 Provide shortcuts
 Offer useful feedback
 Design a beginning, middle and end for
each sequence of actions
 Prevent catastrophic mistakes
 Verify deletion tasks
More Rules for Interface
Design
 Allow
easy reversal of most actions
 Allow user to focus on task not the
interface
 Do not rely on user memory
 Display only currently relevant
information
Interaction Styles
 Menu
Selection
 Form Fill-in
 Command Language
 Natural Language
 Direct Manipulation
Guidelines for Designing
Menus
 Be
consistent
 Use distinctive items
 Be concise
 Put keywords first in the item name
 Create groups of logically similar items
Guidelines for Designing
Effective Forms
 Use
a meaningful title
 Give brief but clear instructions
 Organize fields logically
 Make form visually appealing
 Use familiar labels
 Create boundaries around data-entry
fields
 Allow the cursor to be moved
conveniently
More Guidelines for Designing
Effective Forms
 Allow
easy error correction
 Prevent errors when possible
 Provide error messages when invalid
values are entered
 Clearly mark optional fields
 Explain individual fields
 Clearly signal completion of data-entry
Design Guidelines for
Command Languages
 Limit
the number of commands
 Choose meaningful, distinctive
command names
 Abbreviate consistently
 Select a consistent command syntax
structure
 Use prompts to help intermittent users
 Consider using command menus to
help intermittent users
Design Guidelines for Direct
Manipulation Interfaces
 Use
easy to use icons
 Avoid misleading analogies
 E.g.
Window’s trash bin allows retrieval for
discarded items, otherwise this would be
misleading
 Do
not violate cultural stereotypes
 Use icons for appropriate purposes
 Carefully design iconic interaction
Design Summary
 Create
solution for object
persistence
 Develop user interface designs
 Determine process architecture
Working in Teams
 To
improve development team
dynamics, engage an impartial observer
 By
meeting during class time and getting
class feedback
 By having the instructor observe all
development teams during class time
 By inviting another development team to
observe one of your meetings
Possible Obstacles to
Effective Meetings
 Poor
agendas
 Dysfunctional communication during the
meeting (silence or domination)
 Not adhering to the agenda
 Discussion may not sufficiently focus on
meeting objectives specified by the
agenda
 Team members are not listening to each
other during discussion