UML Class Diagrams

Why UML Class Diagrams

l A class diagram depicts classes and their interrelationships

l Used for describing structure and behavior in the use cases

l Provide a conceptual model of the system in terms of entities

and their relationships

l Used for requirement capture, end-user interaction

l Detailed class diagrams are used for developers

 Identifying UML Classes

l Based on the system descriptions, using object-oriented

analysis (OOA), identify classes, attributes, and operations
l For example, nouns / objects that share common properties
and are used to enable system functionality become classes
l Other nouns related to class nouns become class attributes
l Verbs related to class nouns become class operations
l After identifying classes, identify applicable relationships
l For example, identify cases where objects of one class
reference (are associated with) the objects of another
l Also identify shared (inherited) behavior between classes
 Classes from the Use Case
The following classes are identified:
– As use case actors:
• Course Administrator
• Student
• Tutor
– As system objects:
• Course Calendar
• Course
• Topic
 Identified Class Operations

The following class operations are identified:

– For Course Administrator, using use cases:
• View courses
• Manage topics for a course (Manage topic)
• Manage course information (Manage course)
• View course calendar
• View tutors
• Manage tutor information (but not manage tutors)
• Assign courses to tutors (assign tutors to courses)
Class Diagram – Order Management
 Classes
A class is a description of a set of
ClassName objects that share the same attributes,
operations, relationships, and semantics.
attributes
Graphically, a class is rendered as a
rectangle, usually including its name,
operations attributes, and operations in separate,
designated compartments.
 Class Names
The name of the class is the only required
ClassName tag in the graphical representation of a
class. It always appears in the top-most
attributes compartment.

operations
 Class Attributes

Person

name : String An attribute is a named property of a

address : Address class that describes the object being modeled.
birthdate : Date In the class diagram, attributes appear in
ssn : Id the second compartment just below the
name-compartment.
 Class Attributes (Cont’d)
Attributes are usually listed in the form:

Person attributeName : Type

name : String A derived attribute is one that can be

address : Address computed from other attributes, but
birthdate : Date doesn’t actually exist. For example,
/ age : Date a Person’s age can be computed from
ssn : Id his birth date. A derived attribute is
designated by a preceding ‘/’ as in:

/ age : Date
 Class Attributes (Cont’d)

Person
Attributes can be:
+ name : String
+ public
# address : Address
# protected
# birthdate : Date
- private
/ age : Date
/ derived
- ssn : Id
 Class Operations

Person

name : String
address : Address
birthdate : Date
ssn : Id
eat Operations describe the class behavior
sleep and appear in the third compartment.
work
play
 Depicting Classes
When drawing a class, you needn’t show attributes and operation
in every diagram.

Person Person Person

name : String
birthdate : Date
Person ssn : Id
name Person eat()
address sleep()
birthdate eat work()
play play()
 Class Responsibilities
A class may also include its responsibilities in a class diagram.

A responsibility is a contract or obligation of a class to perform

a particular service.

SmokeAlarm

Responsibilities

-- sound alert and notify guard station

when smoke is detected.

-- indicate battery state

 Relationships
In UML, object interconnections (logical or physical), are
modeled as relationships.

There are three kinds of relationships in UML:

• dependencies

• generalizations

• associations
 Dependency Relationships
A dependency indicates a semantic relationship between two or
more elements. The dependency from CourseSchedule to
Course exists because Course is used in both the add and
remove operations of CourseSchedule.

CourseSchedule
Course
add(c : Course)
remove(c : Course)
Generalization Relationships

Person
A generalization connects a subclass
to its superclass. It denotes an
inheritance of attributes and behavior
from the superclass to the subclass and
indicates a specialization in the subclass
of the more general superclass.
Student
Generalization Relationships (Cont’d)
UML permits a class to inherit from multiple superclasses,
although some programming languages (e.g., Java) do not permit
multiple inheritance.

Student Employee

TeachingAssistant
 Association Relationships

If two classes in a model need to communicate with each other,

there must be link between them.

An association denotes that link.

Student Instructor
 Association Relationships
(Cont’d)
We can indicate the multiplicity of an association by adding
multiplicity adornments to the line denoting the association.

The example indicates that a Student has one or more

Instructors:

Student Instructor
1..*
 Associations (cont.)
• Multiplicity Indicators

Exactly one 1

Zero or more (unlimited) * (0..*)

One or more 1..*

Zero or one (optional association) 0..1

Specified range 2..4

Multiple, disjoint ranges 2, 4..6, 8

 Association Relationships (Cont’d)

The example indicates that every Instructor has one or more

Students:

Student Instructor
1..*
 Association Relationships (Cont’d)
We can also indicate the behavior of an object in an association
(i.e., the role of an object) using rolenames.

teaches learns from

Student Instructor
1..* 1..*
 Association Relationships
(Cont’d)
We can also name the association.

membership
Student Team
1..* 1..*
 Association Relationships
(Cont’d)
We can specify dual associations.

member of
1..* 1..*
Student Team
1 president of 1..*
 Association Relationships
