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