In the field of Knowledge Engineering, dissatisfaction with the rapid-prototyping approach has led to a number of more principled methodologies for the construction of knowledgebased systems. Instead of immediately implementing the gathered and interpreted knowledge in a given implementation formalism according to the rapid-prototyping approach, many such methodologies centre around the notion of a conceptual model: an abstract, implementation independent description of the relevant problem solving expertise. A conceptual model should describe the task which is solved by the system and the knowledge which is required by it. Although such conceptual models have often been formulated in an informal way, recent years have seen the advent of formal and operational languages to describe such conceptual models more precisely, and operationally as a means for model evaluation. In this paper, we study a number of such formal and operational languages for specifying conceptual mode...

The Knowledge Acquisition and Representation Language (KARL) combines a description of a knowledge-based system at the conceptual level (a so-called model of expertise) with a description at a formal and executable level. Thus, KARL allows the precise and unique specification of the functionality of a knowledge-based system independent of any implementation details. A KARL model of expertise contains the description of domain knowledge, inference knowledge, and procedural control knowledge. For capturing these different types of knowledge KARL provides corresponding modeling primitives based on Frame-logic and Dynamic Logic. A declarative semantics for a complete KARL model of expertise is given by a novel combination of these two types of logic. In addition, an operational definition of this semantics, which relies on a fixpoint approach, is given. This operational semantics defines the basis for the implementation of the KARL interpreter which includes appropriate algorithms for efficiently executing KARL specifications. This enables the evaluation of KARL specifications by means of testing. 1

this article, the two most important reasons for this are: . The design process needs to be based on experience with both the work to be supported and the technical possibilities and limitations. Few will probably argue against this. Our point, however, is that this eventually requires an approach in which professional designers and end users cooperate on several of the major design activities. The experience of the end users cannot be effectively mediated by representations of work or representatives of users, such as systems analysts or ethnographers. By such mediation, experience with the work being supported is frozen at the level of explicit understandings existing at the time when the representation of work is made or when the user-proxy finishes his or her analysis. When this understanding is challenged in subsequent design processes, the processes deteriorate --- unless end users themselves are there to create new understandings of the work [19]

. The ways in which we approach systems development practice and research play a major role in shaping professional development within our field. This paper investigates a particular approach, Reflective Systems Development, which has been developed over the past twenty years by a small group of mainly Danish researchers in collaboration with practitioners and students. In this approach, researchers focus on how computer-based information systems are developed in practice; they emphasize the important role played by the local organizational environment; and they combine interpretive understandings of practice with normative propositions to support professional development. The purpose of the paper is to present and evaluate the underlying assumptions and practices of Reflective Systems Development focusing on the following questions: How should we understand, support, and improve practice ? How should we organize and conduct research? How should we relate practice and...

Contents Danish Summary (Dansk Resumé) 1 Acknowledgements 4 1. Introduction 6 1.1 Background........................................................... ..................................... 7 1.2 Cooperative analysis ..................................................................... .......... 11 1.3 Notes on vocabulary ..................................................................... ........... 11 1.4 Progression of this thesis ..................................................................... ... 14 2. Empirical background 18 2.1 The AT-project........................................................... .............................. 20 2.2 The EuroCoOp and EuroCODE projects................................................ 31 3. Six approaches to analysis 46 3.1 Yourdon: Managing the System Life Cycle............................................ 47 3.2 Jackson: System Development ......................................................

Providing the financial engineering community with adequate software tools presents several challenges to application developers. Experience shows that reusability-oriented software development as supported by object technology has the potential to meet these challenges. To back the argument, a project of building a pilot implementation of a swap valuation system using a comprehensive class library including an application framework is reported. As a novelty the project emphasized the use of so-called design patterns. The project experience suggests that the use of design patterns significantly eases the application of a large class library and facilitates the reuse of design.

. To close the gap between knowledge level and symbol level, the MODEL-K language allows to specify KADS conceptual models and to refine them to operational systems. Since both activities may be arbitrarily interleaved, early prototyping is supported at the highest level. Systems written in MODEL-K contain their conceptual model, making them more transparent, easier to communicate to the expert, to explain to the user, and to maintain by the knowledge engineer. The strategy layer of KADS is supposed to control and possibly repair the activities being modeled by the lower layers. MODEL-K views this kind of strategic reasoning as a meta-activity. In the REFLECT project, we came to view meta-activities like resource-management or competence assessment as ordinary problem solving methods, that in turn can be described using KADS. Correspondingly, we extended MODEL-K to model and operationalize such meta-activities. In particular, the lower three layers and the system they mod...

This paper explores the notion of ‘provocation through concrete experience’ towards a provotyping approach. It addresses the question: How do we on the one hand, devise qualitatively new systems, and on the other hand, ensure their usability in a given practice? The notion of provocation through concrete experience is developed through an investigation of prototyping and activity theory. Exploration of this notion leads to the idea of the systemdeveloper ‘provoking ’ concrete, everyday practice, by exposing current problems, calling forth what usually is taken for granted. Problems with current practice and a lack of mutual understanding, usually conceived of as hindrances to successful systems development, are used constructively. These ideas are compared to four related approaches: Future Workshops, Metaphorical Design, Cooperative Prototyping, and Organizational Games. The comparison serves the twofold purpose of contextualizing the new ideas as well as developing techniques for carrying themout.

A major part of software architecture design is learning how specific architectural designs balance the concerns of stakeholders. We explore the notion of “architectural prototypes”, correspondingly architectural prototyping, as a means of using executable prototypes to investigate stakeholders’ concerns with respect to a system under development. An architectural prototype is primarily a learning and communication vehicle used to explore and experiment with alternative architectural styles, features, and patterns in order to balance different architectural qualities. The use of architectural prototypes in the development process is discussed, and we argue that such prototypes can play a role throughout the entire process. The use of architectural prototypes are illustrated by three distinct cases of creating software systems. We argue that architectural prototyping can provide key insights that may otherwise be difficult to obtain before a system is built. Furthermore, they define skeleton systems that serve as communication means and knowledge transfer among stakeholders. 1

An important activity in software development is the testing of developed software using the appropriate techniques. Obviously, these techniques have to take into account the type of the software process and the type of the developed software. This article proposes a technique for testing classes developed during a special type of software process, namely object-oriented prototyping. Furthermore, the technique developed is suited for application domains requiring a high degree of quality of the deployed software. The main idea of our approach is to interpret each prototyping iteration as a correction of the software, similar to corrections taken during the maintenance phase. With this interpretation in mind, we tried to adopt regression testing techniques for testing prototype classes. Unfortunately, all regression testing techniques we have studied have some shortcomings limiting their applicability to testing prototypes. Therefore, we have developed a new technique that integrates two existing techniques resulting in one which can be used for both white- and black-box testing. Keywords Integrated white- and black-box testing, class-level