(Cont’d)
We can constrain the association relationship by defining the
navigability of the association. Here, a Router object requests
services from a DNS object by sending messages to (invoking
the operations of) the server. The direction of the association
indicates that the server has no knowledge of the Router.

Router DomainNameServer
 Association Relationships
(Cont’d)
Associations can also be objects themselves, called link classes
or an association classes.

Registration
modelNumber
serialNumber
warrentyCode

Product Warranty
 Association Relationships
(Cont’d)
We can model objects that contain other objects by way of
special associations called aggregations and compositions.

An aggregation specifies a whole-part relationship between an

aggregate (a whole) and a constituent part, where the part can
exist independently from the aggregate. Aggregations are
denoted by a hollow-diamond adornment on the association.

Engine
Car
Transmission
 Association Relationships
(Cont’d)
A composition indicates a strong ownership and coincident
lifetime of parts by the whole (i.e., they live and die as a
whole). Compositions are denoted by a filled-diamond
adornment on the association.

Scrollbar
1 1

Window Titlebar
1 1

Menu
1 1 .. *
 ER diagram
l An Entity relationship diagram is a graphical
representation of the entities, relationships
and constraints that make up a given design
 The parts of an ER diagram
l ER Model Concepts
• Entities and Attributes
• Entity Types, Value Sets, and Key Attributes
• Relationships and Relationship Types
• Weak Entity Types
• Roles and Attributes in Relationship Types
 Entities

l Entities are specific objects or things in the

mini-world that are represented in the
database.
• A person, place, object, event or concept in the
user environment about which the organization
wishes to maintain data
• Represented by a rectangle in E-R diagrams
Real-world object distinguishable from other objects
(e.g a student, car, job, subject, building ...)
 Example of Entity

sname

Store Locations

manager

qty Keeps

pname

Product price

descrip
 Attributes
• Attributes are properties used to describe an
entity. For example an EMPLOYEE entity may
have a Name, ID, Address, Phone ,BirthDate

Attributes

Address EMP ID

Name Phone

Employee
Entity
 Key Attributes: Identifier
l Key (or uniqueness) constraints are
applied to entity types
l Key attribute’s values are distinct for
each individual entity in the entity set
l A key attribute has its name
underlined inside the oval SSN

l Key must hold for every possible

extension of the entity type EMPLOYEE
l Multiple keys are possible
 Composite Vs. Simple Attributes

Composite attributes can be divided into smaller

parts which represent simple attributes with
independent meaning
l Simple Attribute: Aircraft-Type
l Complex Attribute: Aircraft-Location which is
comprised of :
Aircraft-Latitude
Aircraft-Longitude Notation
Aircraft-Altitude
 Derived Vs. Stored Attributes
Some attribute values can be derived from
related attribute values:
l Age ® Date - B-day
l Y-Sal ® 12 * M-Sal

Age M-sal
B-days Y-sal

EMPLOYEE
 Single Vs. Multivalued Attributes

Simple attributes can either be single-valued

or multi-valued
l SSN Number
Notation

l Multivalued: Degree = {BSc, MInfTech}

Notation

… An “attribute” in the relational model is always

single valued - Values are atomic!
 SUMMARY OF ER-DIAGRAM
NOTATION FOR ER SCHEMAS
Symbol Meaning

ENTITY TYPE

WEAK ENTITY TYPE

RELATIONSHIP TYPE

IDENTIFYING RELATIONSHIP TYPE

ATTRIBUTE

KEY ATTRIBUTE

MULTIVALUED ATTRIBUTE

COMPOSITE ATTRIBUTE

DERIVED ATTRIBUTE

TOTAL PARTICIPATION OF E2 IN R

CARDINALITY RATIO 1:N FOR E1:E2 IN R

E1 R E2
STRUCTURAL CONSTRAINT (min, max) ON PARTICIPATION OF E IN R

E1 N
R E2

(min,max)
R E
 Identify the Attributes of the entities
in our project

Student_ID Phone

Address
DOB

Student
Name Age
 Faculty

Faculty_ID Phone

Address
Email ID

Faculty
Name
 Course

Venue
Course_ID

Slot

Course
Name
Relationship among Entities
• An association between the instances of one or more
entity types that is of interest to the organization
• Association indicates that an event has occurred or that
there is a natural link between entity types
• Relationships are always labeled with verb phrases
• A relationship relates two or more distinct entities with a
specific meaning. For example, EMPLOYEE John Smith
works on the ProductX PROJECT or EMPLOYEE
Franklin Wong manages the Research DEPARTMENT.
 Example

Employees

Departments
 How to relate the entities of our
project
Faculty_ID Phone
Student_ID Phone

Address
Address
Email ID
DOB

Student Faculty

Name Age Name

Course
Venue

Slot

Course_ID
Name
 Relationship Degree

l The degree of a relationship type is the

number of participating entity types
– 2 entities: Binary Relationship
3 entities: Ternary Relationship
n entities: N-ary Relationship
– Same entity type could participate in
multiple relationship types
 Possible Cardinality Ratios
