COMP365: DESIGN Information systems architecture • Information systems have a generic

COMP365: DESIGN
Information systems architecture
• Information systems have a generic
architecture that can be organised as a layered
architecture.
• Layers include:
– The user interface
– User communications
– Information retrieval
– System database
Information system structure
User inter face
User communications
Information retrieval and modification
Transaction management
Database
LIBSYS architecture
•
•
The library system LIBSYS is an example of an information system.
User communications layer:
–
–
–
•
LIBSYS login component;
Form and query manager;
Print manager;
Information retrieval layer
–
–
–
–
Distributed search;
Document retrieval;
Rights manager;
Accounting.
LIBSYS organisation
Web browser inter face
LIBSYS
login
Distributed
search
Forms and
query manager
Document
retrieval
Print
manager
Rights
manager
Accounting
Library index
DB1
DB2
DB3
DB4
DBn
Resource allocation systems
•
•
Systems that manage a fixed amount of some resource
(football game tickets, books in a bookshop, etc.) and
allocate this to users.
Examples of resource allocation systems:
–
–
–
Timetabling systems where the resource being allocated is a time
period;
Library systems where the resource being managed is books and
other items for loan;
Air traffic control systems where the resource being managed is the
airspace.
Resource allocation architecture
•
Resource allocation systems are also layered systems that
include:
–
–
–
–
–
–
–
–
A resource database;
A rule set describing how resources are allocated;
A resource manager;
A resource allocator;
User authentication;
Query management;
Resource delivery component;
User interface.
Layered resource allocation
User inter face
User
authentication
Resource
management
Resource
delivery
Resource p olicy
control
Transaction management
Resource database
Query
management
Resource
allocation
Layered system implementation
• Each layer can be implemented as a large
scale component running on a separate
server. This is the most commonly used
architectural model for web-based systems.
• On a single machine, the middle layers are
implemented as a separate program that
communicates with the database through its
API.
• Fine-grain components within layers can be
implemented as web services.
Weather system description
A weather mapping system is required to generate weather maps on a
regular basis using data collected from remote, unattended weather
stations and other data sources such as weather observers, balloons and
satellites. Weather stations transmit their data to the area computer in
response to a request from that machine.
The area computer system validates the collected data and integrates it
with the data from different sources. The integrated data is archived and,
using data from this archive and a digitised map database a set of local
weather maps is created. Maps may be printed for distribution on a
special-purpose map printer or may be displayed in a number of different
formats.
System context and models of use
• Develop an understanding of the relationships between the
software being designed and its external environment
• System context
– A static model that describes other systems in the environment. Use a
subsystem model to show other systems. Following slide shows the
systems around the weather station system.
• Model of system use
– A dynamic model that describes how the system interacts with its
environment. Use use-cases to show interactions
Layered architecture
«subsystem»
Data display
Data display layer where objects are
concerned with preparing and
presenting the data in a humanreadable form
«subsystem»
Data archiving
Data archiving layer where objects
are concerned with storing the data
for future processing
«subsystem»
Data processing
Data processing layer where objects
are concerned with checking and
integ rating the collected data
«subsystem»
Data collection
Data collection layer where objects
are concerned with acquiring data
from remote sources
Subsystems in the weather mapping system
« subsy stem»
Data collectio n
« subsy stem»
Data display
Observer
Satellite
Co mms
Weather
statio n
Balloo n
M ap
disp lay
M ap
p rinter
M ap
« subsy stem»
Data arch iv ing
« subsy stem»
Data pro cessing
Data
checking
User
User
ininterface
terface
Data
Data
sto
storage
rage
Data
in tegratio n
M ap sto re
Data store
Architectural design
• Once interactions between the system and its environment
have been understood, you use this information for designing
the system architecture.
• A layered architecture is appropriate for the weather station
– Interface layer for handling communications;
– Data collection layer for managing instruments;
– Instruments layer for collecting data.
• There should normally be no more than 7 entities in an
architectural model.
Weather station architecture
UI design principles
• UI design must take account of the needs,
experience and capabilities of the system users
• Designers should be aware of people’s physical and
mental limitations (e.g. limited short-term memory)
and should recognise that people make mistakes
• UI design principles underlie interface designs
although not all principles are applicable to all
designs
15
User interface design principles
Principle
User famili arity
Consistency
Minim al surprise
Recoverability
User guidan ce
User diversity
Descript ion
The interface should use terms and concepts which are
drawn from th e exp erience of the people who will
make most u se of the system.
The interface should b e consistent in that, wh erever
possible, comp arable operations should b e activ ated in
the same way.
Users should n ever be surprised by th e behaviou r of a
system.
The interface should in clude mechanisms to allo w
users to recover from erro rs.
The interface should provid e meaningful f eedback
when errors occur and provid e context -sensitiv e user
help f aciliti es.
The interface should provid e appropri ate interaction
faciliti es for di fferent types of system us er.
COMP340
16
Design principles
• User familiarity
– The interface should be based on user-oriented
terms and concepts rather than computer concepts. For example, an
office system should use concepts such as letters, documents, folders
etc. rather than directories, file identifiers, etc.
• Consistency
– The system should display an appropriate level
of consistency. Commands and menus should have the same format,
command punctuation should be similar, etc.
• Minimal surprise
– If a command operates in a known way, the user should be
able to predict the operation of comparable commands
17
Design principles
• Recoverability
– The system should provide some resilience to
user errors and allow the user to recover from errors.
This might include an undo facility, confirmation of
destructive actions, 'soft' deletes, etc.
• User guidance
– Some user guidance such as help systems, on-line
manuals, etc. should be supplied
• User diversity
– Interaction facilities for different types of user should
be supported. For example, some users have seeing
difficulties and so larger text should be available
18
User-system interaction
• Two problems must be addressed in interactive
systems design
– How should information from the user be provided to
the computer system?
– How should information from the computer system be
presented to the user?
Interaction styles
•
•
•
•
•
Direct manipulation
Menu selection
Form fill-in
Command language
Natural language
19
Direct manipulation advantages
• Users feel in control of the computer and are
less likely to be intimidated by it
• User learning time is relatively short
• Users get immediate feedback on their actions
so mistakes can be quickly detected and
corrected
20
Direct manipulation problems
• The derivation of an appropriate information
space model can be very difficult
• Given that users have a large information
space, what facilities for navigating around that
space should be provided?
• Direct manipulation interfaces can be complex to
program and make heavy demands on the computer
system
21
Control panel interface
Grid
Busy
Title
JSD. example
Method
JSD
Type
Network
Units
cm
Selection
Process
Reduce
Full
OUIT
PRINT
NODE
LINKS
FONT
LABEL
EDIT
22
Menu systems
• Users make a selection from a list of
possibilities presented to them by the system
• The selection may be made by pointing and
clicking with a mouse, using cursor keys or by
typing the name of the selection
• May make use of simple-to-use terminals such as
touch-screens
23
Advantages of menu systems
• Users need not remember command names
as they are always presented with a list of
valid commands
• Typing effort is minimal
• User errors are trapped by the interface
• Context-dependent help can be provided. The
user’s context is indicated by the current
menu selection
24
Problems with menu systems
• Actions which involve logical conjunction (and)
or disjunction (or) are awkward to represent
• Menu systems are best suited to presenting a
small number of choices. If there are many
choices, some menu structuring facility must be
used
• Experienced users find menus slower than
command language
25
Form-based interface
NE W BOOK
Title
ISBN
Author
Price
Publisher
Publication
date
Edition
Number of
copies
Classification
Date of
purchase
Loan
status
Order
status
26
Command interfaces
• User types commands to give instructions to the
system e.g. UNIX
• May be implemented using cheap terminals.
• Easy to process using compiler techniques
• Commands of arbitrary complexity can be
created by command combination
• Concise interfaces requiring minimal typing can
be created
27
Problems with command interfaces
• Users have to learn and remember a
command language. Command interfaces are
therefore unsuitable for occasional users
• Users make errors in command. An error
detection and recovery system is required
• System interaction is through a keyboard so
typing ability is required
28
Command languages
• Often preferred by experienced users because they
allow for faster interaction with the system
• Not suitable for casual or inexperienced users
• May be provided as an alternative to menu
commands (keyboard shortcuts). In some cases, a
command language interface and a menu-based
interface are supported at the same time
29
Natural language interfaces
• The user types a command in a natural language.
Generally, the vocabulary is limited and these
systems are confined to specific application domains
(e.g. timetable enquiries)
• NL processing technology is now good enough to
make these interfaces effective for casual users but
experienced users find that they require too much
typing
30
User interface evaluation
• Some evaluation of a user interface design
should be carried out to assess its suitability
• Full scale evaluation is very expensive and
impractical for most systems
• Ideally, an interface should be evaluated
against a usability specification. However, it is
rare for such specifications to be produced
31
Usability attributes
Attribute
Learnability
Speed of operation
Robustnes s
Recoverability
Adaptability
Des cription
How long does it take a new us er
to
become productive with the s ys tem?
How well does the system response match
the us er’s work practice?
How tolerant is the s ystem of user error?
How good is the s ystem at recovering from
us er errors ?
How clos ely is the system tied to a s ingle
model of work?
32
Simple evaluation techniques
• Questionnaires for user feedback
• Video recording of system use and subsequent
tape evaluation.
• Instrumentation of code to collect information
about facility use and user errors.
• The provision of a grip button for on-line user
feedback.
COMP340
33