Modelling Human Factors using the Systems Modelling Language

HFIDTC/2/WP2.8.9/1Version 2/ 24th September 2008conclusions, unsurprisingly, are mirrored elsewhere in the literature by e.g. Szwilus andBomdorf (2002) and Roberts (2002).Palanque et al also investigated how HCI design philosophies could be supported by theUML, noting that software-centric and user-centric design approaches had developed inparallel. The main finding was not that the UML was deficient, but that as the UML wasdeveloped from a software-centric viewpoint (rather than a user-centred viewpoint),UML-based software design methodologies would benefit from the incorporation of usercentreddesign principles. They stated that the UML is process independent, but criticisedthe current enabling design processes being used. From an HF perspective a number ofkey challenges were also identified, including maintaining consistency between systemand task models i.e. integration, and how to explicitly account for HCI design in theUML. Task models such as Hierarchical Task Analysis (HTA) were also found to bedeficient for modelling the temporal aspects of behaviour and were complimented byother notations/views e.g. Petri Nets. These are all areas of interest for this paper andraise a number of questions. If a UML system design is being produced centrally, thenhow will HFI methods such as Hierarchical Task Analysis be maintained inparallel/integrated to retain consistency? Would task models benefit from othercomplementary views? And how will the Human Views (if used for design) account forinterface design?Wilcox and MacKinnon (2002) also considered the UML in domains beyond SoftwareEngineering and suggested viewing the UML as a ‘Babel Fish’, i.e. a way of translatingand communicating one stakeholder language to another. As an example of how thisprocess could be facilitated, the development of standard conversions between entityrelationship modelling, flowcharts, and UML models was considered. The key challengein ‘translating’ between languages was noted as not just being able to map betweensyntactic constructs, but in being able to retain the semantic context of the original model.This is an important note for this report, as pragmatically we can’t expect HFprofessionals, in the short term, to learn an entirely new way of working to accommodatethe introduction of a new Systems Engineering language. Thus the ability to ‘translate’from traditional HF notation, e.g. HTA, to a UML notation would be beneficial, i.e. itwould enable HF professionals to continue to work in familiar territory and thencommunicate a model clearly to other stakeholders.5.2 The ScepticsHourizi, Johnson, Bruseburg and Solodilova (2002) investigated the utility of the UMLfor modelling complex collaborative work, within the context of system failures in theaviation domain. The Qantas Boeing 747-438 air crash in Bangkok (September, 1999)was used as a retrospective case study. The UML was used to model actors at all levels(including human and automated tasks), and the attempt was made to model theinteractions between these actors leading up to the incident, to diagnose causal factors.They concluded that the UML was ‘insufficient to describe the domain of interest’, withshortcomings in the ability to model goal relationships, communication and failure.Specifically it was noted that the relationship of the goals of actors was more complexthan can be represented (in Use Case Diagrams), as goals were identified that wereshared, conflicting and mutually exclusive. In terms of interactions between actors they8