l The “Cardinality Ratio” for a binary
relationship specifies the number of
relationship instances that an entity Departments
can participate in
– Works-In is a binary relationship
– Participating entities are
DEPARTMENT : EMPLOYEE
– One department can have
Many employees -
Cardinality Ratio is 1 : N Employees
 Possible Cardinality Ratios
. .
l 1–to-1 (1 : 1) . .
– Both entities can . .
participate in only one
relationship instance .
l 1-to-Many, Many-to-1
. . . .
. . .
(1 : N, N : 1) . . .
– One entity can . .
participate in many
relationship instances
.
l Many-to-Many (N: M) . .
– Both entities can participate in
many relationship instance . .
. .
.
 How to relate the entities
Faculty_ID Phone
Student_ID Phone

Address
Address
Email ID
DOB

Student Faculty

Name Age Name

N N

M M

Course
Venue

Slot

Course_ID
Name
 Collaboration Diagram

• Introduction
– Collaboration Diagram places a priority on
mapping the object interactions to the object links
(drawing the participating objects in an Object
Diagram format and laying the message parallel to
The object link).
– Collaboration Diagram emphasize the effect of the
object structures on the interactions.
Collaboration Diagram – Elements

Elements of Collaboration Diagram

– Object
– Link: link between object
– Message
• Send Message
• Return Message
– Condition
• [Condition] Message
Collaboration Diagram – Elements and
Example
 State Chart Diagrams in UML
l Statechart diagrams describe the dynamic
behavior of a system in response to external
stimuli.
l Statechart diagrams are especially useful in
modeling reactive objects whose states are
triggered by specific events.
 State Chart Diagrams in UML
l Use state diagrams to demonstrate the behavior of
an object through many use cases of the system.
l Only use state diagrams for classes where it is
necessary to understand the behavior of the object
through the entire system.
l Not all classes will require a state diagram and state
diagrams are not useful for describing the
collaboration of all objects in a use case.
l State diagrams are other combined with other
diagrams such as interaction diagrams and activity
diagrams.
 Basic State chart Diagram
Symbols and Notations
l States
l States represent situations during the life of
an object.
 Symbols and Notations
l Initial State
l A filled circle represents the object's initial
state.
Final State
l A filled circle nested inside another circle
represents the object's final state.
 Symbols and Notations
l Transition
l A solid arrow represents the path between
different states of an object. Label the
transition with the event that triggered it and
the action that results from it
 Symbols and Notations
l Synchronization and Splitting of Control
l A short heavy bar with two transitions entering it represents a
synchronization of control. A short heavy bar with two transitions
leaving it represents a splitting of control that creates multiple states.
An example state machine diagram for the
Seminar class during registration.
Enrollment is a sub state
 Concurrent State
l Sometimes, it is necessary to model several
independent abstractions of attribute values. For
example, an undergraduate student is required to
complete both the final year project and the core
subjects before he can graduate.
Architectural Design
 Software architecture
l The design process for identifying the sub-
systems making up a system and the
framework for sub-system control and
communication is architectural design.
l The output of this design process is a
description of the software architecture.
 Architectural design
l An early stage of the system design process.
l Represents the link between specification
and design processes.
l Often carried out in parallel with some
specification activities.
l It involves identifying major system
components and their communications.
Advantages of explicit architecture

l Stakeholder communication
• Architecture may be used as a focus of
discussion by system stakeholders.
l System analysis
• Means that analysis of whether the system can
meet its non-functional requirements is possible.
l Large-scale reuse
• The architecture may be reusable across a
range of systems.
Architecture and system characteristics
l Performance
• Localise critical operations and minimise communications.
Use large rather than fine-grain components.
l Security
• Use a layered architecture with critical assets in the inner
layers.
l Safety
• Localise safety-critical features in a small number of sub-
systems.
l Availability
• Include redundant components and mechanisms for fault
tolerance.
l Maintainability
• Use fine-grain, replaceable components.
 Architectural conflicts
l Using large-grain components improves
performance but reduces maintainability.
l Introducing redundant data improves
availability but makes security more difficult.
l Localising safety-related features usually
means more communication so degraded
performance.
 System structuring
l Concerned with decomposing the system
into interacting sub-systems.
l The architectural design is normally
expressed as a block diagram presenting an
overview of the system structure.
l More specific models showing how sub-
systems share data, are distributed and
interface with each other may also be
developed.
Packing robot control system
 Box and line diagrams
l Very abstract - they do not show the nature
of component relationships nor the externally
visible properties of the sub-systems.
l However, useful for communication with
stakeholders and for project planning.
Architectural design decisions
l Architectural design is a creative process so
the process differs depending on the type of
system being developed.
l However, a number of common decisions
span all design processes.
 Architectural design decisions
l Is there a generic application architecture that can
be used?
l How will the system be distributed?
l What architectural styles are appropriate?
l What approach will be used to structure the system?
l How will the system be decomposed into modules?
l What control strategy should be used?
l How will the architectural design be evaluated?
l How should the architecture be documented?
 Architecture reuse
