International Journal of Software Engineering and Knowledge Engineering

A software prototyping environment called TransObj (TRANSaction and OBJect) is used for designing real-time Transaction-based Concurrent Software Systems (TCSS). In a TCSS design process, a software designer should perform both functional design and performance design. The designer should change his design view from a transaction-based paradigm to an object-based paradigm during the TCSS design process. Recognition of re-entrant functional objects and serially reusable functional objects in the TCSS should be required. TransObj includes the Stepwise Prototyping Method (SPM), and two SPM-based tools: Prolog-based TransObj (P-TransObj) and GPSS-based TransObj (G-TransObj). SPM enables the designer to advance both functional design and performance design for the TCSS prototype as controling the change of design view paradigms. P-TransObj mainly checks the prototype in a microscopic view on a personal computer. G-TransObj mainly checks the same prototype with a longer time span on a large-scale computer.

This paper outlines a framework which supports the use of multiple perspectives in system development, and provides a means for developing and applying systems design methods. The framework uses "viewpoints" to partition the system specification, the development method and the formal representations used to express the system specifications. This VOSE (viewpoint-oriented systems engineering) framework can be used to support the design of heterogeneous and composite systems. We illustrate the use of the framework with a small example drawn from composite system development and give an account of prototype automated tools based on the framework.

Rule-based software development environments (RBDEs) model the software development process in terms of rules that encapsulate development activities, and assist in executing the process via forward and backward chaining over the rule base. We investigate the scaling up of RBDEs to support (1) multiple views of the rule base for multiple users and (2) evolution of the rule base over the lifetime of a project. Our approach is based on clarifying two distinct functions of rules and chaining: maintaining consistency and automation. By definition, consistency is mandatory whereas automation is not. Distinguishing the consistency and automation aspects of RBDE assistance mechanisms makes it possible to formalize the range of compatible views and the scope of mechanizable evolution steps. Throughout the paper, we use the MARVEL RBDE as an example application.

The subject of this paper is the description of a process-centered software development environment called MERLIN which monitors and guides teams of software developers and managers in producing software objects. Software objects (or objects for short) include all sorts of documents like requirements analysis, design, code, user manuals, contracts etc. For each user, MERLIN automatically displays a specific working context which contains information like objects, their relations, their current development state, and corresponding tools. This information is filtered according to the (access) rights and duties a particular user has in a particular project, i.e. the working context depends on the user's role (e.g. programmer, designer, manager). Internally, the computation of the information to be contained in a working context, is based on a rulelike definition of a software process and a flexible interpretation mechanism to enact such a process definition. The main feature of the interpreter is an alternating use of backward and forward chaining for the interpretation of rules. In addition, our implementation enables a persistent storage and incremental update during runtime of all process information expressed in facts within the MERLIN knowledge base.

This article investigates the notion of reasoning types and tries to contribute to its clarification, placing special emphasis on relationships to AI programming paradigms. There are probably several different dimensions of reasoning. Here we identify two dimensions, one of which orders reasoning types along the scale "inductive/deductive", whereas the other is closely related to programming paradigms. We would argue for the combination of reasoning types along both these dimensions. In fact, we have integrated heuristic and causal reasoning with various AI programming paradigms and traditional procedure-oriented programming in a kind of hybrid programming, using each method where we decided it fit "best". Since we concentrate in this article on software engineering aspects of building knowledge-based systems, we focus on issues related to the second dimension. In particular, the control knowledge can be represented by a stylized combination of rules and conventional procedures. We postulate that there is a whole spectrum between these extreme paradigms, and that an appropriate balance in the combination of rule-based and procedure-oriented programming can fit the given degree of ordering. Object-oriented programming and frame-based representation serve as a useful means for integrating multiple programming paradigms. Finally, we describe the duality of abstract data types and access-oriented programming, utilizing this view for some suggestions for their respective use.

Rule-based systems are being applied to tasks of increasing responsibility. Deductive methods are being applied to their validation, to detect flaws in these systems and to enable us to use them with more confidence.

Each system of rules is encoded as a set of axioms that define the system theory. The operation of the rule language and information about the subject domain are also described in the system theory. Validation tasks, such as establishing termination, unreachability, or consistency, or verifying properties of the system, are all phrased as conjectures. If we succeed in establishing the validity of the conjecture in the system theory, we have carried out the corresponding validation task.

If the proof is restricted to be sufficiently constructive, we may extract from it information other than a simple yes/no answer. For example, we may obtain a description of a situation in which an error or anomaly may occur.

A method for the gradual formulation of specifications based on the attempted proof of a series of conjectures has been found to be suitable for rule-based systems. Such a specification can serve as the basis for a reengineering of the system using conventional software technology.

Validation conjectures are proved or disproved by a new theorem-proving system, SNARK, which implements (nonclausal) resolution and paramodulation, an optional constructive restriction, and some facilities for proof by induction. The system has already been applied to prove properties of a number of simple rule-based systems.

This paper discusses an object-oriented software requirements analysis method. The approach adopted here draws clear distinction between a system's basic structure (i.e. the object model) and its functionalities. The analysis model generated is a description of a problem domain; it consists of a set of primary and secondary objects that characterize the problem domain, and a set of pseudo objects that define the functional requirements of a system.

There are two stages of analysis in the proposed method: Object Modelling and Functional Requirements Modelling. These two stages are built upon one another. The aim of the object modelling stage is to derive a model of the problem domain in terms of objects, their classification and inter-relationships with one another. The functional requirements modelling stage builds upon this initial object model to complete the requirement analysis specification.

This paper uses a real-life library environment to illustrate how the method can be applied in the specification of an object-oriented software system.