Web Posted on: August 24, 1998
An Object-Oriented Model for Assistive Technology Software Development
Paul Tippell
Thames Valley University, London, UK,
email: paul.tippell@tvu.ac.uk
Jim O'Regan
Thames Valley University, London, UK
Philippa Hardy
Speech and Language Therapy Research Unit, Frenchay Hospital, Bristol, UK
Andrew Lysley
The ACE Centre, Oxford, UK
Mieke van de Sandt
Stichting Afasie, Rotterdam, NL
1. Summary
This paper presents a methodology for assistive technology software development which seeks to provide a framework for requirements elicitation studies and their subsequent mapping through use-case driven object-oriented analysis to implementation using component based software architectures. Usability evaluation is integrated into the process to provide early feedback on the effectiveness of user interface components. GUI components replace classical "Wizard of Oz" prototyping for evaluating user interaction for new concepts.
| Top |
2. Introduction
A range of techniques is used to elicit requirements for Assistive Technology products [1,2]. Representatives of all those involved in the deployment of the proposed product take part in these studies. These "stakeholders" include end-users, carers, user-groups and health care workers. Focus groups, brainstorming, interviews and observational studies are typical methods used at this stage of the development process. In order to produce a validated software product the output of requirements elicitation studies will have to be translated into a precise specification that can be implemented in technologies that today are likely to be object-oriented and component based. Common object-oriented languages include C++, Visual Basic and Java. Windows COM (Component Object Model) is a widely used component based software architecture.
The PCAD project (co-ordinated by Thames Valley University, UK and funded by the EC Telematics Applications Program - Disabled and Elderly Sector) aims to specify, develop, trial and evaluate a portable communication aid for people with the acquired language disorder of dysphasia. In order to provide a structured approach to development which maximised the opportunities offered by new software technologies we needed a framework which provided an effective bridge between requirements elicitation studies and software design and implementation.
| Top |
3. Requirements Elicitation Studies
In the PCAD Project we have conducted interviews with end-users, communication partners and speech and language therapists. Typical communicative situations have been observed in order to identify natural communicative strategies that people with dysphasia use. The state of the art of AAC and dysphasia has been reviewed. These activities yielded valuable "wish-lists" which described features of the proposed products but as Petrie [3] suggests requirements elicitation studies will not necessarily provide sufficient information on how users will interact with the product. Software engineers require highly focussed results for translation into effective specifications.
| Top |
4. Developing with Users
Variation in dysphasic end-users' language and cognitive competencies together with the inherent complexity of the language disorder mitigate against the use of a linear software development model often referred to as the waterfall model. An important feature of the approach used in PCAD is that products should be developed with users in an iterative manner. This is illustrated in Fig1 and employs the mainstream software engineering practice of iterative development with incremental delivery. An increment is a self-contained block of functionality that is useable as a stand alone deliverable. Code increments are evaluated with users and the results fed back to modify the design. Thus users are tightly bound into the development loop.
| Top |
5. Prototyping
Where do you start in an iterative development process? Hix and Hartson [4] argue that "the requirements capture process is both top-down and bottom-up because both structure and details are important." Requirements gathered from the elicitation activities described above are likely to be fairly vague and will lack the focus and clarity needed to translate them into an effective technical specification. Further uncertainty will be introduced where previously untried implementation technology is chosen for the hardware/software platform. "Wizard of Oz" prototyping, where system functionality is partly simulated by a human, has been used with good effect [3] to evaluate interaction with proposed systems. However modern software tools are designed to facilitate rapid application development, so why not dispense with the "Wizard" and use the real thing for prototypes? Such early design, prototyping and evaluation will focus minds and provide opportunities for technical developers to demonstrate functionality and interface features that are drawn from mainstream development and may be appropriate for AAC applications - for example, 'wizards' (a different 'wizard' this time!) for configuration functions.
A disadvantage of the rapid prototyping approach is that after requirements have been specified the product has to be re-engineered in a more structured manner. Writing many 'throw-away' prototypes can lead to an inefficient use of expensive software engineering resources. A process of incremental delivery is more efficient but requires much greater care in structuring requirements capture, analysis and design.
| Top |
6. Usability Evaluation
Bevan [5] suggests that "usability should be the major design objective for an interactive product: that the product can be used for its intended purpose". Usability is defined [6] as 'the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use'. Usability is related to the effectiveness and efficiency of the user interface and to the user's reaction to that interface. The usual stages of usability evaluation are: define the context of use (including user tasks), specify evaluation targets and the context of evaluation, prepare an evaluation, carry out the trials and analyse the trial data. An important part of preparation for usability trial design is an analysis of the tasks that a user will perform with the target system [7]. Major tasks are decomposed into sub-tasks. The features of each sub-task are enumerated paying particular attention to the task goal and output.
| Top |
7. Object-Oriented Software Modelling and Component Based Implementation
The Object Modelling Technique, OMT [8], one of the most widely used object-oriented methodologies for analysing systems, has been integrated with a technique proposed by Jacobson [9] for capturing requirements using Use-Cases. The outputs of analysis are modelled using the Unified Modelling Language (UML) [10]. A requirements specification will consist of a model of the user-interface, a class or entity object model and use-cases. A use-case is a narrative description of a sequence of transactions between a user and the system. Each use-case (there will be many for a complex system) describes the functionality of the required system but not the data structures or user-interface. The entity object model defines the underlying system data.
The object-oriented analysis model maps directly to a multi-tier software architecture that consists of the following components:
- user interface components - derived from a model of the required user interface
- control components - derived from use-cases
- data components and persistent data storage - derived from the entity object model
This approach supports incremental delivery since each increment is based on a use-case(s) and implemented by integrating the associated set of control components, user interface components and entity object components.
| Top |
8. Bridging the Gap between Requirements Elicitation Studies and Software Design
The model presented in Fig 2 represents an attempt to bridge the gap between the outputs of elicitation studies and an object-oriented software engineering approach centred on use-case specifications and implemented using a component based architecture. Stakeholders are encouraged to specify the outputs of elicitation studies in terms of user goals (a statement of what the user wishes to achieve), characteristics, attributes, attitudes and environment. Product concepts are defined within this context, evaluated and refined.
It is important to distinguish between the problem and the solution domains. Artim [11] defines the forces affecting the problem specification to include "how people perceive, think, interact with each other and their machines, and have grown to think about their domain activities". In contrast the solution domain is concerned with the methods and technology to solve the problem. We use task analysis as a problem domain activity to define with stakeholders the actions and cognitive processes to achieve a task. Major tasks are broken down into sub-tasks and user requirements are expressed in terms of task flows represented using flow charts. Use-case definitions are a solution domain activity because they define the interaction between the user and the machine. Tasks flows are analysed and mapped to use-cases which are defined in a form of pseudo-code or program design language using combinations of sequences, selections and iterations.
The use-case is the focal point of the process because it forms the basis for the software increment for trials. Feedback from evaluation is used to modify the use-case. For each use-case low fidelity paper-based prototyping methods such as story-boarding are used in workshop sessions with stakeholders to define the associated user interface which is evaluated for usability. A user-interface or GUI component is developed from the paper-based prototype. A key feature of the proposed method is that the component is not a "throw-away" prototype but a part of the final deliverable. The component will be evaluated for usability and refined. This approach provides an alternative to Wizard of Oz prototyping. GUI components can be used instead to evaluate user-machine interaction.
Usability evaluation is usually carried out after a product has been developed. However conducting evaluation late in the development cycle can result in costly re-engineering and late delivery to users. By integrating usability evaluation with component development we aim to provide a more usable product at lower cost. Much of the context data required for designing usability trials will have been collected when user goals were defined and user tasks analysed.
The entity object or class model must be developed very early in the analysis process. It is important to have a well-defined and stable model of the underlying data that will be as resilient as possible to future changes in system functionality. The model is based on "real world" entities or objects. There is no simple "cook-book" approach to building this model. It requires experience in object-oriented modelling and will initially be derived from an analysis of the product concept in collaboration with problem domain experts. Class model development will be iterative and influenced by task analysis, user interface design and use-case definition.
Integrated components that implement a specific increment are evaluated; usability test design being based on earlier user goal setting and task analysis.
| Top |
9. Feedback
The authors welcome feedback on the proposed methodolgy to be addressed to:
paul.tippell @tvu.ac.uk.
| Top |
References:
[1] Nicolle,C., et.al., A Methodology for Defining User Requirements for Rehabilitation and Assistive Technology, The European Context for Assistive Technology, Proceedings of the 2nd TIDE Congress, 26-28 April1995, Paris
[2] Petrie,H., et.al., The Implications of Smart Card and Self-service Terminal Technology for Disabled and Elderly People, The European Context for Assistive Technology, Proceedings of the 2nd TIDE Congress, 26-28 April1995, Paris
[3] Petrie,H., Placing Users at the Centre of Design for All, Important Issues in Todays Telematics Research, European Telematics Conference: Advancing the Information Society, Barcelona, February 1998
[4] Hix,D., Hartson,R., Developing User Interfaces - ensuring Usability Through Product and Process, 1994, Wiley
[5] Bevan,N., Support for a More Usable Information Society, Important Issues in Todays Telematics Research, European Telematics Conference: Advancing the Information Society, Barcelona, February 1998
[6] ISO/DIS 9241-11-2, Ergonomic Requirements for office work with visual display terminal (VDTs) - Part11: Guidance on Usability, International Organisation for Stanardization, 1997
[7] Daly-Jones,N., et. al., Handbook of User-Centred Design, European Usability Support Centres, Jul 1997
[8] Rumbaugh, J., et.al., Object-Oriented Modelling and Design, Prentice Hall, 1991
[9] Jacobson, I., et.al. Object-Oriented Software Engineering - A Use Case Driven Approach Addison-Wesley, 1992
[10] Unified Modelling Language, Version 1.1, http://www.rational.com/uml/documentation.html
[11] Artim, J.M., Integrating User Interface design and Object-Oriented Development through Task Analysis and Use Cases, CHI97 Object Models in User Interface design Woorkshop, http://w+w.citsys.cm/CHI97/Artim.html
| Top | | TIDE 98 Papers |