l Systems in the same domain often have
similar architectures that reflect domain
concepts.
l Application product lines are built around a
core architecture with variants that satisfy
particular customer requirements.
l Application architectures are covered in
Chapter 13 and product lines in Chapter 18.
 Architectural styles
l The architectural model of a system may
conform to a generic architectural model or
style.
l An awareness of these styles can simplify
the problem of defining system architectures.
l However, most large systems are
heterogeneous and do not follow a single
architectural style.
 Architectural models
l Used to document an architectural design.
l Static structural model that shows the major system
components.
l Dynamic process model that shows the process
structure of the system.
l Interface model that defines sub-system interfaces.
l Relationships model such as a data-flow model that
shows sub-system relationships.
l Distribution model that shows how sub-systems are
distributed across computers.
 System organisation
l Reflects the basic strategy that is used to
structure a system.
l Three organisational styles are widely used:
• A shared data repository style;
• A shared services and servers style;
• An abstract machine or layered style.
 The repository model
l Sub-systems must exchange data. This may
be done in two ways:
• Shared data is held in a central database or
repository and may be accessed by all sub-
systems;
• Each sub-system maintains its own database
and passes data explicitly to other sub-systems.
l When large amounts of data are to be
shared, the repository model of sharing is
most commonly used.
CASE toolset architecture
Repository model characteristics
l Advantages
• Efficient way to share large amounts of data;
• Sub-systems need not be concerned with how data is
produced Centralised management e.g. backup, security,
etc.
• Sharing model is published as the repository schema.
l Disadvantages
• Sub-systems must agree on a repository data model.
Inevitably a compromise;
• Data evolution is difficult and expensive;
• No scope for specific management policies;
• Difficult to distribute efficiently.
 Client-server model
l Distributed system model which shows how
data and processing is distributed across a
range of components.
l Set of stand-alone servers which provide
specific services such as printing, data
management, etc.
l Set of clients which call on these services.
l Network which allows clients to access
servers.
Film and picture library
 Client-server characteristics
l Advantages
• Distribution of data is straightforward;
• Makes effective use of networked systems. May require
cheaper hardware;
• Easy to add new servers or upgrade existing servers.
l Disadvantages
• No shared data model so sub-systems use different data
organisation. Data interchange may be inefficient;
• Redundant management in each server;
• No central register of names and services - it may be hard
to find out what servers and services are available.
Abstract machine (layered) model
l Used to model the interfacing of sub-systems.
l Organises the system into a set of layers (or abstract
machines) each of which provide a set of services.
l Supports the incremental development of sub-
systems in different layers. When a layer interface
changes, only the adjacent layer is affected.
l However, often artificial to structure systems in this
way.
Version management system
 Modular decomposition styles
l Styles of decomposing sub-systems into
modules.
l No rigid distinction between system
organisation and modular decomposition.
 Sub-systems and modules
l A sub-system is a system in its own right
whose operation is independent of the
services provided by other sub-systems.
l A module is a system component that
provides services to other components but
would not normally be considered as a
separate system.
 Modular decomposition
l Another structural level where sub-systems are
decomposed into modules.
l Two modular decomposition models covered
• An object model where the system is decomposed into
interacting object;
• A pipeline or data-flow model where the system is
decomposed into functional modules which transform
inputs to outputs.
l If possible, decisions about concurrency should be
delayed until modules are implemented.
 Object models
l Structure the system into a set of loosely
coupled objects with well-defined interfaces.
l Object-oriented decomposition is concerned
with identifying object classes, their attributes
and operations.
l When implemented, objects are created from
these classes and some control model used
to coordinate object operations.
Invoice processing system
 Object model advantages
l Objects are loosely coupled so their
implementation can be modified without
affecting other objects.
l The objects may reflect real-world entities.
l OO implementation languages are widely
used.
l However, object interface changes may
cause problems and complex entities may be
hard to represent as objects.
 Function-oriented pipelining
l Functional transformations process their
inputs to produce outputs.
l May be referred to as a pipe and filter model
(as in UNIX shell).
l Variants of this approach are very common.
When transformations are sequential, this is
a batch sequential model which is
extensively used in data processing systems.
l Not really suitable for interactive systems.
Invoice processing system
 Pipeline model advantages
l Supports transformation reuse.
l Intuitive organisation for stakeholder
communication.
l Easy to add new transformations.
l Relatively simple to implement as either a
concurrent or sequential system.
l However, requires a common format for data
transfer along the pipeline and difficult to
support event-based interaction.
 Control styles
l Are concerned with the control flow between
sub-systems. Distinct from the system
decomposition model.
l Centralised control
• One sub-system has overall responsibility for
control and starts and stops other sub-systems.
l Event-based control
• Each sub-system can respond to externally
generated events from other sub-systems or the
system’s environment.
 Centralised control
l A control sub-system takes responsibility for
managing the execution of other sub-systems.
l Call-return model
• Top-down subroutine model where control starts at the
top of a subroutine hierarchy and moves downwards.
Applicable to sequential systems.
l Manager model
• Applicable to concurrent systems. One system
component controls the stopping, starting and
coordination of other system processes. Can be
implemented in sequential systems as a case statement.
Call-return model
Real-time system control
 Event-driven systems
