Target Domain and Project

The Target Domain: SDP

• 
  to provide support for object-oriented analysis, design and implementation of large software applications,
  

• 
  to structure not only the software but also the documentation (including specifications, design history, testing, etc.) in an object-oriented fashion,
  

• 
  to structure also the method itself in an object-oriented fashion,
  

• 
  to support reuse of everything such as documentation, specifications, software, etc.,
  

• 
  to allow for a risk-driven approach to the design and realisation of applications,
  

• 
  to ensure traceability from system requirements to their realisation,
  

• 
  to base the analysis of the requirements and, later on, the testing on example usage cases,
  

• 
  to allow for concurrent development of different parts of the target application,
  

• 
  to support a life-cycle view of applications.
  

Processes are related in a hierarchical fashion where attributes of the processes are inherited down the hierarchy. Within one level, the processes are organised both by a temporal order reflecting the order in which activities in a project should happen, and also by a dependency order where certain object types are produced in one process and then used as input to another process. In POP we have studied one particular variant of SDP, named SDP-TA (Telecommunication Applications), that contains about 12 main processes organised into three big super-processes: the usage case definition process (FSAD), the design phase¹⁰ process (subD), and the implementation phase process (SUD). Each of these three phases also includes testing and verification against design requirements. At the lowest level, each of the 12 processes consists of 6 – 12 activities each.

The object types (or object classes) are organised in a hierarchical structure, and they inherit attributes down that hierarchy. The main separation of the object types are into two categories: SPI and STI object types. SPI object types contain models of the software, while STI object types constitute the structure of the software. The object types are related to one another in various ways: one object type can be contained in another object type, they can have an acquaintance relationship which means that they know of the existence of one another, etc. So there is one vertical, hierarchical structure, and one horizontal structure of relations between object types.

Each object type will, when instantiated as a particular object, typically consist of a piece of specification, a piece of implementation, a piece of documentation, a piece of project log (with information on who changed the object last and what happened), a piece of information on the testing of the software, etc. These pieces are named IEs (Information Elements). They are supposed to be the ”atomic” units of information that cannot be further divided into smaller units. The IEs were supposed to be used dynamically so that several different documents with different contents depending upon their intended usage could be generated automatically through combining IEs in various ways. In SDP-TA, there are approximately 80 different object types, and each such object type typically consists of 6 – 12 IEs.

Working with SDP means following the process instructions, and thereby creating one or several instantiations (objects) of the object types. A large software application might generate thousands of objects.

In summary, SDP consists of processes that are in various ways related to other processes, and object types that are related to other object types, and to the processes. The whole structure is very complex, and cannot be depicted in one simple graph. The documentation that existed when we started to study SDP utilised several different views of how processes and object types are related. For example, one view would show the temporal order by which activities within a process are performed, which object types are produced as output and where they are used as input, etc. For each process there were six different views, for each object type there were a couple of views, and in addition there were several global overviews of both processes and object types, serving as maps to the information structure.

Figure E. The structure of the existing on-line manual.

The available on-line manual was organised in a hypermedia tool and implemented in FrameMaker™. A user had no other means of finding a particular textual document, than through clicking in several graphs until the document was reached. A schematic picture of the information organisation of the on-line manual can be found in Figure E. The process structure and the object type hierarchy graphs function as maps to the two main structures in the domain: the process structure and the object type structure. From the process structure graph it is possible to reach graphical descriptions (or views) of each process, the process graphs. From the process graphs in turn, textual descriptions of the processes can be reached. From the object type hierarchy the object type graphs can be reached, and from those the textual descriptions of each object type can be reached.

In order to get to a textual description of a process or object type, it is necessary to navigate via a set of graphs until the bottom of the hierarchy is reached – only there a textual description will be found.

It should be observed that the structure of the SDP domain only partly overlaps with the information organisation used to organise the database in the FrameMaker on-line manual. This means that users shall have to learn (at least) two structures, both the FrameMaker on-line manual information organisation and the structure of SDP. Since different views are more or less important depending on whether the user is trying to learn the temporal order of activities, the logical structure of object types and their relations, or the connection between activities and object types, etc., the user must in fact learn a whole set of structures.

In addition to the descriptions of processes and object types, the SDP on-line manual also offers general documents that describe the underlying principles of SDP, the principles of reuse, a word list, etc¹¹. In total, SDP-TA is documented by approximately 500 documents, where each document consists of 5 – 20 pages of text and pictures.

The reason that the PUSH project studied how to create a new information organisation of the database and create a new on-line manual, was that users of SDP had expressed having problems with the existing on-line manual. The developers of SDP wanted to get a better grip on exactly what it was that users experienced problems with in order to improve both the manual and the method itself.

The PUSH Project

The design of the POP system builds upon the research and experiences made in the PUSH (Plan- and User Sensitive Help) project. The goal was to find adaptive techniques that would be acceptable to users, and so the whole project centred around empirical studies of users, and building prototypes fitted to users’ needs. In Figure F we see a historical overview of the project.

PUSH started in September 1993, and was designed to run for three years. It was a co-operation project between researchers at SICS, the department of Computer and Systems sciences at Stockholm University / KTH, the department of Computer Science at Linköping University, and developers of SDP at the former Ellemtel Utvecklings AB. The first year was devoted to acquiring an understanding of the central issues for adaptive help in the domain, acquisition of help questions and answers, design of the knowledge representation, and the fundamentals of the presentation generation. We designed and implemented a first demonstrational prototype for a knowledge-based information system, implemented in SICStus Prolog and SICStus Objects (SICStus Prolog User’s Manual).

Figure F. The history of the PUSH project.

During the second year, we performed several more focused studies: a task analysis, a study on the relation between cognitive abilities and ability to navigate in hypermedia, and finally, a study on novices’ and experts’ understanding of SDP concepts and principles.

We also performed a small evaluation of the first prototype. Users were positive to the prototype and some interesting viewpoints came up during study.

Furthermore, during the second year we continued the work on designing and implementing our ideas. A second prototype was developed.

During the last year of PUSH we finalised the prototype system and performed a couple of ”bootstrapping” studies and a comparative study of the acceptance of the adaptive system. Our aim was to study whether users felt in control of the system, if they could understand the inner workings of it at some level (transparency) and whether they could predict its behaviour. In order to perform the studies, our prototype was further developed – in particular we designed and implemented a WWW interface using the WWW browser Netscape and the language Java. We also investigated the possibility of using machine learning as a complement to the plan inference approach, (Rudström, 1996).

Finally, we also attempted to provide a natural language interface to the prototype, but as it was not completely implemented when we evaluated POP it will not be described in any detail in this thesis.

Directory: ~kia -> papers
~kia -> Usability and fun An overview of relevant research in the hci community
papers -> Comparing Two Approaches to Context: Realism and Constructivism
~kia -> B. Cahour (1), P. Salembier (1), Ch. Brassac (2), J. L. Bouraoui (1), B. Pachoud (3), P. Vermersch

Download 0.88 Mb.

Share with your friends: