Communications in Information Systems

ISD3 Lecture 7

Topics

• Themes– Person – machine communication– Machine – machine communication

• Sub-themes– The different concerns of Information Systems

development– Technologies for agile development

• Technologies – Stateful interaction– Web Services– Service Oriented Archectures

Information Systems and Computer Systems

• Scope – the boundary of ‘system’– in IS users, customers , partner organisations, suppliers etc are

not external entities – they are part of the system, whose behaviour will be changed. Ignoring this will lead to ‘Unanticipated Consequences’

• Fitness – fitness measures are different. E.g. response time:– Server : how long to process a HTTP message from receipt to

dispatch– Communication system : how long from hitting the submit button

to the result being rendered on the screen– Information system – how long from someone needing

information to its reception and assimilation.• Technologies

– IS includes office procedures, paper-based forms, informal as well as formal, computer-mediated communications

Simple Interaction (lecture 2)

• Request/Response pattern

caller callee

function

Response

Request (+ parameters)

Complex interactions

• Complex interaction made up from chains of simple interactions. Callee may need to collaborate with others to respond.

• Same basic interaction whatever the communication medium (HTTP over TCP/IP, email, telephone call, voice)

• Same basic interaction whatever the actors (machines, people ??)

Simple Interaction goes mechanically wrong

• Potential mechanical breakdowns :– Caller doesn’t know where Callee is – Callee not known– Callee not ready to receive request– Callee fails whilst responding– Callee is unable to respond within a reasonable time span– Caller can’t wait for the response– Caller not ready to receive reponse– Request or response seen by third party en route– Request or response are interfered with en route – Caller is not authorised to send requests to callee– Caller overloads callee with requests

Interaction goes semantically wrong

• Potential semantic breakdowns :– Caller doesn’t know who to ask to perform

function– Caller doesn’t know what kind of request to

send or how– Callee doesn’t understand the request– Caller can’t understand response– Response is late, or of poor quality– Caller doesn’t have confidence in the quality

or coverage of the information returned

Fixing breakdowns

• Timeout : caller waits for n seconds – if no reply, fall back to a reserve callee, or put task on hold until later

• Callee queues the requests so that it an process them later – may send an immediate acknowledgement of receipt, then full response later

• Caller carries on after issuing request and delegates the task of waiting for the response to someone else

Control and data flow

• Control flow and data flow– Caller/callee distinction is based on control flow :

caller initiates interaction, callee responds• UML Sequence diagrams show control flow

– Requirer/provider focuses on data flow• Data flow diagrams show data flow

• Push / Pull– Usually requirer == caller

• Requirer PULLs the data– If requirer is the callee

• Provider PUSHes the data– Data flow is the same, but the interaction is very

different -

Example PUSH and PULL interactions

• Person - Company– You phone a company for information about a service– Company calls you in the middle of a meal with a double-glazing

offer

• Person – News agency– You click on the Google News link– You subscribe to a new service with your areas of interest and

the service emails relevant news items each morning

• Browser – server– Browser uses META REFRESH to refresh the page– Server pushes new data to the browser using server-push

Stateless/ Stateful Interaction

• Stateless– Person interacts with machine– Machine response depends only on the request (and the state of

data sources..)– Each interaction is independent of previous interactions with the

same person– Machine has no memory of previous interactions– Person presumably does have memory of previous interactions!

• Stateful– Machine has memory of previous interactions– Response to an request depends on only on the current request

but on previous interactions– Support for ‘long-running transactions’ such as placing an order,

booking a holiday, buying the best house insurance

Example stateless/stateful interactions

• Person- organisation– I enter my local supermarket – I enter my local pub

• Person – organisation– I make a purchase from my local supermarket with a

loyalty card – I buy a round in my local pub

• Person – website– I click on a link to the UWE website– I click on a link to a site and I’m prompted to accept a

cookie

Stateful interaction

• Advantages– Interaction is not one sided – I remember how the system has

behaved, it remembers something about me and how I’ve behaved

– Interaction is more like talking to another person– Machine can make better decisions about a suitable response

• State can be a problem too– Stateful behaviour can be hard to understand.– Bad memories - ‘let’s just start all over again’– Modal dialogue problem