l Driven by externally generated events where the
timing of the event is outwith the control of the sub-
systems which process the event.
l Two principal event-driven models
• Broadcast models. An event is broadcast to all sub-
systems. Any sub-system which can handle the event
may do so;
• Interrupt-driven models. Used in real-time systems where
interrupts are detected by an interrupt handler and passed
to some other component for processing.
l Other event driven models include spreadsheets and
production systems.
 Broadcast model
l Effective in integrating sub-systems on different
computers in a network.
l Sub-systems register an interest in specific events.
When these occur, control is transferred to the sub-
system which can handle the event.
l Control policy is not embedded in the event and
message handler. Sub-systems decide on events of
interest to them.
l However, sub-systems don’t know if or when an
event will be handled.
Selective broadcasting
 Interrupt-driven systems
l Used in real-time systems where fast
response to an event is essential.
l There are known interrupt types with a
handler defined for each type.
l Each type is associated with a memory
location and a hardware switch causes
transfer to its handler.
l Allows fast response but complex to program
and difficult to validate.
Interrupt-driven control
 Reference architectures
l Architectural models may be specific to some
application domain.
l Two types of domain-specific model
• Generic models which are abstractions from a number of
real systems and which encapsulate the principal
characteristics of these systems. Covered in Chapter 13.
• Reference models which are more abstract, idealised
model. Provide a means of information about that class of
system and of comparing different architectures.
l Generic models are usually bottom-up models;
Reference models are top-down models.
 Reference architectures
l Reference models are derived from a study
of the application domain rather than from
existing systems.
l May be used as a basis for system
implementation or to compare different
systems. It acts as a standard against which
systems can be evaluated.
l OSI model is a layered model for
communication systems.
OSI reference model
 Case reference model
l Data repository services
• Storage and management of data items.
l Data integration services
• Managing groups of entities.
l Task management services
• Definition and enaction of process models.
l Messaging services
• Tool-tool and tool-environment communication.
l User interface services
• User interface development.
User Interface Design
 User interface design

l Designing effective interfaces

for software systems
 The user interface
l System users often judge a system by its
interface rather than its functionality
l A poorly designed interface can cause a user
to
make catastrophic errors
l Poor user interface design is the reason why
so
many software systems are never used
 Graphical user interfaces
l Most users of business systems interact with
these systems through graphical interfaces
although, in some cases, legacy text-based
interfaces are still used
 GUI characteristics

Characteristic Description
Windows Multiple windows allow different information to be
displayed simultaneously on the user’s screen.
Icons Icons different types of information. On some systems,
icons represent files; on others, icons represent
processes.
Menus Commands are selected from a menu rather than typed
in a command language.
Pointing A pointing device such as a mouse is used for selecting
choices from a menu or indicating items of interest in a
window.
Graphics Graphical elements can be mixed with text on the same
display.
 GUI advantages
l They are easy to learn and use.
• Users without experience can learn to use the
system
quickly.
l The user may switch quickly from one task to
another and can interact with several different
applications.
• Information remains visible in its own window
when
attention is switched.
l Fast, full-screen interaction is possible with
immediate access to anywhere on the screen
 User-centred design
l The aim of this chapter is to sensitise
software engineers to key issues underlying
the design rather than the implementation of
user interfaces
l User-centred design is an approach to UI
design where the needs of the user are
paramount and where the user is involved in
the design process
l UI design always involves the development
of prototype interfaces
 User interface design process

Analyse and Produce paper- Evaluate design

understand user based design with end-users
activities prototype

Produce
Design Evaluate design
dynamic design
prototype with end-users
prototype

Executable Implement
prototype final user
interface
 UI design principles
l UI design must take account of the needs,
experience and capabilities of the system
users
l Designers should be aware of people’s
physical and mental limitations (e.g. limited
short-term memory) and should recognise
that people make mistakes
l UI design principles underlie interface
designs although not all principles are
applicable to all designs
 User interface design principles
P r in c ip le D e s c r ip tio n
U s e r f a m ilia rity The in te rf a c e s h o u ld use te rm s and
c o n c e p ts w h ic h a re d ra w n f ro m th e
e x p e rie n c e o f th e p e o p le w h o w ill m a k e m o s t
u s e o f th e s y s te m .
C o n s is te n c y T h e in te rf a c e s h o u ld b e c o n s is te n t in th a t,
w h e re v e r p o s s ib le , c o m p a ra b le o p e ra tio n s
s h o u ld b e a c tiv a te d in th e s a m e w a y .
M in im a l s u rp ris e U s e rs s h o u ld n e v e r b e s u rp ris e d b y th e
b e h a v io u r o f a s y s te m .
R e c o v e ra b ility T h e in te rf a c e s h o u ld in c lu d e m e c h a n is m s to
a llo w u s e rs to re c o v e r f ro m e rro rs .
U s e r g u id a n c e T h e in te rf a c e s h o u ld p ro v id e m e a n in g f u l
f e e d b a c k w h e n e rro rs o c c u r a n d p ro v id e
c o n te x t-s e n s itiv e u s e r h e lp f a c ilitie s .
U s e r d iv e rs ity T h e in te rf a c e s h o u ld p ro v id e a p p ro p ria te
in te ra c tio n f a c ilitie s f o r d if f e re n t ty p e s o f
s y s te m u s e r.
 Design principles
