Communications in Information Systems

1. Communications in Information Systems ISD3 Lecture 7

2. 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

3. 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

4. Simple Interaction (lecture 2) • Request/Response pattern callee caller Request (+ parameters) function Response

5. 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 ??)

6. 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

7. 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

8. 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

9. 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 -

10. 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

11. 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

12. 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

13. 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.

14. The evolving person-machine system User Machine machine user

15. 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..

16. 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

17. 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..

18. 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

19. 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

20. 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?

21. 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

22. 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

23. 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

24. 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

25. 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?)

26. 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

27. 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.