• Application puts up a modal dialogue box which must be responded to before anything else happens.

• Dialogue box gets hidden behind other windows.

The evolving person-machine system

MachineUser

usermachine

Machine-side state mechanisms

• A state mechanism has to deal with– What to store about the interaction

• How much information about the user to retain• Issues : explicit/ implicit, transaction log, data protection act

– How to store the state for the duration of the interaction

• Length of interaction ranges from a site visit to ‘forever’• Issues : what to store, security, reliability, access by other

applications

– Matching a user to a stored state – the ‘identity’ problem

• How is a user identified • Issues : can id be spoofed, is id secure, can identity be

mistaken..

Storing the state

• Hidden fields in form– Server can sent data to the user in a hidden field,

which will then be returned when the user resubmits• Session variable

– Server can store data keyed by a session variable – session id can be sent back in hidden field

• Cookies– Server sends the user a cookie to store data which is

send back when the user next visits the site• Database

– State is stored in a database keyed by some user characteristic

Identifying the user

• IP address of client machine

• Session id

• User id – login id, National Insurance number, passport number …– Cahoot internet bank problem last week

• Address

• Mobile phone number

• Biometric data – finger print, iris pattern..

What to keep

• State must grow and change as the system learns more about you.

• State of interaction includes:– Current attributes of user : name, company.. – History of every interaction allows unanticipated

questions o be asked – cf data mining– Derived / deduced attributes – total expenditure,

most recent address• For data protection reasons, must not retain any

more information than necessary??• State can be defined using a ER model even if

not stored in a database

Explicit / Implicit distinction

• Explicit– Facts held as data in the database

• the person’s name and address

• Implicit– The implicit assumptions about the user which are

built into the system:• The user’s language, ethnicity, location, capabilities

• Implicit -> Explicit– Surfacing assumptions– Representing assumptions explicitly

• multi-language responses

User’s model of the machine

• User’s need to develop their model of the machine to be able to us it effectively

• Part of the machine’s task is to help the user develop an appropriate model of itself.

• User’s have an implicit model of the machine – preconceptions about how to use it.

• What does a person’s model of the machine look like and how does it develop?

Strategies to help the user

• Reduce the need for the user to have an extensive machine model

• Provide guidance• Design the interaction to work in the way a

user would naturally expect:– Donald Norman’s idea of affordance

• The door handle example

• Use natural language• Follow / establish standards

SMS Currency converter

• More difficult interaction design than a web page– No list of currencies to select from– Message length limits explanations

• More interesting– Input is limited natural language– User is mobile

Currency converter – stateful interaction

• Stateful interaction– Request: Cur 100 GBP USD

• Machine stores from and to codes as state, identified by originating mobile number

– Request: Cur 200 • Machine identifies the request as originating from

the same user, no from or to code supplied, so default to stored values

– Request: Cur 100 GBP EUR• From and to codes set , so update state

Currency Converter – message format

• Natural interaction– Allow multiple and surrounding spaces – Allow all sensible ordering of codes

• 100 gbp usd• Gbp 100 usd• Gbp usd (assume 1 unit)

– Allow noise words• Convert 100 usd into eur

– Allow synonyms• Convert 100 pounds into euros (assume GBP)

– Allow mistypes?• 100 GPB ERU

Currency converter - help

• Helpful feedback– If request not understood, give helpful response

• Format of request• Codes for common currencies• Reference to source of codes

– Support country to currency code query (perhaps by another service to get basic country data?)

– Should help be stateful – not the same response each time, but one which depends on what has already been send ( but how long ago?)

Tutorial

• Consider how different interactions cope with the listed breakdowns:– Telephone call to a person in a company– Another interaction of your own choice

• The family notices application as an XP project• Consider

– What state of the interaction is– How the state should be stored, for how long?– How uses should be identified and what are risks/

benefits of an identification scheme

Next week

• Agile development relies on technologies which allow rapid development.

• Object-orientation and component-based development support rapid software development.

• Web services and Service Oriented Architecture (SOA) allow Information Systems to be assembled from small information sources.

• How application-to-application interaction can be implemented.