l 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.
l Consistency
• The system should display an appropriate level
of consistency. Commands and menus should have the
same format, command punctuation should be similar,
etc.
l Minimal surprise
• If a command operates in a known way, the user should
be
able to predict the operation of comparable commands
 Design principles
l 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.
l User guidance
• Some user guidance such as help systems, on-line
manuals, etc. should be supplied
l 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
 User-system interaction
l 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?
l User interaction and information presentation
may be integrated through a coherent
framework such as a user interface metaphor
 Interaction styles
l Direct manipulation
l Menu selection
l Form fill-in
l Command language
l Natural language
Interaction Main advantages Main disadvantages Application
style examples
Direct Fast and intuitive May be hard to Video games
manipulation interaction implement CAD systems
Easy to learn Only suitable where
there is a visual
metaphor for tasks
and objects
Menu Avoids user error Slow for experienced Most general-
selection Little typing users purpose systems
required Can become complex
if many menu options
Form fill-in Simple data entry Takes up a lot of Stock control,
Easy to learn screen space Personal loan
processing
Command Powerful and Hard to learn Operating systems,
language flexible Poor error Library information
management retrieval systems
Natural Accessible to Requires more typing Timetable systems
language casual users Natural language WWW information
Easily extended understanding retrieval systems
systems are unreliable

Advantages and disadvantages

Direct manipulation advantages
l Users feel in control of the computer and are
less likely to be intimidated by it
l User learning time is relatively short
l Users get immediate feedback on their
actions
so mistakes can be quickly detected and
corrected
 Direct manipulation problems
l The derivation of an appropriate information
space model can be very difficult
l Given that users have a large information
space, what facilities for navigating around
that
space should be provided?
l Direct manipulation interfaces can be
complex to program and make heavy
demands on the computer system
 Control panel interface

Title JSD. example Grid Busy

Method JSD
OUIT
Type Network Units cm

Selection Process Reduce Full

PRINT

NODE LINKS FONT LABEL EDIT

 Menu systems
l Users make a selection from a list of
possibilities presented to them by the system
l The selection may be made by pointing and
clicking with a mouse, using cursor keys or
by
typing the name of the selection
l May make use of simple-to-use terminals
such as touchscreens
 Advantages of menu systems
l Users need not remember command names
as they are always presented with a list of
valid commands
l Typing effort is minimal
l User errors are trapped by the interface
l Context-dependent help can be provided.
The user’s context is indicated by the current
menu selection
 Problems with menu systems
l Actions which involve logical conjunction
(and)
or disjunction (or) are awkward to represent
l Menu systems are best suited to presenting
a
small number of choices. If there are many
choices, some menu structuring facility must
be
used
l Experienced users find menus slower than
command language
 Form-based interface
NE W BOOK

Title ISBN

Author Price

Publication
Publisher date
Number of
Edition copies

Classification Loan
status
Date of
Order
purchase
status
 Command interfaces
l User types commands to give instructions to
the system e.g. UNIX
l May be implemented using cheap terminals.
l Easy to process using compiler techniques
l Commands of arbitrary complexity can be
created by command combination
l Concise interfaces requiring minimal typing
can
be created
 Problems with command
interfaces
l Users have to learn and remember a
command
language. Command interfaces are therefore
unsuitable for occasional users
l Users make errors in command. An error
detection and recovery system is required
l System interaction is through a keyboard so
typing ability is required
 Command languages
l Often preferred by experienced users
because they allow for faster interaction with
the system
l Not suitable for casual or inexperienced
users
l 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
 Natural language interfaces
l 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)
l 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
 Multiple user interfaces

Command
Gr aphical user
language
interface
interface

Command
GUI
language
manager
interpreter

Operating system
 Information presentation
l Information presentation is concerned with
presenting system information to system
users
l The information may be presented directly
(e.g. text in a word processor) or may be
transformed in some way for presentation
(e.g. in some graphical form)
l The Model-View-Controller approach is a
way of supporting multiple presentations of
data
 Information presentation

Information to Presentation
be displayed software

Display
 Model-view-controller

View state view modification Controller state

messages User inputs
View methods Controller methods

Model queries
and updates Model edits
Model state

Model methods
 Information presentation
l Static information
• Initialised at the beginning of a session. It does
not change
during the session
• May be either numeric or textual
l Dynamic information
• Changes during a session and the changes
must be
communicated to the system user
• May be either numeric or textual
 Information display factors
l Is the user interested in precise information or
data relationships?
l How quickly do information values change?
Must the change be indicated immediately?
l Must the user take some action in response to
a change?
l Is there a direct manipulation interface?
l Is the information textual or numeric? Are relative
values important?
Alternative information presentations
Jan Feb Mar April May June
2842 2851 3164 2789 1273 2835

4000

3000

2000

1000

