Learning and Using Requirements Representation Notations by Information
Technology Professionals
A Thesis
Submitted to the Faculty
of
Drexel University
by
Ralph Rillman Miller III
in partial fulfillment of the
requirements for the degree
of
Doctor of Philosophy
November 2002
© Copyright 2002 Ralph R. Miller. All Rights Reserved. ii
Dedications
For Doranne, Wally, and Margaret
iii
Acknowledgements
We are not alone. This dissertation is the culmination of fifty years of guidance, encouragement and loving patience from many people. I must first thank and acknowledge my lifelong mentor and uncle Dr. James W. Donald, PhD who has inspired and taught me, as has no other. I am indebted to Dr. Stephen J. Andriole, PhD whose enthusiasm encouraged me to enter this program in the first place. Next I acknowledge the enormous contribution of Dr. Scott Overmyer, PhD whose tireless patience and guidance have, in the end, been crucial to the success of this effort. I must recognize my reviewers who, from the pure goodness of their generous hearts have given unstintingly of their busy lives to help complete this work. And I am equally indebted to the brave volunteers who slogged through piles of papers and sometimes confusing directions to give their very best effort. Thank you all individually and collectively for your critical contributions to the study. You are, indeed, the true professionals. I am especially grateful to Mr. Hugh Gray and Mr. David Stephenson of the Computer Sciences
Corporation who have unquestioningly provided vital support for this work. I must also thank all my friends, neighbors, and family past and present who have encouraged and sustained me especially during these past nine years of study, reflection and work. And finally, without the love, incredible patience and devotion of my lifelong companion, friend and wife Doranne, absolutely none of this, none of it, would have happened. It is inadequate but to all of you I can only say thank you.
iv
Table of Contents
LIST OF TABLES ...... vi
LIST OF FIGURES ...... vii
ABSTRACT ...... xi
CHAPTER 1: INTRODUCTION...... 1
CHAPTER 2: LITERATURE REVIEW ...... 13
Expressing Requirements and the System Development Lifecycle ...... 15
Previous Studies on the Relative Value of Different Notations...... 18
Goals, Scenarios, and Prototypes ...... 25
Notations—Textual, Diagrammatic/Graphical and Formal...... 30
CHAPTER 3: RESEARCH QUESTIONS AND METHODOLOGY ...... 36
Approach of this Research...... 38
Approach: Mapping the REL to the UIML...... 48
Approach: Mapping the UIML to the REL...... 51
Approach: The Pilot Study ...... 54
CHAPTER 4: MAPPING BETWEEN THE REL AND THE UIML NOTATIONS...... 78
Overview of the Mappings...... 78
Mapping the REL in Terms of the UIML Notation ...... 78
Mapping the UIML in Terms of the REL ...... 100
CHAPTER 5: DATA REDUCTION AND ANALYSIS...... 156
Pilot Study Data Reduction ...... 156
Discussion of Mapping Data...... 164
CHAPTER 6: RESULTS ...... 168
LIST OF REFERENCES ...... 185
APPENDIX A: STUDY MATERIALS AND QUESTIONNAIRES ...... 193
Project 01 – LEAP Familiarization ...... 193
Questionnaires for Projects and Reviewer Materials ...... 210
v
Reviewer Materials and Questionnaire...... 223
VITA ...... 250
vi
List of Tables
1. PROJECTS, PHASES AND DOCTYPES...... 58
2. FUNCTIONS OF THE ZEN400...... 62
3. RESEARCH QUESTIONS (RQS) RELATED TO DATA TYPES...... 66
4. TIME KEEPING AND DATA EDITING WINDOWS OF THE LEAP TOOLKIT...... 67
5. PERMITTED RELATIONSHIPS IN THE REQUIREMENTS ELEMENT LANGUAGE ...... 79
6. MEANING OF BOND-ARC MODIFIERS IN THE REQUIREMENTS ELEMENT LANGUAGE ...... 80
7. THE REL ELEMENT LEXICON...... 102
8. THE REL BOND-ARC LEXICON...... 103
9. MODIFICATIONS TO THE REL TO SHOW CARDINALITY...... 105
10. MODIFICATIONS TO THE REL TO INDICATE ORDER AND EXISTENCE...... 106
11. PARSED FUNCTIONS OF THE ZEN400 ...... 158
12. TIME DATA...... 160
13. TIME DATA (CONTINUED) ...... 160
14. AGGREGATE TIME DATA FOR STUDY CATEGORIES...... 161
15. ERROR DATA AS REPORTED BY VOLUNTEERS AND REVIEWERS...... 163
16. KNOWLEDGE AND UNDERSTANDING DATA...... 165
17. EXPERT REVIEWER EVALUATION OF REPRESENTATIONS...... 166
18. EVALUATION OF STUDY MATERIALS BY VOLUNTEERS AND REVIEWERS...... 167
vii
List of Figures
1. THE LUCITE BOX (REDRAWN WITH PERMISSION OF THE AUTHOR.) ...... 8
2. MAPPING BETWEEN THE REL AND THE UIML ...... 41
3. THE SEEHEIM USER INTERFACE MODEL (REDRAWN WITH PERMISSION OF THE AUTHOR.)...... 45
4. THE STRUCTURE OF THE UIML (REDRAWN WITH PERMISSION OF THE AUTHOR.)...... 48
5. XML MODEL FOR REL ELEMENTS...... 49
6. THE XML MODEL OF THE REL BOND TYPES...... 50
7. THE UIML ROOT ELEMENT...... 51
8. THE UIML ROOT ELEMENT REPRESENTED IN THE REL...... 52
9. HIGH-LEVEL VIEW OF RESEARCH APPROACH...... 56
10. THE FLOW OF THE PROJECTS PERFORMED BY VOLUNTEERS...... 60
11. THE ZEN400 (REDUCED SCALE)...... 63
12. THE LEAP CONTROLLER WINDOW ...... 68
13. THE LEAP DATA LOGGER AND DATA EDITOR WIDOW (NAIA)...... 70
14. THE LEAP TIMER WINDOW (IO)...... 70
15. EXAMPLE OF A STUDY QUESTIONNAIRE...... 72
16. EXAMPLE OF A UIML DEFINITION...... 82
17. MODEL OF AN XML ELEMENT...... 83
18. REL ELEMENT MODEL IN UIML...... 86
19. REL ATTRIBUTE MODEL IN UIML ...... 87
20. THE REL MODEL FOR BONDS IN UIML...... 87
21. INDIRECTION IN THE UIML ...... 101
22. THE UIML ELEMENT ...... 108
23. THE REL REPRESENTATION OF THE UIML ELEMENT ...... 109
24. THE HEAD ELEMENT IN UIML ...... 109
25. THE META ELEMENT IN UIML...... 110
26. THE REL REPRESENTATION OF THE UIML HEAD AND META ELEMENTS...... 110
viii
27. THE TEMPLATE ELEMENT IN UIML...... 111
28. THE REL REPRESENTATION OF THE UIML TEMPLATE ELEMENT ...... 112
29. THE INTERFACE ELEMENT IN UIML...... 113
30. THE REVISED INTERFACE ELEMENT IN UIML...... 114
31. STRUCTURE OF THE UIML INTERFACE ELEMENT...... 115
32. THE REL REPRESENTATION OF THE UIML INTERFACE ELEMENT...... 116
33. THE PEERS ELEMENT IN UIML...... 117
34. THE REL REPRESENTATION OF THE UIML PEERS ELEMENT ...... 118
35. THE PRESENTATION ELEMENT OF UIML ...... 119
36. THE REL REPRESENTATION OF THE UIML PRESENTATION ELEMENT...... 120
37. THE D-CLASS ELEMENT IN UIML...... 121
38. THE REL REPRESENTATION OF THE UIML D-CLASS ELEMENT ...... 122
39. THE D-COMPONENT IN UIML...... 123
40. THE REL REPRESENTATION OF THE UIML D-COMPONENT ELEMENT ...... 124
41. THE D-METHOD ELEMENT IN UIML ...... 125
42. THE REL REPRESENTATION OF THE UIML D-METHOD ELEMENT...... 126
43. THE D-EVENT ELEMENT IN UIML...... 127
44. THE REL REPRESENTATION OF THE UIML D-EVENT ELEMENT...... 127
45. THE D-PROPERTY ELEMENT IN UIML...... 128
46. THE REL REPRESENTATION OF THE UIML D-PROPERTY ELEMENT ...... 129
47. THE D-PARAM ELEMENT IN UIML...... 130
48. THE REL REPRESENTATION OF THE UIML D-PARAM ELEMENT...... 130
49. THE SCRIPT ELEMENT IN UIML ...... 131
50. THE REL REPRESENTATION OF THE UIML SCRIPT ELEMENT ...... 131
51. THE LOGIC ELEMENT IN UIML...... 132
52. THE REL REPRESENTATION OF THE UIML LOGIC ELEMENT ...... 132
53. THE STRUCTURE ELEMENT IN UIML...... 133
54. THE REL REPRESENTATION OF THE UIML STRUCTURE ELEMENT ...... 134
ix
55. THE PART ELEMENT IN UIML ...... 135
56. THE REL REPRESENTATION OF THE UIML PART ELEMENT...... 135
57. THE STYLE ELEMENT IN UIML ...... 136
58. THE REL REPRESENTATION OF THE UIML STYLE ELEMENT...... 136
59. THE PROPERTY ELEMENT IN UIML ...... 137
60. THE REL REPRESENTATION OF THE UIML PROPERTY ELEMENT...... 138
61. THE REFERENCE ELEMENT IN UIML...... 139
62. THE REL REPRESENTATION OF THE UIML REFERENCE ELEMENT...... 139
63. THE CONTENT ELEMENT IN UIML...... 139
64. THE REL REPRESENTATION OF THE UIML CONTENT ELEMENT ...... 140
65. THE CONSTANT ELEMENT IN UIML ...... 141
66. THE REL REPRESENTATION OF THE UIML CONSTANT ELEMENT...... 141
67. THE CONDITION ELEMENT IN UIML...... 142
68. THE REL REPRESENTATION OF THE UIML CONDITION ELEMENT ...... 142
69. THE EQUAL ELEMENT IN UIML...... 142
70. THE REL REPRESENTATION OF THE UIML EQUAL ELEMENT...... 143
71. THE EVENT ELEMENT IN UIML...... 143
72. THE REL REPRESENTATION OF THE UIML EVENT ELEMENT ...... 144
73. THE BEHAVIOR ELEMENT IN UIML...... 144
74. THE REL REPRESENTATION OF THE UIML BEHAVIOR ELEMENT...... 145
75. THE RULE ELEMENT IN UIML...... 145
76. THE REL REPRESENTATION OF THE UIML RULE ELEMENT...... 146
77. THE ACTION ELEMENT IN UIML...... 146
78. THE REL REPRESENTATION OF THE UIML ACTION ELEMENT ...... 147
79. THE CALL ELEMENT IN UIML...... 147
80. THE REL REPRESENTATION OF THE UIML CALL ELEMENT...... 148
81. THE REL REPRESENTATION OF THE UIML HOW ATTRIBUTE...... 149
82. THE REL REPRESENTATION OF THE UIML APPEND ATTRIBUTE...... 150
x
83. THE REL REPRESENTATION OF THE UIML CASCADE ATTRIBUTE...... 152
84. THE REL REPRESENTATION OF THE UIML REPLACE ATTRIBUTE...... 153
85. THE REL REPRESENTATION OF THE UIML EXPORT ATTRIBUTE...... 154
86. THE REL REPRESENTATION OF THE UIML MAPS-TYPE ATTRIBUTE...... 155
87. TIME SPENT BY VOLUNTEERS IN COMPLETING THE FOUR STUDY CATEGORIES...... 170
88. TIME SPENT LEARNING NOTATIONS...... 172
89. TOTAL ERRORS FOUND BY VOLUNTEERS AND REVIEWERS...... 172
90. EVALUATION OF REPRESENTATIONS BY REVIEWERS...... 174
91. KNOWLEDGE AND UNDERSTANDING OF STUDY NOTATIONS BY VOLUNTEERS...... 176
xi
Abstract Learning and Using Requirements Representation Notations by Information Technology Professionals Ralph Rillman Miller III Michael Atwood, PhD
This dissertation describes a unified system modeling approach and notation that accommodates the user view and a pilot study of the ability of information technology
(IT) professionals to learn and use requirements notations to represent user interface requirements. The study mapped a non-user view requirements notation into a user-view requirements notation. In so doing, it showed that the issues and concerns of non- technical users could be integrated into the overall requirements for a system. The work consisted of three related parts.
1. A non user view specific notation was shown to be consistent with a
user view specific notation.
2. Experienced IT practitioners defined the user interface requirements for
a simple device using one of three notations.
3. Domain experts reviewed the group’s products to determine errors and
overall quality.
The results of the pilot study suggest that the three notations studied are capable of representing the user’s view of requirements for a system. The pilot study was unique in its use of information technology professionals as subjects (volunteers) in the study.
1
Chapter 1: Introduction
“I’m thinking as hard as I can, but nothing’s happening” – the Three Stooges
Creative thinking is difficult. In a world of many teams, group thinking is perhaps the hardest of all. Working as a group, developers and clients must find ways to represent the requirements for a target system. To do this, they may use one or more requirements notations. To be usable, requirements must be in a form that unambiguously informs clients, developers and operational users of a proposed system as to its functional and non-functional characteristics. And even though each stakeholder may work forward in time with different tools, technologies, and goals in mind, at all times stakeholders should be able to return to the requirements, in whatever notation, and know that a representation is complete, unambiguous and understandable within their domain of interest. In other words, stakeholders in a system development should be able to develop their views
(models) of a system (e.g., data view, network view, process view, user’s view) consistent with their own perspective yet still be able to cross-validate their individual views with those of others. Some significant work has been done to this end (e.g., Davis,
Jordan & Nakajima, 1997, Nuseibah, Kramer & Finkelstein, 1993) that shows how a variety of perspectives can be cross-validated. Prior work, however, has largely ignored the user view and focused primarily on various systems views (Artim, van Harmelen,
Butler, Gulliksen, Henderson, Kovecevic, et al. (1998). This present work extends efforts to integrate a user view into the analyses of a system’s requirements by extending an existing systems meta-language to embrace a markup language built specifically to represent the user’s interface requirements for a system. This should enable designers and
2 developers to create a system view that efficiently and effectively models user interface requirements along with the other requirements for a system.
Why is this important? It’s important because good well-specified requirements are key to success in developing a system. Van Lamsweerde (2000b) suggested that perhaps one in six software projects are successful. Of those that fail, 50% or more fail due to problems associated with requirements. More recently Procaccino (2002) has shown that information technology (IT) developers have a strong perception that poor requirements result in unsuccessful projects. Grady (1997) reported root cause analyses for a number of projects at Hewlett Packard. He found that upwards of 50% of defects found in software were the result of poorly defined or incomplete requirements. At the Jet
Propulsion Laboratory, after rigorous software inspection procedures were implemented,
Kelly, Sherif and Hops (1992) reported, “a higher density of defects in earlier life cycle products [i.e., requirements analysis and design] than in later ones.” In other words proper and fully inspected requirements for a project can impact a project’s success out of proportion to the effort expended in creating them.
The problems with extracting requirements, in a general sense, for a system are difficult enough; but when the user’s view is brought into the mix, issues become even more problematical. The following is representative of the problem of expressing a consistent user view in a system.
Recently a lead systems engineering friend of mine cornered me to vent his frustrations about the lack of human factors effort [i.e., a consistent user view] on a project he was working on. … Each of the human-computer interfaces was designed by disparate groups that did not communicate with one another, and so the interfaces lacked a common look or feel … I communicated with my friend, but there was nothing we could do at that point (Shafer, 1999, p. 3).
3
Both sides of the coin are important. It is important to elicit and represent the declarative, behavioral, and interactive requirements for a system as a whole, as Grady and others have shown; but at the same time it is critical that the requirements of the end- user be obtained and integrated into the development of a system. In a survey reported some time ago, Myers and Rosson (1992) reported that an average of 49% of the code in applications programs then being developed was devoted to the user interface (i.e., the user’s view). Problems in developing the user’s interfaces included “getting users’ requirements” and “communicating among various parts of the program”. This result must be contrasted with the result reported by Shumskas (1991) that US Air Force software development projects commonly devoted 5% of their effort in developing requirements even though requirements had a 50% impact on a project’s outcome. Hooks
(2000) echoed this theme when he stated that stakeholders don’t want to “bother with requirements because they are too hard to define and document”. In the end, nonetheless, stakeholders and designers must be able to understand one another. Van Lamsweerde
(2000a) suggested that requirements need to be formulated in terms of the real-world in a vocabulary accessible to stakeholders (e.g., user,s and sponsors); while software specifications, which must flow from requirements, should be in terms of objects that will be manipulated by the system in terms accessible to the programmer. This view was also expressed by Garlan (2000) at the same conference at which van Lamsweerde spoke. A question, then, is can a useful and consistent user view be determined and represented within the overall software development process? This is the basic question this work sought to answer.
4
There are many widely used techniques for representing system and user requirements ranging from very informal prose to highly rigorous formal languages.
Between these two extremes, on a continuous spectrum, lie a large and highly useful body of techniques sometimes termed “semi-formal” (van Lamsweerde, 2000a) techniques. Semi-formal techniques share some of the syntactic and semantic rigor of formal notations but lack formal proofs. In a practical sense, then, the question finally comes down to that of tying extraction and incorporation of the user view into semi- formal requirements notations. Or put another way, how can the user’s view (viz. “here’s how I want to use this system”) be consistent and integrated with (i.e., be mapped into) the system’s view.
To do this, any mapping between the user view and system views should have the following characteristics.
1. Consistency and compatibility across a number of requirements
notations (e.g., object oriented analysis, data flow diagrams, finite state
machines, decision tables)
2. The ability to simultaneously represent users’ views on the widest
possible target user platforms.
These characteristics form the basis of the work done in this study. The purpose was to show how the user’s view could be modeled so that the results are compatible with and equivalent (i.e., can be cross-validated) to other requirements representation notations.
5
A case study approach was used. The form of the study was tailored from Robson
(1993, p. 52). The following points apply.
1. The study involved research into issues surrounding informal and semi-
formal notations that can be used to represent requirements for the user
interfaces of software systems. This study sought to highlight and
broaden issues surrounding capturing, representing, and using systems
requirements.
2. The study used multiple methods of inquiry. A mapping was completed
between a meta-language that has been shown to be consistent with
fourteen commonly used systems requirements languages but not with a
user interface language; and a language specifically created to represent
user interfaces in systems. The meta-language was mapped to the
widely used eXtensible Markup Language (XML) (Goldfarb & Prescod,
2001). The XML is a general markup language that can be extended for
more specific uses. The User Interface Markup Language (UIML) is a
language of the XML and was created specifically to represent user
interfaces in systems (Abrams, Phanouriou, Batongbacal, Williams &
Shuster, 1999). Because the UIML is a language of and consistent with
the XML (Phanouriou, 2000a), by creating a Data Type Document
(DTD) in XML of the meta-language (termed the Requirements
Element Language or REL) a mapping was shown from the REL to the
UIML. Conversely, all elements of the UIML were diagrammed in the
REL showing correspondence from the UIML to the Requirements
6
Element Language. This mapping was critical to demonstrating that the
user view can be modeled and understood in the context of a variety of
other commonly used system analysis techniques. The study also
involved volunteers who performed work using these requirements
notations. Volunteers created representations of the requirements for an
existing device and responded to a series of questionnaires designed to
determine the extent of their understanding of the notation. This
approach strengthened internal validity of the study by ensuring that the
representation of the requirements (i.e., the device itself) was common
to the three notations used by the volunteers. Expert reviewers reviewed
and evaluated completed requirements documents created by the
volunteers.
3. The study also investigated how well IT professionals learn and use
requirements representation notations by querying them on their
understanding of the notation they were using and of the representation
they were creating. The study used a reverse-engineering approach in
that the volunteers created the requirements for an existing device they
were given.
The overall study question was: How can the user view be incorporated into models for a system as defined in requirements for the system such that the user view can be cross-validated with other views of the system? In this question, the term “user view” is taken to be the sum of issues, concerns, and requirements stemming from and impacting upon the human computer interface to “match the needs of people” with the
7 system (Preece, Rogers, Sharp, Benyon, Holland & Carey, 1994). The user view, then, is analogous to a database view or a communications view of a system. The answer to this question was sought in two ways. First, two notations used for developing requirements for systems were mapped each into the other (i.e., the REL and the UIML); and second, a pilot “proof of concept” study was conducted to show how these two notations can be used to capture the user view of the requirements for a system. In addition an informal notation (natural language) was used in the pilot study.
Showing consistency (i.e., mapping) between the REL and the UIML was done by showing that every construct in the REL could be represented in XML and hence be used by the UIML; and by showing that every construct in the UIML can be represented by a corresponding construct in the REL. In writing UIML code, a requirements engineer would reference the data type document (DTD) of the REL to include the REL as a part of the user interface requirements for a system. By using the XML as an intermediate common language between the REL and the UIML, it also becomes possible to relate virtually any XML compliant language to the REL. This broader generalization is not, however, shown here. Because the goal of this research was to show that the user view could be included with system view notations, the UIML notation was held, with one exception, to be correct and the REL was extended as required to enable it to represent all of the UIML constructs. Extensions to the REL developed by Miller and Overmyer
(2001) and the full mappings are described in Chapter 4.
The pilot study showed that the three notations (REL, UIML and natural language) could express the requirements for a user interface for an existing system. The pilot study was conducted using Information Technology (IT) professionals as subjects
8 and subject matter experts to review their results. The pilot study gave indications that the user view can be made a part of a broader collection of system requirements notations
Some materials used in the case study are provided in Appendix A. This very preliminary finding will have to be investigated by further research. The rest of this introductory chapter discusses concepts and issues surrounding stakeholder views of a model of the requirements for a system in general and the user’s view in particular.
Stakeholders may use many notations to investigate, study, discuss, plan, and develop something that eventually becomes a target system. Davis and Jordan (1990) called this the problem of the Lucite box. It is a box of many sides--as many sides as there are stakeholders. Stakeholders use a variety of techniques (notations) to express their view of a system’s requirements.
OOA View
DFD View Internal FSM View Metamodel Representation
Figure 1. The Lucite Box (Redrawn with permission of the author.)
9
In Figure 1 each stakeholder represents and sees requirements for a system through a different facet of the box. In describing their concept, Jordan and Davis (1991) wrote,
One way of understanding the different perspectives represented by the diversity of requirements notations is to visualize a box with clear sides. Each side provides a different notation or view of requirements…. While the complete set of requirements is inside the box, one can see only the requirements projected by a particular view. Thus, one side of the Lucite Box might be a DFD view while another side might be an OOA view…. Although requirements can be viewed from the outside only, inside the box there exists a model of requirements that integrates all possible external views. (p. 10)
Jordan and Davis (1991) foreshadowed later work by Nuseibeh, Kramer and
Finkelstein (1993) who suggested that the requirements for software systems “… are invariably elicited from multiple perspectives which will overlap, complement and contradict each other.” Hence it is expected that each person expresses, communicates, thinks about, assesses, and digests a system’s requirements using different symbols and metaphors. These may have the same underlying semantics yet differ in their lexicon and syntax. In the end, whatever the constraints, for a system development project to succeed everyone needs to be describing the same requirements for the same system. Overmyer
(personal communication, June 2, 2002) suggests that communicating a person’s view to other stakeholders, however expressed (i.e., natural language, diagrams, or a formal language), necessarily constrains what can be communicated by the sender or known by the receiver. Artim, et al (1998) have suggested that different views in use cases need to be reconciled through task models. Different views must somehow be reconciled so that they have the same meaning. Nonetheless, and however arrived at, aggregate representations of the requirements for a system should constitute a complete and
10 possibly even minimal requirements set. Jordan and Davis (1991) looked for a way to express the common concepts in a variety of different notations using one single language. Their resulting REL is used in this work.
Norman (1983) suggested that the issue of differing perspectives consists of three views -- that of the user, that of the developer, and that of the system itself. Norman said:
…it is the task of the designer to establish a conceptual image of the system that is appropriate for the task and the class of users, then to construct the system so that the system image guides the user to acquire a mental model that matches the designer’s conceptual model. (p. 3)
Although Norman was speaking in terms of the user interface for a system, his observation is appropriate for all aspects of a system. In a practical everyday sense, the general system model proposed by Norman serves not only as a problem to be solved but also as a general road map to developing a system. In this study the REL is considered to be a meta-language able to “speak” in the voice of many stakeholders (e.g., database designers, systems engineers). The REL, then, represents the point of view of the developers. This can be seen from the declared purpose of the REL in Jordan and Davis
(1991) who state that the REL was created to provide, “A mechanism that provides multiple views [that] could serve as a basis for integrating the multiple notations that are necessary for a complete specification of requirements.” None of the notations they considered, however, are used to represent the user interface for a system. The REL, then, speaks from the view of the system. Similarly, in this study, it the UIML is considered to speak in the voice of the user. This language is meant to be a “universal language” that
“could describe user interfaces in a highly appliance-independent manner, and map the description to other markup languages or programming languages via style sheets
11
(Abrams, 1999). In the pilot study it was shown that the REL and the UIML are basically similar in their ability to represent the user view (requirements) of a system. When compared with the use of everyday English, the two semi-formal languages performed as well (among successful representations) as did informal English or “natural language”.
To complete the analogy to Norman’s model, the specific physical device represents the actual system in this work.
Next we turn to a short description of the informal and semi-formal representations of the requirements of a system. Natural language is the informal way requirements can be represented. By this is meant the normal every day written or spoken word--in our case English. There may be rules and conditions placed on a natural language to make it somewhat more formal. Specific words and phrases can be precisely defined and reserved for specific use. Specific structures can be imposed. However, such
“pseudo-languages” though somewhat less freeform than pure text, are at their core still a natural language. This study used the natural language notation as the exemplar of an informal notation. The word TEXT is used in referring to it.
Semi-formal notations include languages that can have defined semantics and syntax but are not provable (van Lamsweerde, 2000a). Semi-formal notations can consist of graphics, diagrams, symbols, pictures and icons and are commonly a mixture of these and natural language. Data-flow diagrams, activity charts, decision tables, use-cases and many others largely depend on some pictorial or graphical method to represent the requirements for a system. The REL and UIML, in van Lamsweerde’s definition, would be considered semi-formal languages. The words REL and UIML are used in referring to them.
12
This dissertation consists of six chapters, the first being this Introduction. The second chapter is a review of the literature concerning requirements notations. Following the literature review, the third chapter sets out the research questions and describes the approach to mapping the REL and UIML into each other. The fourth chapter describes the mapping between the REL and the UIML. The fifth chapter describes the pilot study and the data resulting from the pilot study. The final and sixth chapter discusses the results and points to areas of further study. A list of references is found following the final chapter. Appendix A provides example materials and questionnaires provided to volunteers and reviewers in the pilot study.
13
Chapter 2: Literature Review
“A computer program is a message from a man to a machine” - Fred Brooks (Brooks, 1995, p. 164).
The thrust of the literature review was to determine how studies of notations fit within the larger issues of describing requirements for software systems, what researchers have found in looking at the ease of learning and use of notations, and how well different notations represent systems requirements. This section first reviews literature concerning how requirements are expressed for software systems. Next, literature touching on the three categories (informal [TEXT], semi-formal [REL and UIML], and formal) of notations is reviewed. Then previous studies that have investigated the relative value of different notations are reviewed. Both within category and between category studies are reviewed. In order to provide an overview of all three categories of notations, studies are grouped according to category namely studies concerning formal then semi-formal then informal notations are presented. A final section is devoted to reviewing literature concerning system goals and the use of scenarios and prototypes to describe requirements and goals.
In reviewing the literature, it appears that there are many divergent disciplines of requirements engineering and requirements development--almost as many as there are researchers. The emphasis in this review is on work that touches to some degree on the problems with and the relative value of different notations for describing system requirements. Davis (1993) suggests that unconstrained natural language is a starting point for many practitioners but as one moves to more structured languages such as the
14
Program Description Language (PDL) Davis found that the lines between informal and formal notations blur. Between completely natural language and very formal fully defined languages lies the equally unsettled area of semi-formal notations an area that is equally unsettled. The highly diagrammatic object-oriented analysis (OOA) notations would be considered by some to be semi-formal notations (e.g., van Lamsweerde,
2000b). Others consider OOA to be more than sufficiently formal to describe the requirements for a system (e.g., Jacobson, Christerson, Jonsson, & Övergaard, 1992).
Much work has been concerned with what methods, processes, and technologies work best; but there is very little agreement on a single best approach. There is some agreement that there probably isn’t one best approach and that a variety of techniques can be used. Lang and Duggin (2001) found practitioners tend to use what comes to hand and works for a given situation. In certain cases, formal notations have been found to be the best choice. For example, when used in a clean-room approach (Sommerville, 1996) or for embedded “high-volume unchanging artifacts such as automotive steering-gear firmware” (Boehm & Sullivan, 2000). Those who promote more formal methods of notation would not agree that a mix of methods and notations works best (e.g., van
Lamsweerde, 2000a, Greenspan, Mylopoulos, & Borgida, 1994) although van
Lamsweerde (2000b) has conceded that all discourse has to begin using natural language.
There is a significant body of literature concerned with developing a user’s view of a system. Much of this literature has been devoted to describing different techniques for representing the elements (i.e., the specific parts and pieces) of an interface and to describing the actions (tasks) that must be performed using an interface. As to the former, a variety of “toolkits” have been developed that specify the nature of user interface
15 elements in a computer system (icons, menus, buttons, etc). See Kay (2000), Sybex Inc
(1998) or World Wide Web Consortium (no date) for examples of this approach. Kirwan and Ainsworth (1992) have provided a survey of techniques for representing the actions of an interface. Barnard, May, Duke, and Duce (2000) make a case for a “deep theory” to tie together a variety of heuristic user interface specification techniques. Duke, Fields and
Harrison (1999) have proposed how formal specifications can express user requirements.
Nonetheless, Artim et al. (1998) have shown that the user view is not generally included in representations of a system.
The rest of this section will review in more detail the literature concerning requirements engineering and the notation types. First general research concerning how requirements are expressed within the system development lifecycle will be reviewed.
Then, the few studies that have been performed on notations will be reviewed. Next the role and relationships between goals, scenarios, and prototypes will be reviewed. And finally, specific research and theory relating to notations will be reviewed.
Expressing Requirements and the System Development Lifecycle
When computer systems first became generally available to governments and large businesses, all projects were custom-designed. In part this was because there were no legacy systems to serve as a basis for revision and modifications. It was also because there was a multitude of operating systems, languages, notations, tools, applications and standards. Each problem was a new problem (Brooks, 1995, p. 283). In this early environment (1960’s and 1970’s), the approach to development was linear. So much time was allocated to analysis, so much to design, so much to coding etc. This linear approach
16 moved onward step by step, never looking back, towards completion of a fully realized system (Davis, 1993, p. 7, Brookes, 1995, p. 265). Commonly termed the waterfall model, the linear approach remains today the core paradigm from which other system engineering approaches have evolved. A significant modification to this linear approach was to introduce recursion thereby permitting practitioners to review and presumably correct errors from prior steps (Davis, 1993, p.8). Some suggest that despite all the work and research that has been done since Brooks’ original work (in Brooks, 1995) not much has improved in terms of our ability to successfully develop systems (Verner, Overmyer
& McCain, 1999).
The spiral development model, developed by Boehm (1988), is another transformation of the linear model. In Boehm’s spiral model, short combinations of linear steps are periodically interrupted by a phase that validates that the work accomplished to that point is in accordance with requirements. When these short linear steps are wrapped around each other from the beginning (in the center) such that each validation step lines up with the previous validation step, a spiral model emerges. The spiral model has been used in a variety of venues (Belz, 1986). Other non-linear models break software development into functionally similar units (e.g., the user-interface, communications, system interfaces, data models). These also break software development into short linear processes periodically checking the results against requirements for each functional unit
(Preece, Rogers, Sharp, Benyon, Holland & Carey, 1994, pp 47-50).
Although not necessarily developed to be a software development process (i.e., a methodology for developing software requirements), object-oriented (OO) methods constitute processes for developing software system requirements as well. Object-
17 oriented methods begin with object-oriented analysis and continue through object- oriented design, and object-oriented database design (Yourdon, 1999, p. 13). Object- oriented analysis identifies the objects, their methods, and messaging by analysis of client and user expressed requirements. Approached in this way, objects are a system’s requirements captured directly (Jacobson et al., 1992). Mylopoulos, Chung, and Yu
(1999) suggest that an object-oriented paradigm can serve as a single requirements development paradigm. In such a view, classes of objects are found through a discovery process involving the users and developers. However, Mylopoulos et al. at the same time admit that object-oriented analysis cannot, by itself, completely describe a system’s requirements In particular, it is insufficient to describe the non-functional requirements
(NFRs) of a system such as performance, reliability, usability, and other quality factors generally bundled under the term “illities”. This more recent view reflects a change in
Mylopoulos’ (1980) earlier view that a single paradigm such as a semantic network or formal programming language was sufficient for describing a system.
However, while there is some agreement that requirements will change and continue to be refined during development (e.g., Sommerville, 1996), this view is not universally accepted. Burton-Jones and Weber (1999), for example, assume that it is possible to create a single requirements model for a system at the outset. Their implication is that once practitioners have created an un-ambiguous system model, the team can dispense with further refinements and directly create designs and code. Such an exclusively forward-looking approach necessarily restricts later refinement of requirements in development after the first requirements engineering steps have been completed.
18
There is, however, agreement in one area of requirements engineering. This is the process by which one establishes a requirement. There are many paths to get to it, but in general, researchers agree that requirements must be elicited from the clients and users, they must be modeled (i.e., represented) in some way that is understandable by both clients/users and developers, and finally the modeled requirements must be validated
(i.e., agreed to in commonly understood terms) by both clients/users and developers
(Lausen & Vinter, 2001; Kilov, 2001; Finkelstein & Kramer, 2000; Nuseibeh &
Easterbrook, 2000; Sommerville, 2001, Dawson & Swatman, 1999).Validation, then becomes a process of “convincing stakeholders that the requirements represent what they are asking for” (Nuseibeh & Easterbrook, 2000). This elicitation-model-validation process reflects the need for developers to capture the user and client cognitive model and make it consistent with their own cognitive model; and is thus in keeping with Norman’s
(1983) model of a system. Procaccino (2002) found that the long-term involvement of the clients and users in developing a system was perceived by developers to be a significant success factor in a system’s development process.
Previous Studies on the Relative Value of Different Notations
There are no studies that investigated the relative value of different notations by
IT professionals. Studies have been reported that made use of undergraduate or graduate students as subjects. These are generally novice analysts taking an introductory undergraduate or graduate level course in systems analysis. A few studies have used experienced professionals in the information technology field to explore opinions
19 concerning questions about IT but studies with IT professionals to identify the relative value of different notations have not been reported.
An early study by Yaday, Bravoco, Chatfield, and Rajkumar (1988) compared data flow diagrams (DFDs) with part of the integrated definition (IDEF0) method. Yaday et al. describe the IDEF0 method as similar to structured analysis (see Davis, 1993, p.
80). Graduate students taking systems analysis classes were used as subjects. Syntactic and semantic comparisons were drawn. Yaday et al. found, “It seems that DFD is easier to learn and easier to use [when compared with the IDEF0 method]. It is not clear which technique produces a better result”. Other investigators have replicated this preliminary finding regarding DFDs and structured analysis (see below Vessey and Conger, 1994). In the context of the three notations in this study, Yaday et al. studied the relative value of two semi-formal notations.
Vessey and Conger (1994) also investigated the relative ease of use and efficacy of two semi-formal notations (Object Oriented Analysis--OOA, and the Structured
Analysis and Design Tool--SADT). Their subjects were a small number of undergraduate and graduate students taking an introductory systems analysis course. The time each subject spent studying a problem statement and notes on the individual methodologies was measured. The number and lengths of times subjects broke away to review the problem statement and notes while creating a representation of the requirements in OOA or SADT were determined and used as measures of the difficulty subjects had in using the OOA and SADT notations. All subjects performed the same tasks using both notations. Some subjects did the work using OOA then SADT; and some did the work using SADT then OOA. Experimental sessions typically lasted a few hours. The subjects
20 were videotaped during sessions. Times and counts of subjects switching from performing the required analysis and creating solutions were extracted from these videotapes. The act of switching from performing analysis to reviewing material about a method was termed a “breakdown”. Experts in the two methodologies reviewed the subjects’ solutions. Vessey and Conger found two interesting results. First, subjects found it easier to understand and use reference materials presented in the form of examples of the use of each notation. This was in contrast to poorer resulting analysis products produced by subjects who had reference materials that emphasized only a theoretical discussion of the notations. Second, they found that the SADT method to be more
“natural” and easier to use than they did the OOA method.
In a later study Sinha and Vessey (1999) compared how well graphical and formal language representations of different types of objects found in database analyses compared. In this study, they expected that a more expressive semantic model (i.e., a formal language) would provide a closer cognitive fit with developers. Their subjects were graduate students in a systems analysis course. Subjects were asked to create designs for a university database system using pairs of methodologies. The first pair studied was a combination of extended entity-relationship diagrams (EER) and relational data models (RDM). The EER methodology can be termed diagrammatic (semi-formal) while the RDM is a formal notation. The second pair of notations was a combination of object-oriented diagram (OOD) and object-oriented text (OOT) methodologies. The OOD methodology can be termed a diagrammatic (semi-formal) notation while the OOT can be termed a structured informal (i.e., text based) notation. Experts evaluated subjects’ work in terms of accuracy in modeling classes, entities, attributes, relationships, and
21 generalization relationships. Sinha and Vessey report, “Conceptual [EER and OOD notations] were more effective than logical [RDM and OOT notations] for representing all types of constructs”. They found that this held true for all relationships except simple one-to-one database relationships where it was found that the relational data model
(RDM) and object-oriented text (OOT) logical notations were as effective as the conceptual EER and OOD notations. Their conclusion was that for simple relationships a direct coding of relationships--such as represented in creating RDM and OOT “code”-- appeared to provide a close cognitive fit to a subject’s internal model of the requirements
(i.e., the university database case study). On the other hand, when more complex relationships were considered, (viz., one-to-many or many-to-many relationships) semi- formal graphical methods more closely matched a subject’s cognitive model. Sinha and
Vessey attributed this finding to the notion that coding is a single dimensional problem of translating a concept into a code construct; while creating diagrams and graphics is a two dimensional problem that more closely fits the thought processes of a subject when analyzing more complex relationships. In other words, when moving from simple concepts expressed in a case study (a purely textual document), Sinha and Vessey found that subjects could directly create code only for simple data concepts using a concept they termed sequencing. For more complex concepts a process termed taxonomizing--that of finding objects and defining the relationships between them--was used by subjects.
Sim, Forgionne, and Nag (2000) reported on a similar experiment to determine the quality of requirements expressed in object oriented analysis (OOA) versus those developed using structured analysis (i.e., data flow diagrams - DFDs). However, while
Vessey and Conger (1994) used breakdowns in a subject’s behavior as a measure of fit to
22 a subject’s cognitive model, Sim, et al. tested quality in subjective terms of accuracy and completeness. The difference between the two approaches is that Vessey and Conger took “breakdowns” observed from analyses of videotapes taken of subjects doing the work while Sim et al. analyzed the products of their subjects’ work post hoc. The subjects were graduate students taking a system design course. Sim et al. used a number of different problem cases, expressed in text, which were randomly assigned to groups of students. Students were broken into separate groups. Groups attempted to solve the problem cases using first object oriented analysis then structured analysis or vice versa.
Experts used a five-point Likert scale to assess the quality of the subjects’ results. Sim et al. reported that there was no difference found between the OOA and structured analysis notations used for expressing requirements. Both the notations studied are semi-formal notations.
In another experiment carried out over several years using over 90 undergraduate subjects taking a systems analysis course, Gemino and Wand (1997) reported significant degrees of comprehension, ease of problem solving, and ease of use for text and diagrammatic representations of a system. Subjects reviewed text, OOD and data flow diagram (DFD) representations of a number of different business domain systems.
Subjects then answered questions about the business domain from the information provided by the representations. Gemino and Wand reported that even though text clearly gave the subjects a greater descriptive understanding of the problems, subjects were better able to reason using the OODs than the DFDs and text representations. Even so, subjects scored OOD diagrams lowest in terms of “ease-of-use”. This last finding supports similar findings by Vessey and Conger (1994).
23
In reviewing the usage of the Unified Modeling Language (Booch, Rumbaugh, &
Jacobson, 1999), Kobryn (2000) observed that users of the Unified Modeling Language
(UML) tend to be overwhelmed by UML’s modeling options and overlapping semantics.
Kobryn’s observation supports earlier experimental results reported by Burton-Jones and
Weber (1999) who reported on the ease-of-use, understandability, and ability to reason with different notations. They used undergraduates as subjects. Subjects were asked to solve problems using clear and unclear EER diagrams of problem domains. In some cases, subjects were expected to be familiar with the problem domain and in other cases subjects were challenged to reason in domains with which they were not expected to be familiar. Clear and unclear EER diagrams were created for all cases. Unclear EER diagrams were created so as to be visually complex while remaining semantically correct.
Clear EER diagrams were carefully arranged to provide a close cognitive fit between the problem statement and the diagram. In other words, the unclear EER diagrams were meant to be visually confusing; while the clear diagrams were meant to be straightforward. Burton-Jones and Weber reported that there was little difference in correct reasoning with clear or unclear EER diagrams when the problem domain was not familiar to the subjects (i.e., they were equally “difficult”). But when subjects were familiar with the problem domain, they were able to reason more correctly with the clear
EER diagrams than they were using unclear diagrams. The EER diagrams, whether clear or unclear, are semi-formal notations.
Boehm, Bose, Horowitz and Lee (1995) reported on an approach for negotiating resolution of conflicting requirements for a system. Their method, termed Win-Win, consists of writing down stakeholder objectives (goals) and then identifying conflicts,
24 risks and uncertainties between them. Nuseibeh and Easterbrook (2000) have proposed that the Win-Win model manages requirements through a process of “recognizing change through continued requirements elicitation, re-evaluation of risk, and subsequent operational assessment”. Although modified in later studies, the Win-Win approach has been widely adopted as a process for achieving closure on requirements for a system. In their initial 1995 study, Boehm et al. used students as role-playing subjects. Their study is of interest here because objectives, conflicts, risks, and uncertainties were expressed in free unconstrained natural language. The initial study did not resolve whether, in the end, there was real understanding between the different stakeholders. However in later papers
(Boehm & Egyed, 1998, Boehm, Egyed, Kwan, Port, Shah, & Madachy, 1998) Boehm and his various co-authors reported that closure on requirements issues was obtained more easily by breaking the negotiations into shorter cycles and introducing a validation phase at the end of each short cycle. In these later studies, the spiral approach was compared against a more linear negotiation process. These later studies also used domain experts along with graduate students and faculty in real-life scenarios of requirements negotiations. Resolving conflicts by using natural language between stakeholders was also found to be useful in exploring inconsistencies in “illities” (e.g., maintainability, reliability) (In, Boehm, Rodgers & Deutsch, 2001). The studies of the Win-Win model have sought to determine the best approach to using natural language as a means for creating an initial cognitive fit between users and developers. The Win-Win model is one form of a structured dialogue. Even so, Johnson’s (2000) litany of problems in using natural language to describe the elements of a system’s user interface would suggest that
25 developers still have some way to go when using natural language as their primary means for capturing the requirements for any system.
Continuing the review of past work, the next section looks at how goals, scenarios, and prototypes make use of the three categories of notations to define and elaborate software system requirements.
Goals, Scenarios, and Prototypes
Goals, scenarios and prototypes can capture the nature of a target system. The literature reflects the fact that these three approaches typically use a mix of notations to accomplish their purposes. This section reviews the literature concerning goals, then that concerning scenarios and finally that of prototypes.
Every journey has an objective. The objectives for a system, like those of a journey, are expressed as goals. Although there is a difference of opinion about how goals should be represented, goals are commonly expressed using natural language.
Goals become the starting point from which requirements are derived. Hence, establishing goals is commonly the first step any system engineering team performs. For example, in one case study that looked at experiences in using goals to discover requirements, natural language was used to not only express but also to clarify goals for an e-commerce system (Antón, Carter, Dagnino, Dempster, & Siege, 2001). Some have seen creating and capturing goals for a project is seen as a process of discovering needs
(Jarke, Bui, & Carroll, 1998). Others have seen it as organizing a team’s thoughts prior to undertaking more formal engineering tasks (Kavakli, 2002). Negotiating goals between
26 the different stakeholders then becomes a major activity in these early stages of system development. The Win-Win model is an example of one strategy used to resolve conflicting goals.
Even though requirements change as stakeholders’ opinions change through the system development life cycle (SDLC), van Lamsweerde and Letier (1998) suggested that goals represent the most stable expression of the intent for a system. Because of this, van Lamsweerde and Letier also advocated the exclusive use of formal languages to express system goals (high level requirements). On the other hand, many other researchers have found that goals and requirements change continuously throughout a system’s development. Antón and Potts (1998) suggested that goal “… refinement becomes a process of negotiating, restating, [and] retaining goals to arrive at a set of requirements reflecting everyone’s views”. Anecdotally, my more than forty years of operational, research and development experience supports the views of Anton and Potts.
Goals are also a way to express non-functional requirements (NFRs) that cannot be expressed using more formal notations. Some (Darimont & van Lamsweerde, 1996) have suggested that more formal techniques should be used for expressing NFR goals.
The objective of such an approach is to enable goals to be reasoned with as are other formal representations of requirements. In this vein Nixon (1998) suggested expressing
NFRs after the development of a semantic data model for a system (i.e., after ERDs have been completed). Otherwise, he noted, system design will constrain the NFRs and not the other way around.
27
Darimont and van Lamsweerde (1996) proposed that higher-level patterns expressed as meta-models could be used to formally define goals. They suggested that a meta-model is necessary because stakeholders have different models of goals. By searching for patterns of goals, a meta-model could be created that identifies objects, operations, and requirements for a system. Such a meta-model would then permit these to be assigned to agents within the target system. Lehman (1991) earlier proposed a framework for software development; and later Spanoudakis and Finkelstein (1997) proposed a more formal method for “managing interference, inconsistency and ontological overlap” in requirements.
Scenarios are used to model how a system would appear or be used in practice. As a means for brainstorming (Soffer, Golany, Dori, & Wand, 2001), to elicit goals (van
Lamsweerde, 2000a), or to stimulate thinking and improve intra-team communications
(Anton, Carter, Dagnino, Dempster, & Siegs, 2001), scenarios are useful for clarifying the workings of target systems. In the early formative stages of a development project, scenarios provide a way to focus discussions by the development team and the stakeholders on specific behaviors of a system (Potts, 1995). Leite, Hadad, Dorn, and
Kaplan (2000) recognized that scenarios cannot express the entirety of requirements for a system; but can be useful for achieving a mutual understanding between engineers and clients.
Scenarios can be expressed in many ways using natural to formal languages. One use of scenarios is in the widely used UML (Booch, Rumbaugh, & Jacobson, 1999).
Initial requirements for a system using UML are created as “use cases”. Use cases diagrammatically show the actors, operations, and some constraints for a system. Use
28 cases provide a map useful for acting out how a system would look and be used. Booch et al. (1999, p. 224) suggested that, “Typically, you’ll first describe the flow of events for a use case in text. … however, [eventually] you’ll want to also use interaction diagrams to specify these flows graphically.” Use cases, therefore, do not show temporal logic.
Kösters, Six, and Winter (2001) proposed that activity graphs be appended to each use case in order to “improve consistency and completeness” and give the use cases greater semantic rigor. The activity graphs would, in this case, provide something equivalent to a scripted walk-through of each use case. Activity graphs are a semi-formal representation of a scenario.
Another form of scenarios are topoi diagrams. Topoi diagrams may be developed during the requirements phase of software development. They show actions, actors, and sequences presented as a directed graph. As such, they combine in one representation, the elements of use cases and activity graphs. Although the nodes and edges in topoi diagrams are not semantically unique, they can constrain the solution possibilities for a system. Menzies, Powell and Houle (2001) showed that topoi diagrams could be converted to a semantically rigorous formal language useful for facilitating consistency checks on the diagrams. Menzies et al. suggested that use cases be developed first, then be converted to topoi diagrams, and finally that the topoi diagrams be mapped into their proposed formal language. In this progression, the stakeholders would be moving from relatively informal representations (use cases) through semi-formal representations (topoi diagrams) to a formal consistent, complete, and provable formal language.
Prototypes, among other things, are a tangible expression of scenarios. By their nature, prototypes are not complete representations of a system. If they were, they
29 wouldn’t be prototypes but be the system. However prototypes, like scenarios, are a useful interim step in gaining team understanding of the requirements for a system (Leite,
Hadad, Dorn, & Kaplan, 2000). Indeed, like their underlying scenarios, prototypes can be regarded as a means for eliciting requirements (Ravid & Berry, 2000). Some consider prototyping to be a throwaway process in that none of the prototype is meant to be a production version of the target system (Andriole, 1989). Prototyping done in this way can be considered underlying research leading to systems specifications (Somerville,
1996). My experience is that prototyping is useful for clarifying specific issues for a client; but that prototypes seldom translate directly into target system software.
Users often state their needs in negative not affirmative terms. In these instances, prototypes and scenarios often provide the mechanism to bring people’s understanding of requirements together (van Lamsweerde, 2000a). However, there are two views concerning prototypes as methods for eliciting requirements. Van Lamsweerde appears to suggest that once requirements elicitation has been done, it is done for all time. Laueson and Vinter (2001) and Kavakli (2002) support this view. Others are not so sure.
Sommerville (1996) suggested that the term “engineering” when applied to software development can be misleading. Instead, Sommerville would refer to developing system software as “software growth” using an intentionally organic or biological metaphor.
Sutton (2000) sees requirements elicitation as spiral in nature and continuous throughout the SDLC. Certainly, as suggested by Verner and Cerpa (1997), the use and efficacy of prototyping is a function of your point of view. It follows then, that some form of prototyping as well as some use of scenarios can continue over the life of the development of a system.
30
Modeling requirements using Class, Responsibilities, and Collaboration (CRC) cards can be both prototyping and scenario building. A CRC card represents a class (in the object-oriented sense of the word) of a system. CRC cards are “ideal for the early stages of analysis when a team composed of users, analysts, and designers is trying to articulate a comprehensive model of the system.” (Bellin & Simone, 1997, p. 31).
Information on a CRC card is in natural language. The different team members use individual cards to play-act how cards work internally and how class-objects interact. The process is one of iterative scenario development. The end product is a set of cards that represent an expression of the target system; or, depending on how they are used, an initial object-oriented design of the system. In the former sense, CRC cards could be the starting point for creating a full object-oriented design using, for example, the Object
Modeling Technique (OMT) (Rumbaugh, Blaha, Premerlani, Eddy, & Lorensen, 1991); while in the latter sense, they could be used by programmers directly to create class- objects in some suitable object-oriented code.
Notations--Textual, Diagrammatic/Graphical, and Formal
This section reviews the literature pertaining to notations used to describe requirements for a software system. The review begins with informal notations (i.e., natural language), then semi-formal notations and finally formal notations.
Natural language is the starting point (Lang & Duggan, 2001) and natural mode of discourse between stakeholders (Davis, Overmyer, Jordan, Ceruso, Dandashi, Dinh, et al., 1993). It helps to ensure that stakeholders agree on “relevant objects and relationships” (Mylopoulos, Chung & Yu, 1999). Natural language is nevertheless
31 fraught with ambiguous semantics and ill-defined syntax (van Lamsweerde, 2000a).
Some find this ambiguity useful for narrowing the general field of discourse in defining requirements (Garlan, 2000) and for moving to more formal representations (Potts, 1995).
In discussing software architectures, Garlan recognized that while software architectural terms such as “client-server” may be imprecise in engineering terms, they nonetheless deliver “significant semantic content” because they convey issues, “paths of evolution”, overall computational paradigms, and relationships between internal and external systems. Hence, even though using natural language for discourse about a system may involve imprecisely defined terms, it serves a vital role by establishing the general nature and structure of the system.
A number of authors use a form of structured natural language, sometimes termed
“pseudo-code”, as a means for overcoming the problems of ambiguity in natural language requirements (e.g., Sommerville, 2001, Davis, 1993, Pressman, 1997, Wood, 1997). Such pseudo-code uses a “free-form English with certain key words reserved with special meanings” (Davis, 1993).
Boehm and his co-authors in several papers, has found natural language useful in negotiating requirements, from a goals and needs standpoint and also from the standpoint of constraints, conflicts, and risks (Boehm, Bose, Horowitz & Lee, 1995, Boehm &
Sullivan, 2000, In, Boehm, Rodgers & Deutsch, 2001). While obviously of use in capturing data in ethnographic studies of requirements elicitation (Coakes & Coakes,
2000), natural language can also be an obstacle to understanding. For example, Ravid and
Berry (2000) reported that it is much harder to validate requirements stated in natural language than requirements embodied by prototypes.
32
Even though using natural language to develop system requirements remains an eminently popular activity with those not directly involved in architecting and developing systems, Davis (1993) has remarked that, “The larger the natural language document becomes, the more impossible consistency and maintenance become”. Similarly Abrams et al. (1999) commented that natural language is inappropriate to specify a user interface.
Although Davis did not recommend writing all of a specification in natural language, he did find that there are times when it is more appropriate to use natural language over more formal techniques. The goal in the end, according to Davis, is a complete
“description of what the software will do without describing how it will do it.” Natural language is commonly used to define NFRs that specify the environment for a system, the external requirements of maintenance, portability, etc, as well as requirements that apply to the development process such as coding errors per thousand lines of code.
Semi-formal notations are widely used in developing requirements for systems.
The REL and the UIML are both semi-formal languages. As a bridge between the natural language of users and clients and the more formal notations commonly used by developers (e.g., the Vienna Development Method [VDM] and the “Z” language), such semi-formal diagrammatic and graphical notations find wide usage. Davis (1993) reviewed widely used systems requirements notations. This is not the place to repeat
Davis’s review except to observe that notations he reviewed could, using van
Lamsweerde’s definition, be termed semi-formal notations; and that they essentially consist of labeled two-dimensional figures connected together by arcs and arrows.
Although the meanings can be reversed, commonly figures represent things, actions and processes; while arcs represent a relationship or flows of data or control between the
33 figures. Keywords, labels and other symbols (e.g., “+” and “1:m”) modify arcs and arrows. Figures can be nodes on a graph, a process box in a data flow diagram, class- objects in an object-oriented analysis, or an entity in an EER diagram. In the meta- modeling language created by Davis, Jordan and Nakajima (1997) (i.e., the REL) figures
(termed elements) and arcs are semantically unique. They have shown the REL to be consistent with fourteen commonly used semi-formal notations. The Unified Modeling
Language (UML) is a widely used technique. It consists almost completely of numerous semi-formal notations such as graphs, diagrams, event diagrams and decision tables to represent the requirements for a system (Booch, Rumbaugh, & Jacobson, 1999, Booch &
Rumbaugh, 1995). Semi-formal notations, then, incorporate some of the informality of natural language and some of the formality of formal languages.
Formal languages, finally, are semantically expressive, unique, and provable.
They may also be difficult to learn and use when used to directly represent the requirements for a system. In van Lamsweerde’s view (2000b), overall there are two possible frameworks within which requirements engineering can occur. The first he termed a Central Approach in which all requirements are expressed in a single common
“logic-based assembly language”. In this approach, there are only language primitives. If a logic-based language were used to define requirements van Lamsweerde argues, it would be impossible (absent human errors) for requirements to be anything but correct, consistent, and complete. Van Lamsweerde defines any approach that does not rely solely on formal languages as the Distributed Approach. The Distributed Approach permits different stakeholder viewpoints to be represented in different notations. These different viewpoints necessarily need to be, unlike the Central Approach, checked for correctness,
34 consistency, and completeness. Specifications created using the Distributed Approach are also termed multi-notation specifications. In van Lamsweerde’s view, the major problem with the Distributed Approach is that multi-notation specifications do not have a common underlying logic-based formalism. Because of this a specification written in several notations cannot be shown to be complete, correct, or consistent. Van Lamsweerde uses the term specification to mean a representation of a system used by developers.
Duke and Harrison (1995b) view the formal process of software development as a
“process of transformations that, through validation or formal derivation can be shown to be valid”. Duke and Harrison (1995a) further suggested that such a process could be facilitated by “interactors” intended “to bridge the gulf between system and user-oriented concerns”. Interactors provide a formal logical basis for the descriptions of transformations and interactors in these two papers. Finally, in discussing how to bridge the gulf between the requirements for the user-interface (as separate from the entire target system), Duke, Bernard, Duce, and May (1998) have developed “a mathematical framework” to model the interface.
Other researchers, also recognizing that requirements will generally be developed using different notations, have proposed a framework to enable them to be unified within an “object-based” framework (Nuseibeh, Kramer & Finkelstein, 1993). In later work,
Jacquot and Quesnot (1997) defined a formal technique for expressing user-interfaces.
They proposed a “… semantic foundation of a specification language which can be used as the first formal description of a user-interface… [that would allow] … an executable instance of the interface along with an interactive visualization of the dialogue
35 structures.” In this manner, they sought to bring under a single formalism, the specification of a system and its user-interface.
Formal languages such as the Vienna Development Method (VDM) and Object-Z seek to precisely define requirements using formally defined objects and relationships.
Agerholm, LeCoeur and Reichert (1998) have shown the VDM to be appropriate for safety-critical control systems of land and space applications. The VDM was found to facilitate system simulation testing and rapid prototyping. Extensions to the Z formal specification language have been proposed to create a formal approach to web applications. This approach would create an “XML/XSL approach to the development of a web environment for the formal specification language Object-Z” (Sun, Dong & Wang,
2001). Their work brings together elements of object-oriented development, the UML, and the formal specification language Z. However as “formal” as a programming or markup language may be, formal languages are usually heavily “commented” within the code. Such in-line explanations enable, “someone [to] pick up the code and immediately start to understand it.” (McConnell, 1993, p. 488).
The next chapter defines the research question and the methodology used in this study.
36
Chapter 3: Research Questions and Methodology
The first section of this chapter describes the research question of this study.
Next, this chapter describes the approaches to mapping process and the study design.
Finally, the types of data and the measurement methods used in the pilot study are described in a section on the structure of the pilot study.
There are three questions this research investigated.
RQ1: Is it possible to create or extend a modeling notation in such a way that permits the integration of user-oriented requirements (i.e., user interface, data, and tasks) with the mainstream analysis activities of traditional analysts? Are these two views of a system simply too heterogeneous or complex that they cannot simultaneously represent a user-oriented view in a single modeling notation?
RQ2: Is there a relative advantage, in terms of accuracy and ease of view representation and comprehension, of one or another of these notations when representing user interface requirements? If a “meta-notation”, theoretically capable of representing all views of a system’s requirements is possible, does such a notation represent the user view as well as other notations specifically designed to do so? In other words, how well, relative to each other, do the TEXT, REL and UIML categories of requirements notations represent the requirements for a user-interface.
RQ3: If these distinct views can be represented in a single notation, does the single notation become impossibly complex for experienced analysts to use; or would another intermediate representation such as the UIML or natural language that can be integrated into a meta-notation after the initial view is created be preferable? How easily can experienced IT professionals learn and use the informal and more formal requirements notations
When put together these three questions are key to understanding how well the model of the user view can be integrated into the overall system view. We ask ourselves: is there a facet of Jordan and Davis’ Lucite box that can present the user’s view and if so, can these different views be reconciled and even cross-correlated?
37
In requirements studies previously reported, the nature of the starting point in creating requirements has varied. Vessey and Conger (1994) and Burton-Jones and
Weber (1999) and others have used written (i.e., English) requirements. Boehm et al.
(1998) used domain experts to define requirements. As a starting point to understand how well a notation can represent requirements, such approaches are necessarily of limited value. This is because it is inherently illogical to investigate one notation relative to another when one or another notation is used as the starting point. To overcome this problem, in this study the completed target system itself was used as the starting point.
This set aside problems of interpretation of some proto-representation of requirements by subjects.
The mapping of the REL notation into the UIML notation was done to address the first research question. The second and third research questions were addressed in the pilot study using recruited volunteers. A case study (Sproull, 1995, p. 154, Robson, 1993, p. 52) was used to address these questions. This researcher did the mapping of the REL notation into the UIML notation and vice versa. The pilot study involved volunteers who were asked to learn one exemplar notation and use it to represent the requirements of the target system. The value of a notation, then, was determined by measuring the time it took to learn and use a notation and from the errors in the requirements representation as found by the subjects plus those found by independent reviewers.
The next section in this chapter describes the approaches used to investigate these questions. First, the approach for the REL-UIML mapping will be outlined and then the nature of the pilot study will be described.
38
Approach of this Research
The critical task in this study has been to show that the REL and the UIML are equivalent in describing the user view portion of a system’s requirements. To show this, the two have been mapped one into the other. In so doing, comparisons between the study results from the REL and the UIML become possible. No language can ever be shown to be complete in the absolute sense. Hence, it is only necessary to show that one language
(the REL) can represent all of the elements of the target language (the UIML). This approach is taken here.
Although the mappings between the REL and the UIML were relatively straightforward, there were issues and some inconsistencies one to the other. Miller and
Overmyer (2001) proposed extensions to the REL addressing these issues and inconsistencies. These proposed extensions were included in these mappings. The REL lexicon does not consider order of evaluation, cardinality between elements or relationships and in some instances, existence. The Miller and Overmyer extensions provide notations for these cases. The extensions consist of modifications to bonds
(relationships). The specifics of these extensions are given in Chapter 4. An overview of the REL and the UIML and an overview of the approach to the mappings and the resolution to issues raised in these mappings are reviewed next. Following this, the elements of the pilot study are described. Following this chapter, Chapter 4 provides a complete description of the mappings. Chapter 5 then describes the data and results from the pilot study.
39
Overview of the REL and the UIML
The REL was created for the purpose of providing a common meta-language that can represent a variety of commonly used systems analysis notations in each other’s terms. This enables designers who work using different graphical requirements representation notations within the same project to see representations of each other’s work in terms of the particular technique each is using. Hence, if one analyst is using
DeMarco data flow diagrams (DeMarco, 1979) and another is using Coad OOA diagrams
(Coad & Yourdon, 1990), each will see the other’s portion of the system’s requirements in their own notation. They will not, however, see portions that cannot be represented in the notation they may be using. The REL was created to achieve the following goal
(Davis et al., 1997)1.
… a better understanding of primitive elements of requirements specification can help us to define newer, and better, requirements languages based on existing or new requirements compounds. (p. 65)
The term “requirements compounds” is specific to the REL and will be explained later. Davis et al. (1997) have shown the REL to be internally and logically consistent.
The UIML is a language for defining user interfaces. The UIML designers sought to “propose a comprehensive solution to the problem of building device-independent (or multi-channel) user interfaces promoting the separation of the interface from the application logic” (Phanouriou, 2000b). The UIML is an XML language (World Wide
Web Consortium).
1 Davis et al. did not name their language. I have named it the Require ments Element Language (REL), a term they used in passing reference to their language.
40
The UIML separates each of the elements of the architecture of a user interface into distinct sections of the specification. This separation is necessary for several reasons
(Abrams et al., 1999).
First, different appliances use different languages … Thus, developers must maintain multiple source code families to deploy interfaces to one information system on multiple appliances. Second, user interfaces differ dramatically in complexity … [and] Third, developers risk writing appliance-specific interfaces for an appliance that might not be on the market tomorrow. (p. 1)
The UIML is a declarative language that explicitly separates specification of an appliance, the interface, and application code. By separating what an interface does from how it does that makes it possible to link multiple applications and platforms with one generalized description of an interface.
First, the REL was mapped to the XML. This made sure that the REL mapping was complete and consistent. In other words, the REL was modified, as needed, to enable the mapping to be done. One element definition of the UIML was modified. This was done to correct a logic error wherein an exclusive OR form was used by the designers of this version of the UIML when the form should have been a non-exclusive OR. The mapping of the REL to the UIML was concomitantly changed. To create a representation of the REL in the UIML a data type document (DTD) could have been written. However, because the UIML is a language of the XML (Phanouriou, 2000b) such that all constructs in the UIML are XML compliant, it was only necessary to write a DTD mapping the REL into XML. The UIML is then capable of making use of the REL by reference to the REL
DTD.
41
The REL DTD, then, represents the mapping and is a direct translation of every possible REL element and bond (i.e., arc) into the XML. In practice, a UIML document would call this DTD by reference in order to create a DTD that represents an REL diagram in the UIML (World Wide Web Consortium). Conversely, and as shown in
Figure 2, by creating an REL representation for every element in the UIML, mapping to the REL from a UIML representation was achieved.
World of System Definition World of Markup Languages Languages
OOA
UIML define UIML in terms of REL DFD/ CFD REL World of XML Dialects State define REL in terme of XML Machines World of XML Event Diagrams etc.
Figure 2. Mapping Between the REL and the UIML
In Chapter 4 will be found a data type document (DTD) that represents every REL element in the UIML. In Chapter 4 also will be found an REL representation of every element in the UIML (version 2.0e). An overview of the REL and the UIML are presented in the next sections.
The Requirements Element Language (REL)
The Requirements Element Language was created to enable a number of graphically oriented systems definition languages to be represented in each other's
42 format. Thus, a Data Dictionary developed using Control Flow Diagrams (CFDs) could be represented simultaneously to another software engineer using object oriented analysis in the appropriate OOA formats (Davis et al., 1997). The REL has not been shown to be compatible with the large body of languages that stem from the Standard Generalized
Markup Language (SGML). One of the most important of these markup languages is the
Hypertext Markup Language (HTML) widely used on the Internet to describe web pages and their content. However, thousands of "tags" have been created in HTML such that today describing pages and their content is becoming increasingly difficult for software engineers. As a result, the XML was created to be compliant with HTML but to be more robust and maintainable than is HTML. The XML was designed from the SGML to consist of relatively few easy to use constructs. The XML is also commonly used to define specialized languages that contain specific constructs useful in a particular problem domain. The UIML is one such language of the XML (Abrams et al., 1999). The
UIML was designed to enable web designers to describe the requirements for the user interface of multiple platforms using one description and still remain compliant to the
XML language.
The REL consists of objects (in the generic sense) representing things and relationships between them. In the REL, Davis et al. (1997) refer to objects as elements and relationships between elements as bond-arcs. The term “bond” will be used hereinafter to mean, “bond-arc”. Elements and bonds are represented graphically through the use of basic geometric shapes and directed arcs. Elements and bonds represent the objects in a variety of diagrammatic notations used by practitioners (e.g., data flow diagrams). While the REL has been precisely defined, it was not found to be broad
43 enough to cover all constructions in the UIML. To overcome this problem, Miller and
Overmyer (2001) created extensions to the REL. These extensions expand the REL to clarify issues of existence, order and cardinality.
Existence was clarified by providing for weak (non-mandatory) and strong
(mandatory) relationships between elements. These correspond to XOR and OR logical relationships respectively. The notations “s” and “w” were introduced as modifiers to part-of bonds between elements for this purpose. A number of elements in the UIML enforce a specific order in which hierarchically inferior elements will be executed.
Numbering the bonds between related elements created a notation that specifies the order of execution of related elements in an REL diagram. Finally, in order to indicate the cardinality of an element in the UIML in the REL, a notation was created that accounts for the three possibilities (viz. zero or one, zero or more, one or more).
There are eight element types in the REL. These are entities, processes, messages, predicates, constraints, values (or states), state-spaces (or attributes), and transitions.
Entities represent real world things or concepts. Processes represent actions, tasks, or functions. Messages are things moved between two entities. Predicates are prepositions or common Boolean operators. A constraint asserts a necessary relationship between elements. A value represents an initial value or a specific state. A state-space is a characteristic of another element and can change during execution. A transition acts like a daemon and fires when stimulated.
There are nine bonds in the REL. These are specialization, part-of, has-value, sends, receives, stimulus, response, equivalence, and operand. A specialization bond
44 establishes a child of a parent. Part-of bonds establish relationships between the pieces of a parent (e.g., the wheels of a car). The has-value bond establishes a specific value to an element that is invariant when the model is run. The sends and receives bonds permit message elements to send and receive things. The operand bond represents a relationship between a predicate, a constraint or message and its operand. The stimulus and response bonds cause a transition to fire because of the value of one element and carry the response to another element. Equivalence bonds establish aliases for elements. The REL also permits what are termed requirement compounds. Requirement compounds represent groups of elements and bonds. These compounds are a graphical device to promote visual simplicity in an REL diagram. Further description of the REL is found in Chapter 4. The following section describes the UIML.
The User Interface Markup Language
The UIML was chosen for this study because it was specifically developed to describe the user interfaces for systems. It is particularly suited, therefore, to describe the user interface for the study device. Also, because it is an XML language, UIML was chosen because of the growing use of XML compliant markup languages to capture the elements of many domains.
The UIML was in part developed to incorporate elements of the Seeheim user interface interaction model. The Seeheim user interface model was created to enable designers to distinguish relationships between the various functional elements of a user interface (Green, 1986, Phanouriou, 2000a). Figure 3 (Phanouriou 2000a) illustrates the model that resulted from the conference in Seeheim.
45
Application Dialogue Presentation Interface Control Model
Application User Logic Feedback
Figure 3. The Seeheim User Interface Model (Redrawn with permission of the author.)
A user interface represents the external interface of a system manipulated by operators. Because of the differences between what a system can do and what an operator would like to do with a system, it is useful to separate the elements of the user interface from other aspects of an application and its operating environment. Green (1986) described the Seeheim model as having a presentation component, dialogue control and an application interface model.
The presentation component deals with the physical representation of the user interface. … The presentation component … deals directly with devices. … [and] can be viewed as the lexical level of the user interface. … The dialogue control mediates control and dialogue between the application model and the user. … It can be viewed as the syntactic level of the user interface. … [Finally, the application interface model] defines the interface between the user interface and the rest of the program. (p. 245-246)
The Seeheim model is one of the more useful user view models as it delineates a relatively clean break between the user and a system. Other more detailed elaborations of this theme have been proposed. For purposes of this study, however, it is important to note only that, while separated from the system, a user view model is nonetheless directly linked to it. This is true for all systems that have a user interface (i.e., purely embedded systems would hence not be directly concerned). Separating the model of the user’s view does not, however, mean that the software and hardware for the user interface, the parts
46 of a system that I term “interfaceware”, can be specified and developed without reference to and yet remain consistent with the rest of the system.
In developing software systems for commercial products, the different functional elements of a user interface are nonetheless often neither created nor implemented together. One team of developers may create the underlying operating system, another may create the applications and another may write the functional code for the interface.
By separating and standardizing the interfaces between application code, presentation code, and dialogue control, developers are able to separately create the elements of a user interface. This considerably reduces developmental, maintenance and upgrade problems
(Abrams et al., 1999). Likewise a goal for the UIML was to be able to create one interface description: for multiple platforms that perform the same tasks, for multiple interface component toolkits that are suitable for differing application languages, for multiple programming languages and for multiple operating environments (Abrams et al.,
1999).
The UIML makes it possible to create common user interfaces across multiple platforms and implementations. It does this by creating three basic components
(Phanouriou 2000a).
[The first is a presentation component that] provides a canonical way for the user interface to render itself while hiding information about the widgets and their properties and event handling. … [The second is an interface component that] describes the dialogue between the user and the application… including structure, style, content, and behavior. … [Thirdly a logic component provides] a canonical way for the user interface to communicate with an application while hiding information about the underlying protocols, data translation, method names, or location of the server machine. (p. ii)
47
Two other components in the UIML provide a means for referring indirectly to external toolkits and style sheets (the peers element) and for creating reusable components (the template element). The UIML, therefore, is a language built upon the concepts of separating a user interface into functional parts to maintain consistency of actions across multiple instantiations of the interface while still remaining consistent with other parts of the system. Figure 4 illustrates the general structure of the elements in the
UIML. All possible parent-child relationships are shown by this figure. For example, the behavior element can have a rule child while a rule parent can have a condition or an action child. Order and set functions are not shown.
The UIML, was primarily designed to separate structure, content, actions/functions (behavior), and presentation. In so doing the UIML enables each of these to point to one or several instances of themselves providing flexibility and power to the UIML. The next section gives an overview of the mapping between the REL and the
UIML
48
UIML
head peers template
meta presentation logic
d-class d-component
d-event d-property d-method
d-param script interface
structure style content behavior
part property constant rule
reference condition action
equal event call
Figure 4. The Structure of the UIML (Redrawn with permission of the author.)
Approach: Mapping the REL to the UIML
In mapping the REL to the UIML it is sufficient, as we have said, to represent the elements and bonds of the REL in an XML Document Type Definition (DTD). The DTD
49 then stands as a complete and sufficient definition of the REL in XML terms such that a parser could be created capable of translating REL into executable XML code.
There are two object types in the REL, elements and bonds. As a result, there are two basic object2 types in the REL DTD. Element types in the REL were defined using the XML-compliant model shown in Figure 5.
i.e., a different name for each element-type, list all bond-arcs possible for element i.e., whatever the information designer wants to say about this REL element. Figure 5. XML Model for REL Elements
As shown in Figure 5, XML definitions of REL elements consist of three essential parts. First, the element is named using the expression “!ELEMENT” which contains the
“element-name” and the related bond types. Parentheses enclose the names of the bond types that can connect to the element. The nature and characteristics of bonds are defined separately. The “!ATTLIST” names and lists attributes of the element. The “this- instance-name” and the “ID” provide a unique identification for the element. Cardinality is indicated for the element through the use of the Extended Backus-Naur Form (EBNF) notation (World Wide Web Consortium). Finally “source-information” provides
2 The term “object” is here used in its general sense.
50 collateral information about an element as needed. This could be a reference to a toolset where a formal definition (e.g., in the form of a style sheet) of the element type would be found. As used here to describe the REL, CDATA would define the REL element in terms that the particular UIML parser would use to execute the UIML.
The REL bonds were similarly defined using the model in Figure 6.
i.e., a different name for each bond-arc type i.e., whatever the designer information wants to say about this REL element. Figure 6. The XML Model of the REL Bond Types
Each bond instance is unique. A bond emanates from just one element and points to just one element. The !ATTLIST lists the element from which and the element to which a bond points. The directionality of the bond is indicated as one-way or two-way.
A two-way bond connects equivalent elements. This reflects the reflexive nature of equivalent elements (i.e., aliases). The count attribute identifies in what order this bond is to be evaluated. Source information is as for REL elements.
51
In addition to the eight element types and nine bond types in the REL, an additional root element is needed to complete an XML DTD. The root element establishes the existence of the elements in the REL. It is defined Figure 7.
Figure 7. The UIML Root Element
A mapping of all elements and bonds in the REL to the XML (and hence to the
UIML) is found in Chapter 4. The next section outlines the approach used in mapping the
UIML to the REL.
Approach: Mapping the UIML to the REL
The UIML is mapped to the REL in Chapter 4. This section explains the approach that was taken. The specific version of the UIML used was version 2.0e as proposed by
Phanouriou (2000a). Although similar to the published version 2.0a (World Wide Web
Consortium) of the UIML, version 2.0e incorporated naming and structural changes. The changes proposed by Phanouriou have made the language easier to understand and more straightforward in use. For this admittedly subjective reason, version 2.0e was used exclusively throughout this study.
The UIML is a hierarchical language for expressing the existence, structure, functions and relationships of a user interface for multiple platforms, applications and interface realizations. A UIML document begins with the UIML root element that can
52 consist of a head element, template elements, an interface element, and zero or one peers element.
To illustrate how the mapping was done, Figure 8 shows the translation of the
UIML root element into the REL. The XML notation is given in World Wide Web
Consortium (World Wide Web Consortium).
UIML element
The "UIML" element is the root element of a UIML document. The data type definition of the UIML element is as follows:
The meaning of this definition is that the UIML element can contain zero or one HEAD element, zero or many TEMPLATE elements, zero or one INTERFACE element, and zero or one PEERS element. The HEAD, TEMPLATE, INTERFACE, and PEERS elements are to be evaluated in that order.
As the root element, the UIML element serves only as a container for all parts of the interface(s) defined within.
UIML
prt-w-1 prt-w-2 prt-w-3 prt-w-4
(0,1) (0, inf) (0,1) (0,1) [head] [template] [interface] [peers]
In the REL representation, the order of evaluation is indicated by the suffix to the label "part- of" as in "prt-w-2". Which means that the element (in this case a TEMPLATE) does not have to be a part of the UIML element, but if one is present, it will occur after any head element. That is, the "w" means that the existence of the referred to element is not required. Order and cardinality as in Miller and Overmyer (2001)
Figure 8. The UIML Root Element Represented in the REL
53
The REL “compounds” are graphical simplifications that represent combinations of elements and bonds defined somewhere else. Such combinations are represented by the compound symbol “ ”. In Figure 8, the compound symbol is used to represent the head, template, interface, and peers elements because each is a hierarchical element in itself. This REL figure, then, says that a UIML element can consist of combinations of head, template, interface, and peers elements; and further that these elements are themselves compounds of hierarchically lower ranking elements. The bonds
(shown as directed arrows with labels (e.g., “prt-s-1”) establish the relationship and, if applicable, the cardinality and order between the element types. In this case, each compound is a “part-of” the element type UIML. All of the relationships are weak (not mandatory). Notice, while a UIML document can only contain at most one head, one interface and one peers element, it can contain any number of template elements. But, as shown by the order of the bonds, the template elements must come after the head and before an interface element when they exist. This enables DTDs to be created that consist solely of template elements. Such templates can then be referred to (i.e., reused) in other projects.
As a matter of practice, unless one is writing UIML solely to create re-usable templates, a fully parsable UIML document will contain, after the UIML element, at least a head and an interface element. When the document is meant to describe multiple interfaces for multiple platforms, there will also be a peers element enabling the analyst to call on outside toolkits and style sheets specific to individual platforms for the interface (e.g., a telephone, a laptop, a PDA). The next section of this chapter describes the approach taken in the pilot study.
54
Approach: The Pilot Study
To study the second and third research questions, a pilot study was undertaken that looked at four categories of tasks. These four categories were evaluated in terms of the time it took volunteers to complete the tasks within these categories as well as the number of errors volunteers introduced into the requirements documentation they created.
The four study categories were:
1. Overview reading and tasks--involved reading materials associated with
each individual Project (Overview)
2. Learning and Reading tasks--involved reading study and notation
specific materials and papers (Learn)
3. Creating requirements representations--a two-step process was used.
First volunteers created an initial high level set of requirements and
then, in the final Project, completed the representation of requirements
(Create)
4. Correcting representations--wherein volunteers corrected their
requirements representations (Correct)
Throughout the rest of this paper, the terms “Overview”, “Learn”, “Create” and
“Correct” has been used when referring to these four categories. When referring to these categories, the terms will always be capitalized to distinguish them from the common use of these words.
55
The purpose of the pilot study was to show that user interface requirements for a simple device could be represented using three exemplar representation notations (REL,
UIML and TEXT). This “proof of concept” was undertaken to demonstrate one possible approach to validating that the user view can be included into the system view of the requirements for a system. To do this, volunteers were asked to create the requirements for the user interface of a simple device (the target system). Each volunteer used one of the three notations (TEXT, REL or UIML). Volunteers were recruited (i.e., purposefully selected) from highly experienced and competent practitioners in the fields of information technology, systems architecture, and software design and development. All volunteers used an automated tracking tool to measure their progress. The REL, UIML, and natural language TEXT exemplars have been explained. Each volunteer completed four Projects. In so doing, they each learned and used one of the three exemplar notations. The four Projects for one notation constituted a study leg. Hence each volunteer completed one leg of the study. The products of each volunteer’s work were reviewed and evaluated by independent expert reviewers recruited from industry and academia. Reviewers determined errors in completed requirements representations and evaluated representations for overall value.
For all volunteers the first two Projects were the same, namely learning to use the time measurement tool and learning about the study device. The final two Projects were similar in structure and intent for each of the three notations studied; however the differences in notations dictated differences in specific tasks.
56
Tasks and Data In The Pilot Study
Figure 9 is an overview of the tasks and data created by the volunteers and expert reviewers who participated in this study. The figure shows that volunteers created timing data and requirements representations. They also answered questionnaires for each
Project. Error data were embedded in the timing data for Project 04 as will be explained.
Expert reviewers reviewed the volunteer’s final requirements representations of the target system. These data, along with the questionnaire and timing data, were analyzed. Not shown in this figure is the work done independently by this researcher to map the REL into the UIML.
Volunteers Tasks Project Project Project Project 1 2 3 4 Result Timing Exemplar Requirements Representation Tool Tutorial Device of the Exemplar Device s
Data Data Data Data
Timing Data From Each Project Task
Questionn- Questionn- Questionn- Questionn- aires aires aires aires Data Analysis Initial Final Expert Representa- Representation tion Reviews
Figure 9. High-Level View of Research Approach
The study materials supplied to volunteers for Project 01 and materials provided to reviewers for Project 04 are provided in Appendix A. Some questionnaires given to volunteers and reviewers are also provided in Appendix A.
57
Four basic data types were gathered in the pilot study: questionnaire results, within Project task timing results, initial and finished requirements representations of the study device and expert qualitative and quantitative evaluations of finished requirements. Questionnaires were created for each of the four Projects to probe a volunteer’s knowledge of the subject of the Project as well as to garner subjective responses concerning the value and ease of use of the notation. Each Project consisted of readings and tasks for the volunteer. For each task, a volunteer used the automated measuring tool to capture time spent performing the task. An independent body of experts scored the resulting representations.
Terminology of the Pilot Study
The terms used to hierarchically structure tasks in a Project were necessarily dictated by the terminology of the particular automated timing tool used (i.e., the Leap tool described in the “Measurement Tools” section subra). The term “Project” is an example of the terminology of the Leap tool. In the Leap tool, Projects are broken down into Phases, Phases into Document Types (called DocTypes), and DocTypes further annotated with a Description (called a Desc) consisting of free-form text. The detailed data thus gathered enables analysis to be done to the DocType and Description levels.
Roughly, a DocType would correspond to what hereinafter is termed a task.
The pilot study, as shown in Figures 9 (above) and 10 (to follow), consisted of three legs. The term “leg” was meant to suggest a pathway or road for the volunteers.
· Each volunteer followed one of these legs. Every leg was broke up into
four Projects.
· Each Project consisted of five or more tasks for the volunteer to complete.
· Each Project consisted of an Overview set of materials that included
terminology and information helpful in understanding the study and the
58
notations. The Overview acted as a script of tasks volunteers were to
complete in each Project.
· Volunteers performed the same tasks in Projects 01 and 02. These were
first to download, install and use the automated timing tool they were
going to be using for the remaining Projects; and second to become
familiar with the study device (i.e., the ZEN400).
· In the third Project, the volunteers created an initial representation of the
requirements for the device in the notation of the leg they had been
assigned.
· In the fourth Project, they completed and corrected their representations.
Additionally, volunteers completed questionnaires at the end of each Project.
Questionnaires given to volunteers were of two types. The first, administered with each
Project, concerned the just completed Project. The second, administered with the second and fourth Projects, cut across Projects and concerned the study as a whole. The individual tasks in Projects, Phases, and Doctypes are shown in Table 1.
Table 1. Projects, Phases and DocTypes Task Project Name Phase Document Type (DocType) Project 01 1.1 Leap Familiarization Leap Installation Leap Installation 1.2 Leap Familiarization Leap Tutorial Leap - Using Io 1.3 Leap Familiarization Leap Tutorial Leap - Using Naia 1.4 Leap Familiarization Leap Tutorial Leap - Using the Controller 1.5 Leap Familiarization Leap Tutorial Leap - Familiarization Questionnaire Project 02 2.1 Device Familiarization Study Background Study Familiarization 2.2 Device Familiarization Study Background Study Questionnaire (1)
59
Table 1. (continued) Task Project Name Phase Document Type (DocType) 2.3 Device Familiarization Device Briefing Device Functions 2.4 Device Familiarization Device Briefing Device UI 2.5 Device Familiarization Device Briefing Device Familiarization Questionnaire Project 03 3.1 Problem Familiarization UIML Familiarization UIML Overview 3.2 Problem Familiarization UIML Familiarization UIML Manual and Structure 3.3 Problem Familiarization UIML Familiarization UIML Familiarization Questionnaire 3.4 Problem Familiarization UIML/REL/TEXT Problem Problem Reading 3.5 Problem Familiarization UIML/REL/TEXT Problem Initial Representation 3.6 Problem Familiarization UIML/REL/TEXT Problem Problem Questionnaire 3.7 Problem Familiarization UIML/REL/TEXT Problem Reviewing Previous Material Project 04 4.1 Representing the UI UIML/REL/TEXT Complete Representation Requirements Representation 4.2 Representing the UI UIML/REL/TEXT Review of Representation Requirements Representation 4.3 Representing the UI UIML/REL/TEXT Reviewing Previous Material Requirements Representation 4.4 Representing the UI UIML/REL/TEXT Study UIML/REL/TEXT Final Questions Problem Questionnaire 4.5 Representing the UI UIML/REL/TEXT Study Study Questionnaire (2) Questions 4.6 Representing the UI UIML/REL/TEXT Study Reviewing Previous Material Questions
Volunteers followed the script in the Overview to work through the Phases and
DocTypes. See Appendix A for some of the materials (less readings and papers) provided to volunteers in the study. As the volunteers worked through a script, they kept track of the time spent in each task using the Leap automated timing tool. Using the Leap tool, volunteers were able to accommodate their own individual styles of work.
60
Pilot Study Design and Methodology
The study consisted of three groups of volunteers (the “study group”). The time each volunteer spent in performing the tasks of the study was recorded using the automated time keeping tool Leap. Volunteers also completed questionnaires covering their tasks. Experts reviewed their work and completed a questionnaire for each volunteer reviewed. In addition to questionnaires, the study yielded timing data and requirements representations of the device. The flow of the part of the study involving the volunteers is shown in Figure 10.
REL Proj 03 REL Proj 04
Requirements Proj 02 Proj 01 Leap Representation Device UIML Proj 03 UIML Proj 04 Familiarization Timing Data Familiarization Questionnaires
TEXT Proj 03 TEXT Proj 04
Figure 10. The Flow of the Projects Performed by Volunteers
Volunteers were solicited from the professional systems engineers, programmers, and analysts of the Computer Sciences Corporation, a major information technology company; information technology PhD students from the College of Information Science and Technology, Drexel University (Philadelphia, PA); and Massey University (Aukland,
NZ). Volunteers were asked to represent requirements for the user-interface of a hand- held VCR remote-control (the Zenith ZEN400)--termed the “device”--using one of the
61 three notations. When completed, experts reviewed and evaluated volunteers’ representations.
Structure of the Pilot Study
In order to prepare materials for the volunteers to use, several colleagues were asked to review them. These initial studies were helpful in clarifying language in the materials and questionnaires for the study. They also pointed out that the tasks associated with creating a representation in any one of the exemplar notations were too much to be done in one Project. Accordingly what had been one Project (03) was broken down into two Projects (03, 04).
The backgrounds of volunteers were important to this case study for several reasons. Initially the study was attempted using what Conger and Vessey (1994) have termed as novice systems analysts. Third and fourth year undergraduates in the College of Information Science and Technology at Drexel University were solicited to do the study. The level and sophistication of the problems put to this set of volunteers were quickly found to be well beyond them. A major purpose of the study was to focus on the efficacy of the three notations and not how well novices could learn and use them. As was evident from the review of the literature, most studies concerning the usefulness of different ways of representing requirements have enlisted the aid of more or less novice systems analysts. While useful to a degree, such studies leave unanswered the question of how learning and using different notations compare when used by experienced professionals--a situation more representative of the everyday working world.
Accordingly the study was restarted using recruited volunteers who were well
62 experienced in the general field of systems engineering including creating requirements for systems.
In the first Project, volunteers were asked to obtain and learn how to use the Leap productivity tool. Volunteers first went to the University of Hawaii website to obtain the
Leap tool. Then they manipulated parts of the Leap tool to understand what parts they would be using in the study.
Next in Project 02, volunteers needed to understand the particular device chosen as the interface exemplar for the study. This device was the Zenith ZEN400 multi- platform remote control. The functions of the user interface to the ZEN400 are shown in
Table 2. The ZEN400 is a programmable remote control device capable of controlling up to four media devices. Its user-interface, while relatively straightforward, has several nested functions. This degree of complication in the device’s user interface was useful in studying the three requirements representation notations. The ZEN400 has a total of 31 items in its interface (buttons and a light); and a total of 36 possible actions that can be performed by those items. Figure 11 is what the ZEN400 looks like. In addition, in the second Project, volunteers studied general materials covering all three notations in order to gain a broader understanding of the purposes of the study.
Table 2. Functions of the ZEN400 ZEN400 Functions of the ZEN400 Button Name Indicator Light On, Off, Blink - Indicator light used to show user the remote is in a particular mode. PWR Push(on), Push(off) - Power button to enable user to switch devices on and off depending on which state the remote is in
63
Table 2. (continued) ZEN400 Functions of the ZEN400 Button Name TV Down, Up - When pushed down, indicator light comes on. When programming, light comes on and blinks on release VCR Down, Up - As for TV CBL Down, Up - As for TV AUX Down, Up - As for TV Code Search Down, Up - When pushed, causes remote to enter code search mode. When released, causes light to blink Prev Ch Push - When pushed and released, sends signal to platform to return to the previous channel Chan + Push - When pushed and released, sends signal to platform to increment channel by one Chan - Push - When pushed and released, sends signal to platform to decrement channel by one Vol - Push - As for Chan +/- except for sound volume Vol + Push - As for Chan +/- except for sound volume M(ute) Push(on), Push(off) - When pushed and released, toggles between the muted state and the unmated state Number Buttons Push (x10) - When pushed and released sends the number of button. (x10) Enter Push - When pushed and released, causes the enter command to be sent to the platform TV/VCR Push(TV), Push(VCR) - When pushed and released, toggles the TV between the TV and VCR mode. REW Push - When pushed and released, causes a VCR platform to rewind a tape. If remote not in VCR state, no action occurs PLAY Push - As for REW. Causes VCR to play a tape F.F. Push - As for REW. Causes a VCR to fast forward a tape REC Push - As for REW. Causes a VCR to rewind a tape STOP Push - As for REW. Causes a VCR to stop playing a tape PAUSE Push(on), Push(off) - When pushed and released causes VCR to toggle between pause and play modes
Figure 11. The ZEN400 (reduced scale)
64
In the third part of the study consisting of Projects 03 and 04, volunteers created a representation of the requirements for the user interface of the ZEN400 using one of the three notations. In Project 03, volunteers were asked to study the notation for their leg of the study. This involved reading original materials describing the notation, some examples of their leg’s notation and further explanatory materials. They were then asked to create an initial representation of the requirements for the ZEN400 device using their notation. For the UIML leg, this involved identifying the major elements in the interface element as well as creating the UIML (root) and head elements. The UIML template and peers elements were not used in this study. For the REL leg, this involved identifying the entities, state-spaces, values, and processes for the interface. For the TEXT leg, volunteers were asked to create an overall description of the goals of the interface and a natural language outline of the high level requirements for the ZEN400. TEXT volunteers were asked to identify the “nouns” that constitute the device’s user-interface as well as categories of functions that the device can perform.
Project 04 was the final half of the third part of the study. Volunteers completed their representations to include all objects, functions, and states of the device. After completing the representation to their satisfaction, they performed a formal walk-through of the representation by talking aloud their representations at the same time as they worked the device. In the walk-through they were to stop and fix errors as they found them. The numbers and types of errors and the time it took volunteers to correct them were kept using the Leap tool. Volunteers were asked to keep going through their representation correcting errors as until they found no more errors or until they had walked through their representation three times.
65
One volunteer, who had conflicts with professional travel, could not complete the requirements for the entire ZEN400. This volunteer was asked only to complete requirements for a selected part of the ZEN400 interface. In doing so, this volunteer completed requirements for 11 of the 36 possible actions of the interface. This constitutes
30% of the actions possible in the ZEN400. The effort expended by this one volunteer in studying and preparing to represent the interface involved the same materials as were used by the other volunteers.
In the end, volunteers produced three types of data: a representation of the requirements for the device using the notation of their assigned leg; timing data representing the time they spent performing the Projects, Phases and DocTypes of the study; and finally questionnaires about each project and the study as a whole.
Additionally, expert reviewers evaluated volunteers’ results.
There were many difficulties in obtaining finished results and a sufficient number of volunteers from which statistical inferences might be drawn could not be found. To overcome this problem, it may be possible to use a Central Composite Design studies as suggested by Williges, Williges and Han (1992). A Central Composite Design uses sequential integrated models. They suggest that, as long as specific factors are handled in common between experiments, it is possible to significantly reduce the needed number of statistically valid comparisons in order to draw valid inferences from the combined results. Although not followed here, their approach could point the way to successive smaller studies that, when combined, might provide valid insights into the issues surrounding different requirements notations.
66
Pilot Study Measurement Tools
There were four types of measurements taken in this study. The first was from the personal productivity-timing tool--Leap. The second were responses to a series of questionnaires that gathered information about a volunteer’s understanding and reactions throughout the study. The third was the finished requirements representation developed by each volunteer. And the fourth type was the reviews and evaluations of the finished requirements representations by expert reviewers. Table 3 shows the data types gathered by the study and their relationship to the three study questions.
Table 3. Research Questions (RQs) Related to Data Types Data Types RQ1 RQ2 RQ3 Time to do tasks in Projects X Error data from volunteers X Error data from reviewers X Questionnaires for volunteers covering Learning and X Knowledge Questionnaires by reviewers of quality of volunteers’ results X Mapping between REL and UIML notations X
Each measurement type is discussed in turn in the following sections that cover the Leap tool, questionnaires, the notations used, volunteers, and expert reviewers.
67
The Leap Tool
Leap3 is a “… Java application for software developer improvement” developed by the Computer Science Development Laboratory (CSDL) of the University of Hawaii
(Moore, 1999). The Leap toolkit is designed to support the Personal Software Process methodology of Humphreys (1995). The tool enables practitioners to automate many of the tedious aspects of keeping track of how long it takes to perform tasks. If practitioners know how long it takes to perform tasks compared to how long they forecast it would take, in the future they can better forecast how long it will take them to perform similar tasks (Humphreys, 1995). A study of the teaching capabilities of Leap reported by Moore
(1999) tends to support Humphreys’ supposition.
The Leap toolkit has many sophisticated project tracking and analysis tools. Only the time keeping and data editing functions of Leap were used for this study. Basically the tool has a “VCR-like” interface that resides on the user’s computer desktop. This enables the practitioner to categorize, start, stop, pause, and save time spent doing tasks.
A Controller window, always resident on a developer’s computer desktop, controls the
Leap tool when it is running. Table 4 describes the windows of the Leap tool used in this study.
Table 4. Time Keeping and Data Editing Windows of the Leap Toolkit Leap Window Window Description Controller The window in LEAP that gives access to all of the other tables
3 Lightweight, Empirical, Anti-measurement dysfunction, and Portable software
68
Table 4. (continued) Leap Window Window Description Io The “Timer” and the window used to start and stop the clock on activities. Works similar to a tape recorder: start/stop/pause. It also has a save function to save the time captured doing work. Io is the Hawaiian word for the Hawaiian Hawk. Io is pronounced “EE-oh” Naia The “Times” window is a tabular presentation of timing data gathered using Io. Naia was used to manually enter the time it took to download and configure the Leap toolset. After that the volunteer did not need to access this tool. Naia is the Hawaiian word for porpoise. It is pronounced “nah-EE-ah”
Each volunteer was given pre-defined Leap files for this study. These files specified Project, Phase, and DocType names for their leg (see Table 1). This imposed a structure on the volunteers for working through the study. Although a volunteer could change this structure without constraint (i.e., the file cannot be made un-editable), specific directions to volunteers asked them not to do this. The Leap tool permits the user to establish three hierarchical levels of elaboration in keeping data about a project. Thus, the data logged for each Project-Phase-DocType triplet represents a description of the accumulated time to perform a task. In addition, a triplet can be further distinguished by adding a description of the triplet as it is being kept. Volunteers used this feature of Leap to discriminate, for example, between error types during their formal walk-through.
Figure 12 is an example of the Controller window. (Leap windows are reproduced with permission of the CSDL, University of Hawaii.)
Figure 12. The Leap Controller Window
69
The Controller, gives the user the ability to load and save timing and Project,
Phase, DocType and description data; the ability to bring up the Io timer window; and the ability to bring up the Naia data logging and editing window to enter and edit data.
When they started Project 01, volunteers did not yet have Leap installed on their computer desktops. So, for the first few steps of Project 01, they were asked to keep elapsed times manually and enter them later using the Leap data-editing tool--Naia. Once volunteers had entered their manually kept data from the first phase of Project 01 into the
Naia data logger, they were asked not to open or use Naia again. Subsequent timing data were kept using the installed Leap tool. Individual timing files from each volunteer represent the basic timing data gathered in this research.
Figure 13 is an example of timing data from a volunteer as shown by the Naia window from Leap. The Naia window shows the Project, the Phase and DocType names.
In addition, the user-entered “Description” is shown. The start and stop times are shown overall for the each session. A user may have many sessions with the same Project, Phase and DocType. Leap is able to pause to allow the user to interrupt work and engage in other activities. Leap discards the time intervals associated with pauses and just gives the cumulative time spent in each session and the number of pause periods (identified as
“Interrupt”). Actual working times are shown in aggregate minutes under the “Delta” column. Time is kept in whole minutes by Leap. Once the volunteers had downloaded and installed Leap, they were able to enter their manually kept data into Naia and then use the Leap Controller and the timer (Io) to thereafter time their activities.
70
Figure 13. The Leap Data Logger and Data Editor Widow (Naia)
In order to initiate a session, a volunteer loaded the existing Projects, Phases,
DocTypes and Times files using the Controller. Once this was done, they brought up the
Io window and used it to set Project, Phase, and DocType. They were asked to type in a description of what they were working on in the Description (“Desc”) data entry field.
Users invoke the Io timer through the Controller. Figure 14 is the Io timer window.
Figure 14. The Leap Timer Window (Io)
A volunteer used the Io timer window to track the time to do their work. The timer is similar in functionality to a standard video-cassette recorder with start, stop and pause functions. In addition, users must “record” work and “save” their data when they close Leap. A user can also clear data from this window.
71
Pilot Study Questionnaires.
Two types of questions were asked on questionnaires. Closed-ended questions were asked using a continuous scale. Open-ended questions were asked to acquire extended opinion, knowledge, and information from the volunteers. Parnas and Weiss
(1985) refer to these as “brief” surveys. Both types of questions were designed to probe the respondent’s understanding of a knowledge area and ability to apply that understanding in providing an answer. This study did not ask the volunteers to do simple tasks that derive from their common cultural knowledge. It required a thorough understanding and application of a specific notation. While the questions asked were meant to be probing, questions were not, on the other hand, exhaustive. Parnas and Weiss have suggested that such an approach is sufficient in order to show that a respondent understands the subject under discussion. One need not, for example, ask an auto mechanic for an explanation of the workings of every part of an automobile to be able to gauge whether or not the person is a competent mechanic. It is sufficient to probe only part of a person’s knowledge set to gain an understanding of their depth of knowledge.
There were three purposes in using survey instruments in this study. First, they were used to acquire demographic data from the study population of volunteers. Such data were useful to ensure that the study group consisted of sufficiently experienced IT professionals as well as for understanding the data from different volunteers performing the same and different legs. Secondly, survey data provided checkpoints from each of the volunteers as they proceeded through and as they completed the study. Volunteers were asked to give their impressions of the study overall after the second and fourth Projects.
72
These data provided a means for understanding before and after the pressures and problems placed on the volunteers. Finally, the survey data asked specific open-ended questions of volunteers as they finished successive tasks. Their answers provided a measure of their understanding of the material they had just read and the work they had done. An example of a questionnaire is shown in Figure 15. This example questionnaire was administered to volunteers after each had finished the last Phase of Project 02.
Selected questionnaire data are summarized in the discussion of results.
Project 2B Device Familiarization Questionnaire
Background: Now that you are familiar with the Device, you are ready to complete this questionnaire about it. Answers can be typed onto this document following the questions.
1. Please enter the sum of the digits of your full telephone number - in the US use the full ten digit number plus your extension, if you have one. In other places, use everything except your country code. (e.g., my phone number at work is 856-234-1100 extension 6205. The sum of 85623411006205 is 43. Hopefully everyone will have a different check-sum) a. The sum of my telephone digits is ______2. The ZEN400 can control a total of _____ devices at any one time. How is this enforced?______3. The ZEN400 uses multiple key sequences to enter a variety of modes. List the key sequences for the following actions: a. Change channels ______b. Program for a different TV ______c. Program for an unlisted device ______d. If I’m controlling my TV using the ZEN400, and I have a blank tape in the VCE, how do I set the tape to record my program (assuming the VCR is already hooked as an input to the TV)? ______4. What happens if I try to enter a code for a device whose code is “001” and I only hit the “1” key?_____ 5. After I did this (in question 4 above), will the code now be entered into the ZEN400? ______6. What meaning does the purple color imply for the Volume, Change Channel, and Mute buttons? ______7. Were you able to program the ZEN400 to run your TV? _____ What problems did you have? ______
Don’t forget at this point you should be stopping the Io timer and saving your times before you save and close this Word document.
Now please save this Word document under its original name and return it to me via e-mail.
Thanks again for completing this Project. Next proceed onto the third Project
Figure 15. Example of a Study Questionnaire
73
Sproull (1995) stresses that questions should be appropriate to the research questions, yield data required for data analysis and avoid leading the respondent. All questionnaires were reviewed for simplicity, unambiguousness, and ability of the item to support the investigation of the research questions using the Sproull’s questionnaire checklist.
Requirements Representations
Each leg of the study looked at a different exemplar notation for representing requirements. Two legs used a semi-formal notation and one used an informal notation.
The UIML leg requirements representation result was a UIML data type document
(DTD). The REL requirements representation was one or more graphics using the REL symbol set. The natural language used was English (TEXT). In the TEXT representation, the volunteer created indented paragraphs to indicate the objects and functions and their hierarchical relationships of the device’s UI.
A UIML DTD consists of complete and sufficient UIML code which, when presented to an appropriate code parser, would result in an executable user interface.
Individual toolsets invoked by the UIML each have a parser/compiler. Because there is no toolset or corresponding XML DTD for the device, a “fake” data type document was created that contained widgets possibly useful in describing a ZEN400 interface. The
UIML code was hand checked for correctness, completeness, and consistency by an expert reviewer.
74
A REL requirements representation consists of a graphical representation of the requirements for the user interface of the ZEN400. There is an existing requirements engineering environment that automatically translates these meta-models into any one or all of the fourteen notations known to be consistent with the REL (Davis et al., 1997).
These representations, either individually or collectively, may or may not cover all aspects of the ZEN400 interface. Accordingly this engineering environment was not used in this research. An expert reviewer and this researcher checked the REL representations for correctness, completeness, and consistency.
Finally, as there is no general format or structure for natural language requirements, the TEXT representations were checked without reference to specific format or structure for correctness, completeness, and consistency by an expert reviewer.
Volunteers initially corrected their representations themselves. They were asked to identify four error types. These were Errors of Omission (EEO) which occur when a function or other part of a representation has been left out; Errors of Commission (EOC) which occur when the representation has material in it that is in excess of requirements or is incorrect; Errors of Understanding (EOU) which occur when the volunteer did not understand the notation sufficiently to represent something from the device; and finally
Errors of Specification (EOS) which occur when some function or part of the device was specified that did not occur in the device.
The Volunteers
Volunteers for this study were recruited from the doctoral students at the College of Information Science and Technology of Drexel University, systems analysts and
75 programmers from the Computer Sciences Corporation and other technology professionals. Five volunteers completed four Projects. A sixth volunteer completed three
Projects and a reduced version of the fourth Project (i.e., a reduced requirements representation). The results from these six persons constitute the data set analyzed for this study. The average years of professional experience of the volunteers was almost 26 years with a low of 16 years and a high of 45 years experience. Volunteers were asked to place themselves in decadal cohorts. Two volunteers were in their forties, three were in their fifties and one was in his sixties. Volunteers characterized their current job titles as
Program Manager, Assistant Professor, Computer Scientist, Information Science,
Chemical Engineer, and Systems Engineer. Degrees held by the volunteers ranged from
Associate of Science (1), Bachelor of Science (1), Master of Science (3), to Doctor of
Philosophy (1).
Finally, it was important to find volunteers who would actually complete the study. Although the tasks were structured so as to lead the volunteers through a common path, they were nonetheless difficult and at times complex. This created a twofold problem. First, the complexity of the tasks and the need to keep three legs that were essentially the same meant that three sets of instructions that were identical in form but different in content had to be created. Unfortunately, this sometimes meant instructions created for one leg (e.g., REL) were meant in part for another (e.g., UIML). Informal communications between the volunteers and myself were used to resolve these issues. In keeping with the case study nature of this research, volunteers were encouraged to correspond with myself to resolve issues of interpretation of the instructions. My answers to these questions were made available to all relevant volunteers. Secondly, the
76 experience level and depth of knowledge of the volunteers was important for them to understand the intent and flow of the tasks. Volunteers, although highly experienced in their fields, were not familiar with the specifics of the REL and UIML notations. This meant each had to self-teach the particular notation used in the leg they were performing.
Here, the experience and ability to work an assignment through to completion became of paramount importance. So, for example, whereas volunteers might be very experienced in using HTML or XML (and some were), they would nonetheless have to learn the UIML language. That the volunteers were not familiar with specific notations meant that all started off on an equal footing (i.e., at the same relative knowledge level).
Expert Review and Evaluation
The penultimate task for volunteers in Project 04 (before filling out questionnaires) was to identify and correct errors in their representations. As an additional check for errors, several experts in the field of requirements engineering were sought. These experts are very senior in their field. Three experts were used - Professor
Emeritus Robert Smith of California State University, Long Beach California (REL),
Professor Scott Overmyer of Massey University, Auckland, New Zealand (TEXT), and
Mr. Ralph Mattei Senior Computer Scientist of Computer Sciences Corporation (UIML).
Each expert reviewed the representations of the volunteers for one leg of the study. They were asked to determine the numbers and types of errors in the work of the volunteers.
Each expert reviewed two representations. In addition, their opinion as to the quality of the representations within the context of the methods reviewed was recovered through responses to questions using a continuous scale from 1 (lowest) to 5 (highest).
77
Each expert was asked to review the requirements representations from one study leg. They were asked to identify three types of errors.
1. Error of Commission - something added to the representation that introduces error
2. Error of Omission - something missing from the representation that introduces
error
3. Error of Over-Specification - material in the representation that duplicates an
already defined functionality of the interface; that introduces functionality not
found in the device; or that misses functionality in the device.
The three error types are listed in priority order. If, for example, an element in a representation was found to be both an error of omission and an error of specification, the experts assigned it as an error of omission giving this category precedence over an error of specification. In this instance, only an error of omission was to be recorded. The purpose of identifying errors was to determine the degree to which the volunteers understood and were able to use the representation methods. The next chapter is Chapter
4. It shows the mapping between the REL and the UIML.
78
Chapter 4: Mapping Between the REL and the UIML Notations
Overview of the Mappings
This Chapter describes the mapping between the REL and the UIML. In the first section, the REL is represented in terms of the UIML notation. In the second section, the
UIML is represented in terms of the REL notation.
Mapping the REL in Terms of the UIML Notation
It is necessary to construct a data type document (DTD) in order to represent something in the XML. A DTD identifies that “something’s” elements and their attributes. The elements of a DTD define what a parser (also termed a processor) can call in order to compile an executable program. Attributes modify and constrain the elements.
Therefore the first step in defining the REL in terms of the UIML is to identify what relationships are permitted between the entities in the REL; and then to create the DTD that corresponds to these permitted relationships. According to the rules of the REL, only certain entities can be bonded to other entities and only certain bonds can define the relationships between entities. These relationships and their modifiers are first described in a general form and secondly in formal terms of the XML as a DTD.
General Considerations of the REL
As noted, not all possible relationships between the elements in the REL are permitted. Table 5 identifies the permitted relationships. This table summarizes the
79 relationships defined by Davis et al. (1997). The abbreviations and terms used here were created from the full descriptions given by Davis et al.
Table 5. Permitted Relationships in the Requirements Element Language REL Relationships are Permitted FROM these ELEMENTS Ent Pro Msg Prd Cnt Vst Sts Xit Ent Spc Prt Prt Prt Prt Prt Prt Opd T Equ O Pro Prt Spc Prt Prt Stm(up) Prt Stm T Equ Rsp(bot H h) E Msg Prt Prt Opd Opd Opd Stm(up) S Snd Snd Equ Stm E Rcv Rcv Rsp(bot h) E Prd Prt Opd Opd Opd Stm(up) L Equ Stm E Rsp M Cnt Prt Equ Prt E Vst Prt Prt Opd Opd Opd Equ Val Stm(up) N Equ Stm T Rsp(bot S h) Sts Prt Prt Opd Opd Opd Val Spc Prt Equ Xit Stm(down) Stm(down) Stm(down) Stm(down) Equ Stm Stm Stm Stm Rsp(both) Rsp(both) Rsp Rsp(both) Notes: Elements: Ent = entity, Pro = Process, Msg = message, Prd = predicate, Cnt = constraint, Vst = Value (or state), Sts = State -space (or attribute, Xit = Transition Bonds: Spc = specialization, Prt = part-of, Val = has value, Snd = sends, Rcv = receives, Stm = stimulus, Rsp = response, Equ = equivalence, Opd = operand
Table 5 is read from the column to the row. For example, the “Constraint” column intersects the “Value (or state)” row with the value “Opd”. This means the constraint element can have an operand relationship with a value-state element and further that the relationship flows from the constraint element to the value-state element. Table 5 also
80 uses the terms (from Davis et al., 1997) “up” and “down” and “both” as modifiers on the stimulus and response bonds. Davis et al. (1997) created these modifiers to define the nature of stimulus/response relationships.
Table 6 identifies the effects of all modifiers on bonds. These include the extensions to the REL proposed by Miller and Overmyer (2001). The Miller and
Overmyer extensions will be discussed shortly.
Table 6. Meaning of Bond-Arc Modifiers in the Requirements Element Language Bond Meaning When Used With REL Elements
Specialization AND/OR – describes a parent-child relationship between REL entities
Part-of (strong) Element + -> a required relationship Part-of (weak) Element * -> an optional relationship
Has-value Initial value of an element
Sends Sends a flag to indicate something (a message entity) is to be sent. The data are elsewhere defined by a has-value element
Receives As for send
Stimulus (up arrow) Sets a flag. If points to a value-state or message or predicate element -> evaluate “true” Stimulus (up arrow) Sets a flag. If points to a process element -> perform the process Stimulus (down arrow) Sets a flag. If points to a value-state or message or predicate element -> evaluate “false” Stimulus (down arrow) Sets a flag. If points to a process element -> stop performing the Process Stimulus (no arrow) Reads a flag. If points to a value-state element -> If the flag is “true” the value is assumed; if the flag is “false” the value is ignored Stimulus (no arrow) Reads a flag. If points to a message or predicate element -> If the flag is “false”, the message or the predicate is not active. If the flag is “true”, the message or predicate is active and remains so.
81
Table 6. (continued) Bond Meaning When Used With REL Elements Stimulus (no arrow) Reads a flag. If points to a process element -> If the flag is inactive, the process-element is not active. If the flag is active, the process- element is active and remains so. Response (up arrow) Sets a flat. If points to a value-state or message or process element - > evaluate “true” Response (down arrow) Sets a flat. If points to a value-state or message or process element - > evaluate “false” Response (down arrow) Sets a flat. If points to a process element -> process is inactive Response (no arrow) Reads a flag. If points to a predicate element that predicate element status must be “true”. If so, then the action occurs. If evaluates to “false”, no action occurs.
Equivalence Equates one element-name to another element-name.
Operand If points to a message element -> Enables the value-state value to be sent as the content of the message element. Operand (number) If points to a predicate or state -space or value-state element -> Returns the value of the element. The number is the ith state-space pointed to. Notes: Stimulus (up/down/no arrow) The stimulus bond “can connect transition elements to most elements”. Stimulus (up) bonds are triggered by the inception of what they point to. Stimulus (down) bonds are triggered by the completion of what they point to. Stimulus (with no arrow) bonds are triggered by the presence (or truth) of what they point to. Response (up/down/no arrow) The response bond records what needs to occur when a transition fires. There are three types of response bonds just like for stimulus bonds. Response (up) bonds cause the inception of what they point to. Response(down) bonds cause the cessation of what they point to. Response (no arrow) bonds point to something that must be true (i.e., a post-condition).
General Considerations Of the UIML
The UIML uses the semantics and syntax of XML to define itself. Figure 16 is a representative example of a UIML definition. (For clarity, the convention “words like this” represent elements and attributes of the UIML.)
82
name NMTOKEN #IMPLIED
source CDATA #IMPLIED
how (append | cascade | replace) “replace”
export (hidden | optional | required) “optional”>
Figure 16. Example of a UIML Definition
Which means the following
1. An element of type interface is defined to consist of one or more elements of type structure, or one or more elements of type style...
2. Each instance of an interface element has a name attribute defined by NMTOKEN data which exists elsewhere
3. The data content of each instance of an interface element is defined by a source attribute identified by CDATA which exists elsewhere
4. Each instance of an interface element may be created by a how attribute that appends, cascades, or replaces two sets of attribute data together. The replace attribute is the default attribute
5. Each instance of an interface element may be exported by an export attribute as a hidden, optional, or required attribute. The optional attribute is the default attribute
The functionality of ‘how’ and ‘export’ are defined in the UIML parser (i.e., processor). The draft UIML specification explains the how attribute (Phanouriou, 2000a).
The export attribute is not explained.
All element definitions, then, follow this general format: The element type is named and its structure defined using the format from XML. An element’s attributes then are defined using the format. The structure and attributes of an
83
element type and its attributes are indicated as well as how, for each attribute, data will be represented and where they will be found. Figure 17 is the general model of an XML element as used here.
Attribute type Data type Location or Qualification of data>
Attribute type …
Figure 17. Model of an XML Element
There are some general forms, then, that the UIML employs that repeat throughout the language. These consist of the following: the structure of a type or attribute e.g., (structure | style | content | behavior); the hierarchical arrangement of attribute properties and the element instance they modify; and the semantics of specified words e.g., #IMPLIED. These are taken in turn.
The structure of a type or attribute is represented in Extended Backus-Naur Form
(EBNF) notation as used by the XML. The following definitions apply (World Wide Web
Consortium, section 6)
1. “String” matches a literal string matching that inside the quotes. This meaning holds for single as well as double quotes.
2. A B implies A followed by B. Represents a logical AND function namely A AND B
3. A | B implies A or B but not both. Represents a logical XOR function namely A XOR B. In addition, the rule also causes the XOR function to be evaluated from left to right
84
4. A – B implies any string that matches A but does not match B. Represents a logical MINUS function namely A MINUS B. This rule also implies order of evaluation
5. A+ matches one or more occurrences of A. Represents cardinality namely (1, infinity)
6. A* matches zero or more occurrences of A. Represents cardinality namely (0, infinity)
7. A? Matches optional A. Represents cardinality namely (0, 1)
The UIML further makes use of XML definitions for white-space, commas, etc. Thus another definition would be
A, B, C, … implies A or B or C … Represents a logical OR function namely: A OR B OR C…
Cardinality and white-space definitions are important in defining the structure of elements and attributes. In part this is because they permit constructing structures that consist mixes of element types under a single (for example) interface element. As it is clear that in any single UIML document (wherein the term ‘document’ is taken in the sense of an XML-compliant document) there will be only one interface element, it becomes necessary to be able to have mixes of elements beneath it. If this were not the case, then the UIML goal of separating behavior, content, style and structure would not be achieved.
For the second form--hierarchical arrangement of the attributes of an element type--the rules are not so clear. The following rules are derived from the form of an element’s definition in the UIML 2.0e draft specification (Phanouriou, 2000a).
The name of an element type instance is denoted by a name attribute. This name will generally be a link to another element instance in order to achieve the separation of style,
85
content, etc. desired by the UIML. The equal and condition elements do not have name attributes.
Except where an element does not have content, the source of the data content of an instance of an element type is denoted by a source attribute. A source attribute
“specifies a link from the UIML document to a Web resource named by a URL.
(Phanouriou, 2000a)” A URL link in a source element may or may not contain UIML code. Elements that don’t have content are the param, event, action, equal, condition, reference, d-event, d-param, d-attribute, template, meta, and head elements. The meta element has a content attribute that is a literal string about the UIML document.
An element may have one or more attributes that define how it is used or what its
‘visibility’ will be to other elements in a template element. These are the how and export attributes.
Modifiers can be associated with the element or with its attributes. The name attribute, for example, is associated with the element; while the source attribute can be associated with each of the possible elements under an element.
In the abstract, then, an element can have hierarchical elements under it. The interface element, diagrammed subra, is an example of this. Each instance of an element will have a unique name attribute associated with it; while (sub-) elements can have names and data content unique to them. For example, the interface element could have a structure element. One structure (sub-) element can have content (i.e., a source); while another structure (sub-) element under the interface element could have a different source attribute. Similarly, each attribute of an element’s definition can be looked at as to
86 whether it is an attribute of the element or other child elements that are contained within it.
Finally and thirdly, the UIML follows the naming conventions of the XML. It uses the ‘#’ sign to indicate a reserved word recognized by the UIML parser in rendering code.
From these descriptions, the following DTD relates the REL in terms of XML.
The DTD is preceded by an overall description of how the REL is represented in the
DTD. Verification that the mapping is complete has been done by observing that all of the elements and bonds in the REL are in fact defined in the DTD; and that these definitions use the proper XML syntax and semantics in accordance with the discussion above.
Requirements Element Language (REL) Document Type Definition (DTD)
This DTD is not intended to create documents of executable XML code, rather to serve as a bridge between the REL and the XML languages. In the following the computer code font will distinguish XML from exposition.
The general model that will be used is for elements to be identified by their element type and a unique ID. All elements have one or more bonds emanating from/to them. These bonds are themselves connected to other elements. Circular references are possible. For elements, the general model for an element follows as Figure 18.
Figure 18. REL Element Model in UIML
87
There will be a different element-name for each element-type. The tokens following the element-name list all bonds possible for element. The attributes of an element use the general model in Figure 19.
myname ID #REQUIRED
bondID ID #REQUIRED
fromElement ID #REQUIRED
toElement ID #REQUIRED
constraint (one-way | two-way) "one-way"
count ( unicode for 1 thru n) " 1 "
direction (up | down | none) "none"
Figure 20. The REL Model for Bonds in UIML
88
In the following DTD, the symbol “
entityID ID #REQUIRED
90
sourceInfo CDATA #IMPLIED>
entityID ID #REQUIRED
sourceInfo CDATA #IMPLIED>
entityID ID #REQUIRED
sourceInfo CDATA #IMPLIED
entityID ID #REQUIRED
sourceInfo CDATA #IMPLIED>
entityID ID #REQUIRED
sourceInfo CDATA #IMPLIED>
92
entityID ID #REQUIRED
sourceInfo CDATA #IMPLIED>
entityID ID #REQUIRED
sourceInfo CDATA #IMPLIED
parentElement ID #REQUIRED
stateGeneral CDATA #REQUIRED
stateType (general | data | content | continuous | discontinuous |
internal | external | replicable | nonreplicable)>
94
bondID ID #REQUIRED
fromElement ID #REQUIRED
toElement ID #REQUIRED
spcType (restrictive | nonrestrictive) “nonrestrictive”
bondID ID #REQUIRED
fromElement ID #REQUIRED
95
toElement ID #REQUIRED
prtType (strong | weak) >
bondID ID #REQUIRED
fromElement ID #REQUIRED
toElement ID #REQUIRED >
96
bondID ID #REQUIRED
fromElement ID #REQUIRED
toElement ID #REQUIRED >
bondID ID #REQUIRED
fromElement ID #REQUIRED
toElement ID #REQUIRED >
bondID ID #REQUIRED
fromElement ID #REQUIRED
97
toElement ID #REQUIRED
countOpd PCDATA #OPTIONAL >
98
bondID ID #REQUIRED
fromElement ID #REQUIRED
toElement ID #REQUIRED
stmType (up | down | none) >
99
bondID ID #REQUIRED
fromElement ID #REQUIRED
toElement ID #REQUIRED
direction PCDATA “two-way” >
100
Mapping the UIML in Terms of the REL
This section describes the User Interface Markup Language in terms of the
Requirements Element Language. Each element in the UIML is represented in a corresponding REL diagram. Elements in the UIML that call scripts and external files are diagrammed accordingly. The following section describes the general nature of the indirection built into the UIML. Following that a section describes the graphical language of the REL both for elements and for bonds. The graphical modifications proposed by
Miller and Overmyer (2001) are also described in this section. The final section shows the UIML diagrammed in the REL. The formal definition of the REL is found in Davis et al. (1997). The formal definition of the UIML version 2.0e is found in Phanouriou
(2000a). The elements of the REL are shown in the computer code font. The draft specification for the UIML 2.0a (Phanouriou, 2000b) has been used for clarification where necessary.
The Structure of the UIML
Indirection is a key strategy of the UIML. The UIML incorporates the Seeheim model (Green, 1986) by separating application toolkits, external style sheets, external code from other UIML documents. The UIML employs a four-layered indirection structure. Indirection separates structure, behavior (i.e., content, actions, functions) and presentation pieces of a user interface. Indirection also enables the UIML to point to
101 several instances of a platform type enabling, for example, a developer to represent interfaces for successive models of a remote control device for home entertainment systems. Additionally, templates can be included by reference into any UIML document.
This enables families of platforms to share a common interface definition. Figure 21 illustrates how indirection in the UIML is handled between the major elements in the
UIML.
UIML
Interface Element
Style Behavior Structure Content elements elements elements element Document UIML
INTERNAL INTERNAL
INTERNAL Peers <-> element INTERNAL EXTERNAL <-> INTERNAL EXTERNAL <-> EXTERNAL
Presentation Logic elements -> elements with component, classes -> events, methods, properties, including scripts methods,...
INTERNAL INTERNAL <-> <-> EXTERNAL EXTERNAL Documents/ External
EXTERNAL Files EXTERNAL EXTERNAL APPS, defining Toolkits, defining Stylesheets, e.g., CSS, methods etc. do. widgets, e.g., the DSSL e.g., the "HOW" "WHAT" of a part of a method
Figure 21. Indirection in the UIML
102
The interface element in a UIML document is an internal-facing representation of an interface. The interface element principally uses internally recognized names and references. On the other hand peers, style, and content elements reference external representations and hence must recognize external names for these entities and their parts.
There are thirty defined elements in the UIML version 2.0e. Each is diagrammed in the REL in the following section. The order of presentation is consistent with the order of the elements in Phanouriou (2000a) with the root (UIML) element being shown first. The symbols used here in REL representations are given in Tables 7, 8, 9, and 10. Table 7 illustrates the REL elements and table 8 illustrates the REL bonds as defined by Davis et al. (1997). Tables 9 and 10 illustrate the modifications to the REL proposed by Miller and
Overmyer (2001).
Table 7. The REL Element Lexicon REL Element Name and REL Element Meaning Exemplars Name: Entity The “entity” element represents something in the real element system. Represented as a square box with the name of the entity inside it Name: Process The “process” element represents an action, task, function, or activity of the system. Represented as a parallelogram process with the name of the process inside it.
Name: Message The “message” element represents something being moved
103
Table 7. (continued) REL Element Name and REL Element Meaning Exemplars Name: Predicate The “predicate ” element represents an application specific preposition or Boolean operation. Represented by a XOR segmented box. The name of the element is adjacent and
outside of the box. The preposition or Boolean operation is labeled on the left while the number of segments to the right indicates the number of cases or branches. Conditional logic may be shown to the right in parentheses e.g., (0.1) to represent conditional existence. Name: Constraint The “constraint” element represents a relationship that must exist between or among elements. A constraint defines an XOR element (0, inf) assertion. Represented by a segmented box within a box. Otherwise the constraint element is depicted similarly to a predicate element. Name: Value The “value (or states)” element represents an application- [Ralph] [Class List] [Hot] related value or set of values. Represented by double brackets enclosing a value, set of values, or state name. Name: State-space The “state-space (or attribute)” element represents a characteristic or descriptor of another element. Represented as a circle with the name of the state -space or attribute hidden inside of it.
Name: Transition The “transition” element represents the causes and effects XIT of a change in the system. It is represented by the phrase “XIT”
Table 8. The REL Bond-Arc Lexicon REL Bond-Arc Name and REL Bond-Arc Meaning Exemplar Name: Specialization The “specializatio n” bond-arc type represents a parent-child --- spc --- > relationship. The child is a representative example of the parent. Represented by a named arc pointing from the more general to the more specific. E.g., TRUCK ---spc--- > F150 Name: Part-of The “part-of” bond-arc type represents a also represents a ---prt--- > parent-child relationship. The child is a constituent part of the parent. Represented by a named arc pointing from the constituent part to the whole. E.g., STEERING WHEEL --- prt--- > Ford F150. Name: Value The “has-value” bond-arc represents the value given to an --- val --- > element. Represented by an arc that points from the element to the value.
104
Table 8. (continued) REL Bond-Arc Name and REL Bond-Arc Meaning Exemplar Name: Sends The “sends” bond-arc represents the requirement for a ---snd--- > process or entity to make a message element active. Represented by an arc that points to the message element from the element initiating the message. Name: Receives The “receives” bond-arc represents the requirement for a ---rcv--- > process or entity to accept an active message. Represented by an arc that points to the “message” entity from the element receiving the message. Name: Operand The “operand” bond-arc represents a relationship between a ---opd--- > predicate , constraint or message element and its operands. Represented by an arc pointing from the operand to the element. E.g.,
Table 9 shows modifications to the REL to permit the cardinality of an element to be portrayed. Cardinality can be attached to a number of different element types. This table uses an entity type for an example. There are four notations for cardinality in the
UIML. These use the EBNF notations: “?”. “+”, “*” and no (i.e., null) symbol. These four cases represent all possible modifiers that indicate the occurrence of an element in the UIML. The general modification proposed is to indicate cardinality by a parenthetical expression attached to an REL element.
105
Table 9. Modifications to the REL to Show Cardinality Examples of Usage of UIML Explanation of Proposed Modifications Expressions that Use Cardinality (Cardinality can be placed anywhere around the REL element symbol as is graphically convenient so long as it is visually and logically associated with the element it modifies.) “?” Optional 0 or 1 occurrence Case 1. If an element (shown as a labeled box) is optional Ex: (elem1, elem2?) but can only have one example when it does occur, the UIML code would be: And the corresponding REL representation would be element (0,1) 2. “+” Required and repeatable, Case 2 and Case 3. If an entity must or could exist one or 1 or more occurrences more times, the UIML code would be: Ex: (elem1+, elem2?) 3. “*” Optional and repeatable, 0 or more occurrences The corresponding REL representation would be Ex: (elem1+, elem2*) element (1, inf) or (0, inf) 4. “” (no symbol) - exactly 1 Case 4. The fourth case (exactly 1 occurrence) is shown occurrence without any cardinality and the unary occurrence is Ex: (elem1) assumed.
Table 10 shows modifications to the REL to permit the order or existence of an operation to be portrayed. In many graphical notations, there is only a loosely implied order of evaluation. This is generally taken to be from left to right, but this can and often is not followed. In hierarchical representations, the order of hierarchy is generally from top to bottom, but again, there are not universally accepted rules concerning this. Davis et al. (1997) do not specify how the elements and bonds should be arranged in an REL diagram. However, it would be prudent to observe the results of Burton-Jones and Weber
(1999) and try to make REL diagrams as “clear” as possible. Wherever possible, the following convention is used here. Higher ranking elements in a hierarchy are higher up in a diagram. Order of execution is shown from left to right. However, it should be emphasized that there are no specific syntactic rules given by Davis et al.
106
The UIML definition of ELEMENTS is specific as to order and existence whereas in the REL, the sequence that operations occur in is not specifically indicated. Therefore, in order to impose order on REL bonds used to represent the UIML, the modifications and rules in Table 10 have been proposed by Miller and Overmyer (2001).
Table 10. Modifications to the REL to Indicate Order and Existence Examples of Usage of UIML Expla nation of Proposed Modifications Expressions that indicate Order (Order is explicitly indicated by a sequence number and Existence following the bond-arc it modifies) [In the UIML, order is shown in the element definition. These order operators can occur in combinations. They are always evaluated from left to right. There are three cases.] Case 1. “,” Commas separate Case 1. When the UIML enforces order, the order of elements. Enforces existence and evaluation is shown in the REL as a suffix to the bond label. order from left to right For example the following defines the UIML element “the- Ex: (elem1, elem2, elem3) elements”: Each element (elem1 elem2 elem3) is a child of the element “the-elements”. Each is evaluated in order starting with elem1, then elem2, and lastly elem3. In the REL, order of evaluation for bonds uses the following notation: ------prt-w-1---- > Part bonds in REL point from the child to the parent. This notation shows that the child entity this bond emanates from is evaluated first of more than one. Case 2. “|” Vertical bar separates Case 2. Existence is enforced using the predicate element. elements. Enforces existence to Consider the following example of (incomplete) UIML just one of those shown code: (equivalent to XOR) Ex: (element1 | element2 | The template element can occur many times in a UIML element3) document, but each template is only of one element type. In this simplified example, three element types are shown. The corresponding REL notation to represent this UIML code would be:
107
Table 10. (continued) Examples of Usage of UIML Explanation of Proposed Modifications Expressions that indicate Order (Order is explicitly indicated by a sequence number and Existence following the bond-arc it modifies)
TEMPLATE
prt-s
XOR ...
prt-w-1
prt-s
behavior
name ditto val constant, content ... [NMTOKEN]
In this example, there may be many more elements that could be in a template element. The “ditto” expression used here is for presentation convenience. Case 3. The ampersand (“&”) Case 3. When there is no order imposed on the relationships indicates that all elements must between elements, then no additional notation is needed and exist but can occur in any order the third case is assumed. Existence is presumed by (equivalent to OR) existence of the appropriate element in the REL Ex: (elem1 & elem2 & elem3)
108
The Elements of the UIML Diagrammed in the REL
This section shows the elements of the UIML diagrammed in the REL. The initial element in all UIML documents is the “UIML” element. The individual elements are shown first with the UIML definition followed by the corresponding REL diagram.
The UIML Element
The UIML element is the root element of a UIML document. “To create a user interface using the UIML, one writes a UIML document which includes presentation style[s] appropriate for devices on which the UI [user interface] will be deployed. UIML is then automatically mapped to a language used by the target device …(Phanouriou,
2000b, p. 4)” The definition of the UIML element is shown in Figure 22.
Figure 22. The UIML Element
The meaning of this definition is that the UIML element can contain zero or one head element, zero or many template elements, zero or one interface element, and zero or one peers elements. The head, template, interface, and peers elements must occur within the UIML document in the order shown. Figure 23 shows the REL representation of the
UIML element.
109
UIML
prt-w-1 prt-w-2 prt-w-3 prt-w-4
(0,1) (0, inf) (0,1) (0,1) [head] [template] [interface] [peers]
Figure 23. The REL Representation of the UIML Element
The UIML element serves as a container for the rest of the UIML document. In
Figure 23, the order of evaluation is indicated by the suffix to the label “part-of” namely
“prt-w-2”. This indicates that the element (in this case a template element) does not have to be part of the UIML element (i.e., it is a weak relationship), but if one is present, it will occur, and hence be evaluated by a parser, after any head element. The head, template, interface, and peers elements are shown as compound elements. Compound elements are a diagrammatic device to show that there is content within them.
The Head Element
The head element is the first element in a UIML document. The head element is a container for one or more meta elements. The type definition of the head element is shown in Figure 24.
Figure 24. The Head Element in UIML
The type definition of meta elements is shown in Figure 25.
110
name NMTOKEN #REQUIRED
content CDATA #REQUIRED>
Figure 25. The Meta Element in UIML
The meta element contains
…metadata about the UIML document. [In the head element it is possible to] specify metadata using the ‘meta’ tag… similar to the head/meta [tag] from HTML… Usually, one UIML element equates to one file, in much the same that there is one HTML element per file…however, other arrangements are possible. For example, the UIML element might be retrieved from a database, or the elements contained within the UIML element might be stored in multiple files. (Phanouriou, 2000b)
Hence multiple markup vocabularies may be referenced within the same UIML file. These multiple vocabularies are defined (i.e., referenced) by the head element. Figure
26 shows the REL representation of the head and meta elements.
head
prt-s
XOR
prt-w prt-w
meta (0,inf) null prt-s prt-s
val name content [EMPTY] val {val}
[NMTOKEN] [CDATA]
Figure 26. The REL Representation of the UIML Head and Meta Elements
111
The meta element in the head element can occur zero or infinitely many times. The name of each meta element has the value of NMTOKEN while the content (i.e., the pointer to an external file) has the value of CDATA. The meta element could be an empty element--diagrammed as a null state having an EMPTY value.
The Template Element
The template element follows the head element in a UIML document. The type definition of the template element is shown in Figure 27.
Figure 27. The Template Element in UIML
The template element enables reuse of UIML elements. Elements inside a template element can be used “by another element with the same tag.” (Phanouriou, 2000b).
Phanouriou (2000a) wrote the following concerning the template element for version 2.0a of the UIML:
…UIML template [elements] enable interface implementers to design parts or to make their entire UI [user interface] reusable as a component in another UI.... The template element permits several handy shortcuts when writing UIML. It allows (1) one fragment of UIML to be inserted in multiple places of a UIML document; (2) one UIML document to include a UIML fragment from another document; and (3) style and other elements to be cascaded in a manner analogous to the CSS [cascading style sheets] specification.
The template element consists of one or many of one of the following elements: behavior, constant, content, d-class, d-component, interface, logic, part, peers,
112
presentation, property, rule, script, structure and style. A template element cannot contain another template or head element. As only one kind of element may be represented within a template element, it represents an XOR relationship. A UIML document can have multiple template elements. However, each template element points to just one type of element such as behavior, or content, or logic and so forth. There can be multiple examples of each included as separate templates. Figure 28 shows the REL representation of the template element.
TEMPLATE
prt-s
XOR ...
prt-w-1
prt-w
behavior
name ditto val constant, content ... [NMTOKEN]
Figure 28. The REL Representation of the UIML Template Element
In Figure 28, the term “ditto” is shorthand to indicate that the rest of the elements that can be a part of a template element have the same diagrammatic structure as the one shown for the behavior element.
113
The Interface Element
The interface element follows the template element in a UIML document. The definition of the interface element is shown in Figure 29.
name NMTOKEN #IMPLIED
source CDATA #IMPLIED
how (append | cascade | replace) "replace"
export (hidden | optional | required) "optional">
Figure 29. The Interface Element in UIML
This definition is in error as it indicates an XOR relationship between the structure, style, content and behavior elements that may make up an interface element.
That this definition is incorrect is evident when one considers that all of these elements are required to describe an interface. A proposed revised definition is shown below in
Figure 30 and diagrammed as such in Figure 31. This revised definition permits one or more of all of the four elements that makeup the interface element to occur in one UIML document.
name NMTOKEN #IMPLIED
source CDATA #IMPLIED
114
how (append | cascade | replace) "replace"
export (hidden | optional | required) "optional">
Figure 30. The Revised Interface Element in UIML
The interface element describes the basic structure, style, content, and behavior of the interface. The structure element describes the hierarchical arrangement of the objects that constitute the user interface. As different platforms and toolsets may handle the specifics of objects differently, not all elements in an interface may be used by a specific platform’s implementation. Nor may the hierarchical arrangement of objects be possible for a given platform. In this case, a non-hierarchical arrangement of objects would be assumed by the parser. Parsers, then, must be specific to the particular platform user interface the UIML code represents. The style element describes the properties of a user interface, or points to an external document that describes the style (e.g., a cascading style sheet). The content element contains specific text, images, or other media, that constitute the user interface. The content element may also use indirection to point to different content. The constant elements within the content element can be static or dynamic at run-time. Finally, the behavior element contains pointers to operational code for the interfaces. The algorithmic capabilities of the UIML are relatively limited and it was expected by Phanouriou (2000a) that all but the simplest functions performed by the interface would be coded in separate documents specific to particular platforms and styles of interface. This is in keeping with the separation of application code from user interface code as embodied in the Seeheim model. The basic structure of an interface element is shown in Figure 31.
115
Figure 31. Structure of the UIML Interface Element
The REL representation of the interface element is shown in Figure 32.
116
interface
prt-s
OR element (0, inf)
rsp stm rsp [export] XIT stm [export] stm XIT stm stm stm stm [how] source stm [how] source val prt-s [structure] val [EXT] prt-s name [style] CDATA [EXT] name val CDATA val [NMTOKEN] rsp rsp [NMTOKEN]
stm [export] XIT XIT stm stm stm stm stm [how] stm source source [export] stm val val prt-s prt-s [content] [EXT] [EXT] name [how] name CDATA CDATA val val [NMTOKEN] [NMTOKEN] [behavior]
Figure 32. The REL Representation of the UIML Interface Element
In this diagram, as in others, the notation "[EXT]" with "CDATA" indicates a data file external to the UIML. These contain the data that make up the value passed to the source entity. Data passed into the UIML are shown by the notation {val}. Curly brackets indicate a set of values. Plain brackets indicate a single value. The cardinality of the predicate is indicated as a constraint element modified by the nature of that cardinality--
117 in this case "(0, inf)". The REL does not provide for cardinality for entity-elements, however the same notation as for a constraint element is used here.
The Peers Element
The peers element follows the interface element in a UIML document. The definition of the peers element is shown in Figure 33.
name NMTOKEN #IMPLIED
source CDATA #IMPLIED
how (append | cascade| replace) "replace"
export (hidden | optional | required) "optional">
Figure 33. The Peers Element in UIML
Phanouriou (2000a) explains the use of the peers element as follows:
The UIML uses three …[ways to name] … interface parts and events. The first is chosen by the UIML author. The second … is in the style element and maps the mnemonic to an abstract widget name. [This] allows a mapping from one abstract set of names to multiple platforms without modifying the rest of the interface description. Finally, the third name [that is found] in the peers element is part of a toolkit-specific vocabulary and maps the abstract widget name to a name of a widget from the target platform….
Figure 34 shows the REL representation of the peers element.
118
peers
prt-s
XOR
rsp rsp [logic] stm stm [presentation] stm XIT XIT [how] stm stm stm [how] stm stm [export] stm stm
[export]
name source name source
val {val} val {val}
[NMTOKEN] [CDATA] [NMTOKEN] [CDATA]
Figure 34. The REL Representation of the UIML Peers Element
“The peers element provides mappings from interface elements to actual device- specific components that can be rendered (presentation) or executed (logic) (Abrams et al., 1999).” The peers element can only contain presentation elements or logic elements but not both.
The Presentation Element
The presentation element is one of two elements that can be a part of the peers element. The definition of the presentation element is shown in Figure 35.
name NMTOKEN #IMPLIED
119
source CDATA #IMPLIED
how (append | cascade | replace) "replace"
export (hidden | optional | required) "optional">
Figure 35. The Presentation Element of UIML
The presentation element provides the mapping between abstract interface parts and platform dependent widgets. The presentation element has two child elements the d- component and the d-class elements. In a presentation element either a d-class or a d- component element will be found but never both together. The construction of this REL compound is similar to that of the peers element in that it requires at least one of the sub- classes to be present and is itself made up of a collection of lower level compounds and an element which contains the data for the element - in this case defined as CDATA in the external toolkit pointed to by the UIML requirements code. Figure 36 shows the REL representation of the presentation element.
120
presentation
prt-s
XOR (0, inf)
rsp rsp stm stm [export] [export] XIT XIT stm stm stm stm stm stm [how] [how] source source
val prt-s val prt-s [d-component] [d-class] [EXT] name [EXT] name CDATA CDATA val val [NMTOKEN] [NMTOKEN]
"d-class" compound "d-component" compound Figure 36. The REL Representation of the UIML Presentation Element
The D-Class Element
The d-class element can be a part of the presentation element. The definition of the d-class element is shown in Figure 37.
name NMTOKEN #REQUIRED
source CDATA #IMPLIED
how (append | cascade | replace) "replace"
export (hidden | optional | required) "optional"
maps-type (event | method | tag) #REQUIRED
121
maps-to CDATA #REQUIRED>
Figure 37. The D-Class Element in UIML
The d-class element "declares any name used in the 'class' attribute of part and event elements. It declares the interface to classes representing presentation widgets, tabs in a markup language, or events (Phanouriou, 2000b).” If it occurs, the d-class element can occur many times in a presentation element. It consists of two child elements each of which can occur many times together or by themselves. Hence an individual d-class element can have multiple properties and/or events associated with it. The d-class element maps to both a class type and data that define it. The child elements (i.e., d- property and d-event) are REL compounds. Figure 38 shows the REL representation of the d-class element.
122
d-class
prt-s
OR (0, inf)
rsp rsp
stm XIT stm XIT [d-property stm [d-event] stm
stm stm stm stm [maps-type] [maps-type] stm stm source source [export] [export]
prt-s prt-s prt-s prt-s [how] [how]
maps-to name maps-to name {val} {val}
{val} val {val} val
[EXT] [EXT] [NMTOKEN] [NMTOKEN] CDATA CDATA
[EXT] [EXT] CDATA CDATA
Figure 38. The REL Representation of the UIML D-Class Element
The D-Component Element
The d-component element "declares the interface to logic components in the backend (Phanouriou, 2000b).” The d-component can occur many times but has only one child element--the d-method element. Hence a d-component element could refer to a class in an object oriented language or a function in a scripting language. In addition to source
123
CDATA and how and export attributes, the d-component maps to functional code and the location for the method. The definition of the d-component element follows as Figure 39.
name NMTOKEN #REQUIRED
source CDATA #IMPLIED
how (append | cascade | replace) "replace"
export (hidden | optional | required) "optional"
maps-to CDATA #REQUIRED
location CDATA #IMPLIED>
Figure 39. The D-Component in UIML
Figure 40 shows the REL representation of the d-component element.
124
d-component
rsp
d-method stm XIT stm
[export] stm stm stm stm
[how]
location maps-to source val prt-s val prt-s val prt-s [EXT] name [EXT] name [EXT] name CDATA CDATA val CDATA val val [NMTOKEN] [NMTOKEN] [NMTOKEN] Figure 40. The REL Representation of the UIML D-Component Element
The D-Method Element
The d-method element consists of the d-param and script elements. The d-method element describes a "routine that forms part of a component's callable interface (i.e., the component's 'API') (Phanouriou, 2000).” The script child element does not need to be present; but if it is present, only one may be present. The instance where the script child element does not exist (i.e., is not present) is represented by the 'null' state-value element. On the other hand, the d-param element may be present in zero or many instances for one d-method element. The formal definition of the d-method element follows as Figure
41.
125
name NMTOKEN #REQUIRED
source CDATA #IMPLIED
how (append | cascade | replace) "replace"
export (hidden | optional | required) "optional"
maps-to CDATA #REQUIRED
return-type CDATA #IMPLIED>
Figure 41. The D-Method Element in UIML
Figure 42 shows the REL representation of the d-method element.
126
d-method
prt-s
OR (0, inf)
rsp prt-s [how] stm
stm XIT XOR (0, 1) [export] stm
rsp prt-s [how] [d-param] stm stm stm stm prt-s stm XIT null
stm name [export] return-type maps-to val
val stm stm stm {val} {val} [script] [EMPTY] [EXT] [EXT] [NMTOKEN] CDATA CDATA name return-type maps-to
source val {val} {val} prt-s {val} [EXT] [EXT] [NMTOKEN] CDATA CDATA [EXT] CDATA source
{val}
[EXT] CDATA
Figure 42. The REL Representation of the UIML D-Method Element
The D-Event Element
The d-event element "describes an event from the platform (Phanouriou, 2000a).”
It is an event that occurs at the user interface and is made available to the application
127
code or back-end code. In essence it is a flag. The definition of the d-event element is shown in Figure 43.
name NMTOKEN #REQUIRED
type CDATA #IMPLIED>
Figure 43. The D-Event Element in UIML
Figure 44 shows the REL representation of the d-event UIML element.
d-event
prt-s
class
val
[NMTOKEN] Figure 44. The REL Representation of the UIML D-Event Element
The D-Property Element
The d-property element is an element of the d-component element. A d-property element (formerly termed an "attribute" in UIML 2.0d) "associates a specific property with the methods that set and get its value (Phanouriou, 2000a).” Hence, a d-property element has the elements d-method and d-param as child elements. Each or either of these
128
may be present in multiple instances as children of a d-property element. The formal definition of the d-property element is shown in Figure 45.
name NMTOKEN #REQUIRED
maps-type (attribute | getMethod | setMethod) #REQUIRED
maps-to CDATA #REQUIRED
return-type CDATA #IMPLIED>
Figure 45. The D-Property Element in UIML
Figure 46 shows the REL representation of the d-property element.
129
d-property
prt-s
OR (0, inf)
rsp rsp
[maps-type] stm [maps-type] stm stm XIT stm XIT
[d-method] [d-param] stm stm stm stm stm stm
name name return-type maps-to return-type maps-to
val val {val} {val} {val} {val}
[EXT] [EXT] [NMTOKEN] [EXT] [EXT] [NMTOKEN] CDATA CDATA CDATA CDATA
Figure 46. The REL Representation of the UIML D-Property Element
The D-Param Element
The d-param element "denotes either a single formal parameter to a callable routine or attribute in a markup language (Phanouriou, 2000).” The d-param element can be called at most one time for any one d-method or d-property element. The formal definition of the d-param element is shown in Figure 47.
name NMTOKEN #IMPLIED
130
type CDATA #IMPLIED>
Figure 47. The D-Param Element in UIML
Figure 48 shows the REL representation of the d-param element.
d-param
prt-s
type (0, 1)
val prt-s
[EXT] name val [NMTOKEN] CDATA Figure 48. The REL Representation of the UIML D-Param Element
The Script Element
The script element is used to pass data to an “embedded scripting engine
(Phanouriou, 2000a).” The purpose is to make external code available to the parser. The type attribute identifies which scripting language is being used. The formal definition of the script element is shown in Figure 49.
name NMTOKEN #IMPLIED
type NMTOKEN #IMPLIED
source CDATA #IMPLIED
131
how (append | cascade | replace) “replace”
export (hidden | optional | required) “optional”>
Figure 49. The Script Element in UIML
Figure 50 shows the REL representation of the script element.
script
prt-s
prt-s prt-s prt-s
XOR (0, 1)
prt-s prt-s prt-s source name type [export] null {val} val val
[how] [EXT] [NMTOKEN] [NMTOKEN] CDATA Figure 50. The REL Representation of the UIML Script Element
The Logic Element
The logic element can be part of a peers element. “The logic element specifies the connection between the interface and the backend application, including support for scripting (Phanouriou, 2000a).” Through the d-component and d-method elements, the logic element enables complex scripting (i.e., code) to be included in the compiled code specific to a platform. The definition of the logic element is shown in Figure 51.
132
name NMTOKEN #IMPLIED
source CDATA #IMPLIED
how (append | cascade | replace) "replace"
export (hidden | optional | required) "optional">
Figure 51. The Logic Element in UIML
Figure 52 shows the REL representation of the logic element.
logic
rsp
XIT
stm
XOR (0, inf)
prt-s prt-s prt-s
[how] prt-s null
[export]
[d-component] Figure 52. The REL Representation of the UIML Logic Element
The Structure Element
The structure element is the initial element in the interface element. The structure elements "describes the initial logical relationships between the ... parts that
133 comprise the user interface (Phanouriou, 2000a).” The hierarchical arrangement of the parts elements in the structure element is an implicit specification of the relationship in a platform's interface. The parser, however, only renders the hierarchical structure of the specification when the user application, operating system and physical elements of the target platform can accommodate it. Otherwise it is ignored and all part elements are assumed to have equal standing. The definition of the structure element is shown in
Figure 53.
name NMTOKEN #IMPLIED
source CDATA #IMPLIED
how (append | cascade | replace) "replace"
export (hidden | optional | required) "optional">
Figure 53. The Structure Element in UIML
The part child element in the structure element can be included any number of times to define the overall relationships between objects in a user interface. Figure 54 shows the REL representation of the structure element.
134
structure
prt-s prt-s
prt-s source [export] prt-s {val} prt-s
[EXT] name [how] CDATA val (0, inf) [NMTOKEN] [part] Figure 54. The REL Representation of the UIML Structure Element
The Part Element
The part element can consist of none or one each of style, content, or behavior child elements; and none or many other part elements. The part element "describes a conceptually complete component of the user interface (Phanouriou, 2000a).” The part element can refer to other part elements thereby providing for the “part-of” relationship between an object and its component parts. In Figure 56, this recursive relationship can be seen in the “[part]” compound. It is the part element that names the parts of the interface whose structure is defined by the structure element. The definition of the part element is shown in Figure 55.
name NMTOKEN #IMPLIED
class NMTOKEN #IMPLIED
source CDATA #IMPLIED
how (append | cascade | replace) “replace”
135
export (hidden | optional | required) “optional”>
Figure 55. The Part Element in UIML
Figure 56 is the REL representation of the part element.
part
prt-s
prt-s [export] prt-s
prt-s source prt-w [how] val prt-s prt-w [EXT] name [style] (0, 1) prt-w CDATA val [NMTOKEN] [content] (0, 1)
[behavior] (0, 1)
[part] (0, inf) Figure 56. The REL Representation of the UIML Part Element
The Style Element
The style element is used to define the look of a user interface through one or more property elements. The formal definition of the style element follows as Figure 57.
name NMTOKEN #IMPLIED
136
source CDATA #IMPLIED
how (append | cascade | replace) "replace"
export (hidden | optional | required) "optional">
Figure 57. The Style Element in UIML
The style element also, through the property element provides a means for indirectly referring to style sheets of various types (e.g., cascading style sheets). Figure
58 shows the REL representation of the style element.
style
prt-s prt-s
prt-s source [export] prt-s prt-s {val} name [how] val (0, inf) [EXT] [NMTOKEN] [property] CDATA Figure 58. The REL Representation of the UIML Style Element
The Property Element
The property element is used to define the property of a part element. The property can be defined as PCDATA; be referred to elsewhere in a content element; as a reference element; or with a call element. The property element can also refer to another property element. This permits a form of inheritance to be used. The definition of the property element is shown in Figure 59.
137
name NMTOKEN #IMPLIED
source CDATA #IMPLIED
how (append | cascade | replace) "replace"
export (hidden | optional | required) "optional"
part-name NMTOKEN #IMPLIED
part-class NMTOKEN #IMPLIED
event-name NMTOKEN #IMPLIED
event-class NMTOKEN #IMPLIED
call-name NMTOKEN #IMPLIED
call-class NMTOKEN #IMPLIED>
Figure 59. The Property Element in UIML
Figure 60 shows the REL representation of the property element.
138
property
prt-s prt-s
XOR (0, inf) prt-s prt-w [export] prt-s
prt-w prt-w prt-s
prt-s [how] prt-w prt-w prt-s part-name source prt-s [constant] val val {val} {val} [NMTOKEN] [NMTOKEN] [property]
[EXT] event- call-class name CDATA [reference] val val [NMTOKEN] [NMTOKEN] [call] event- class [PCDATA] call-name val
val [NMTOKEN] [NMTOKEN]
Figure 60. The REL Representation of the UIML Property Element
The Reference Element
A reference element refers the parser to a constant element that is defined elsewhere. “A reference [element] may be thought of as a property-get operation, where the property to be read is a constant element defined in the UIML document's content section” (Phanouriou, 2000a). The definition of a reference element follows as Figure 61.
139
constant-name NMTOKEN #REQUIRED>
Figure 61. The Reference Element in UIML
Figure 62 shows the REL representation of the reference element.
reference
prt-s
constant-name
val
[NMTOKEN] Figure 62. The REL Representation of the UIML Reference Element
The Content Element
The content element consists of one or more constant elements. Each constant element specifies a fixed value. Constant elements may be hierarchically structured. The formal definition of the content element is shown in Figure 63.
name NMTOKEN #IMPLIED
source CDATA #IMPLIED
how (append| cascade| replace) "replace"
export (hidden| optional| required) "optional">
Figure 63. The Content Element in UIML
140
Figure 64 shows the REL representation of the content element.
content
prt-s prt-s prt-s [export] prt-s
source [how] val
[CDATA] [constant]
Figure 64. The REL Representation of the UIML Content Element
The Constant Element
The constant element is a means of establishing constant values of a user interface. These values are set at runtime. The definition of the constant element is as shown in Figure 65.
name NMTOKEN #IMPLIED
source CDATA #IMPLIED
how (append | cascade | replace) "replace"
export (hidden | optional | required) "optional"
model CDATA #IMPLIED
141
value CDATA #IMPLIED>
Figure 65. The Constant Element in UIML
The REL representation of the constant element is shown in Figure 66.
constant
prt-s prt-s prt-s prt-s [export] prt-s prt-s model source [how] {val} {val} (0, inf) [CDATA] [CDATA] [constant]
value
{val}
[CDATA]
Figure 66. The REL Representation of the UIML Constant Element
The Condition Element
The condition element permits a rule element to be invoked. The condition element establishes whether some expression is to be equal to another or if an event will occur. It is an implied 'if-then-else' structure in the UIML. Hence the condition element can be read as: IF either the equal or event elements exist (i.e., equate to “true”), THEN the condition element evaluates TRUE (and the rule element is invoked), ELSE do nothing. The definition of the condition element is shown in Figure 67.
142
Figure 67. The Condition Element in UIML
Figure 68 is the REL representation of the condition element.
conition
prt-s
XOR
{val} {val}
[equal] [event]
Figure 68. The REL Representation of the UIML Condition Element
The Equal Element
The equal element equates to either or both of an event or one of the following: a pre-defined constant, a property, or a reference to an external data object. The definition of the equal element is shown in Figure 69.
Figure 69. the Equal Element in UIML
Figure 70 is the REL representation of the equal element.
143
equal
prt-s
OR
{val} {val} XOR
{val} {val} {val} [event]
[constant] [property] [reference]
Figure 70. The REL Representation of the UIML Equal Element
The Event Element
The event element defines the event in terms of the affected part of the interface.
The definition of the event element is shown in Figure 71.
name NMTOKEN #IMPLIED
class NMTOKEN #IMPLIED
part-name NMTOKEN #IMPLIED
part-class NMTOKEN #IMPLIED>
Figure 71. The Event Element in UIML
Figure 72 is the REL representation of the event element.
144
event
prt-s
prt-s name val [NMTOKEN] prt-s
prt-s class val [NMTOKEN]
part-name val [NMTOKEN]
part-class val [NMTOKEN]
Figure 72. The REL Representation of the UIML Event Element
The Behavior Element
The behavior element "…gives one or more rules that specify what action is to be taken whenever an associated condition becomes true (Phanouriou, 2000a).” The condition is specified within the rule invoked. The formal definition of the behavior element is shown in Figure 73.
name NMTOKEN #IMPLIED
source CDATA #IMPLIED
how (append | cascade | replace) “replace”
export (hidden | optional | required) “optional”>
Figure 73. The Behavior Element in UIML
145
Figure 74 is the REL representation of the behavior element.
behavior
prt-s prt-s
prt-s source prt-s [export] {val} val
[how] [EXT] [NMTOKEN] CDATA [rule] (0, inf) Figure 74. The REL Representation of the UIML Behavior Element
The Rule Element
The rule element is associated with two types of conditions (a) whenever some expression is equal to some other expression (i.e., when condition evaluates to TRUE); or
(b) whenever some event is triggered and caught (i.e., when an action occurs and hence evaluates to TRUE). The definition of the rule element is shown in figure 75.
name NMTOKEN #IMPLIED
source CDATA #IMPLIED
how (append | cascade | replace) “replace”
export (hidden | optional | required) “optional”>
Figure 75. The Rule Element in UIML
146
Figure 76 is the REL representation of the rule element.
rule
prt-s prt-s prt-s
prt-s prt-s source XOR (0, 1) [export]
{val} val {val} {val}
[how] [EXT] [NMTOKEN] CDATA [condition] [action] [rule] (0, inf) Figure 76. The REL Representation of the UIML Rule Element
The Action Element
The action element can use any number of either property or call elements with none or one event element. It ties, therefore, property and call elements to an event element. The definition of the action element is shown in Figure 77.
Figure 77. The Action Element in UIML
Figure 78 is the REL representation of the action element.
147
action
prt-s
OR
{val} {val}
XOR (0, inf) [event](0, 1)
{val} {val}
[property] [call]
Figure 78. The REL Representation of the UIML Action Element
The Call Element
The call element references a callable param element. The definition of the call element is shown in Figure 79.
name NMTOKEN #IMPLIED
class NMTOKEN #IMPLIED
transform-name CDATA #IMPLIED
transform-mime CDATA #IMPLIED>
Figure 79. The Call Element in UIML
Figure 80 shows the REL representation of the call element.
148
call
prt-s
prt-s prt-w name val [NMTOKEN] prt-w
prt-s transform- {val} class [CDATA]
[param] (0, inf) transform- {val} mime [CDATA]
class {val} [NMTOKEN]
Figure 80. The REL Representation of the UIML Call Element
The following section maps the attributes of elements into the REL.
Attributes of Elements
Several of the elements are defined using complex attributes that modify how an attribute or element is to be handled by a parser. This section defines these in terms of the
REL. Those attributes that are defined simply as NMTOKEN, #IMPLIED, or CDATA are defined in external files according to the rules of the XML. Parsing these attributes is a function of a UIML parser. Accordingly they need not be mapped to the REL.
The How Attribute
The how attribute is defined by one of the following: "replace", "append", or
"cascade". In the notation (xx|yy|zz) "zz" is taken to mean invoke {xx} XOR {yy} XOR
{zz}. The notation "zz" is the default value. The default state is a null state i.e., there is no property attached to the how attribute.
149
The meaning of “replace”, “append” and “cascade” are mapped after the how attribute. Figure 81 explains these terms further.
XOR STM XIT RSP how
prt-w
AND prt-w prt-w prt-w opd
val null
{ } { } { } { }
"replace" "replace" "append" "cascade"
Where the expressions " { } " are compounds defined as below.
GIVEN: {A} and {B} where {A} is the initial set and operations are performed replacing all or part of the elements in {A} with all or part of the elements in {B}
{ } Means set {A} is deleted; and set {B} is put in its place. Equivalent to "replace" "replace" => {B} NOT {A}
{ } Means all elements in set {A} are retained; and all elements in set {B} are added to the set. Equivalent to "append" "append" => {B} AND {A}
{ } Means all elements in set {A} not found in {B} are retained; and all elements in set "B" are added to the set. "cascade" Equivalent to
"cascade" => {B} AND comp{A}
Figure 81. The REL Representation of the UIML How Attribute
150
The Append Attribute
The append attribute is a logical add operation meaning: include all members of
{B} into {A} and remove duplicates from {B}. It is assumed that an "AND" constraint or predicate in the REL will perform this operation.
Figure 82 shows the relevant sets as {A} and {B} or {file reference to A} and
{file reference to B}. The mixed combinations (e.g., {A} with {file reference to B} and vice versa) are not shown for diagrammatic simplicity. The purpose of the append attribute is to both point to the function and to the external sets which are inputs to the function the form {file reference to A] and {file reference to B] would normally be used as. The same is true for replace and cascade.
append
prt-s
XOR
prt-s prt-s
AND AND
prt-s prt-s prt-s prt-s
{A} {B} {file reference to A} {file reference to B}
Figure 82. The REL Representation of the UIML Append Attribute
151
The Cascade Attribute
The cascade attribute is expressed logically as the complement of {A} over {B}.
Figure 83 expresses two possibilities. The first is when both {A} and {B} are references to internal sets in the UIML; and the second is when the UIML points to external files containing {A} and {B}.
In this mapping, it is assumed that the UIML has or can point to a function that will determine the complement of two sets (i.e., perform the subtraction of {A} from {B} leaving only those elements in {A} that are not in {B}). If this assumption does not hold, then it will be necessary to create entities in the REL that can perform the basic logic functions directly. While the REL can theoretically accommodate reserved processes, this would break the authors’ assumptions of the REL as a meta language.
In order to keep the diagram manageable, there are remaining two possibilities not mapped here. These are where there is {A} over {file reference to B}; and {B} over {file reference to A} (e.g., {A} complement {file reference to B} etc.). Figure 83 means for either form (e.g., {A} or {file reference to A}) that the cascade attribute is defined to be the complement of {A} added to {B}.
152
cascade
opd
xor
prt-s prt-s
AND AND
prt-s prt-s prt-s prt-s
complement {B} complement {file reference to B}
opd-1 opd-2
opd-2 {A} {B} opd-1
{file reference to A} {file reference to B}
Figure 83. The REL Representation of the UIML Cascade Attribute
The Replace Attribute
The replace attribute means to replace all of {B} with all of the elements in {A}
(i.e., {A} NOT {B}). Figure 84 says that when either "NOT" predicate is TRUE (through the XOR predicate), then the replace attribute exists. The value of the resulting set is equal to either {A} NOT {B} or to {file that defines A} NOT {file that defines B}. If neither predicate is TRUE, then the replace attribute does not exist.
153
replace
prt-s
xor
prt-s prt-s
NOT NOT
prt-s prt-s prt-s prt-s {A} {B} {file reference to A} {file reference to B}
Figure 84. The REL Representation of the UIML Replace Attribute
The Export Attribute
The export attribute has three options: hidden, optional, and required. From the context of the UIML 2.0e DTD, this attribute defines whether or not an element of a user interface will be hidden all the time, optionally visible/available, or must be visible/available. The default value (i.e., when no option is explicitly defined) is optional.
Figure 85 shows the REL representation of the export attribute.
154
XOR STM XIT RSP attribute
prt-s
opd-1 opd-2 opd-3 opd-4 name
val
null ["export"] hidden optional required
val val val val
[EXT] "required" [EXT] "hidden" [EXT] "optional" [EXT] "required" Figure 85. The REL Representation of the UIML Export Attribute
The Maps-Type Attribute
The maps-type attribute is two separate attributes with the same name. However, as the set of possible values of each is mutually exclusive, they can be represented as a single REL compound. The evaluation of the XOR predicate ensures only that the correct state value is passed to the particular instance of the maps-type attribute. In no case of the maps-type attribute is there a null (default) value. Figure 86 shows the REL representation of the maps-type attribute.
155
XOR STM XIT
RSP
opd-1 opd-2 opd-3 opd-4 opd-5 opd-6 maps-type
getMe- setMe- event method type attribute thod thod
val val val val val val [EXT] "event" [EXT] [EXT] "type" "getMethod" [EXT] [EXT] [EXT] "attribute" "method" "setMethod" Figure 86. The REL Representation of the UIML Maps-Type Attribute
156
Chapter 5: Data Reduction and Analysis
“… nicely calculated, less or more.” -William Wadsworth
This chapter is in two sections. The first section describes and reduces the data collected from volunteers and expert reviewers in the study. The completed data derived from the study are presented in the second section. This chapter presents quantitative as well as questionnaire data.
Pilot Study Data Reduction
The four measurement types collected from volunteers and reviewers during the study are analyzed and presented here. First the time gathered by the Leap tool from each volunteer has been summarized into the four study categories, namely Overview, Learn,
Create and Correct. The error data are collected and analyzed next after which data from questionnaires completed by volunteers are presented.
Five volunteers finished the study. Of the three categories of notations (UIML,
REL, TEXT), two volunteers fully completed the UIML leg; two fully completed the
TEXT leg, and one fully completed the REL leg. A sixth volunteer completed all of the first three Projects of the REL leg and a reduced version of Project 04. The volunteers are identified herein according to the category of notation that each learned and used to create their representations. Volunteers in the UIML leg are identified as U1 and U2. The volunteers in the REL and TEXT legs are likewise identified as R1 and R2 and T1 and
T2 respectively. Three expert reviewers participated in the study. One reviewer was
157 assigned to each category of notation. These are identified as U Ex, R Ex, and T Ex respectively.
The Leap timing data returned by the volunteers were not, for two volunteers, complete. The first case involved volunteer R2. This volunteer was unable to fully complete the representation of the target device user interface in Project 04 due to constraints imposed by work-related travel. To accommodate this, and in order to provide for two sets of data for each category of notation, this sixth volunteer completed a selected sub-set of the requirements for the device. The data reported for this volunteer, therefore, represents just this selected sub-set. The important point in this volunteer’s results is that the requirements for the revised portion of the device’s functions were
Created by this volunteer; and although this volunteer’s final results cannot be directly related or compared with the results from the other volunteers, the point is that the sixth volunteer was successful in representing the revised elements of the user interface of the
ZEN400 using the REL notation. The second case involved volunteer T2 whose timing data were not complete for Projects 03 and 04. This volunteer’s data will be reported only insofar as data were provided in the volunteer’s Leap Naia file.
Although disappointing in their absence, the missing timing data do not negate the fact that volunteer T2 did in fact complete all four Projects in full and that the reviewer assessed the requirements representation in the TEXT notation to be successful. The purpose of this pilot study being to show that the user view of a system (i.e., the user’s interface for the ZEN400 device) could be represented in a non-user specific notation, successful completion of at least a partial set of the functions remains an important part of the demonstration. This short section describes the reduced set of functions that
158 volunteer R2 completed. This is provided to give a sense of the import of the requirements representations created by this volunteer when considered alongside those of the other five volunteers.
Volunteer R2 was unable to devote an extended period of time to the Project 04
Create and Correct categories of the study. In order to create a sub-set of functions of the device for volunteer R2 to complete, a representative group of functions in the device was sought. Some of the 36 functions of the ZEN400 device are single button functions
(e.g., Rewind, Pause). As the representation of these functions is very straightforward, these were not considered further for volunteer R2. The remaining buttons of the device are used in sequences to accomplish more complex functions. There are six such sequences of multi-button functions. All are associated with “programming” the device.
Accordingly one of these sequences was defined as a subset of functions for volunteer R2 to complete. Table 11 shows all of the functions of the ZEN400 device and identifies those functions represented by the REL requirements representation created by volunteer
R2. The particular group of functions was the sequence of button pushes required to program the ZEN400 to control a TV set.
Table 11. Parsed Functions of the ZEN400 Button or Item Down Up On Off Blink Used by R3 CODE SRCH X X 2 LITE X X X 3 AUX X X 0 TV X X 2 VCR X X 0 CBL X X 0 NUM BUTTONS X (x10) 3 CHAN + X 1 CHAN - X 0 PWR X 0 M(UTE) X 0
159
Button or Item Down Up On Off Blink Used by R3 VOL + X 0 VOL - X 0 PREV CHAN X 0 REW X 0 PLAY X 0 FF X 0 REC X 0 STOP X 0 PAUSE X 0 Totals 28 5 1 1 1 11
Consequently, volunteer R2 was asked to complete an REL representation of 11 functions of the ZEN400. When compared with all functions of the ZEN400, the reduced set of requirements created by volunteer R2 represented 30% (11/36) of all possible functions of the device. While not a complete set of functionality for the ZEN400, this reduced set appeared to be at least representative of the overall functionality of the device and hence a useful sub-set of functions for volunteer R2 to consider.
Volunteer R2 had previously fully completed Project 03 including an initial representation of an REL document for all of the functionality in the ZEN400 (task 3.5 - see Table 14 below). The reviewer of this volunteer’s completed work from Project 03 commented that the initial representation of volunteer R2 was “significantly better’ than was that of the other REL volunteer. This reviewer further commented that the final
(reduced) representation created by volunteer R2 was “effectively laid out with high engineering precision”. Given these observations and that the overall result from volunteer R2 was successful, no additional learning effect, over the learning from Project
03, was assumed in regards to volunteer R2.
160
The aggregate results from the study group are reported in Tables 12 and 13.
Table 12 contains data for tasks 1.1 through 3.3 (task numbers are defined in Table 1
“Study Projects, Phases and DocTypes”).
Table 12. Time Data Time Data In Whole Minutes Shown By Task (Tasks defined in Table 3) Volunteers 1.1 1.2 1.3 1.4 1.5 2.1 2.2 2.3 2.4 2.5 3.1 3.2 3.3 U1 12 2 2 10 29 2 11 18 147 17 U2 17 1 11 15 40 20 12 141 21 R1 35 2 21 10 60 10 11 5 11 34 49 16 R2 36 2 74 137 18 T1 105 1 15 17 15 95 39 22 123 23 T2 58 38 44 12 15 33
Table 13 is the continuation of Table 12. It shows the time reported for tasks 3.4 through 4.5. The times for volunteers R2 and T2 are reported as described above, namely for R2, the time represents time spent in Creating and Correcting the reduced functionality for the ZEN400; while the time for volunteer T2 is blank reflecting the lack of data in that volunteer’s Leap Naia file.
Table 13. Time Data (Continued) Time Data In Whole Minutes Shown By Task (Tasks defined in Table 3) Volunteers 3.4 3.5 3.6 3.7 4.1 4.2 4.3 4.4 4.5 U1 47 49 15 108 62 23 26 U2 43 13 164 129 22 68 49 R1 51 104 55 56 355 90 137 R2 58 107 16 23 109 81 38 72 108 T1 70 89 116 55 26 23 T2 30 24 31 16 17
Missing data are shown as blank. Missing data (except as discussed previously relative to volunteer T2) are from tasks not included in the Overview, Learn, Create and
161
Correct study categories hence their absence had no direct impact on the result of the study. The times shown for volunteer R2 in tasks 4.1, 4.2, and 4.3 are as reported but are shown in italics to indicate they come from this volunteer having completing a reduced set of functions for the ZEN400. Table 14 shows the aggregate time data for each volunteer for each of the four study categories. The Create time for volunteer R2 is the sum of the time this volunteer spent in Creating an initial representation in Project 03 plus the time this volunteer spent in completing a reduced set of requirements in Project
04. As in Table 13, these values are shown in italics.
Table 14. Aggregate Time Data for Study Categories Study Categories (Aggregate time in minutes) Overview Learn Create Correct U1 18 194 157 62 U2 12 163 207 129 R1 34 156 459 90 R2 74 344 216 81 T1 22 193 205 55 T2 15 57 31 Note: Overview = task 3.1 Learn = tasks 3.2 + 3.4 + 3.7 + 4.3 Create = tasks 3.5 + 4.1 Correct = task 4.2
The Categories were formed by isolating just those tasks from Tables 13 and 14 that relate to each. For example, the Overview Category includes the time for just one task (3.1), as this was the only task where volunteers received an overview of the notation they were to use. Likewise the Create Category consists of tasks 3.5 and 4.1. These two tasks were the time spent in creating an initial and final requirements representation respectively. Creating categories in this manner isolated the time volunteers spent
162 learning and using the notations. The Correct category is separated out so results relating to errors found by the study group can be compared to those found by the reviewers.
Error data were gathered by volunteers and by reviewers. Volunteers were directed to perform walkthroughs of their completed requirements representation. When an error was found, they were to switch the Leap tool from timing their walkthrough to timing how long it took to correct the error. At the same time they identified the type of error they were correcting by inserting the appropriate error type in the “Desc” text box of the Leap timer tool. When the error had been corrected to their satisfaction, they then switched the Leap tool back to keeping time for their walkthrough. Volunteers considered four error types. These were Errors of Omission (EOO), Errors of Commission (EOC),
Errors of Understanding (EOU) and Errors of Specification (EOS).
Reviewers evaluated finished requirements representations by each volunteer for errors. As with all software, it is unknowable if volunteers introduced additional errors while “correcting” errors they found. It was realized, after the fact, that a reviewer cannot know the mind of a volunteer, therefore Errors of Understanding cannot be detected by a reviewer and consequently were dropped from the final calculations. This amounted to dropping the one EOU error of all errors reported by volunteers. Error data and means and standard deviations by error type are presented in Table 15. The number of errors reported by volunteer R2 (all of the EOC type) and the REL reviewer are shown in italics for the errors found in the volunteer’s reduced requirements representation set.
163
Table 15. Error Data as Reported by Volunteers and Reviewers Volunteers and Expert Found Error Type Errors U1 U2 R1 R2 T1 T2 Errors of Commission EOC(volunteer) 2 9 2 4 2 1 EOC(expert) 8 90 3 4 0 4 EOC (total) 10 99 5 8 2 5 Errors of Omission EOO (volunteer) 5 0 8 0 2 4 EEO (expert) 10 9 144 1 1 8 EEO (total) 15 9 152 1 3 12 Errors of Specification EOS (volunteer) 0 4 1 0 0 0 EOS (expert) 0 0 6 0 17 9 EOS (total) 0 4 7 0 17 9 Total Errors Total Errors 25 112 164 9 22 26
The reviewer of the UIML leg commented after counting 99 errors that the requirements representation created by U2 had so many additional EOC errors as to be
“uncountable”. Accordingly this result is recorded as the largest number the reviewer did record (viz. 99). The REL reviewer likewise found too many errors to count beyond twelve errors found on the first of twelve REL diagrams finished by volunteer R1.
Accordingly, the number of EOC errors for R1 has been estimated to assume twelve errors per diagram times the number of diagrams created by this volunteer.
The six volunteers’ error data fall into two distinct groupings. The first, termed the successful group, had about 25 errors per volunteer; while the second, termed the unsuccessful group, had overall about five times as many errors. The error data gathered by volunteers and experts come from two outcomes: 1) from an unsuccessful requirements document and 2) from a successful requirements document. The representations created by volunteers U2 and R1 are taken to have been unsuccessful.
164
Successful representations were remarkably similar in outcome showing a range of 22 -
26 errors overall; while unsuccessful representations showed a range of 112 - 164 errors.
The errors of volunteer R2 were considered to represent a successful outcome for the reduced set of functions for which this volunteer created a REL requirements representation.
Discussion of Mapping Data
The results of mapping the REL into and from the UIML; and questionnaires from volunteers are discussed in this section. This is a case study intended to point the way to further research, hence, statistical comparisons will not be made from the pilot study data.
Mapping Study Discussion
The mapping study resulted in a completed set of mappings showing all elements and bonds of the REL as represented in XML code. There are eight elements and nine bonds in the REL. In addition there are a number of modifying labels and notations that have been provided by the developers of the REL (Davis et al., 1997) and by Miller and
Overmyer (2001). These are termed attributes and are provided for in the mappings.
The UIML has approximately 30 element types that can be combined in a variety of syntactically correct ways. Each UIML element type was mapped to a corresponding
REL diagram using the elements, bonds and attributes of the REL. All possible logical
165 forms in the XML’s use of the EBNF were found to be capable of being represented in the REL enabling thereby the representation of all the UIML element types.
Questionnaire Data
Questionnaires in each Project of the pilot study probed volunteers’ knowledge and understanding of the three notations used in this study with an especial focus on the notation each volunteer was using. This was done through the use of open-ended questions about notations. This researcher graded these questions. Answers were categorized ordinally as substantially correct, partially correct/wrong, substantially wrong. In the Project 01 (Proj 01 - familiarization) questionnaire (see also Table 1) there were four such question; in the Project 02 (Proj 02 - familiarization) questionnaire there were nine such questions for the REL and TEXT legs while eight such questions for the
UIML leg; in Project 03 there were two questionnaires the first (Proj 03a - familiarization) questionnaire had eight questions while the second (Proj 03b - problem) questionnaire had five questions; and the final (Proj 04 - problem) questionnaire in
Project 04 had eleven questions. Table 16 shows the count of right/partial/wrong and percent averages for answers from questionnaires returned by volunteers.
Table 16. Knowledge and Understanding Data Questionnaire Volunteers (Right/Partial/Wrong) Avg (%) Type U1 U2 R1 R2 T1 T2 M
Proj 01* 4/0/0 4/0/0 3/0/1 4/0/0 2/1/1 3/4/0 83 Proj 02 8/0/0** 8/0/1 6/1/1** 9/0/0 6/2/1 7/0/2 85 Proj 03a* 6/1/1 6/1/1 4/0/1 4/0/1 4/1/0 78 Proj 03b 4/1/0 1/3/1 4/1/0 5/0/0 3/1/1 4/1/0 70 Proj 04 2/8/1 7/3/1 7/0/4 7/1/3 6/2/3 53 Avg/Vol (%) 75 71 73 89 64 73
166
Questionnaire Volunteers (Right/Partial/Wrong) Avg (%) Notes: * The UIML questionnaire contained a different number of questions Than did the REL and TEXT questionnaires. ** One question not answered
Familiarization questionnaires probed a volunteer’s knowledge and understanding of the overall topics covered in each Project’s overview materials. For Projects 03 and 04, problem questionnaires probed volunteers’ specific understanding of their notation and their requirements representations. The apparent decline in knowledge and understanding will be discussed later.
Reviewers reported their evaluations of the representations created by the volunteers. Reviewers answered questions about each volunteer’s representation in a continuous scale (Table 17). These questions have been summed and averaged. The evaluations show a range of results that tend to support a conclusion that the representations created by volunteers U2 and R1 were not successful when compared to the representations of volunteers U1, R2, T1 and T2.
Table 17. Expert Reviewer Evaluation of Representations Volunteers Evaluations U1 U2 R1 R2 T1 T2 Average (M) 2.78 1.60 1.60 2.30 2.78 2.00
Finally both volunteers and reviewers were asked to assess the readability, understandability and relevance of the explanations of materials provided in the study.
Their responses were summed and averaged across the questions asked. Their responses
167 were on a continuous scale. Reviewer averages within each notation group are summarized in Table 18.
Table 18. Evaluation of Study Materials by Volunteers and Reviewers (U Ex = UIML Expert etc.) Volunteers Reviewers U1 U2 R2 R3 T1 T2 U Ex R Ex T Ex 2.00 2.33 2.44 2.10 1.50 1.86 2.67 2.83 2.44
168
Chapter 6: Results
“… a perfect notation would be a substitute for thought…” attributed to Bertrand Russell
The major research question this research addressed was to show that the user view could be integrated into the system view. This work adopted the REL meta- language as the base representation for system requirements and extended it to accommodate user requirements as well. This was done by mapping and extending the
REL to accommodate the user view specific UIML. This mapping, including the extensions proposed by Miller and Overmyer (2001) now make it possible for users to validate requirements for a system from the user view and in so doing, to ferret out errors in other representations that may be inconsistent with requirements shown in the UIML and hence in the REL. This enables users to now ensure that a user view is consistent with other views of a system (e.g., the database view, the communications interfaces view). This enables all views to be expressed in the notation of choice for other stakeholders.
This study also showed the possibility, in a pilot study, for experienced IT professionals to use the REL notation to model user interface requirements. In so doing, the possibility is opened up to enlarging meta-languages such as the REL to encompass the wider domain of users as well as systems developers. However, this has been only an initial study. Having now shown that the REL is consistent with the UIML and vice versa, it now must be shown if the REL can be used in a practical sense, or if another approach should be taken to include the user view in a system’s requirements
169 representations. This pilot study has shown that there is some expectation that the user view can be represented in the three notations (REL, UIML and TEXT) by IT professionals. This result is further supported by the results from experts who found at least one representation in each of the three notations could be termed successful.
The next part of this Chapter describes some of the specific results of the pilot study and relates them to the study questions posed in Chapter 3.
The pilot study sought to show that the user view could be included in systems requirements, and to show that experienced professionals in the information technology field could learn and use notations to represent user requirements for a system. The study also sought to show the relative difficulty of using each of the three notations. Six volunteers participated in the study. Three experts in requirements analysis and systems engineering evaluated the requirements representations the volunteers created. This section presents how well the three notations perform with each other as found by the pilot study.
A variety of data gathering techniques were used in order to bring understanding to the research questions from a number of directions. Figures 87, 88 and 89 show results of the amount of time and the errors found in all volunteers’ representations. In addition, reviewers were asked to give their opinions as to the value of the requirements documents created by the volunteers. Their results are reported in Figure 90. Overall volunteers exhibited a decline in knowledge and understanding from the beginning of the study to its end. This decline is shown in Figure 91. Selected written feedback from the volunteers is
170 included to enable a fuller picture of the issues surrounding the research question to be gained.
The overall time spent by each volunteer in working the four Projects is shown in
Figure 86. These data do not include time spent by volunteers in filling out questionnaires.
Time Spent By Volunteers
800 700 600 500 CORRECT CREATE 400 LEARN 300 OVERVIEW Time (minutes) 200 100 0 U1 U2 R1 R2 T1 T2 Volunteers
Figure 87. Time Spent by Volunteers in Completing the Four Study Categories (task data from Tables 12 and 13)
The REL notation took volunteers the most time to read and (presumably) to learn. The REL notation was presented to the volunteers in the form of a definitive paper about it (viz. Davis et al., 1997). While sufficient to learn the notation, Davis et al. did not provide the volunteers much beyond a few examples to guide them through the learning process. Similar to the findings of Vessey and Conger (1994), the lack of a more tutorial approach in this material may have contributed to the disparity in the time taken
171 by the REL volunteers to Learn the REL notation when compared with the other volunteers.
While volunteers U1 and U2 have similar backgrounds only one successfully created a requirements representation. Volunteers U1 and U2 spent an almost equivalent amount of time overall in each task when seen together. Volunteer U2 spent over twice as much time as did volunteer U1 in correcting errors. This contrasts with volunteer R2, whose representation was deemed a success by the reviewer; and volunteer R1, whose representation was not. It would appear, then, from these data, that it is easier to represent a user interface’s requirements using a user-view specific notation (e.g., the UIML) than it is using one that is not (e.g., the REL). The time data from the TEXT leg would appear to indicate that the TEXT notation is comparably easy (or difficult) to use as is the UIML notation.
The amount of time spent by volunteers in Learning the notations was determined. Figure 88 shows these results. The data in this figure are taken from Tables
12 and 13 for tasks 3.1, 3.2, 3.4, 3.7 and 4.3. This represents the combination of the
Overview and Learn categories. Each notation is shown as the aggregate time of both volunteers in each category.
172
Time Spent Learning Notations
700 600 500 400 Overview 300 Learn 200
Time (minutes) 100 0 UIML REL TEXT Notation
Figure 88. Time Spent Learning Notations
Figure 89 shows the total errors found in representations. While volunteers U1,
T1 and T2 had approximately the same number of errors, volunteers U2 and R1 had disproportionately more. The errors reported by volunteer R2 are also shown.
Total Errors by Volunteers
180 160 140 120 EOS 100 EOO 80 Errors 60 EOC 40 20 0 U1 U2 R1 R2 T1 T2 Volunteers
Figure 89. Total Errors Found by Volunteers and Reviewers
The average number of errors (i.e., the estimated mean) for volunteers U1, T1 and
T2 taken as a whole was about 25 errors; while the average for U2 and R1 taken together
173 was 138.0. The errors for the representation from volunteer U2 have been conservatively estimated at the number counted even though the reviewer indicated there were many more. The large number of EOCs in the representation by volunteer U2 reflects the fact that this person consistently misused one type of element in the UIML. Each example was counted as a separate error. An alternative way to count these would be to count them as one EOC that occurred many times. Such an approach would mask the degree of error in the final count. Similarly, the errors of omission reported for volunteer R1 are a combination of several error types taken many times. Because of the overall difficulties
1) in determining what constitutes an error and, 2) how many of a particular type of error has occurred, all errors were added together, regardless of type. This enables an overall measure of error to be obtained without regard for deeper issues of error definitions and counting procedures.
Each reviewer evaluated the representations they reviewed overall and for readability, understandability, completeness, consistency and conciseness. In sum, these six characteristics defined how “good” a representation was. These combined evaluations are presented in Figure 90 (data from Table 17).
174
Evaluation of Representations by Reviewers
3 2.8 2.6 2.4 2.2 2 1.8
1=low, 3=high 1.6 1.4 1.2 1 U1 U2 R1 R2 T1 T2 Volunteers
Figure 90. Evaluation of Representations by Reviewers
The average evaluation by reviewers was 2.18 (s = 0.52) on a continuous scale.
Although multiple reviewers did not evaluate each representation, it would appear nonetheless that the reviewers found the representations of volunteers’ U2 and R1 to be less successful than those of the others in the study group as shown by the low evaluations assigned to them.
A possible confounding factor affecting how well the requirements for the
ZEN400 were represented by the volunteers was the degree to which the volunteers felt that the materials supplied for the pilot study were useful. Reviewers and volunteers alike were asked to rate study materials for readability, understandability and relevance to the problem of creating a requirements representation. In comparing the responses from volunteers and reviewers, no difference was found. Accordingly, it is accepted that reviewers and volunteers found materials for the study to be equally useful.
175
Open-ended questions probed volunteers’ knowledge and understanding of the study materials, the notations and their own representations. All six volunteers submitted responses to all questionnaires. Over the five questionnaires, all volunteers showed a steady decline in understanding through the four Projects. The average percent correct answers from these questions are shown in Figure 91. The percent average for each
Project over all volunteers declined from 83% after Project 01 to 53% after Project 04.
The decline in correct answers over the four Projects is not a decline over the same question sets. Consequently statistical inference tests cannot be applied. However, the questions were written to probe similar areas of each of the notations. As a result, the overall decline, which was consistent for all volunteers, represents a decline in understanding increasingly difficult materials across all notations for the four Projects.
This decline may be attributed to the increasing complexity of the materials and the difficulty volunteers experienced in creating the initial and final versions of their requirements document. Such a conclusion is also reflected in the increasing amount of time it took them to Create and Correct their representations when compared with the time spent doing the Overview and Learning categories of the study.
176
Decline in Correct Answers Over All Volunteers for Projects
100 80 60 40 20 0 Average (Right/Total) Proj 01 Proj 02 Proj 03a Proj 03b Proj 04
Figure 91. Knowledge and Understanding of Study Notations by Volunteers
Volunteers were also asked if they would use the notation they worked with in their future professional work. Their responses are useful in determining the value of each notation as seen through the eyes of IT professionals. Responses are summarized below.
Volunteers had a variety of difficulties using the notations they worked with some time in the future. Volunteer U1 simply stated, “I would not use this [UIML] method” and further, “The language employs its own format and structure to modularize the information about the product [the ZEN400]. This makes it easier to generalize about what happens without specifying the physical implementation.” Volunteer U2 found that the UIML would be “somewhat” useful for describing a system. This volunteer wrote,
“The methodology [UIML] was created to save time and effort” to describe “what needs to be in the UI and not how to render it in the UI.”
177
Both UIML volunteers remarked that it was difficult to learn the UIML alone without other help. Both used an iterative method and created the representation in small chunks.
As regards the REL, one volunteer wrote, “I found the notation very tedious to use.” This person “would use a different process [from the reverse engineering approach used in this study] … In the case of building a new system … [I would] start with a requirements step and build the prototype.” And further, “I would prefer to use the UML activity diagrams….”
Another REL volunteer found that it was difficult to “reflect repeated activities
(i.e., loops) … [as] the XIT [element in REL] doesn’t appear to have a repeat modifier.”
This volunteer concluded with this comment about the REL. “[the] REL is good but not sufficient, and as for describing a User Interface, it would require a good deal of effort….
The question is, will others wish to go through the rigor required to do so, and when done will other [sic] be able to review it and agree upon the result.”
As regards the TEXT notation, one volunteer commented that the TEXT notation
“would be moderately helpful … in the future.” Another TEXT volunteer also found the
TEXT notation “moderately” helpful and recommended that, “the addition of simple graphics might aid in display [of the requirements] to decision makers. …[because] graphics can be easier to comprehend [for management] than text alone.” However, when the requirements are to be used by “system designers [then] the text is generally easier to use since the next level of design can be incorporated directly into the preliminary design without gong to very detailed drawings…”.
178
One of the REL volunteers commented that the REL lacked the capability to create recursive relationships. While the notation does not have an explicit mechanism for creating recursion (e.g., a construction akin to if-then-else constructions in formal languages), it can accommodate recursion through the use of the elements and bonds it does have. Accordingly, it was not felt necessary to extend the REL any further. The next section is a discussion of the overall results of this research. It also points to areas of further research brought out by this work.
At the beginning of this study, several research questions were raised concerning notations used to define requirements for systems. Briefly these questions were as follows.
RQ1: Can we create a unified modeling notation that accommodates the user’s view of a system?
The REL and the UIML were chosen as exemplars of each type of notation (non- user view specific, and user-view specific). Two approaches were chosen to show that the user view might be represented simultaneously in non-user view specific and user-view specific notations. The first was to map the REL into the UIML and vice versa; and the second was to conduct a pilot study to show that each approach can be used to describe the user interface requirements (i.e., the user view). The tentative answer, then, is yes, a unified modeling notation is possible and we have shown this by extending the REL and then using it to represent the user view for a system.
RQ2: Can we represent the user view as well as we could using a user-view specific notation as when using a non-user view specific notation?
This question is secondary to the first. The pilot study sought to understand, in relative terms, if the three notation exemplars used could successfully create requirements
179 for a target device. The pilot study was able to show that all three notations are capable of representing the user interface requirements of a target device thereby demonstrating that it is possible to include the user view into notations not specifically created to represent it
(viz. the REL and TEXT). The judgment of the experts who reviewed the completed requirements documents of the volunteers was that indeed the three notations are equally capable of representing the user view regardless of whether a user-specific or non-user specific notation is used. Hence the answer to this question is also yes, it is possible to represent the user view using a number of different notations including those not specifically designed to capture it.
RQ3: Can experienced analysts directly use the new notation reasonably well, or should the meta-notation remain just a “meta-“ notation?
This question flows from the lack of the use of IT professionals in other studies that sought to understand the relative ability of different notations to represent requirements. Although novice systems analysts have been used previously (e.g., Sinha and Vessey, 1997), studies using experienced IT professionals to create requirements for a system have not been reported. By using experienced professionals, many issues of learning and inexperience can be set aside.
Regarding the first question, this work has shown that the REL notation can be mapped into the UIML notation. To do this, it was necessary to develop a number of extensions to the REL notation (Miller & Overmyer, 2001). It was also necessary to correct a logic error in the UIML before a mapping could be completed. In Chapter 4 it was demonstrated that all structures in the UIML could have corresponding structures in the REL and vice versa. The REL was mapped to the UIML by mapping the elements
180 and bonds of the REL into an XML Data Type Document (DTD). As the UIML is a language of the XML, correspondence is shown thereby to the UIML. In practice this would mean that a user view model represented in a UIML DTD would reference the
REL/XML DTD. As all UIML structures can also be represented by specific REL compounds the UIML representation of the requirements for the user model would then, insofar as a notation is capable of representing them, be translatable into the fourteen notations with which the REL is now consistent. Davis et al. (1997) explain that their meta-language (the REL) could not translate all structures from one of the fourteen languages they showed it to be consistent with into any of the other thirteen languages.
What they claim is that structures that are compatible between the fourteen languages can be cross-represented. The results here must be taken in the same light namely that those structures in the UIML user view capable of being represented in one of the fourteen languages under the REL will be represented; and those that cannot will not. This ability to now move an explicit user view model into these fourteen notations is seen as a key and important result of this work. It now becomes possible to cross-validate differing views for a system that includes the user’s view as well.
This study has shown some unexpected results that suggest further work. It appears that the three categories of notations are roughly equally effective in modeling the user view for a software system when effectiveness is measured in terms of the number of errors introduced into the requirements. Even though the REL notation may take more time to learn, the pilot study suggests that requirements expressed using the
REL are comparable with results using the UIML and TEXT notations.
181
The mapping between the REL and the UIML does not mean, as previously discussed, that the mapping will always be represented in another system view language
(e.g., as data flow diagrams). Davis et al. (1997) speaking of system view languages suggested that even though the structures of a, for example, data flow diagram will be translated into another notation, such as a finite state machine, correctly the translated version will only include those elements of a data flow diagram that can be represented by a finite state machine. In other words one notation may not be completely covered by another. And although every element and relationship in the UIML notation can be represented via the REL, this is not to say that every element and relationship in the
UIML could be represented by the REL in a third notation such as a finite state machine.
What can be said is that a practitioner working using one of those fourteen notations with which the REL is consistent, will see as much of the UIML elements and relationships as the notation being used will permit.
This raises a number of interesting issues for further research.
1. What is the impact of cross-validating requirements using different languages for a system’s requirements and its user interface? One approach to addressing this issue would be to show, in a different notation, not just elements and relationships from the UIML that have been represented in this different notation, but also to show the “missing” non-translatable pieces as well. These pieces could be represented in their native UIML form as well as the translated REL form. As the REL is the bridge between all of these notations, reading and understanding it directly would then be something akin to a graphical Esperanto. The REL representation of a UIML DTD then, would be annotated to show the pieces that have been translated into a third notation and those that have not. Further research is needed to determine the nature and effectiveness of this or other approaches.
2. What problems arise when different elements of a system are represented using different languages for the system and for the user interface? While a UIML DTD, which conforms to the Seeheim model
182
(see Green, 1986), is primarily a language to describe the declarative, behavioral, and interactive characteristics of the user view of a system, it is also tied to the system. A UIML DTD, then, will refer to the applications, operating systems and other environmental elements of the system(s) with which its interface(s) will operate. It can therefore be expected that some parts of a UIML DTD will define parts of the environment. Hence the UIML DTD must not only be consistent with the requirements for the user interface, but also consistent with parts of the system that are the responsibility of other practitioners (e.g., databases, networks, attached devices). Research is needed to understand how these intersections of interest can be handled from the point of view of reconciling the notations. How, for example, will the REL handle translating notation “A” into notation “B” when there is a piece that is common to each? Beyond the immediate technical problem of representing common parts in “A” and “B” are issues relating to engineering practices (process), testing strategies and cross-validation of requirements.
The pilot study suggests that while all three notations are capable of representing the user view for a system, the REL notation maybe more difficult to learn and use. There are several issues here that need further research. First is to validate these initial findings; and if they hold up to experimentally extend them to determine when (in what technical areas and with what stakeholders) each is better suited for representing requirements. It is probably, in a practical sense, impossible to study all aspects of the relative value of the three notation paradigms simultaneously. It may, however, be possible by designing sequential integrated experiments, to arrive at a fuller understanding of their relative value using the Central Composite Design proposed by Williges, Williges and Han
(1992).
However arrived at, requirements need to be understood by clients and developers; a conclusion reaffirmed by Procaccino (2002). As van Lamsweerde (2000a) has said already a natural language has to be the starting point for all requirements elicitation and analysis. The question is one of how and through what forms of
183 representations does one then move to a system that satisfies those requirements.
Research is needed, therefore, that maps out what the best approaches for moving from a natural language representation of requirements to more and more formal representations.
The purpose of this study was to show how the user’s view could be integrated into this overall process. But much work remains to ensure that this view is adequately and sufficiently represented from representations to finished systems. The results of this work suggest that the REL/UIML approach to introducing a user model into systems engineering processes may be useful. But further research is needed to support or refute this initial finding.
A practical issue is that of automated tools. Such tools are needed to translate the user view into the variety of notations consistent with the REL is raised by this work. If the views of non-technical users and other like stakeholders are to be integrated into an overall system view, then those views must also be integrated into computer assisted systems engineering (CASE) tools. Such a CASE tool would need to have at least the following characteristics.
1. Ability to translate simultaneously and freely from one notation into any number of other notations.
2. Ability to show areas where one notation (e.g., the user’s view) is not represented in another view.
3. Ability to show the assemblage of areas where pieces of different notations are showing the same thing.
4. Ability to highlight resultant conflicts between common pieces of representations in different notations.
5. Ability to provide disparate teams of stakeholders synchronous and asynchronous techniques for resolving conflicts, remedying areas of
184
incomplete coverage and areas of redundant or unnecessary requirements specification.
Such a CASE tool must be robust across a variety of platforms and expansible to easily incorporate the new and ever changing technologies associated with identifying and capturing the user and system views for new and modified computer systems.
There is plenty of work yet to be done. There are many techniques within each category. We need to determine their relative value so as to put techniques along a continuum stretching from the least to the most formal. We need to be able to define what is meant by the complexity of a notation. We need to be able to move from requirements goals through to prototypes, scenarios and documentation to design with complete understanding. This study has shown it may be possible to do this by using forms that speak to client and developers alike.
185
List of References
1. Abrams, M, Phanouriou, C., Batongbacal, A. L., Williams, S. M., & Shuster, J. E. (1999). UIML: An appliance-independent XML user interface language. Paper presented at Session 5B: Hypertext and Hypermedia of the 8th International World Wide Web Conference, Toronto, Canada. Retrieved March 24, 2000 from http://www8.org
2. Agerholm, S., LeCoeur, P. J., & Reichert, P. E. (1998). Formal specification and validation at work: A case study using VDM-SL. Proceedings of the Second Workshop on Formal Methods in Software Practice (pp. 78-84). Clearwater Beach, FL. New York: ACM Press.
3. Andriole, S. J. (1989). Storyboard prototyping: A new approach to user requirements analysis. Wellesley, MA: QED Information Sciences, Inc.
4. Antón, A. I., Carter, R. A., Dagnino, A., Dempster, J. H., & Siege, D. F. (2001). Deriving goals from a use-case based requirements specification. Requirements Engineering, 6, 63-73.
5. Antón, A. I., & Potts, C. (1998). The use of goals to surface requirements for evolving systems (pp. 157-166). Proceedings of the 20th International Conference on Software Engineering, Kyoto, Japan. Los Alamitos, CA: IEEE Computer Society.
6. Artim, J., van Harmelen, M., Butler, K., Gulliksen, J., Henderson, A., Kovecevic, S., et al. (1998). Incorporating work, process and task analysis into commercial and industrial object-oriented systems development. ACM SIGCHI Bulletin, 30 (4), 33-36.
7. Barnard, P., May, J., Duke, D., & Duce, D. (2000). Systems, interactions, and macrotheory. ACM Transactions on Computer-Human Interaction, 7 (2), 222-262. New York: ACM Press.
8. Bellin, D., & Simone, S. S. (1997). The crc card book. Reading, MA: Addison-Wesley.
9. Belz, F. C. (1986). Applying the spiral model: Observations on developing system software in ada (pp. 57-66). Proceedings of the Fourth Annual National Conference on Ada Technology, March 19-20, Atlanta, GA.
10. Boehm, B. (1988). A spiral model of software development and enhancement. IEEE Computer, 5, 61-72.
11. Boehm, B., Bose, P., Horowitz, E., & Lee, M. (1995) Software requirements negotiation and renegotiation aids: A theory-W based spiral approach. Proceedings of the 17th International Conference on Software Engineering. Incremental Requirements Engineering (pp. 243-253) Seattle, WA. New York: ACM Press.
186
12. Boehm, B., & Egyed, A. (1998). Software requirements negotiation: Some lessons learned. Proceedings of the 20th International Conference on Software Engineering (pp. 503-506) Kyoto, Japan. Washington, DC: IEEE Computer Society.
13. Boehm, B., Egyed, A., Kwan, J., Port, D., Shah, & Madachy, R. (1998). Using the win win spiral model: A case study. IEEE Computer, July 1998, 33-44.
14. Boehm, B., & Sullivan, J. (2000). Software economics: A roadmap. Proceedings of the 22nd International Conference on Software Engineering. Conference on the Future of Software Engineering (pp. 319-343) Limerick, Ireland. New York: ACM Press.
15. Booch, G., & Rumbaugh, J. (1995). Unified method for object-oriented development (Documentation set version 0.8). Santa Clara, CA: Rational Software Corporation.
16. Booch, G., Rumbaugh, J., & Jacobson, I. (1999). The unified modeling language user guide. Reading, MA: Addison-Wesley.
17. Brooks, F. K., Jr. (1995). The mythical man-month: Essays on software engineering (Anniversary Edition). Reading, MA: Addison-Wesley. (Original work published 1975)
18. Burton-Jones, A., & Weber, R. (1999). Understanding relationships with attributes in entity-relationship diagrams. Proceedings of the 20th International Conference on Information Systems (pp. 214-228), Charlotte, NC. Atlanta, GA: Association for Information Systems.
19. Coad, P., & Yourdon, E. (1990). Object-oriented analysis. New Jersey, Englewood Cliffs: Prentice-Hall Inc.
20. Coakes, J. M., & Coakes, E. W. (2000). Specifications in context: Stakeholders, systems and modeling of conflict. Requirements Engineering: 5, 103-113.
21. Darimont, R., & van Lamsweerde, A. (1996). Formal refinement patterns for goal- driven requirements elaboration. ACM SIGSOFT Software Engineering Notes: 21 (6), 179-190.
22. Davis, A. M. (1993). Software requirements: Objects, functions, & states (Ref. ed.). Upper Saddle River, NJ: Prentice Hall PTR.
23. Davis, A. M., & Jordan, K. A. (1990, September). Requirements engineering metamodel: A unified view of requirements (Draft technical report: COMPASS Contract 90-CSN-001). George Mason University, Center for Software Systems Engineering, School of Information Technology and Engineering. Fairfax, VA.
24. Davis, A. M., Jordan, K., Nakajima, T. (1997). Elements underlying the specification of requirements. Annals of Software Engineering: 3, 63-100.
187
25. Davis, A., Overmyer, S., Jordan, K., Ceruso, J., Dandashi, F., Dinh, A., et al. (1993). Identifying and measuring quality in a software requirements specification. Proceedings of the 1st International Software Metrics Symposium, Baltimore MD (pp. 141-152). Los Alamitos, CA: IEEE Computer Society Press.
26. Dawson, L., & Swatman, P. (1999). The use of object-oriented models in requirements engineering: a field study (pp. 260-273). Proceedings of the 20th International Conference on Information Systems, Charlotte, NC. Atlanta, GA: Association for Information Systems.
27. DeMarco, T. (1979). Structured analysis and system specification. Englewood Cliffs, NJ: Prentice Hall, Incl
28. Duke, D. J., Barnard, P. J., Duce, D. A., & May, J. (1998). Syndetic Modeling. Human-Computer Interaction: 13 [4], 337-393.
29. Duke, D., Fields, B., & Harrison, M. D. (1999). A case study in the specification and analysis of design alternatives for a user interface. Formal Aspects of Computing. 11, 107-131.
30. Duke, D. J., & Harrison, M. D. (1995a). Event model of human-system interaction. Software Engineering Journal: 1, 3-12.
31. Duke, D. J., & Harrison, M. D. (1995b). Mapping user requirements to implementations. Software Engineering Journal: 1, 13-20.
32. Finkelstein, A., & Kramer, J. (2000). Software engineering: A roadmap (pp. 3-22). Proceedings of the Conference on the Future of Software Engineering, Limerick, Ireland. New York: ACM Press.
33. Garlan, D. (2000). Software architecture: A roadmap (pp. 91-101). Proceedings of the Conference on the Future of Software Engineering, Limerick, Ireland. New York: ACM Press.
34. Gemino, A., & Wand, Y. (1997). Empirical comparison of object-oriented and dataflow models (pp. 446-447). Proceedings of the 18th International Conference on Information Systems. Atlanta, GA: Association for Information Systems.
35. Goldfarb, C. F., & Prescod, P. (2001). The XML Handbook (3rd ed.). Upper Saddle River, NJ: Prentice Hall PTR.
36. Grady, R.B. (1997). Successful software process improvement. Upper Saddle River, NJ: Prentice Hall PTR.
37. Green, M. (1986). A survey of three dialogue models. ACM Transactions on Graphics: 5 (3), 244-275.
188
38. Greenspan, S., Mylopoulos, J., & Borgida, A. (1994). On formal requirements modeling languages: RML revisited. Proceedings of the 16th International Conference on Software Engineering (pp. 135-147), Sorrento, Italy. Los Alamitas, CA: IEEE Computer Society Press.
39. Hooks, I. (2000). Requirements engineering: Is it ‘mission impossible’? Requirements Engineering: 5, 194-197.
40. Humphreys, W. (1995). A discipline for software engineering, New York: Addison- Wesley Inc.
41. In, H., Boehm, B., Rodgers, T., & Deutsch, M. (2001). Applying win win to quality requirements: A case study (pp. 555-564). Proceedings of the 23rd International Conference on Software Engineering, Toronto, Ontario, Canada. Washington, DC: IEEE Computer Society.
42. Jacobson, I., Christerson, M., Jonsson, P., & Overgaard, G. (1992). Object-oriented software engineering. Reading, MA: Addison-Wesley Publishing Company.
43. Jacquot, J. P., Quesnot, D. (1997). Early specification of user-interfaces: Toward a formal approach (pp. 150-160). Proceedings of the 19th International Conference on Software Engineering, Boston MA. New York: ACM Press.
44. Jarke, M., Bui, X. T., Carroll, J. M. (1998). Scenario management: An interdisciplinary approach. Requirements Engineering: 3, 155-173.
45. Johnson, J. (2000). Textual bloopers. Interactions: 7 (5), 29-48.
46. Jordan, K., & Davis, A. M. (1991). Representing multiple requirements techniques: A final report. University of Colorado at Colorado Springs, CO.
47. Kachigan, S. K. (1986). Statistical analysis: An interdisciplinary introduction to univariate and multivariate methods. NY: Radius Press.
48. Kavalki, E. (2002). Goal-oriented requirements engineering: A unifying framework. Requirements Engineering: 6, 237-251.
49. Kay, M. (2001). XSLT Programmer’s reference, 2nd Edition. UK, Birmingham: Wrax Press Ltd.
50. Kelly, J.C., Sherif, J.S., & Hops, J. (1992). An analysis of defect densities found during software inspections. Journal of Systems Software, 17, pp. 111-117
51. Kilov, H. (2001). Back to basics (2nd Ed.). Requirements Engineering: 6, 200-203.
52. Kirwan, B. & Ainsworth, L. K. (1992). A guide to task analysis. London: Taylor and Francis.
189
53. Kobryn, C. (2000). Modeling components and frameworks with UML. Communications of the ACM: 43 (10), 31-38.
54. Kösters, G., Six, H., & Winter, M. (2001). Coupling use cases and class models as a means for validation and verification of requirements specifications. Requirements Engineering: 6, 3-17.
55. Lang, M., & Duggan, J. (2001). A tool to support collaborative software requirements management. Requirements Engineering: 6, 161-172.
56. Lausen, S., & Vinter, O. (2001). Preventing requirement defects: An experiment in process improvement. Requirements Engineering: 6, 37-50.
57. Lehman, M. M. (1991). Software engineering, the software process [sic] and their support. Software Engineering Journal, 6 (5), 243-258.
58. Leite, J. C. S. P., Hadad, G. D. S., Doorn, J. H., & Kaplan, G. N. (2000). A scenario construction process. Requirements Engineering: 5, 38-61.
59. McConnell, S. (1993). Code complete: A practical handbook of software construction. WA, Redmond: Microsoft Press.
60. Menzies, T., Powell, J., & Houle, M. E. (2001). Fast formal analysis of requirements via “topoi diagrams” (pp. 351-400). Proceedings of the 23rd International Conference on Software Engineering, Toronto, Canada. Washington, DC: IEEE Computer Society.
61. Miller, R. R., & Overmyer, S. P. (2001). Deriving the “user view” from analysis and design models of requirements (pp. 61-69). Proceedings of the 2001 AWRE 2001, Sydney, Australia.
62. Moore, C. A. (1999). Teaching software engineering skills with the leap toolkit (ICS- TR-12). Retrieved January 224, 2000, from University of Hawaii, Department of Information and Computer Science Web site: http://csdl.hawaii.edu/techreports
63. Myers, B. A., & Rosson, M. B. (1992). Survey on user interface programming. Proceedings of CHI ’92 (pp. 195-202). New York: ACM Press.
64. Mylopoulos, J. (1980). A perspective for research on conceptual modeling. Proceedings of the 1980 workshop on data abstraction, databases and conceptual modeling, Pingree Park, CO. New York: ACM Press.
65. Mylopoulos, J., Chung, L., & Yu, E. (1999). From object-oriented to goal-oriented requirements analysis. Communications of the ACM, 42 (1), 31-37.
66. Nixon, B. A. (1998). Managing performance requirements for information systems (pp. 131-144). Proceedings of the 1st International Workshop on Software Performance. New York: ACM Press.
190
67. Norman, D. (1983). Design principles for human-computer interfaces (pp. 1-10). Proceedings of 1983 Conference on Human Factors in Computing Systems. New York: ACM Press.
68. Nuseibeh, B., & Easterbrook, S. (2000). Requirements engineering: A roadmap (pp. 35-46). Proceedings of the Conference on the Future of Software Engineering, Limerick, Ireland. New York: ACM Press.
69. Nuseibeh, B., Kramer, J., & Finkelstein, A. (1993). Expressing the relationships between multiple views in requirements specification. Proceedings of the 15th International Conference on Software Engineering (pp. 187-196), Baltimore, MD. Los Alamitos, CA: IEEE Computer Society Press.
70. Parnas, D. L., & Weiss, D. M. (1985). Active design reviews: Principles and practices (pp. 132-136). Proceedings of the 8th International Conference on Software Engineering, London. Los Alamitos, CA: IEEE Computer Society Press.
71. Phanouriou, C. (2000a). A device-independent user interface markup language. Unpublished doctoral dissertation, Virginia Polytechnic Institute, Blacksburg, VA.
72. Phanouriou, C. (Ed.). (2000b). User interface markup language (UIML) draft specification (Language version 2.0a). Universal Interface Technologies. Retrieved January 7, 2000, from http://www.uiml.org/specs/uimll12/DraftSpec.htm
73. Potts, C. (1995). Using schematic scenarios to understand user needs (pp. 247-256). Proceedings of Conference on Designing Interactive Systems: Processes, Practices, Methods, & Techniques (DIS 95). New York: ACM Press.
74. Preece, J., Rogers, Y., Sharp, H., Benyon, D., Holland, W., & Carey, T. (1994). Human-computer interaction. MA, Reading: Addison-Wesley Publishing Company.
75. Pressman, R. S. (1997). Software engineering: A practitioner’s approach (4th ed.). New York: McGraw-Hill Companies, Inc.
76. Procaccino, J. D. (2002). Quantitative models for early prediction of software development success: A practitioner’s perspective. Unpublished doctoral dissertation, Drexel University, Philadelphia, PA.
77. Ravid, A., & Berry, D. M. (2000). A method for extracting and stating software requirements that a user interface prototype contains. Requirements Engineering: 5, 225- 241.
78. Robson, C. (1993). Real world research: A resource for social scientists and practitioner-researchers. Cambridge, MA: Blackwell.
79. Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., & Lorensen, W. (1991). Object- oriented modeling and design. Englewood Cliffs, NJ: Prentice-Hall Inc.
191
80. Shafer, J. B. (1999). Comment from the editor. Ergonomics in Design. April, 3.
81. Shumskas, A. F. (1991). Certification of production-representative/production software-intensive systems for dedicated test and evaluation. IEEE AES Systems Magazine, September 1991, 9-14.
82. Sim, E. R., Forgionne, G., & Nag, B. (2000). An experimental investigation into the effectiveness of OOA for specifying requirements. Requirements Engineering: 5, 199- 207.
83. Sinha, A. P., & Vessey, I. (1999). An empirical investigation of entity-based and object-oriented data modeling: A development life cycle approach (pp. 229-244). Proceedings of the 20th International Conference on Information Systems, Charlotte, NC. Atlanta, GA: Association for Information Systems.
84. Soffer, P., Golany, B., Dori, D., & Wand, Y. (2001). Modeling off-the-shelf information systems requirements: An ontological approach. Requirements Engineering: 6, 183-199.
85. Sommerville, I. (1996). Software process models. ACM Computing Surveys: 28 (1), 269-271.
86. Sommerville, I. (2001). Software engineering (6th ed.). New York: Addison-Wesley.
87. Spanoudakis. G., & Finkelstein, A. (1997). Reconciling requirements: A method for managing interference, inconsistency and conflict. Annals of Software Engineering, 3, 3- 23.
88. Sproull, N. L. (1995). Handbook of research methods: A guide for practitioners and students in the social sciences (2nd Ed.). Metuchen, NJ: The Scarecrow Press, Inc.
89. Sun, J., Dong, J.S., & Wang, H. (2001). Object-Z web environment and projectsions to UML (pp. 725-734). Proceedings of the 10th International Conference the International World Wide Conference, Hong Kong. New York: ACM Press.
90. Sutton, D. C. (2000). Linguistic problems with requirements and knowledge elicitation. Requirements Engineering: 5, 114-124.
91. Sybex Inc. (1999). HTML complete. CA, Alamida: Sybex Inc.
92. Van Lamsweerde, A. (2000a). Formal specification: A roadmap (pp. 147-159). Proceedings of the Conference on the Future of Software Engineering, Limerick, Ireland. New York: ACM Press.
93. Van Lamsweerde, A. (2000b). Requirements engineering in the year 00: A research perspective (pp. 5-19). Proceedings of the Conference on the Future of Software Engineering, Limerick, Ireland. New York: ACM Press.
192
94. Van Lamsweerde, A. & Letier, E. (1998). Integrating obstacles in goal-driven requirements engineering (pp. 53-63). Proceedings of the 20th International Conference on Software Engineering, Kyoto, Japan. Washington, DC: IEEE Computer Society.
95. Verner, J. M. & Cerpa, N. (1997). Prototyping: Does your view of its advantages depend on your job?. Journal of Systems Software: 36, 3-16.
96. Verner, J.M., Overmyer, S.P., & McCain, K.W. (1999). In the 25 years since the mythical man-month what have we learned about project management. Information and Software Technology: 41 (14), 1021-1026.
97. Vessey, I., & Conger, S. A. (1994). Requirements specification: Learning object, process, and data methodologies. Communications of the ACM: 37 (5), 102-113.
98. Williges, T.C., Williges, B.H., & Han, S.H. (1992). Developing quantitative guidelines using integrated data from sequential experiments. Human Factors, 34(4), 399- 408.
99. Wood, L. E. (1997, March/April). Semi-structured interviewing for user-centered design. Interactions: 48-61.
100. World Wide Web Consortium, (n.d.). Extensible markup language (XML) 1.0. Retrieved January 16, 2001, from http://www.xml.com/axml/target.html
101. Yaday, S. B., Bravoco, R. R., Chatfield, A. T., & Rajkumar, T. M. (1988). Comparison of analysis techniques for information requirement determination. Communications of the ACM: 31 (9), 1090-1097.
102. Yourdon, E. (1999). Object-oriented systems design: An integrated approach. Upper Saddle River, NJ: Prentice Hall PTR.
193
Appendix A: Study Materials and Questionnaires
Projects 01 Materials
Volunteers performed Projects 01 and 02 together and in sequence. The materials from Project 01 are provided here as an example of the approach taken in providing task scripts to volunteers. Volunteers were provided with an Overview and tasking document that told them about the study and how to proceed. They were provided Leap files that had Projects, Phases, and DocTypes for the entire study already entered into them. They were provided electronic files of reference/reading materials (not included herein).
Finally they were provided questionnaire files to be completed and returned after each project had been completed. The second section of this Appendix contains additional questionnaires for Projects 01 through 04.
Project 01- LEAP Familiarization
Prologue : In this first project, of four projects, you will install and practice using the LEAP toolset. This toolset is a semi-automatic way for you to keep track of the time you spend on the various phases of each project in this Study. You will be going to the website where the toolset is stored and downloading a copy of the toolset appropriate to your operating system. The toolset is free-ware so you don’t need to worry about paying for anything. After you have installed and configured the LEAP toolset, you will do a short tutorial with LEAP to familiarize yourself with those tools you will use throughout this Study.
194
So basically you are doing two things this in this project:
1. Downloading and installing the LEAP toolset
2. Completing a short tutorial on the LEAP tools you will use throughout this Study
The overall study consists of completing four Projects. The first two Projects familiarize you with LEAP and with the specific device we will be creating a requirements representation for. The last two projects ask you to learn a specific requirements representation method and to apply it to the specific device we are working with.
The device we will be using is a multi-function remote device commonly used to control TVs, VCRs, and other multi-media devices.
You will be representing a subset of the requirements for the device. You will be working with one of three possible methods the Study is considering. These methods are first a graphical method, second an XML language method, and third a textual method.
Terminology: We will be using a variety of unfamiliar terms and concepts. This section will get you started on terms used in this first Project.
Term Definition LEAP Lightweight, Empirical, Anti-measurement dysfunction, and Portable software - (don’t blame me I didn’t make this one up!) LEAP Website http://csdl.ics.hawaii.edu/Tools/LEAP/LEAP.html Project In LEAP, a project is a high level group of activities Phase In LEAP, a phase is a sub-section or part of a Project DocType (Also Document Type) is a table that collects timing data. Can be used in more than one Project or Phase Controller The window in LEAP that gives you access to all of the other tables Io The “Timer” and the window that starts and stops the clock on your activities. Works similar to a tape recorder: start/stop/pause. Also
195
Term Definition has a SAVE function to save the time you have captured while you work. Io is the Hawaiian word for “Hawaiian Hawk”. It is pronounced “EE-oh) Naia The “Times” window is a tabular presentation of timing data gathered using Io. You use Naia to manually enter times and edit existing data. You will use Naia to manually enter the time it takes you to download and configure the LEAP toolset. After that you should not need to access this tool. Naia is the Hawaiian word for “Porpoise”. It is pronounced “Nah-EE-ah” (notice in Hawaiian that all vowels are pronounced individually) Questionnaire Elsewhere questionnaires are uncomplicated affairs asking yes/no or choose-from-a-list sorts of questions. Because our purpose is to more actively probe your work, more probing questions requiring you to explain your reasoning or approach will be asked. Study The term Study (as capitalized here) refers to this field study of different ways to represent the user interface for a system User Interface (also UI) Refers to the human to machine functions. Encompasses the physical and virtual “widgets” used that permit a person to interact with the system. In this first Project we’ll be looking at the LEAP UI and some of the functionality within the LEAP toolset Representation In this Study, the term “representation” stands for an instance or realization of the requirements for a system. Hence, if I write down that, “The system shall be capable of being turned on and off from a front panel”, I have “represented” a requirement in a textual format. You will create a representation of a system in one of three methods. Requirement Requirements are representations of what a system is, what it does, and how it does the things it does.
Methodology: We will follow a fairly consistent methodology for each of the four Projects in the Study. Each Project will consist of two or more Phases. Each Phase is a self-contained entity in itself. Each Phase will have DocTypes to be used for capturing the time(s) it takes you to complete the parts of each Phase (more on this later).
In all Phases and for all activities in this Study, you will use the Io timing tool in
LEAP to capture how long you spend doing them. The keeping of this timing data is a critical element in the Study methodology. Without it, the Study will fail. So I ask here
196 for your slavish devotion to capturing these times as we move through the four projects of the Study.
Here is the over-all approach to the Projects.
Each Project will have an overall set of directions and terminologies to guide you through the rest of the Project. What you are reading now is that set of directions for this first Project.
Each Project will have specific written materials to teach you certain things and skills you will need in completing the rest of the Project. For example, this Project will start off by having you learn about the LEAP tools you will be using.
Each Project will have a Tutorial or an Example problem to be worked that utilizes the information you have just learned about. For example, after you have launched the LEAP toolset, you will be capturing some data concerning a small memo- writing task [note: this was later deleted].
And each Project will have one or more Questionnaires to probe your just completed work. There is a Final Questionnaire at the end of the fourth (and last) phase that will cover your whole participation in the Study.
Each Phase in a Project is individually provided as an appendix to this, the overview. Hence, for this project, as it has three Phases, has three appendices that give you directions for each Phase in turn.
197
The three Phases for this Project are listed in this next table. The table shows each phase and the DocTypes you will be using in a phase. In later Projects, you may be re- using some Doctypes (but not in this Project)
Project 1 Phases Document Types Comments or Explanations LEAP Installation Installing LEAP An introductory Phase to get us going. You will be downloading LEAP and installing the configuration files I have provided you for this Study LEAP Tutorial Using Io A quick tutorial to familiarize yourself Using Naia primarily with the Io “timer”. Using Controller LEAP LEAP Questionnaire Questions about this Project Questionnaire
Materials : Besides this overview, you have been provided the LEAP configuration files. These files are needed to configure LEAP with the proper Project,
Phase, and DocType information. After you have downloaded LEAP and installed it on your computer, you will place these files inside the “Leap” folder.
Projects
Times
You will also go to the LEAP website where you will find basic information about the LEAP toolset. This website also has a pointer to a publications library of online papers. Many of these papers are about LEAP, its design, implementation, and validation.
It also has several papers on why a tool like LEAP is valuable to systems and software designer communities.
198
Lets Get Started!: Proceed now to Appendix 1A - “Phase 1a - LEAP
Installation”
______
Project 01 - Appendix 1A “Leap Installation”
On a separate sheet of paper write down the time in hh:mm:ss right now - you will use this later to determine how much time you spend on this part of the Project. Label this time as “Installing LEAP”. As LEAP isn’t yet installed, we have to keep the time manually and enter it into the Naia tool later on in the LEAP Tutorial.
Go to the LEAP site - http://csdl.ics.hawaii.edu/Tools/LEAP/LEAP.html
Scroll down to a heading “Documentation” and click on “Reflective Software
Engineering With the LEAP Toolkit”. You will be taken to a page that shows an interactive Table of Contents
In the Table of Contents, scroll down to Chapter 3 “Introduction to Time
Recording” and read the entire chapter. You want to understand three things:
How to invoke (i.e., bring up or launch) and use the real-time recording tool - Io
How to invoke and use the effort manual editing and time entry tool - Naia
Understand the concepts of Projects, Phases, Document Types
Now return to the Table of Contents (use the back arrow on your browser) and scroll down to and click on Chapter 2 “Installation and Invocation” and read the first part
199 on how to download and install LEAP. Notice that the installer should identify the
Operating System you are using automatically and download the appropriate files.
Write down the time of day on your separate sheet of paper and note the total time you spent on steps 1 thru 5 above. This is part of the “Installing LEAP” DocType time.
Don’t lose it though because we’ll start the clock running again.
Return to the original LEAP site (use the back arrow on your browser) and scroll down to the heading “Software Download” and click on “Version 5.8.4 (December 99 release)”.
Use the defaults in downloading. The “Install Anywhere” software will detect what operating system you are using and give you the correct download files. Do not use the “Advanced Options” feature unless you want to do the installation later from the downloaded files.
[I know this works for Windows 95 and Macintosh OS. If you are running a Sun
OS, you’re out of my territory and don’t personally know if it works - RRM]
Now, or whenever you want to install the LEAP software, again write down the time on a piece of paper - again this time is a part of your “Installing LEAP” timeset.
Return to the installation package for LEAP and double click the package to begin the installation process.
Click “OK” when asked in “Preparing to Install”.
200
Click “Next” to “Choose Install Folder”. If you are running a PC, accept the default location (C:\Program Files\Leap) by clicking “Install”. [If you are running a
Macintosh, you may place the LEAP files in a location of your choice]
When the installation is complete click “Done” and quit your browser.
Now take the configuration files I have given you and place them inside the
“Leap” folder. These are two files:
Now launch the Leap application. You will get a little window in the upper left corner called the Leap Controller. Here’s what it looks like:
Pulling down the File menu, click on Load and select the file I gave you that ends in “Projects”. A short message at the bottom of the Controller will tell you when it has loaded the file.
Now pull down the Data menu and click on Timer (Io).
In the lower right corner of Io, expand the window downwards so you can see the
Clear and Save buttons. Or, alternatively, expand the Io window far enough to the right so you can see these buttons.
201
Again in Io, using the three fall down menus click on Project: “aLEAP
Familiarization”, in Phase “aLEAP Tutorial”, and in DocType “Using IO”. Your Io tool should look like this:
Write down the time on your piece of paper. Now total up the time you have captured thus far. This is a total of all the time you actually spent the “Installing LEAP”.
Make sure just the time spent in doing tasks so far is represented and that you have excluded time away from the Project, and downloading times.
You will be manually entering this time in Phase 1b
Now proceed to the Phase 1b “LEAP Tutorial” where we’ll learn how to use Io,
Naia, and the Controller a little more
______
Project 01 - Appendix 1B - “LEAP Tutorial”
In this tutorial you will use the Controller to bring up the timer and timing table
(Io and Naia).
If you haven’t already done this, launch Leap - this brings up the Controller and any other windows in Leap you left open the last time.
In the controller, pull down the Data menu and select “Timer (Io)”
202
Io should be configured as you left it the last time.
If Io is empty (nothing in the data fields) then go back to the controller, pull down the File menu and Load the file
When the Controller is “Finished Loading”, then
Pull down the Project Menu and select “LEAP Familiarization”
Pull down the Phase Menu and select “LEAP Tutorial”
Pull down the DocType Menu and select “Using Io”
OK, now your timer should be up and look like this (don’t worry about lower case preceding letters - e.g., aLeap Familiarization):
Now, remembering what you read in Phase 1a about Io, click the Start button
(it’s the right-pointing triangle on the left of the picture above)
Notice now that Io begins to log your time. Notice that the timing data window turns green indicating that the timer is keeping your time. You are now logging your time to familiarize yourself with the workings of Io. This will be a somewhat imperfect record because we’re going to turn things on and off in the middle. But bear with me on this.
Now you can type into the “Desc” data field “Practicing Using Io”
203
When you are done that, click on the Pause button (it’s the two vertical black bars next over from the Start button). This causes the timing data window to again turn gray while the Interrupt Time data window turns yellow and begins to accumulate time. This represents the time you paused your task.
When you have paused for a short while, again click on the Pause button and notice that the time picks up again and continues to log your time on the task (of practicing to use the Io tool). Notice that the timing window again turns green and the interrupt time data window stops logging time and turns gray.
NOTE: We will refer to these actions of the Pause button as “Pause” and
“Continue”.
Now let’s record our time and move on. Click on Record. Notice that you get a warning window like this:
That’s because you haven’t stopped the timer from keeping time. Let’s do that now. Click on “OK” to dismiss this Error window.
Click on the Stop button (the black square in the location of the Start button).
And notice that the data window stops keeping the time. Now click on the Record button and notice that the “Desc” window goes blank and the times in the data logging fields
204 returns to zero. This means the timer is ready to begin timing something else. Here’s some more information about Io:
Io: Timer-based Time Support
"Io" is Hawaiian for the "Hawaiian Hawk".
Collecting accurate data on the time required for various tasks can be an important component of process improvement. Io is a tool designed to support collection of time data. It implements a timer that can associate elapsed times with work on specific projects and document types. Io also provides a "pause" function that collects the amount of "interrupt" time associated with this work interval.
Io displays and records data about a single time interval. Naia supports review and editing of the set of time intervals associated with one or more projects.
Now that we’ve learned about Io, we’ll move on to Naia. We’re going to be using the DocType “Using Naia” next
First go to the DocType menu in Io and select “Using Naia”
Type “Entering Leap Installation Data” into the Io’s “Desc” data field and click the Start button. You have started timing the next task which is using Naia to manually enter the times you wrote down earlier.
205
Now go back to the controller and using the Data fall down menu, select “Times
(Naia)”. This brings up the Naia tool. It looks like this:
Notice several things about this table. First of all, it has captured the time that you spent in “Practicing Using Io”. My picture also shows an entry called “Reading Stuff”.
This is because I already manually entered these data before bringing up the Naia tool.
You are going to enter your data now. Since I have been practicing and developing these instructions, my entries will differ slightly from yours.
Select the title of this Project “LEAP Familiarization” from the Project field
Tab over to the next column (“Phase”) and select “LEAP Installation”
Tab over to the DocType column and “Installing LEAP”
Tab over to the Start column and enter the time you began Phase 1a step 1. Naia may already have started a clock on you. You can erase this and enter your actual written down time. You erase using double-click in the data field to select it all and then just start typing.
206
Notice the format when you do this. If you have to, go to the top of the column and placing your cursor over the right vertical line of the column, hold-click and pull the column to the right so you can see the entire entry.
Tab over to the Stop column and enter the time you finished Phase 1a step 19
Next Tab over to the “interrupt” column and enter the total time in min:sec that you spent in downloading the Load files. We won’t keep track of this time because everyone’s download experience differs independently of what you are yourself doing.
This may seem a bit confusing, but here’s what we’re after. We want to record, in
“c” and “d” above, the totaled time you recorded in step 19. And here we want you to sum up the total time you spent being “interrupted” (i.e. downloading or whatever other interruptions you kept track of) and enter that total interrupt time in the “interrupt” column.
NOTE: Start and Stop times are in HH:MM. That is, they are wall clock times.
While Interrupt times are in accumulated time expressed also as HH:MM. Interrupt time is simply a sum expressed in hours and minutes. Don’t keep seconds - it’s so tedious!
The beauty of the LEAP system is that from now on you won’t ever have to worry about this as it keeps these times for you!
Now finally tab over to the Description field and enter “Reading and Installing
Leap”
Then click on Save to save your manual entry in the
207
And then Close the Naia tool. Here’s some more general information about Naia:
Naia: Time Entry Support
"Naia" is Hawaiian for "porpoise".
Naia is used to enter and edit time data. Time data in Leap is represented as a set of entries, where each entry records a time interval. Each time interval is associated with a project, a phase, and the doctype of interest. Within each time interval, a cumulative amount of "Interrupt" time (in minutes) can be recorded to represent when the developer was distracted from the task at hand. The "Delta" time represents the total time (in minutes) during the time interval that the developer was actively engaged in the work product.
Naia is for use in recording time data "after the fact", or for editing previously recorded time entries.
18. That’s it for “Using Naia”. Click on Io and click the Stop button and then
Save your time.
Time to move on to the Leap Questionnaire - Phase 1c. But see my final note next page!!
208
(Notice we never used the doctype “Using Controller”. If you wish, you can experiment with the Controller and keep the time using this doctype on your own. If you decide to do this, be sure to change the doctype in Io to “Using Controller” and use Io’s logging function to keep track of how long you’re at it.
Be careful in exploring the Controller not to permanently edit any of the types of tools or datasets - this would mess me up something awful! - Ralph)
In this phase, you will answer some questions about yourself and about this
Project (LEAP Familiarization). Please take your time in answering these questions as they, with the timing data, lie at the heart of the Study.
Launch Leap and the Io timing tool. Set Io to record. Project = LEAP Installation;
Phase = LEAP Questionnaire; DocType = LEAP Questionnaire. In the “Desc” data field enter “Doing the LEAP Questionnaire”. Click the Start button in Io.
Now launch the Word Document I have given you entitled “LEAP
Questionnaire”. Complete the questionnaire
Remember if you have to get up or do something else while doing the questionnaire that you must hit the Pause button. When you return to the questionnaire don’t forget to resume Io’s timer by hitting the Pause button again (this is equivalent to a
“resume” function). You can Pause and resume any number of times.
If you have to completely stop for the day and put away your work altogether, just hit the Stop button in Io, then Save.
209
When you begin again the next day, again launch Leap and again bring up Io
(don’t forget to Load the Projects and Times data files from the Controller File menu).
Your previous Project/Phase/DocType should still be loaded. In the “Desc” data field, you can enter something like “Doing the LEAP Questionnaire - 2” to show a sequence of actions.
When you have finished the questionnaire, save it and return to the Io timer and click the Stop button.
OK, that’s it - we’ve completed the first Project.
210
Questionnaires for Projects and Reviewer Materials
Project 01 (Familiarization) Questionnaire
Background: Now that you are familiar with the basic user functions of the Leap tool, you are ready to complete this questionnaire about yourself and this first Project.
Answers can be typed onto this document following the questions.
Please enter the sum of the digits of your full telephone number - in the US use the full ten digit number plus your extension, if you have one; in other places, use everything except your country code. (e.g., my phone number at work is 856-234-1100 extension 6205. The sum of 85623411006205 is 43. Hopefully everyone will have a different check-sum)
1. The sum of my telephone digits is ______
2. Please enter your age to the nearest ten’s (e.g., I am 62 so I would enter “60”)
My age category is ______.
3. You are a working professional, please indicate the number of years you have
worked in your overall profession ______.
4. What is your profession? ______
5. What is the highest degree you hold? ____.
211
6. I asked you to go to a website and read materials about the Leap toolset. Why
did the makers of Leap feel that such a toolset is necessary? __.
7. What functions must be invoked using the Io timer before it will store timing
data in Naia? ____.
8. What is the difference between Save and Stop functions in using Io?____.
9. When entering data into the Naia tool, what is the format for entering time
under “Start”?__
Don’t forget at this point you should be stopping the Io timer and saving your times before you save and close this Word document.
Now please save this Word document under its original name and return it to me via e-mail.
Thanks again for completing this Project. Next proceed onto the second Project
“Device Familiarization”
Project 02 (Familiarization) Questionnaire
Background: Now that you are familiar with the Device, you are ready to complete this questionnaire about it. Answers can be typed onto this document following the questions.
212
Please enter the sum of the digits of your full telephone number - in the US use the full ten digit number plus your extension, if you have one. In other places, use everything except your country code. (e.g., my phone number at work is 856-234-1100 extension 6205. The sum of 85623411006205 is 43. Hopefully everyone will have a different check-sum)
The sum of my telephone digits is ______
The ZEN400 can control a total of _____ devices at any one time. How is this enforced?______
The ZEN400 uses multiple key sequences to enter a variety of modes. List the key sequences for the following actions:
Change channels ______
Program for a different TV ______
Program for an unlisted device ______
If I’m controlling my TV using the ZEN400, and I have a blank tape in the VCE, how do I set the tape to record my program (assuming the VCR is already hooked as an input to the TV)? ______
What happens if I try to enter a code for a device whose code is “001” and I only hit the “1” key?_____
After I did this (in question 4 above), will the code now be entered into the
ZEN400? ______
213
What meaning does the purple color imply for the Volume, Change Channel, and
Mute buttons? ______
Were you able to program the ZEN400 to run your TV? _____ What problems did you have? ______
Don’t forget at this point you should be stopping the Io timer and saving your times before you save and close this Word document.
Now please save this Word document under its original name and return it to me via e-mail.
Thanks again for completing this Project. Next proceed onto the third Project
Project 02 Study Questionnaire
Background: Now that you are familiar with the Study, you are ready to complete this questionnaire about the Study. Answers can be typed onto this document following the questions.
Please enter the sum of the digits of your full telephone number - in the US use the full ten digit number plus your extension, if you have one. In other places, use everything except your country code. (e.g., my phone number at work is 856-234-1100 extension 6205. The sum of 85623411006205 is 43. Hopefully everyone will have a different check-sum)
The sum of my telephone digits is ______
214
While you individually will only be working on one, this Study consists of three separate legs. What are they? ______
What will be used to evaluate the three legs? ______
Expressing requirements in natural language is not easy because ______
Davis refers to objects, functions, and states. In a few words what is a state?
______
There are four high level elements in the UIML. Which element defines where external toolkits for a user interface will be found? ______
In the REL, relationships are represented by bond-arcs (or just “bonds). There are two bonds that describe parent-child relationships. What are they and what is the difference between them? ______
If the REL is meant to be a background language (i.e., not directly visible to a practitioner), why are we using it to represent the requirements for a UI?
______
Don’t forget at this point you should be stopping the Io timer and saving your times before you save and close this Word document.
Now please save this Word document under its original name and return it to me via e-mail.
Thanks again for completing this Project. Next proceed onto the third Project
215
Project 03 Questionnaires
Project 03 (UIML Familiarization) Questionnaire
Background: Now that you are familiar with the UIML, you are ready to complete this questionnaire about it. Answers can be typed onto this document following the questions. Remember to turn on your Io timer.
Please enter the sum of the digits of your full telephone number - in the US use the full ten digit number plus your extension, if you have one. In other places, use everything except your country code. (e.g., my phone number at work is 856-234-1100 extension 6205. The sum of 85623411006205 is 43. Hopefully everyone will have a different check-sum)
The sum of my telephone digits is ______
The UIML has four top-level elements. What are they? Explain briefly what purpose each serves.
How does the UIML separate the particular device (platform) types in a
UIML?______
PART and STRUCTURE elements are used to do what in a UIML document?
______
How does a UIML document know what toolkit to use when it is rendered?
______
216
How does UIML maintain the “user view” of a system without defining the system? ______
What problems did you have in understanding the UIML? ______
Now Stop the Io timer and Record and Save your times before you save and close this Word document.
Now save this Word document under its original name but add your last name to the file title.
Thanks again for completing this Phase. Next proceed onto the second Phase of this Project: UIML Problem
Project 03 UIML Problem Questionnaire
Background: Now that you are familiar with the UIML, you are ready to complete this questionnaire about your initial UIML Structure. Answers can be typed onto this document following the questions. Remember to turn on your Io timer.
Please enter the sum of the digits of your full telephone number - in the US use the full ten digit number plus your extension, if you have one. In other places, use everything except your country code. (e.g., my phone number at work is 856-234-1100 extension 6205. The sum of 85623411006205 is 43. Hopefully everyone will have a different check-sum)
The sum of my telephone digits is ______
217
Explain the difference between the HEAD and UIML elements in the UIML
Explain, using one example from your skeleton DTD, how you handled a multi- functioning button in the ZEN400.
In using the “Fake ZEN400 Toolkit” did you find anything “missing” that needs to be added to make it complete? If so, what was missing?
What you have created thus far is a skeleton - it doesn’t have “functionality” as yet. How will this be added to your DTD?
Create a short table showing the elements in your DTD that create “handlers” for each button. Do not include the numeric keypad buttons.
What problems did you have in creating the UIML DTD?
Now Stop the Io timer and Record and Save your times before you save and close this Word document.
Now save this Word document under its original name and return it to me via e- mail.
Thanks again for completing this Project. Next proceed onto the final Project:
Representing the UI.
Project 04 Questionnaires
Project 04 UIML Problem Questionnaire
218
Background: Now that have completed the UIML representation of the ZEn400, you are ready to complete this questionnaire. Answers can be typed onto this document following the questions. Remember to turn on your Io timer.
Please enter the sum of the digits of your full telephone number - in the US use the full ten digit number plus your extension, if you have one. In other places, use everything except your country code. (e.g., my phone number at work is 856-234-1100 extension 6205. The sum of 85623411006205 is 43. Hopefully everyone will have a different check-sum)
The sum of my telephone digits is ______
What is the name of your entity that tells the interface to do when the “VCR” button is pushed.
Assume that the person has the following media setup:
A TV cable hookup going through a converter box.
The converter box is connected to the TV input.
The VCR output is connected to another TV input; and the
VCR input is connected to an output from the TV.
The auxiliary device is a CD (audio) player that can only be turned on and off by the ZEN400.
219
The auxiliary device is not connected to the VCR or the TV but to a separate amplifier not controllable by the ZEN400.
Explain how a person would do each of the following by walking through your
UIML representation. Explain the function of each entity and bond that would come into play.
The person is watching television and wants to switch to watching a VCR tape
Assume the TV is on and the VCR is off
The person is watching a VCR tape and wants to watch television
Assume the VCR is on and the TV is on
The person just sits down and wants to activate the cable box which is turned off
The person wants to record a TV program on the VCR
The person is watching TV and wants to turn on the auxiliary CD
The person is watching a video tape being played on the VCR and displayed on the TV and the person wants to turn off the sound for a moment. Then, at a later time, the person wants to turn the sound back on.
The person is watching TV on channel 4 and wants to switch to channel 15
The person is watching TV and wants to turn off the cable converter box.
220
Assume the person buys a new TV and scraps the old one. Now the person wants to have the same media setup as explained in #3 above with the new TV replacing the old. How would the person reprogram the ZEN400 to now control the new TV - again walk through your REL representation and explain the function of each entity and bond that would come into play.
In working with the UIML to represent the requirements for the ZEN400, did you find anything that you were unable to represent or that you found especially difficult.
Please provide example and explanation for your answer.
Complete your table showing all the elements in your UIML document that describe the functions of each button. (only include one number button)
What problems did you have in creating the UIML Document. Please elaborate with specific examples?
Now Stop the Io timer and Record and Save your times before you save and close this Word document.
Now save this Questionnaire.
Thanks again for completing this Study. Next proceed onto the final
Questionnaire: Study Questionnaire (2).
221
Project 04 Final Study Questionnaire
Background: Now that you have completed the Study, you are ready to complete this questionnaire about the Study. Answers can be typed onto this document following the questions.
Please enter the sum of the digits of your full telephone number - in the US use the full ten digit number plus your extension, if you have one. In other places, use everything except your country code. (e.g., my phone number at work is 856-234-1100 extension 6205. The sum of 85623411006205 is 43. Hopefully everyone will have a different check-sum)
The sum of my telephone digits is ______
What thread (TEXT, UIML, or REL) did you complete? ______
Describe to me, as though I knew nothing about it, the method (thread) that you used. Take several paragraphs and explain the methodology.
Describe in several paragraphs, the overall process you used to create a realization of the requirements for the ZEN400.
If you were going to describe the requirements for something else (another system or sub-system), would you follow the same/similar process as you described in question
#4 or some other process. Explain your answer in several paragraphs.
On a scale of 1 (lowest) to 5 (highest), please rate my directions for each project overview (not the work, the directions). You may use non-integers (e.g., 3.6, 2.1 etc) ___
222
On a scale of 1 to 5, rate the appendix directions for Project 1 _____
On a scale of 1 to 5, rate the appendix directions for Project 2 _____
On a scale of 1 to 5, rate the appendix directions for Project 3 _____
On a scale of 1 to 5, rate the appendix directions for Project 4 _____
Presuming you have had some experience in considering how to build a system, define a system, review a system, understand a system - tell me if the method you used here would be helpful. Use a scale of 1 (being not at all helpful) to 5 (being extremely helpful)
Now explain your answer in #11 with examples from your experiential background and from this Study. Compare your examples so I can understand the relative merits between examples. Give me at least two examples from each (experience and
Study).
You’re done! If you have any comments, residual issues, or just plain whatever now’s the time ___
Don’t forget at this point you should be stopping the Io timer and saving your times before you save and close this Word document.
Please make sure you forward me your final time file (this is absolutely critical!)
PLEASE don’t forget.
Also send me this questionnaire, the project 04 questionnaire, and your final representation of the requirements for the ZEN400.
223
Reviewer Materials and Questionnaire
Reviewer Materials (UIML only)
Project 4: Representing the UI (UIML) (Expert Review Version)
Prologue : In this last project subjects completed the UIML code of the device.
There were no new readings for this Project. However, there is additional explanation of a UIML document - see below.
Subjects did two things in this final project:
Completed representing the requirements for the ZEN400 using the UIML
Checked their representation of the requirements.
In addition, they completed a questionnaire on this final project; and a questionnaire about the entire Study.
Terminology: No new terms were introduced for this Project
Term Definition LEAP (or Leap) Lightweight, Empirical, Anti-measurement dysfunction, and Portable software - (don’t blame me I didn’t make this one up!) LEAP Website CSDL - Research - LEAP Project In LEAP, a Project is a high level group of activities Phase In LEAP, a Phase is a sub-section or part of a Project DocType (Also Document Type) is a table that collects timing data. Can be used in more than one Project or Phase Controller The window in LEAP that gives you access to all of the other tables Io The “Timer” and the window that starts and stops the clock on your activities. Works similar to a tape recorder:
224
Term Definition start/stop/pause. Also has a SAVE function to save the time you have captured while you work. Io is the Hawaiian word for “Hawaiian Hawk”. It is pronounced “EE-oh) Naia The “Times” window is a tabular presentation of timing data gathered using Io. You use Naia to manually enter times and edit existing data. You will use Naia to manually enter the time it takes you to download and configure the LEAP toolset. After that you should not need to access this tool. Naia is the Hawaiian word for “Porpoise”. It is pronounced “Nah-EE-ah” (notice in Hawaiian that all vowels are pronounced individually) Questionnaire Elsewhere questionnaires are uncomplicated affairs asking yes/no or choose-from-a-list sorts of questions. Because our purpose is to more actively probe your work, more probing questions requiring you to explain your reasoning or approach will be asked. Study The term Study (as capitalized here) refers to this field study of different ways to represent the user interface for a system User Interface (also UI) Refers to the human to machine functions. Encompasses the physical and virtual “widgets” used that permit a person to interact with the system. In this first Project we’ll be looking at the LEAP UI and some of the functionality within the LEAP toolset Representation In this Study, the term “representation” stands for an instance or realization of the requirements for a system. Hence, if I write down that, “The system shall be capable of being turned on and off from a front panel”, I have “represented” a requirement in a textual format. You will create a representation of a system in one of three methods. Requirement Requirements are representations of what a system is, what it does, and how it does the things it does. Device Always refers to the device being used in this Study - the Zenith Universal Remote4 remote control Button A part of the device UI that the user pushes to cause something to happen Label A text word, abbreviation, or phrase meant to convey the purpose of an interface element in the device UI Element Any active part of the device UI - buttons, lights - not labels Programming In the terminology of the device - performing a sequence of actions with the device so as to change what media platforms it can communicate with (i.e., does not mean writing computer code) Media Any platform with which the device can communicate - TV, VCR, etc. User Interface Markup A language of the XML created by Marc Abrams and Language (UIML) Constantinos Phanouriou at the Virginia Polytechnic Institute and State University. UIML is consistent with and meant to be used with the XML. Element (as used in Another name for the tags (a term from HTML) that describe the UIML) parts of an interface with which an end user interacts.
225
Term Definition Behavior UIML describes in a behavior element what actions are to occur as an end user interacts with a UI. Rule A behavior element is based on rule -based languages. Each rule contains a condition and a sequence of actions. Event Whenever an end user interacts with a UI, the UI generates events. A condition can occur only when an event occurs. Action What occurs when an end user interacts with a UI. There are three types a property of some part in the UI changes a function in a scripting language is invoked a function or method in the application logic Hence actions can be described within a UIML document or be referenced by pointing to an external script or application method Part Each interface element is called a part. Parts may be organized according to categories of end users and different families of devices Tags (in UIML) UIML does not contain tags specific to a particular toolkit. Rather UIML captures the elements common to any UI through the elements and references toolkits from which tags may be referenced indirectly. W3C The world organization that regulates the XML and its languages. http://www.w3c.org Style Sheet A style sheet is a separate file describing the stylistic elements of a device’s interface. Cascaded Style Sheets (CSS) are a popular form of these. By using such style sheets, one interface might be told to render all headlines in bold type while another could be told to render it in italics. Widget A tool or functionality that can be implemented in a software interface. In actuality it is a reusable piece of code that is generally imported from a toolkit of widgets. Term comes from the Unix world. Unix In case you asked, I have no idea where the term comes from. But Bill Gates once said, “Unix will set you free. But first it will drive you mad.”
Overview of UIML (Continued):
REPEAT: This section contains a very simple introductory UIML document.
Consider the following “Hello World” example in UIML. (This is quoted from the UIML Reference Manual we will be reading after other introductory materials.)
226
http://uiml.org/dtds/uiml2_0a.dtd>
227
One thing not here are the