Applying the Domain Theory to Design for Reuse Alistair Sutcliffe and George Papamargaritis Centre for HCI Design, Department of Computation, UMIST, PO Box 88 Manchester M60 1QD, UK +44- (0)161-200 3315,
[email protected] http://www.co.umist.ac.uk/hci_design/index.htm Abstract. A theoretical framework of domain knowledge is proposed, consisting of classes of generalized object collaboration models and generic tasks that describe patterns of human activity. The reusable library of generic models is applied to analysis and design for reuse of generalized componentbased frameworks by reusing the models as templates, with associated design knowledge in the form of attached design rationale. A design by reuse method is described for identifying at the analysis stage generic abstract models of the structure and behaviour of new applications. Generic requirements of the identified abstractions link to object oriented patterns for design solutions. The design process is applied for the design of a generalized telemedicine framework. The discussion reviews the prospects for integrating generic domain models with design patterns in component-based development.
1 Introduction Designers of reuse component libraries have to rely on their experience of the domain and heuristics for abstraction to guide the process of discovering and specifying generic components. Consequently reuse libraries have tended to be more successful in stable application domains [1], [2], [3]. Domain analysis methods (e.g. FODA [4]) advocate a comprehensive systems analysis of an application area to identify variable functions and more stable components but give little guidance on discovering appropriate generic models. In contrast, application frameworks [5] describe templates for general applications that identify hotspots were variation is probable and hence specialization may be necessary. Application frameworks target large-scale software reuse by assembling small components into a component sub-system [6], [7] augmented to a set of finer-grained application components. However, domain analysis method and frameworks give little advice on how to discover components at suitable levels of abstraction, and how the interfaces between components should be specified to maximize flexibility in future reuse contexts. The patterns movement [8] has proposed reuse of design knowledge and specifications with the potential for more wide-ranging reuse; however, the designers of new patterns still face the problem of discovering components at the right level of abstraction. Patterns or components containing too much detail restrict their future scope of potential reuse; in contrast, more abstract patterns may contain insufficient detail to make them useful for designers. This balance is difficult to strike. On one hand the success of the Gang of Four object oriented design patterns [7] can be attributed to a high level of abstraction and a consequent wide-ranging scope for
reuse. On the other hand, the equally successful Enterprise Resource Plans (ERPs: [9]) reflect lower abstraction levels, and greater utility for the application developer, in spite of the pain of tailoring complex application frameworks [10]. ERPs express requirements in business-oriented blueprints; however, they enforce an envelope within which reuse by customization and tailoring can be achieved. The reuser has to accept a de facto standard for the application area. Patterns, in contrast, offer more flexibility by virtue of a small unit of reuse that can be composed into large-scale applications [11], [12]. The Domain Theory [13], [12] evolved as a partial answer to these problems by positing a set of abstractions at the requirements level. Generalized models of the problem domain were specified at a higher level of abstraction and small granularity (i.e. a collaboration of 3-4 classes) than ERP blueprints, with the motivation of enabling more flexible reuse. The Domain Theory specifies models that are more closely anchored in problem descriptions at a slightly less abstract level, e.g. the essence of loans/hiring applications, sales-oriented transactions, command and control, etc. In the patterns genre problems frames [14] or Fowler’s [15] conceptual patterns are a close, but less comprehensive, relative. The Domain Theory’s utility lies in reuse of conceptual models and design rationale attached to the models with generic requirements that point to design issues and possible solutions. Hence it supports the analysis phase of reuse, but to achieve greater utility the Domain Theory conceptual models need to be mapped on to a set of design-oriented abstractions. This forms one of the starting points for this paper, which reports experience in applying the Domain Theory to a design for reuse problem, coupled with an investigation of how the Domain Theory models can be integrated with object oriented design patterns. The paper is organized as follows. The following section describes the Domain Theory and reuse approach. In sections 3 and 4, we illustrate the application of the compositional reuse method to development of a reuse library for telemedicine applications. Section 5 discusses the lessons learned and section 6 concludes the paper.
2 Domain Theory Framework The Domain Theory describes a knowledge-representation ontology for generic reusable models of application classes, with a library of models that cover a wide range of software system development problems. It is based on a cognitive model of analogy [16] and has been developed over several years [17], [18], [13]; it has also stood the test of validation and application [18], [20]. The Domain Theory models were constructed from knowledge acquisition interviews with expert designers, by investigations and abstraction from specific problems published in the literature, and by refining the models via empirical testing [19]. To deal with a wide range of applications, the theory proposes families of generic models describing transaction oriented problems, called object system models (OSMs), and generic tasks that describe human goal-oriented activity. Attached to these models are generic requirements (GRs), that indicate high-level solutions to the problems. OSMs are a set of collaborating objects that achieve a goal or provide a
service, hence following object-oriented concepts of responsibility modeling [21]. The overall OSM hierarchy is illustrated in Fig. 1.
Object Allocation
o
o
o Accounting Object Transfer
Object Object Composition Decomposition
Object Containment
ooo
o
oo
oo
o
o
o
Object Inventory
oo
o
Object Hiring
oo
o
o
continued below
o
Object Sensing
Object Returning
oo Object Servicing/Repair
continuation
o Agent Control
OSM family structure object agent partitioned structure object
o
Object Simulation
o Object Logistics
o Object Construction
state transition key object financial object augmented object
Fig. 1. OSM families, showing outline schema of the structure of each family. OSMs are expressed as goal-oriented collaboration between a structure object that contains active objects which undergo change during the transaction
The top levels of the tree have been pruned, because models at such high levels of abstraction do not contain sufficient knowledge to be informative. The hierarchy therefore starts with nine separate trees, or OSM families, which are: Object Allocation that describes matching and broking style problems; Object Containment that models transaction processing problems such as sales order processing, loans, and inventory management; Object Composition that models assembly and manufacture, with its inverse abstraction Object Decomposition; Object Sensing for monitoring and detection problems; Agent Control for command and control applications; Object Simulation that represents decision support and other interactive modelling applications; Object Logistics for movement of goods and messages; and Object Construction which models manufacture and processes that change objects. Design rationale and generic requirements are attached to each model to provide reusable knowledge that can be specialized into functional requirements in the new
application, and a checklist of issues that may require in-depth analysis. An example of an OSM with attached GRs is illustrated in Fig. 2. LevelLevel-2 class Spatial Object Sensing agent
agent
o movement reports
world segments
segmented world in which o objects move
object movements
1
detection report
Generic Requirements
1. System model 2. Event filters 3. Rare event monitor 4. Event interpretation 5. Trace history
2
receive exist-in object
sensor 4
3
events change
signal 5
Fig. 2. Object Sensing OSM with associated generic requirements
Generic tasks are carried out by agents to change the state of some object and thereby achieve a goal. Generic tasks draw upon the HCI tradition of describing human goal-oriented activity in task analysis methods [22], [23]. Examples of generic tasks are comparing, evaluating, identifying and classifying objects. Similar but less extensive taxonomies have been described by [24] who focus on tasks involved with visualization of information; and by [25] whose taxonomy covers generic information processing tasks. Generic tasks, composed into composite structures called generalized tasks, are closer to the everyday meaning of a task. Some familiar examples are: • Diagnosis: determining the cause of some malfunction in a system, locating its cause and proposing remedial treatment. Examples may vary from medical diagnosis of a patient’s illness to a technical diagnosis of a fault in a photocopier. • Information retrieval: finding information to satisfy either a task or curiosity-driven need, locating the appropriate information resources, searching for the necessary items, assessing their usefulness and extracting the required information. In a similar manner to OSMs, generalized tasks represent families which are specialized into more specific tasks; for example, diagnosis is specialized into fault finding for machinery, diagnosis of pathologies in living entities, and diagnosis of problems in organized systems, etc. Generalized tasks are organized in eleven families: Information acquisition that involves eliciting and gathering facts and data from people or other sources; Analysis/modelling: that organizes facts in a coherent representation (i.e. modelling) and then inferring interesting properties of the modelled phenomena; Diagnosis has two major sub-structures, causal analysis and repair, that recruit lower-level generic tasks, e.g. interpretation, evaluation, comparison and sorting; Information retrieval: involves searching for information items but also evaluating the relevance of search results; Validation/testing checks that a design or a problem solution satisfies a set of sufficiency criteria; and other
families describe Progress tracking, Planning/scheduling; Judgement/decision making, Explanation/advising and Matching.
Navigation,
3 Modelling Approach This section introduces the case study and the process of discovering the appropriate Domain Theory abstractions. The case study was part of a BTexact Technologies1 research project into component-based service provision [26], [27]. The business motivation is to create a reuse library for CSCW (computer supported cooperative work) applications; an additional aim is to create a reusable application framework for telemedicine built on top of the CSCW reuse library. The problem is how to partition this application when the components interact, e.g. end-user interaction in the medical domain may have implications for CSCW support. The telemedicine project aimed to design a reusable set of middleware collaboration and diagnosis-support services. In a specific medical application, a number of medical experts would use the system to examine concurrently a patient and seek advice from each other in order to arrive at a diagnosis. The system required services for patient monitoring as a set of diagnostic sensors (hardware components) and a set of methods that interpret a set of inputcritical patient properties (i.e. blood pressure, ECG signals, temperature) supplied from the sensors. The Domain Theory (DT) method starts by identifying the generic models that characterize the new application. Finding the appropriate generic models is the most difficult part of the method because abstractions are rarely explicit in any domain. A set of heuristics guides matching application sub-systems to OSMs. The process follows a walkthrough-style analysis and starts by identifying any sub-systems in the application. These may be suggested by geographical distributions, ownership by different parts of the organization, or by locating who operates the system. In this case study, two sub-systems are apparent, one for communication and collaboration, with another for medical support services. This is followed by analysis of the objects, structures, agents and state transitions to match one or more OSMs by a goodness of fit signature. The heuristics are applied in a decision table format, shown in Table 1, to trace the OSMs that may fit within the new application. A lexical analysis of domain functions is also carried out using synonyms of keywords to point to OSMs that indicate system goals and activities. Taking the collaboration/communication sub-system first, this has goals of delivering messages to users that point towards an Object Messaging OSM. Collaboration is more complex because it involves shared objects, with change control being shared between two or more users. Control objectives implicate Agent Control; however, editing changes indicate Object Construction family, Object Manipulation sub-class, which has a better fit with the application. Generic requirements (GRs) associated with the Object Manipulation OSM point to the issue of access control for editing operations. This in turn points to the need for an Object Allocation model to handle the process of controlling user access to shared objects and editing operations. The Object Allocation OSM consists of three objects: a set of 1
British Telecom Group
resources; a client that requests the resources; and an allocator object that matches requests to resources and then forms a reserve/allocate association. Two instances of object allocation are necessary: one for controlling turn taking and another to handle logon procedures to assign authorized users to collaboration sessions. In the latter case, the allocation involves checking user identity against a list of authorized users, and the Object Allocation GRs indicate possible matching and identity checking algorithms. Design rationale linked to the Object Messaging and GRs in Object Allocation models suggests different methods for sharing and controlling user access, e.g. round robin turn taking, first-come-first-served, reserve access queues, prioritization schemes, etc. Table 1. Decision table for identifying Object System Models OSM family
Keywords/ synonyms
Goal type
Object role
Dependencies /links
1
Object Allocation
Matching, broking, assignment, goodness of fit
Attain: resource matched to requests and demands
Passive: joined to requesting client/resource
2, 8, 9 for goods, resources allocation
2
Object Containment
Inventory, order process, loans, stock control
Attain: all requests for objects satisfied
Passive: responds to transaction events
3
Object Composition
Packaging, assembly, aggregation
Attain: parts joined to form whole
Passive: transformed by process
4
Object Decomposition
Partitioning, unwrapping, fragmentation
Attain: whole broken up into parts
Passive: transformed by process
5
Object Sensing
Monitoring, detecting, event process, alarms
Attain/Maintain: events detected and interpreted
Active: detects events and interprets
6 for control applications
6
Agent Control
Command and control, ordering
Attain: desired behaviour of agent is effected
Active: gives commands or responds
5 for control applications
7
Object Simulation
Models, interactive decision support, animations, demonstrations
Attain: behaviour of modelled world represented faithfully to user
Active: undertakes behaviour
9 updates to model
8
Object Logistics
Dispatch, distribution, communication
Attain: all goods/info. arrive at correct destination
Active: moves location, is transferred by agent
1 for routing, pathway allocation
9
Object Construction
Transformation, construction, ti
Attain: new object created b
Active: transformed d t db
4 as precursor sub-assembly 7f d l
8: components before manufacture
creating, manufacture
by process acting on input components
and created by agent
7 for model editing
To analyze the medical implications the generalized task part of the method are required. To identify generalized tasks, the goals and activities that achieve them are analyzed and associated with the agents that are responsible for them. A lexicon of synonyms is used for identifying generalized tasks. Once activities have been listed, questions focus on discovering dependencies. Associations between OSMs and tasks are traced, e.g. the goal state of an OSM often points to the need for a task to achieve it; similarly, transactions are initiated by generalized tasks; for instance, matching results in Object Allocation. Other dependencies are information inputs for tasks that prompt questions about the source of the information and where it is generated. Probable dependencies are recorded as hypertext links in the DT generic model library that provide cues for the analyst. Table 2. Decision table for identifying generalized tasks Generalized task
Goal/end state
Information requirements
Synonyms
Analysis/ modelling
Represent and understand modelled world
Filter information, modelling schema
Investigation, comprehending
Diagnosis
Causal explanation of fault/error
Symptoms of fault, possible causes
Fault finding, trouble shooting
Validation
Model/beliefs agreed, conform to criteria
Model/beliefs and test criteria
Testing, checking, evaluating
Information acquisition
Relevant facts and information gathered
Information sources, documents, data
Information gathering, browsing, fact finding
Information retrieval
Relevant information found for a need
Information sources, databases, search terms, need
Information search
Planning/ scheduling
Plan exists, organization specified
Goals, constraints, contextual knowledge
Organizing, deciding strategy
Judgement/ decision making
Decision made, best alternative selected
Choices, alternatives, selection criteria
Choosing, selecting, adopting policy
Matching
Best match found
Object properties, matching criteria
Goodness of fit, finding similarity
Forecasting
Future state of model/domain predicted
Domain history, trends, forecast algorithms
Prediction, forward projection
Navigating
Target found
Spatial information, maps, routes, pathways,
Pathfinding, journey planning,
Explanation/ advising
Other person(s) understand information or knowledge
directions
wayfinding, orienteering
Domain knowledge, information, arguments
Clarifying, tutoring, instruction
The goals of the medical sub-system are to support consultation among a group of medical personnel located at different sites, with the objective of reviewing a patient’s condition and agreeing a diagnosis based on observed symptoms. Task identification is supported by Table 2, which indicates mappings between specific goals and generalised tasks via a lexicon. Diagnosis
Gather facts
Locate problem
Remedy problem
Analyse cause
Form hypotheses
Select causal hypothesis
Plan repair
Carry out repair
Test effectiveness
Confirm cause
Run test
Check results are consistent
Generic information requirements: 1. Components, sub-assemblies of the artefact, machine or agent being considered. 2. Fault failure history for the object/artefact instance. 3. Typical faults found with the class of objects/artefacts. 4. Heuristics or rules for forming diagnoses from the observed evidence, differential diagnosis hints. 5. List of treatments coupled to diagnosed causes. Generic functional requirements: 1. Pre-processors to sort and rank symptoms and observed problems in order of severity, importance, time, etc. 2. Question checklist dialogues to ensure full capture of diagnostic information. 3. System model simulations to locate problems and support diagnostic reasoning. 4. Expert system inference to diagnose possible causes from observed signs. 5. Interactive microworld system models with “what-if?” testing facilities. 6. Automatic implementation of treatments for identified problems. 7. Suggestions for potential cures/treatments. 8. Facilities for follow-up tests to confirm diagnosis. 9. Guided assistance for repair strategies and procedures.
Fig. 3. Diagnosis Generalized Task showing generic requirements for task support
The sub-system goals point to the diagnosis generalized task (GT). Requirements attached to the generalized task models (see Fig. 3) suggest functional requirements for this sub-system and point to the needs for acquiring information and questions about the sources thereof. Information needs can be satisfied by query processes (information retrieval GT) or from external entities, in which case the Domain Theory cross references Object Sensing models. This family of models describes problems of monitoring and detecting events in the world. The family tree is traced to identify the most appropriate sub-class for monitoring patient data, which is Object Property sensing. Generic requirements in this family point out issues such as fidelity of detecting events, deviations from reference values, interpreting information reliably, danger of false alarms, etc. Links in the Domain Theory library point to the interfaces between the subsystems, information inputs to the diagnosis task and consequently the need for another sub-system for patient monitoring and information provision. The composite architecture of both sub-systems is illustrated in Fig. 4. Object Allocation: password Allocator
System
Transporter
World locations
resource
Patient
exists in
transfer 1
move
Object Allocation: shared object control
Sensor User
used by
Allocator
Patient 3 information
2 Reserve allocate
update
request
detect patient events Monitor
lock unlock
Sender
Receiver
Owner
Object
interpret Model, information manipulate
edit owned by
Object Messaging: communication
Object Sensing
Fig. 4. Composite system architecture after the modelling phase, showing the CSCW and patient monitoring components with interfaces between sub-systems: 1. logon authorization; 2. shared object allocation; 3. patient monitoring data. The diagnosis task and Object manipulation OSMs have been omitted for simplicity
Once the composite architecture is in place, the Domain Theory provides reusable knowledge that helps to elaborate the specification. Space precludes exhaustive treatment of reuse of all the generic requirements, so we have selected an example to using design rationale for allocation of access control in Object Messaging domains. This indicated trade-offs among three options, see Fig. 5. : a) System-based: if the client requests the floor, the system assigns it to that client if the floor is free; if not, then the client’s request is queued. As soon as the floor becomes free because the previous owner releases it, the system assigns it to the longest-waiting client b) Manager-based: a user is given authority for the resource allocation. The usermanager assigns the floor to a participant or releases it on another request. If the manager releases control it returns to a system mode. c) Token-based: in this case, the user who owns the floor may choose the next owner of the floor. If the current owner releases the floor then the control switches to a system mode. A specialization of this option is round robin based token control. Queue Based
-
+ Shared Floor Control
+
Token Holder -
Manager Controlled
Design issue
Equal Sharing
-
Options Generic requirements
Response Time +
+
Implementation Cost
Selection criteria Non-functional requirements
Fig. 5. Design rationale for shared object control. Positive influences are marked with a plus sign, negative or decreasing influences with a minus sign; thus the manager-controlled option has a positive influence on cost and response time
Generally one option would be chosen for implementation; however, because we were constructing a reuse library we intended to provide the reuser with the choice of all three options. This had design consequences which we explore in the following section.
4 Mapping to Object Oriented Patterns This section records our experiences in mapping the Domain Theory models to object oriented patterns [7]. The motivation for this was twofold: first, to facilitate completion of the Collaboration/Telemedicine reuse library as a set of software components that could be indexed to specifications derived from the Domain Theory models; second, a more general aim, to investigate the potential coupling between GOF patterns [7] and Domain Theory models. Space constraints enforce a selective report of the implementation of the reuse library, so we describe the use of object oriented patterns to illustrate the types of dependency we discovered between the two reuse paradigms. The Domain Theory models indicated a choice of control policies for shared object access in the Object Messaging OSM. Considering that potential reusers of the collaboration sub-systems may want to choose the access method, it was decided that the access policy should be dynamically re-configured without affecting the communication interface to the attached clients. To fulfil this requirement, a generic façade pattern was linked to a factory object [7]. The façade pattern provides a unified interface (in this case, generic communication methods) to a set of sub-classes. The factory pattern dynamically selects one of the associated subclasses with its access control method and binds it seamlessly to the façade (see Fig. 6). Floor control Façade
Request floor (agent) Release floor (agent) Assign floor (agent) Reject floor (agent) Interrupt (agent)
Floor control Manager
Floor control Factory
Floor control object = Factory. Create ()
Create (floor parameter)
System floor control
Token holder floor control
Manager floor control
Fig. 6. Collaboration floor control composite design pattern
The role of the mediating manager is to establish the binding between the façade and the sub-class selected by the factory. In this case the mappings to object oriented patterns were motivated by implementation concerns and no persistent links to Domain Theory models could be proposed. The generic requirements associated with the Object Messaging domain model indicated alternative message routing methods and protocols. Flexible reuse of
different routing methods, e.g. broadcast to all, selective address, sequential routing, can be implemented using a similar Façade-Factory configuration as shown in Fig. 7. However, routing also depends on the dynamic network topography as clients join and leave. To handle message-passing in dynamically configurable sessions, the remote proxy design pattern was used which enables distributed clients to send distributed commands to a server through a server proxy object with the proxy installed locally on each client. In this case the selection and choice of object oriented patterns was motivated by implementation concerns. Client sender Façade
Agent control Façade
Agent control proxy
Joint session (agent, username, password) Request floor (agent) Release floor (agent) Interrupt (agent) Multicast event (agent, event)
Joint session (receiver, username, password) Request floor (receiver) Release floor (receiver)
Client receiver Façade
Receiver proxy
Fig. 7. Remote proxy design pattern
The monitoring sub-system consisted of an Object Sensing OSM that indicated requirements for sensors to detect changes in the patient’s condition and report them to receiving agents. This mapped to the Observer Design Pattern (see Fig. 8). Apart from detecting specific events, the observer component should also assemble algorithms for interpreting in medical terms the data outsourced by real-time hardware devices (i.e. analog-to-digital signal converters). Algorithms for classifying observed digitized signals (i.e. classify ECG signals to normal and abnormal or associate them to candidate diagnoses) were indicated by the GRs associated with Object Sensing OSMs and the Interpret generic task. Object
Sensor signals
State
Observer event
Interpret () Notify ()
Update () = Object.getState ()
Fig. 8. Patient monitoring: observer design pattern
5 Lessons Learned The Domain Theory contributed significantly to identifying and understanding the collaboration and monitoring components in the telemedicine architecture. The Domain Theory’s distinction between transaction-oriented processing in OSMs, in contrast to processes that directly support human activity (i.e. generalized and generic tasks), indicated a clear demarcation between the CSCW environment and the telemedicine, or indeed any other application, that might be built on top of the generic CSCW architecture. The role of message and communication in group working mapped intuitively to the Object Messaging model which supplied design rationale and generic requirements for message handling protocols. However, mapping to appropriate abstractions for shared object control did not come so naturally. In this case the design rationale and generic requirements had not been developed in the Domain Theory library to cover all aspects of the CSCW problem, i.e. allocating resources to users was covered, but access control functions such as the request-lock object-unlock had not been described. This experience underlines the point that the theory provides a framework upon which to build. Once object allocation had been identified, mapping this OSM to the password security part of the application seemed to be natural. However, once again we discovered room for improvement in the generic requirements and design rationale. Advice of appropriate algorithms for password validation, checking PIN numbers, etc. needed to be added to the Domain Theory library. Identification of task support requirements in the telemedicine was facilitated by an obvious mapping to the diagnosis generalized task. The dependencies between the task and OSM models resulted in extending the basic CSCW reuse library to support remote data capture for monitoring patients, hence the abstract models facilitated requirements discovery by considering the sources of input to each model. Consequently, several Object Sensing models were integrated into the CSCW reuse library, e.g. monitoring patients, monitoring user input and monitoring requests to join the teleconference. Interfaces between the two major applications became clear through use of the DT models and applying the concept of dependency. Our experience in mapping DT models to GOF patterns demonstrated that some patterns have a direct mapping to the problem space expressed in DT models; however, many do not. For instance, the Object Sensing OSM mapped naturally to the Observer Pattern, which specifies classes for monitoring. However, use of Proxy, Factory and Façade were motivated by design considerations such as dynamic configuration of services and hiding complexity. Since design patterns and OSMs are specified at approximately the same level of granularity (i.e. 3-4 collaborating classes), discovering interfaces between the problem and solution space models was not difficult. However, learning the DT models and discovering the appropriate abstractions took some time. Educating software engineers to consider requirementslevel abstractions proved to be difficult; consequently, one major lesson is that comprehensive training needs to be given in the DT framework. In spite of these
problems, use of the DT did provoke discussion beyond more traditional domain analysis approaches [4], which consequently resulted in a more complete specification.
6 Discussion Although application of the Domain Theory did provide interesting insights into specifying the reuse library and indicated that the library has more accurate and adaptable requirements as a result, we cannot claim objective evidence for this. However, application of the Domain Theory did create new insights into abstraction for reuse, and there are few other methods or frameworks that offer similar advice. Indeed, when we examined other pattern libraries that describe models at the requirements/problem domain level [15], [31], they did not fit the telemedicine application or give analytic guidance as found in the Domain Theory. The Domain Theory aims to assist design for reuse by providing a set of abstract models to guide analysis and assist design for reuse with design rationale and generic requirements. The case study demonstrated that while some advice was useful there were several gaps that need to be addressed by improvements to the DT library. Mapping to the GOF patterns provided interesting lessons about the relationships between problem and solution domain abstractions. It appears that most GOF patterns are motivated by design concerns not shared by the Domain Theory; however, monitoring/observation models are the exception. Other reuse approaches that integrated problem and solution space are application frameworks [5] and Enterprise Resource Plans [9]. These tend to be oriented more strongly towards middleware (e.g. network support) instead of general applications. We are not aware of any generalized framework for CSCW support, although a reuse library could be developed from a multimedia telecommunication services framework [5]. However, this framework does not contain models for shared object control, authentication and many other functional areas in the case study. Similarly, reuse of ERPs would not have been profitable because they do not provide appropriate abstractions for CSCW (or telemedicine). In contrast, the small-scale, abstract models of the Domain Theory allowed rapid design by composition. The downside is finding many small-scale abstractions in a complex application area. Our future work will continue to augment the Domain Theory library with more knowledge, and increase links to design solutions to improve its utility. Further case studies need to be undertaken, and follow-up studies are planned to investigate how the CSCW-telemedicine reuse library created using the Domain Theory fares when it is tested in design by reuse.
Acknowledgements The case study was part of a research project at BTexact Technologies. The authors need to give special thanks to the project leader, Alan Smith, as well as to Dr Chris Voudouris whose comments were useful for the structure and syntax of this paper.
References 1. Arango, G., Schoen, E., Pettengill R.: Design As Evolution and Reuse.Proceedings: 2nd International Workshop on Software Reusability (Advances in Software Reuse). IEEE Computer Society Press, Los Alamitos CA (1993) 9-18 2. Prieto-Diaz, R.: Domain Analysis: An Introduction. Software Engineering Notes 15 (1990) 47-54 3. Tracz, W.: Confessions of a Used Program Salesman: Institutionalizing Software Reuse. Addison-Wesley, Reading MA (1995) 4. Vici, A.D., Argentieri, N., Mansour, A., d’Alessandro, M., Favaro J.: FODAcom: An Experience with Domain Analysis in the Italian Telecom Industry. In .Devanbu, P., Poulin J.: Proceedings: Fifth International Conference on Software Reuse. IEEE Computer Society Press, Los Alamitos CA (1998) 166-175 5. Fayad, M.E., Johnson R.E.: Domain-Specific Application Frameworks: Frameworks Experience by Industry. John Wiley, New York (2000) 6. Johnson, R., Foote B.: Designing Reusable Classes. Journal of Object Oriented Programming 1 (1988) 22-35 7. Gamma, E., Helm, R., Johnson, R., Vlissides J.: Design Patterns: Elements of Reusable Object-Oriented Software, Addison Wesley, Reading MA (1995) 8. Coplien, J.O.: Software Patterns. SIGS, New York (1996) 9. Keller, G., Teufel T.: SAP/R3 Process Oriented Implementation. Addison WesleyLongman, Reading MA (1998) 10. Krumbholz, M.: The Impact of Largescale ERP Implementations on Organizations with Diverse Corporate, Business and National Cultures.Proceedings: Doctoral Symposium 4th IEEE International Symposium on Requirements Engineering. IEEE Computer Society Press, Los Alamitos CA (1999) 11. Sutcliffe, A.G., Maiden, N.A.M., Bright B.: An Evaluation Framework for Representations. In Requirements Engineering. Proceedings: Interactive Software Development. IEEE Computer Society Press, Los Alamitos CA (1997) 12. Sutcliffe, A.G.: The Domain Theory: Patterns for Knowledge and Software Reuse. Lawrence Erlbaum Associates, Mahwah NJ (in press) 13. Sutcliffe, A.G., Maiden N.A.M.: The Domain Theory for Requirements Engineering. IEEE Transactions on Software Engineering 24 (1998) 174-196 14. Jackson, M.: Problem Frames: Analysing and Structuring Software Development Problems. Pearson Education, Harlow (2001) 15. Fowler, M.: Analysis Patterns: Reusable Object Models. Addison Wesley, Reading MA (1997) 16. Gentner, D.: Structure-Mapping: A Theoretical Framework for Analogy. Cognitive Science 7 (1983) 155-170 17. Maiden, N.A.M., Sutcliffe A.G.: Requirements Critiquing Using Domain Abstractions. In Proceedings: First International Conference on Requirements Engineering. IEEE Computer Society Press, Los Alamitos CA (1994) 184-193 18. Maiden, N.A.M., Sutcliffe A.G.: Analogical Retrieval in Reuse-Oriented Requirements Engineering. Software Engineering Journal 11 (1996) 281-292 19. Maiden, N.A.M., Mistry, P., Sutcliffe A.G.: How People Categorise Requirements for Reuse: A Natural Approach. In Harrison, M.D., Zave P. (eds.) Proceedings: 1995 IEEE International Symposium on Requirements Engineering (RE ’95). IEEE Computer Society Press, Los Alamitos CA (1995) 148-155 20. Sutcliffe, A.G.: Bridging the Communications Gap: Developing a Lingua Franca for Software Developers and Users. In Actes du XVIIIe Congres: INFORSID. Inforsid, Toulouse (2000) 13-32
21. Wirfs-Brock, R., Wilkerson, B., Wiener L.: Designing Object-Oriented Software. Prentice Hall, Englewood Cliffs NJ (1990) 22. Johnson, P., Johnson, H., Waddington, R., Shouls R.: Task-Related Knowledge Structures: Analysis, Modelling and Application. In Jones, D.M., Winder R. (eds.) Proceedings: HCI ’88. Cambridge University Press, Cambridge (1988) 35-61 23. Annett, J.: Recent Developments in Hierarchical Task Analysis. In Robertson, S.A. (ed.): Contemporary Ergonomics 1996. Taylor Francis, London (1996) 24. Zhou, M.X., Feiner S.K.: Visual Task Characterization for Automated Visual Discourse Synthesis. In Proceedings: Human Factors in Computing Systems: CHI ’98. ACM Press, New York (1998) 392-399 25. Wehrend, R., Lewis C.: A Problem-Oriented Classification of Visualization Techniques. In Proceedings: First IEEE Conference on Visualization: Visualization 90. IEEE Computer Society Press, Los Alamitos CA (1990) 139-143 26. Rudkin, S., Smith A.: A Scheme for Component-Based Service Deployment. In Proceedings: Conference on Universal Service Markets. (2000) 27. Rudkin, S., Alan, S., Papamargaritis G.: COMPOSE: A Component-Based Service Provision Architecture. Martlesham, BTexact Technologies (2001) 28. Potts, C., Takahashi, K., Anton A.I.: Inquiry-Based Requirements Analysis. IEEE Software 11 (1994) 21-32 29. Sutcliffe, A.G.: Modelling Business Goals and Requirements Acquisition (Centre Report HCID/93/10). School of Informatics, City University, London (1993) 30. Anton, A.I., Potts C.: The Use of Goals to Surface Requirements for Evolving Systems. In Proceedings: 1998 International Conference on Software Engineering: Forging New Links. IEEE Computer Society Press, Los Alamitos CA (1998) 157-166 31. Borchers, J.: A Pattern Approach to Interaction Design. John Wiley, Chichester (2001)