0
Jan Feb Mar April May June
Analogue vs. digital presentation
l Digital presentation
• Compact - takes up little screen space
• Precise values can be communicated
l Analogue presentation
• Easier to get an 'at a glance' impression of a
value
• Possible to show relative values
• Easier to see exceptional data values
 Dynamic information display

1
0 10 20
4 2

Dial with needle Pie chart Thermometer Horizontal bar

 Displaying relative values

Pressure Temper atu re

0 100 200 300 400 0 25 50 75 100
 Textual highlighting

!
The filename you have chosen h as been
used. Please choose an other name

Ch. 16 User interface design

OK Cancel
 Data visualisation
l Concerned with techniques for displaying large amounts of
information
l Visualisation can reveal relationships between entities and
trends in the data
l Possible data visualisations are:
• Weather information collected from a number of sources
• The state of a telephone network as a linked set of nodes
• Chemical plant visualised by showing pressures and
temperatures in a linked set of tanks and pipes
• A model of a molecule displayed in 3 dimensions
• Web pages displayed as a hyperbolic tree
 Colour displays
l Colour adds an extra dimension to an
interface
and can help the user understand complex
information structures
l Can be used to highlight exceptional events
l Common mistakes in the use of colour in
interface design include:
• The use of colour to communicate meaning
• Over-use of colour in the display
 Colour use guidelines
l Don't use too many colours
l Use colour coding to support use tasks
l Allow users to control colour coding
l Design for monochrome then add colour
l Use colour coding consistently
l Avoid colour pairings which clash
l Use colour change to show status change
l Be aware that colour displays are usually
lower
resolution
 User support
l User guidance covers all system facilities to
support users including on-line help, error
messages, manuals etc.
l The user guidance system should be
integrated with the user interface to help
users when they need information about the
system or when they make some kind of
error
l The help and message system should, if
possible, be integrated
Help and message system
Application

Help Error message

interface system

Message
presentation
system

Help Error message

frames texts
 Error messages
l Error message design is critically important.
Poor error messages can mean that a user
rejects rather than accepts a system
l Messages should be polite, concise,
consistent
and constructive
l The background and experience of users
should be the determining factor in message
design
 Design factors in message
wording
Context The user guidance system should be aware of what the user is
doing and should adjust the output message to the current
context.
Experience As users become familiar with a system they become irritated
by long, ‘meaningful’ messages. However, beginners find it
difficult to understand short terse statements of the problem.
The user guidance system should provide bothtypes of message
and allow the user to control message conciseness.
Skill level Messages should be tailored to the user’s skills as well as their
experience. Messages for the different classes of user may be
expressed in different ways depending on the terminology which
is familiar to the reader.
Style Messages should be positive rather than negative. They should
use the active rather than the passive mode of address. They
should never be insulting or try to be funny.
Culture Wherever possible, the designer of messages should be familiar
with the culture of the country where the system is sold. There
are distinct cultural differences between Europe, Asia and
America. A suitable message for one culture might be
unacceptable in another.
 Nurse input of a patient’s name

Please type the patient name in the box then click ok

Bates, J.

OK Cancel
System and user-oriented error messages

User-oriented error message

System-oriented error message

?
Error #27 Patient J . Bates is not registered
Invalid patient id entered Click on P atients f or a list of registered patients
Click on Retr y to re-input a patient name
Click on Help f or more inf ormation

OK Cancel
Patients Help Retry Cancel
 Help system design
l Help? means ‘help I want information”
l Help! means “HELP. I'm in trouble”
l Both of these requirements have to be taken
into account in help system design
l Different facilities in the help system may be
required
 Help information
l Should not simply be an on-line manual
l Screens or windows don't map well onto
paper
pages.
l The dynamic characteristics of the display
can
improve information presentation.
l People are not so good at reading screen as
they are text.
 Help system use
l Multiple entry points should be provided so
that
the user can get into the help system from
different places.
l Some indication of where the user is
positioned
in the help system is valuable.
l Facilities should be provided to allow the
user
to navigate and traverse the help system.
Entry points to a help system
Top-level
entry

Entry from
application

Entry from error

message system

Help frame network

 Help system windows
Help frame map Mail redirection

Mail may be redirected to another

network user by pressing the
redirect button in the control
panel. The system asks for the
name of the user or users to
whom the mail has been sent

You are here more next top ics

Help history

1. Mail
2. Send mail
3. Read mail
4. Redirection
 User documentation
l As well as on-line information, paper
documentation should be supplied with a
system
l Documentation should be designed for a
range of users from inexperienced to
experienced
l As well as manuals, other easy-to-use
documentation such as a quick reference
card may be provided
 User document types

System System Novice Experienced System

evaluators administrators users users administrators

Functional Installation Introductory Reference Administrator’s

description document manual manual guide

Description of How to install Getting Facility Operation and

services the system started description maintenance
 Document types
l Functional description
• Brief description of what the system can do
l Introductory manual
• Presents an informal introduction to the system
l System reference manual
• Describes all system facilities in detail
l System installation manual
• Describes how to install the system
l System administrator’s manual
• Describes how to manage the system when it is
in use
 User interface evaluation
