The present work describes a technology for developing software in unique and large projects. The present model-based technology supports the projects where a single software product is developed. This is di erent from the block languages and model-based software tools on the market, which provide a set of components where the reusability of the components is an important requirement. A distinguished feature of the technology is a support that it gives to the software design at an early stage of the design process. The design process begins on the architectural level where implementation details can be ignored. Components are introduced considering their functionality, but the implementability of a component is taken into account at the early stage of the design process only based on an experience of a designer.
The present paper describes a technology for developing software in unique and large projects. Contrary to the model-based software tools on the market, which support the development of a set of components where the reusability of the components is an important requirement, the present tool and technology support the projects where a single software product is developed. The reusability is a bene cial, but not necessary property of the components designed and developed with this technology.
A distinguished feature of the technology is a support that it gives to the knowledge-based design of software at an early stage of the design process. One can say that the design process begins on the architectural level where implementation details can be ignored. Instead of classes, components are introduced. The implementability of a components can be taken into account only based on an experience of a designer. This design technology is intended to be analogous to the architectural design in other engineering areas like civil engineering or mechanical engineering.
Implementation of a component results in a class, but an implemented component has also a formal speci cation used in composition of the software system { the metainterface. Beside that, a component may support (local) protocols for communicating with other components. A component can be considered as a knowledge module, or even an agent, operating in a coordinated way with other components. 2
We present here a de nition and a notation of knowledge module that can be
used for describing software architecture on the knowledge level. A knowledge
module is considered as a pair of sets: a set S of notations (objects) and a set M of
denotations (meanings of notations) together with a notation-denotation relation
between these sets. (This gives interpretation of the notations.) Also means to
perform operations on the set S must be given, although we do not specify these
means here, see details in [
Hierarchical connection. We say that knowledge modules K1 and K2 are hierarchically connected, i there is a relation R between the set of meanings M1 and the set of objects S2, and strongly hierarchically connected, i there is a one-to-one mapping between the elements of a subset of M1 and of a subset of S2, see Fig. 2. A hierarchical connection of knowledge modules can be observed quite often in real life. An example is deductive program synthesis. The knowledge system of logic and the calculus of computable functions (CCF) are strongly hierarchically connected, because there exists a Curry-Howard isomorphism of proofs and formulae as types, see Fig. 2b.
Semantic connection. Knowledge modules that have one and the same set of meanings are semantically connected. This is the case, for instance, with classical
K1 M1 K2
S2 (a)
R
Intuitionistic logic logic systems that have di erent sets of inference rules, or even with natural languages that belong to closely related cultures (i.e. that have the same set of meanings). Graphical notation of semantic connection is shown in Fig. 3a.
K1
K2
K1
K2
K1
K2 (a) (b) (c) Operational dependence and operational connection. Knowledge module K1 is operationally dependent on a knowledge module K2, if some of its derivation rules use K2 in deriving a new object, i.e. the result of derivation in K1 depends on knowledge processing in K2, Fig. 3b.
Knowledge modules K1, K2 are operationally connected, if K1 is operationally dependent on K2, and K2 is operationally dependent on K1. Graphical notation of this connection is shown in Fig. 3c. The notations presented here are used for the architectural design of software at the rst stage of a software project. 3
The rst stage of design of a software system is its architectural design. At this stage, only the most general structure of the system is developed and speci ed by the knowledge architectural means. It is important to decide, which knowledge modules are needed, and how they will be connected. The input for this stage is a speci cation of functional requirements.
graphics texts logic CCF (a) user interface (b) texts logic CCF
Java
We present our technology on an example of design and development of a
model-based software tool CoCoSynth that includes also a program synthesis
functionality. For a speci cation of functional requirements, we refer to [
It follows from the documentation of CoCoViLa that there must be two hierarchically connected knowledge modules logic and CCF that support the deductive program synthesis as it has been shown in Fig. 2b. This is the core of the software tool. We see also from the documentation that the input of the tool is not in a logical language, but in a textual domain-oriented speci cation
language and/or in a visual language. This adds two more knowledge modules: texts and graphics to the architecture of the tool. These knowledge modules are hierarchically connected with the logical module, Fig. 4a. Operation of the tool is controlled by a user through a visual user interface that is also a knowledge module. We can describe this connection by operational dependence of this module on other modules. If we wish to show also the functionality that re ects the usage of Java at runtime, then we have to add a Java knowledge module tool as shown in Fig. 4b. 4
This stage includes a conceptual analysis of the domain, and can be called also domain engineering, although the domain is presented by a single new software product in this case. Having an architectural description of software, one can take the knowledge modules of this description as components in the rst place. However, these components may be too large or too small. The knowledge modules can be sometimes divided into smaller components, or collected into a single component, considering their functionality and realisability. A separate component may be required for representing a hierarchical relation between the knowledge modules. This will be demonstrated on the example below.
In the present example, we keep the user interface knowledge module as a separate component controller. The knowledge modules graphics and texts will be joined into a single component editor, in order to facilitate their usage by controller, because the latter will produce the text in parallel with the graphics. We keep the knowledge module of logic as a separate component planner. This name re ects the purpose of the logic component that synthesises an algorithm of the software product. The hierarchical connection between editor and planner will be represented by a separate component parser which transforms a text into logical formulae. The computational knowledge module CCF gives a component called exe. Also a hierarchical relation between planner and exe will be represented by a separate component generator which generates a Java program that has to be run. We introduce an additional component algorithmVisualiser for the visualisation of synthesised algorithms. 5
The tool used in our technology must support convenient implementation of
components, preferably visual speci cation of software models and automatic
code generation from a model. The tool CoCoViLa [
The speci cation editor, referred further as CoCoViLa itself, uses a package of components for specifying tasks in respective domain or, in the present case, specifying a software model, and it supports code generation from the model. Essential working principles of this tool are the following: { besides a visual representation, each software component has two parts: 1) logical speci cation of the component (LO), called metainterface, 2) objectoriented (OO) realisation of the component { a Java class; { a component is called metaclass, because after program synthesis it may be transformed into several di erent classes; { object-oriented and logical parts have separate namespaces, except for names of methods from OO used in LO { this enables one to write speci cations of components almost independently of their Java realisations; { OO and LO have a common type system.
Metainterface has a precise logical semantics given as a set of formulas { axioms
with realisations given by methods of its Java class. These formulas constitute
a theory in intiutuonistic logic that is used by structural synthesis of programs
[
Components can be de ned hierarchically, i.e. a metainterface of a component may contain components whose types are given by metaclasses, i.e. by other components. Also equations, as well as some other language constructs can be used in the metainterface. A metaclass may consist of a metainterface only, e.g. in a case when computations are speci ed by equations. Metainterface is written in a speci cation language, and it is included as a comment in the Java class of the component between /*@ ... @*/. We give an example of a metaclass now. The metaclass And represents a logical element (and-gate) for signals represented by 0 and 1. It includes a Java method calc as a realisation of the axiom in1, in2 -> out. s p e c i f i c a t i o n And f i n t i n 1 , i n 2 , out ; i n 1 , i n 2 > out f c a l c g ;
Lines 02 to 06 of the example are a metainterface. Line 04 is a variable speci cation of integer variables, and line 05 is an axiom. All Java classes and metaclasses can be used as type speci cations. Lines 07 and 08 are in Java, and describe the method calc referred to in the axiom. An axiom is a formula of a conjunctive-implicative fragment of intuitionistic propositional logic, where commas represent conjunction symbols. 6
Each implemented component has graphics, metainterface and Java class. It is reasonable to start with writing a metainterface, although the development of all three components can occur in parallel.
Writing metainterfaces. A metainterface is written in the speci cation language and included in the class of a component as a comment. Lines 6 to 15 of Fig. 5 show a metainterface for the component PARSER as an example. The metainterface shows that problem can be computed in three steps speci ed by the axioms in lines 12, 13 and 14.
Developing graphics. For developing graphics of a component one uses the Class Editor program of CoCoViLa that supports the development of visual representation of the component, de nition of ports for binding components, as well as description of properties of component as it is described in the documentation of the Class Editor.
Implementing methods. Class of a component is created already when a metainterface is written. This class must be completed by writing all methods referred to in axioms of the metainterface. In the case of the component PARSER in our example, the methods are getMainClassName , m a k e C l a s s L i s t , makeProblem .
It is obvious that in these methods, other methods may be used that need to be implemented as well. This is a usual program development in Java. For instance, we see that he method getClassName of a class SpecParser is used in addition in the method getMainClassName.
As our example is in essence redeveloping CoCoViLa, it is reasonable to use its classes as much as possible for the implementation of methods. We have used the source code of CoCoViLa, that consists of 240 Java classes, totally about 30K lines of code. These classes were developed without any restrictions on programming in Java. Our experiment has shown that most classes could be used as is, or with only minor changes, depending on the developed metainterfaces. Static model of software. When components are implemented, a high-level structural model of software can be written immediately in CoCoViLa specication language or drawn as a diagram. This is called static model. For the synthesis, the static model is automatically translated into a metainterface of a new Java class.
The static model is a speci cation for the tasks that the system has to perform. Programs for the tasks are synthesized automatically. When translated into logic, the static model describes a theory representing all possible computations on the model. Let us denote by G the set of the goals that describe the tasks solvable on the model. Each goal is written in the form
x1; x2; : : : ; xm ! y1; y2; : : : ; ym; where x1; x2; : : : ; xm; y1; y2; : : : ; ym are variables of the static model, e.g. specication, problem, algorithm etc. in our example. These variables are considered in logic as propositional variables of the theory, and commas as conjunction symbols. Fig. 6 shows the static model where all components described in the previous section are present.
Dynamic model. The static model describes only tasks that the software can perform, but not a user interface to invoke these tasks. In order to describe the interaction between a user and the system, a dynamic model of GUI is introduced. This model is speci ed as a statechart. This statechart may be explicitly given as a part of a requirements speci cation, or it may be implicitly described by other requirements. In the latter case, the development of the statechart is performed in a conventional way, e.g. as recommended by some UML-based technolgy.
Each transition t in the dynamic model is marked by an event e(t) and a goal g(t). The event is either a user action (e.g. pushing a button) or an event created by the system that triggers some transition. The goal describes a task to be performed on the static model when the transition t occurs. The tasks for all transitions must be solvable on the static model, i.e. for every task t must be g(t) 2 G. Fig. 7 shows abstractly a fragment of the dynamic model, and the connection between the static and dynamic models with the tasks u ! v, x ! y and events denoted by a and b.
The dynamic model must be implemented as a component that becomes a superclass for the class of the static model. In our example, this is the component controller. Fig. 8 shows a part of the dynamic GUI model for our example with events created by user commands Run, Compute goal, Compute all, Scheme. One can nd meaning of these commands from the documentation on CoCoViLa. The respective tasks for the commands are c ! speci cation c; speci cation ! algorithm c; algorithm ! code c; speci cation; goal ! algorithm c; speci cation ! results c; speci cation ! schemeMenuOpen; where c is a control and context variable. The user interface is implemented as a component as described above. Its functionality is described by the dynamic model that is in the form of a statechart. Java technology can be used in full in this implementation. However, implementation of a connection between of the dynamic and the static model by means of events and tasks deserves a special attention, and here are some hints for this. 1. The user interface component (controller in our case) can be implemented as a superclass for the static model. This enables one to use the names of variables of the static model for representing the tasks to be solved on it. 2. A task is always invoked by a respective event (see the dynamic model). The event is handled by an event handler in Java. Hence a call of program for a task must be included in the event handler. 3. As a program for a task is synthesised automatically using SSP, each task must be described by an implication in an axiom whose implementation creates event handlers. In our example, the event handlers are created by the method initGUI. Its axiom, included in the metainterface of controller, is as follows: [ c > s p e c i f i c a t i n ] , [ c , s p e c i f i c a t i o n > algorithm ] , [ c , algorithm > code ] , [ c , s p e c i f i c a t i o n , g o a l > algorithm ] , [ c , s p e c i f i c a t i o n > r e s u l t s ] , [ c , s p e c i f i c a t i o n > schemeMenuOpen ] , c > doneinitGUI f initGUI g ; 8
When the static model is implemented including the dynamic model as a superclass, a new program can be synthesised automatically by giving command Run from Scheme menu of the CoCoViLas main window. This means bootstrapping CoCoViLa in our CoCoSynt example.
The bootstrapping process and its results can be explained in Fig. 9. It shows the windows that open during the bootstrapping and running the bootstrapped tool. The two upper windows belong to CoCoViLa, they are a diagram of the static model of the new CoCoViLa (CoCoSynth) and the Java code of CoCoSynth synthesized in CoCoViLa. This completes the development of the new tool CoCoSynth.
The static model di ers from the model in Fig. 6 by more compact presentation, where ports of the components are directly connected with each other without intermediate data components. Also an extra component GUIactions has been added to the model. It includes additional action listeners for the controller. When command Run is given from Scheme menu in this window, CoCoSynth is synthesized and started as well. The lower windows belong to the synthesized CoCoSynth. The leftmost window is the main window of CoCoSynth, it opens automatically after Run command given from CoCoViLa. It can be used for loading packages, drawing diagrams and performing computations. We see a package Gearbox loaded, and a diagram with several wheels, a motor and two visualizer components in it. After invoking Speci cation... command from Scheme menu of CoCoSynth, a new speci cation window opens according to the dynamic model.
This window can be used for textual editing of speci cation, for synthesizing application programs, for running these programs and for some other actions. After the command ComputeAll from the speci cation window, this window will show the synthesized Java program (partially visible in the second window from left). After the command Compile &Run from this window, the synthesized program is compiled and executed and, in our example, a table of results is calculated and visualized (visible in the lower right window). Also a small part of algorithm for calculations on gearbox is visible from behind the result window. As the structural synthesis of programs used in CoCoViLa is fast, the whole process of bootstrapping and creating these windows takes less than 30 seconds (including interaction with a user, e.g. opening windows from GUI, etc) in the case when the diagrams are ready and loaded from some repository. 9
Model-based software development (MBSD) has been increasingly popular
during several decades and a number of tools supporting implementation of
modeldriven principles have developed. The comprehensive study of achievements in
the eld can be found, for example, in the book [
UML2 is de facto standard not to be ignored in model-based software development. Our technology uses two kinds of UML diagrams: statecharts and component diagrams. However, we have implemented the semantics of these diagrams in a way that guarantees automatic code generation from them for large 2 www.uml.org
Java software including more than two hundred classes. This is a di erence from
the existing examples of code generation from UML models, e.g. [
Considerable amount of work is being done in improving the existing
UMLbased approaches with the aim of providing automated support to the software
development[
The system CoCoVILa used in this papaer belongs to the another research
direction in the MBSD { Model-Integrated Computing (MIC) that addresses
the problems of designing, creating, and evolving information systems by
providing rich, domain-speci c modelling environments including model analysis
and model-based program synthesis tools [
CoCoViLa has been applied mainly as a model-based simulation tool [
A technology with automatic code generation from models has been
developed by Steven Kelly and Juha-Pekka Tolvanen. Their technology and tool
MetaEdit+ have been well described in literature [
Bootstrapping of software tools has been popular since early days of computing. It was helpful in developing compilers for new hardware, when there was no tool support on hardware. It is a non-trivial test of the language compiled. A list of languages having self-hosting compilres today includes 41 names 4. From this perspective, bootstrapping of CoCoViLa can also be considered a good test of our technology.
The presented technology is summarised in Fig. 10. It shows the roles of different experts: domain expert, system engineer, graphic expert and code developer in a project developed in accordance with this technology. We see that after the requirements speci cation, developing the knowledge architecture and components speci cation, one can proceed by developing in parallel components metainterfaces and graphics as well as a dynamic model. Components code could be developed in parallel with graphics and metainterfaces as well, but one will need the dynamic model for writing the user interface component. The most important role has a system engineer, who performs six steps of the project. Also coordination of the project as a whole belongs to his role.
Debugging and testing are not shown in Fig. 10. After developing the static model, its completeness can be tested on tasks prescribed by the dynamic model even before the code of components has been developed. After developing the code of user interface, one can test the interaction of dynamic and static model even without of other components codes. As usual, repetitions of some steps of the technology will be needed when errors are detected.
Acknowledgements This research was supported by Estonian Research Council institutional research grant no. IUT33-13, and by the ERDF through the ITC project MBJSDT and Estonian national CoE project EXCS.