l Some evaluation of a user interface design
should be carried out to assess its suitability
l Full scale evaluation is very expensive and
impractical for most systems
l Ideally, an interface should be evaluated
against a usability specification. However, it
is rare for such specifications to be produced
 Usability attributes

Attribute Description
Learnability How long does it take a new user to
become productive with the system?
Speed of operation How well does the system response match
the user’s work practice?
Robustness How tolerant is the system of user error?
Recoverability How good is the system at recovering from
user errors?
Adaptability How closely is the system tied to a single
model of work?
 Simple evaluation techniques
l Questionnaires for user feedback
l Video recording of system use and
subsequent
tape evaluation.
l Instrumentation of code to collect information
about facility use and user errors.
l The provision of a grip button for on-line user
feedback.
Software Reuse and Component-Based
Software Engineering
 Software Reuse

l In most engineering disciplines, systems are

designed by composition (building system out of
components that have been used in other systems)
l Software engineering has focused on custom
development of components
l To achieve better software quality, more quickly, at
lower costs, software engineers are beginning to
adopt systematic reuse as a design process
 Types of Software Reuse

l Application System Reuse

• reusing an entire application by incorporation of one
application inside another (COTS reuse)
• development of application families (e.g. MS Office)
l Component Reuse
• components (e.g. subsystems or single objects) of one
application reused in another application
l Function Reuse
• reusing software components that implement a single
well-defined function
Opportunistic Reuse
Development Reuse as a Goal
 Benefits of Reuse

l Increased Reliability
• components already exercised in working systems
l Reduced Process Risk
• less uncertainty in development costs
l Effective Use of Specialists
• reuse components instead of people
l Standards Compliance
• embed standards in reusable components
l Accelerated Development
• avoid custom development and speed up delivery
Requirements for Design with Reuse

l You need to be able to find appropriate reusable

components
l You must be confident that that component you plan
to reuse is reliable and will behave as expected
l The components to be reused must be documented
to allow them to be understood and modified (if
necessary)
 Reuse Problems

l Increased maintenance costs

l Lack of tool support
l Pervasiveness of the “not invented here” syndrome
l Need to create and maintain a component library
l Finding and adapting reusable components
 Economics of Reuse - part 1

l Quality
• with each reuse additional component defects are
identified and removed which improves quality.
l Productivity
• since less time is spent on creating plans, models,
documents, code, and data the same level of functionality
can be delivered with less effort so productivity improves.
 Economics of Reuse - part 2

l Cost
• savings projected by estimating the cost of building the
system from scratch and subtracting the costs associated
with reuse and the actual cost of the software as
delivered.
l Cost analysis using structure points
• can be computed based on historical data regarding the
costs of maintaining, qualification, adaptation, and
integrating each structure point.
 Generator-Based Reuse

l Program generators reuse standard patterns and

algorithms
l Programs are automatically generated to conform to
user defined parameters
l Possible when it is possible to identify the domain
abstractions and their mappings to executable code
l Domain specific language is required to compose
and control these abstractions
 Types of Program Generators

l Applications generators for business data

processing
l Parser and lexical analyzers generators for
language processing
l Code generators in CASE tools
l User interface design tools
Program Generation
Assessing Program Generator Reuse

l Advantages
• Generator reuse is cost effective
• It is easier for end-users to develop programs
using generators than other CBSE techniques
l Disadvantages
• The applicability of generator reuse is limited to
a small number of application domains
 Component-Based Software
Engineering

l CBSE is an approach to software development that

relies on reuse
l CBSE emerged from the failure of object-oriented
development to support reuse effectively
l Objects (classes) are too specific and too detailed to
support design for reuse work
l Components are more abstract than classes and
can be considered to be stand-alone service
providers
 Component Abstractions
l Functional Abstractions
• component implements a single function (e.g. ln)
l Casual Groupings
• component is part of a loosely related entities like declarations
and functions
l Data Abstractions
• abstract data types or objects
l Cluster Abstractions
• component from group of cooperating objects
l System Abstraction
• component is a self-contained system
Commercial Off-the-Shelf Software

l COTS systems are usually complete applications

library the off an applications programming interface
(API)
l Building large systems by integrating COTS
components is a viable development strategy for
some types of systems (e.g. E-commerce or video
games)
 COTS Integration Problems

l Lack of developer control over functionality and

performance
l Problems with component interoperability as COTS
vendors make different user assumptions
l COTS vendors may not offer users any control over
the evolutions of its components
l Vendors may not offer support over the lifetime of a
product built with COTS components
Developing Components for Reuse

l Components may constructed with the explicit goal

to allow them to be generalized and reused
l Component reusability should strive to
• reflect stable domain abstractions
• hide state representations
• be independent (low coupling)
• propagate exceptions via the component interface
 Reusable Components

l Tradeoff between reusability and usability

• generic components can be highly reusable
• reusable components are likely to be more complex and
harder to use
l Development costs are higher for reusable
components than application specific components
l Generic components may be less space-efficient
and have longer execution times than their
application specific analogs