Yframe: a Modular and Declarative Framework

for Software Engineering ∗

Manuel Kolp Esteban Zimányi
University of Toronto, University of Brussels,
Department of Computer Science, Department of Informatics,
10 King’s College Road, 50 Av. F.D. Roosevelt,
Toronto, Ontario M5S3G4, Canada, CP 165-15, 1050 Brussels, Belgium
e-mail: [email protected] e-mail: [email protected].

Abstract
This paper describes Yframe, a modular and customizable framework
supporting the process of both object-oriented method engineering and
OO software engineering. We show how a declarative language like Prolog
can be used to design such a tool including a sophisticated Graphical User
Interface. We explain the essential role of a declarative programming
approach in developing this framework, illustrating its advantages and
facilities.
Keywords: Prolog, object-oriented development, CASE tool, modeling
framework, software architectures.

1 Introduction
This section presents some considerations and basic aspects of the software en-
gineering history, the so-called software crisis, and the object paradigm aimed at
remedying it. Then, we introduce the motivation of Computer-Aided Software
Engineering, its evolution and describe the modeling and development context
in which we have designed Yframe.

1.1 The software crisis

It is almost certain the term software engineering was first used at a NATO
conference in 1968. Since these far-off days, analysts and developers have al-
ways realized the importance of a systematic approach to cope the software
development process with a rapidly-changing reality. At the same conference
it was also revealed that a software crisis existed. It was a recognition that
∗ This work is part of the YEROOS (Yet another Project on Evaluation and Research on

Object-Oriented Strategies) project, principally based at the University of Louvain and the
University of Brussels. It was partially supported by FNRS grants 8.4702.94 and 8.4505.97.

1
something was fundamentally wrong with the production of software, especially
large and complex ones. While small systems were relatively easy to build, pro-
fessionals quickly learned that huge systems were difficult and often impossible
to design. At that time, the state of the industry was simply not ready to handle
such complexity. Naturally, the lesson was learned the hard way; systems were
rarely delivered on time and were nowhere near the initial budget.
Early attempts to solve this complexity did not produce any tangible solu-
tions. The software gurus incorrectly identified the production of code as being
the main cause of problems. Hence this brought a scourge of techniques that
were introduced and tackled the problems at the code level. The late 60’s and
early 70’s saw a large number of techniques for developing and documenting
low-level designs ”structured flow charting” being a well known example. Due
to the lack of success of the ”instant pot noodle solutions” of the 60’s and early
70’s, the mid and late 70’s brought a change of approach and the problems
of specification, design, measurement and management began to be addressed.
This period saw the introduction of a variety of techniques that focused on the
early phases of the software development life cycle.
System development methods from that time used a”structured” approach
based on a functional decomposition paradigm by wich system functionalities
were specified through a ”black-box” view. But, while these methods were suit-
able for describing systems driven by data transformations, they were inade-
quate for coping with more sophisticated technologies like networks, distributed
computing, real-time systems or man-machine interfaces. A key problem was
that structured methods were only of limited use in describing the run-time
behavior of hardware and software applications.
The object paradigm has grown from the mid 80’s to be the primary tech-
nology aiming at addressing this software crisis. Although most concepts of
object technology are not new, the technology as a whole (which has by now
become mainstream in the software development industry) concerns all aspects
of the software life cycle and proposes a constantly improving methodology to
software development and deployment.

1.2 The Object Paradigm

Object-oriented (OO) methods (e.g., [RBP+ 91, JCJO92, MO92, Boo94, CAB+ 94,
DW98, MO98, BRJ99]) led to a new way of thinking about problems with mod-
els organised around real-world concepts. The fundamental construct is the
object, which combines both data structure and behavior in a single entity.
Object-oriented methods are useful for understanding problems, communicat-
ing with application experts, modeling entreprises, preparing documentation
and designing programs and software.
OO methods generally agree on the decomposition of the development life
cycle into several steps: requirements specification, analysis, system design, ob-
ject design, and implementation. Requirements specification consists of eliciting
requirements from the users. Analysis starts from these requirements and builds
a model of the real-world situation showing its important properties. System

2
design makes high-level decisions about the overall architecture of the system
and its components. Object design builds a design model based on the analysis
model but containing implementation details. Implementation translates the
object classes and relationships developed during object design into a particular
programming language, database or hardware implementation.
OO methods use several kinds of models to describe a system. Each model
captures a particular type of information or viewpoint about the system at a
particular step of the development life cycle. These models are orthogonal parts
of the description of a complete system and are cross-linked. A few examples of
models proposed by the different methods are as follows.
An object model describes the static structure of the objects in a system;
usually such a model is a improved and extended variant of the classical entity-
relationship model. A dynamic model describes the aspects of a system that
change over time and implements the control aspects of a system; such a model
is usually based on state machines, statecharts, or Petri nets. A functional model
describes the data value transformations within a system; usually such a model
is a variant of the data flow diagrams. A requirements model, usually based on
use cases, specifies the system operations, i.e., the set of transactions between
the system and the agents in its environment. Object interaction graphs define
an implementation of system operations stating the objects involved and how
they communicate to realize the specification.
Each OO method has its own characteristics both with respect to the kinds of
models they use to represent a system and to the steps prescribed to construct
such models (the process). Some models appear in several methods, like the
object model which is common to all methods. However the variations of such
models in each method may be significant. For example, there is still a debate
on whether an object model should contain relationships of the kind found in
ER models.

1.3 Our Framework

Due to the ever-increasing complexity of software engineering, a significant re-
search activity was the development of Computer-Aided Software Engineering
(CASE) tools (e.g. [MNS96]). Significant development in CASE tools has been
spurred on by rapid advances in computing power. The basic idea behind CASE
is to support each phase of the software life cycle with a set of laboursaving tools
and aim at improving both the productivity and the quality of the software by
taking care of tedious tasks. They give automated assistance in the form of
automated diagram drawing, screen painting, and corrections checking. Others
focus on the implementation phases of the life cycle. They include automated
code and test case generators.
However, new objectives for OO development continually arise. In par-
ticular, technological aspects such as client/server architectures, distributed
computing, parallel, information systems, component-ized software that can
be downloaded and used in a variety of computing platforms around the world
interraise new requirements for altering the methodological basis of software

3
development.
These new needs lead to the concept of method engineering which concerns
the specification of the syntax and semantics of modeling notations, specification
tasks and their dependencies, and modeling the organization of tasks among
the various actors [MNS96]. To support this activity new computerised systems
called Computer-Aided Method Engineering (CAME) tools are developed for
allowing the user to correctly manage, create or customize design methods to
fit a given development situation.
In this modeling and development context, we have developed in Prolog a
flexible CASE framework supporting both tasks of method engineering and OO
software development. Several methods such as [RBP+ 91, CAB+ 94, Boo94,
JCJO92, KZ00] have already been implemented. Other methods like UML
[BRJ99] and Catalysis [DW98] are currently being integrated into Yframe.
As will be explained in Section 2, our tool is characterized by a high de-
gree of flexibility which permits the user to configure the methods supported
and the ways these methods are supported. Thus, it supports the approach
of incremental method engineering, i.e., methods can be gradually refined on
users’ experiences and learning, and the changing demands of the development
situation.
The use of Prolog for completely building our framework is essential to our
approach. As it is well-known, the declarative nature of Prolog gives it sev-
eral advantages (clarity, modularity, conciness and legibility) over conventional
programming languages and make it more suitable for prototyping. Moreover,
Prolog contributes to the modular and declarative nature of our framework.
For instance, it allows us to easily integrate an important feature to achieve
Yframe flexibility: the representational independence, i.e., the separation of
the conceptual and representational constructs and their flexible combination
in the modeling environment. Finally, we also use Prolog as the only language
for the development of both the GUI and the core of the system. We con-
cretely show that, contrary to what is currently believed, using Prolog for the
development of the entire application is better and more consistent than the
alternative approach of implementing the GUI using an imperative language
and implementing the Inference Engine in Prolog.

The rest of the paper is structured as follows. Section 2 gives an overview

of our framework insisting on its modular ans declarative characteristics while
Section 3 presents the inside architecture. The following sections explain and
illustrate the main components of Yframe. Sections 4 and 5 present, respec-
tively, model management and method management. Section 6 deals with fact
base management. Section 7 is devoted to graphics management while Section
8 explains the GUI management. Section 9 describes an example session for the
Statechart model. Related works on other frameworks and CASE tools for OO
development are discussed in Section 10. Finally, Section 11 gives conclusions
and points to further work.

4
 Figure 1: General layout of Yframe

2 A Declarative and Modular Framework

Figure 1 gives the general layout of Yframe for the Statechart Model. Figure 4
gives the layout of the Object Model Editor. As shown, it has a sophisticated
GUI including graphical schema editors, Multiple Document Interface (MDI)
windows, palettes, tool bars, status bars, menus, dialogue boxes etc. This leads
to a user-friendly and ergonomic development environment only requiring basic
familiarity with Windows or X Window interfaces.
A high degree of modularity and flexibility characterizes Yframe and intu-
itively allows the software developer to configure the implemented methods and
the ways these methods are supported with respect to the user’s requirement
specifications. Thus, it supports incremental method engineering: methods can
be gradually customized, expanded, refined, reduced, and formalized based on
users’ needs and the changing demands of the development life cycle.
For instance, in the system architecture described in Figure 2, UML is actu-
ally integrated into the tool, reusing modules, primitives, rules and constraints
already defined for existing models (e.g., ER+, Statecharts, or Use Cases) or
even methods (e.g., OMT, Booch, Jacobson) since UML (Unified Modeling Lan-
guage) ”unifies” such models and methods previously defined by UML authors.
And, since Catalysis is based on UML, it can be easily added in a similar way.
In order to ensure this level of flexibility, one important characteristic of our
system is the concept of representational independence: while the conceptual
and representational constructs can combined in a customizable way in the
modeling environment, they are implemented separately.
The use of a declarative and intuitive language like Prolog (e.g. [CM84,

5
Bra86, Mos94]) for completely building our CASE environment is then essential
to our approach.
First, the nature of Prolog offers, of course, several well-known advantages
over conventional programming languages such as clarity, modularity, concise-
ness, and legibility. As a result, programs are much closer to the developer’s
perception of the domain and, for this reason, much easier to maintain. This is
especially important in the context of large-scale programming.
Our system has a highly modular architecture to be able to manipulate
different design methods, each one composed of different models. The fact that
Prolog is a dynamic language with untyped variables allowed us to implement
different levels of abstraction, realized by the separation of abstract and concrete
primitives. Abstract primitives are low-level rules and primitives common to any
modules, while concrete primitives are rules specific to a particular modules.
As explained in Section 2, Prolog allows us to define an integrated three-layer
architecture in which the abstract primitives are grouped in a kind of Operating
System called Yframe engine while the concrete primitives, grouped in concrete
model or method subsystems, are ”plugged in” over the Yframe engine.
Prolog offers a powerful and expressive development environment allowing
to separate concepts from algorithmic control. As will be explained in Section 7,
to achieve representational independence, the fact base of our system consists
of two repositories: one stores concepts and the other stores their graphical
representation. These repositories were exploited by the Prolog inference engine,
using the mechanisms of pattern-matching and backtracking.
Second, and more important, we use Prolog as the only language for con-
structing both the Graphical User Interface (GUI) and the core of the system.
We concretely show that, contrary to what is most frequently believed, devel-
oping the entire application in Prolog is better and more consistent than the
alternative approach of implementing the GUI in an more imperative graphical
development language such as Tcl/Tk or Visual C++ and implementing the
inference engine of the system in Prolog. This alternative approach is more
complex, not uniform and sometimes not elegant: for instance, in such a dual
approach on a Windows platform, the Prolog inference engine must be called
through Dynamic Link Libraries (DLLs) in order to be able to use it with the
running GUI on a Windows platform or through Motif-like Libraries on a Unix
platform.
Again, as will be shown in Sections 7 and 8, the memory management fea-
tures of Prolog offer facilities for graphics and GUI development. In constrast
with other imperative languages, Prolog does memory management automati-
cally, freeing the programmer from this error-prone task. Thus, the developer
always works with expressive names instead of low-levels pointers. This was
a major benefit when working with the fairly complex dynamic structures of
graphical applications and sophisticated user interfaces.
Third, Prolog is better suited to framework prototype design than con-
ventional languages: its declarative nature encourages incremental prototyping
where code is gradually fleshed out in a top-down manner over a period of time.
Rather than throwing away the prototype and re-writing the final program from

6
 Y f ra me

Method Layer Con crete Met ho d

compo nen ts
Relational
OMT U ML Jacobson Fusion DB Desig n Meth od
Definition
Mo del Lay er Customized




State Us e GU I
O bj e c t charts DFD OIG Cases

Yf En g i n e Mod el
Definition
Ab stract Ab stract Kno wled ge Customized
Mo d el GUI Bas e Man ager 

GU I

Ab stract Method Ap p lication

 

Grap hics


Gr ap hics
 

Pr imitives


Manag er 

Definition

Con crete Mo del

co mponents

Figure 2: System architecture of Yframe

scratch, incremental prototyping saves development time and costs, and allows
continuous user feedback. Imperative languages are not really suited for incre-
mental prototyping. In this context, Prolog allows us to easily implement new
models and methods but also to reuse, improve and update models and methods
already implemented in the tool.

3 A Three Layer Structure

Figure 2 shows the architecture of Yframe which consists of three integrated
layers. The bottom first layer is the Yframe engine, which is the core of the
system. It implements what we call abstract primitives, that is, low-level prim-
itives and rules common to all modules (models and methods) of higher layers.
This first layer can be viewed as a kind of operating system providing services
to the upper modules. The Yframe engine is composed of six subsystems which
are explained next.
The abstract model subsystem defines primitives for defining concrete models
(e.g., enhanced entity-relationship model) which are implemented in the second
layer. Similarly, the abstract method subsystem contains primitives for defin-
ing concrete methods (e.g., OMT method) which are implemented in the third
layer. The abstract graphics subsystem provides low-level primitives for defin-
ing the graphical representation of models while the abstract GUI subsystem
provides basic rules for manipulating GUI components such as parent/child
windows, menus, dialogue boxes, list boxes, buttons, and palettes. The fact
base manager is in charge of managing and especially checking consistency of
the fact base. Finally, the application manager takes in charge low-level appli-

7
cation tasks such as management of files, applications, projects, schemas, and
reports (new application, open schema, save project, close reports, save as file)
This last subsystem is a classical module of any computerized tool. So it will
require no further information in the rest of the paper.
The second layer (model layer) implements specific concrete models: object
(basically enhanced entity-relationship), statechart, data flow diagram (DFD),
object interaction graphs (OIG), use cases, strategic dependency or strategic
rationale [Yu95].
Each concrete model subsystem is composed of three components. It de-
fines, in a specific model definition component, the conceptual language used to
describe each particular aspect of the system. For example, our object model de-
fines rules and primitives for the basic object constructs (e.g. class, relationship,
attributes), in addition to abstraction mechanisms such as generalization, ag-
gregation, aggregated and derived relationships, as well as several interrelation-
ship constraints. Two other components are associated to each concrete model
subsystem: a Model GUI component implements GUI management primitives
specific to the model while a Graphics Definition component contains informa-
tion about the graphical representation of the model abstraction mechanisms.
Each of these concrete model subsystems use the primitives provided by the
Yframe engine.
The third layer (method layer) implements concrete methods such as OMT,
Booch, Jacobson, Fusion, or relational DB design and are about to partially
take UML, Catalysis into consideration. Each method is implemented by a
subsystem and uses models defined in the model layer. For instance, OMT inte-
grates the object, statechart and DFD models, respectively, as static, dynamic,
and functional model. Each concrete method subsystem is composed of two
components. A method definition component defines primitives specific to one
method such as customization rules for the method or consistency constraints
between its models, while a method GUI contains GUI management rules asso-
ciated to a particular method. A concrete method subsystem can also directly
call primitives of the engine.
As shown by the dashed lines in Figure 2, each concrete model or method
is defined by providing the concrete subsystems corresponding to the abstract
subsystems. Examples of a concrete model and a concrete method are given,
respectively, in Sections 4 and 5.

4 Model Subsystems
To each concrete model is associated a set of concepts, each defined by a pred-
icate concept. This predicate has three arguments: the first one describes the
concept with its arguments, the second one defines the design phase, and the
third one represents the model in which the concept is used. For example, some
of the concepts defined in our object model are the following:

8
 concept(class(’Class Name’),’Conceptual’,’Object’).
concept(relationship(’Relationship Name’),’Analysis’,’Object’).
concept(participates(’Relationship Name’,’Participant Name’,
’Minimal Cardinality’,’Maximal Cardinality’,’Role’),’Analysis’,’Object’).
concept(attribute(’Owner Name’,’Attribute Name’,’Minimal Cardinality’,
’Maximal Cardinality’),’Analysis’,’Object’).
concept(weak_class(’Class Name’,’Ident. Relationship’),’Analysis’,’Object’).
concept(fd(’Owner Name’,’Left-Hand Side’,’Right-Hand Side’),’Analysis’,’Object’).
concept(subset_of(’Left Relationship’,’Right Relationship’),’Analysis’,’Object’).
concept(generalization(’Superclass Name’,’total/partial’,’excl/overl’,
’Criteria’,’Defining Attribute’),’Analysis’,’Object’).
concept(isa(’Subclass Name’,’Superclass Name’,’Criteria’,’Defining Expr.’),
’Analysis’,’Object’).
concept(derived_relationship(’Derived Relationship’,’Defining Relationships’),
’Analysis’,’Object’).

Different predicates define the arguments of concepts. For example, the

following facts define some properties of the concept participates, linking a
class to a relationship:
domain(participates,’Participant Name’,string).
domain(participates,’Minimal Cardinality’,integer).
default_value(participates,’Minimal Cardinality’,0).
allow_nulls(participates,’Role’).

Predicate domain defines the domain of the argument, default_value states the
default value of the argument, and allow_nulls specifies optional arguments.
To each concept is associated a set of integrity constraints. Integrity checking
is realized at three different levels:
(1) arguments of a concept (ic_arg)
(2) whole concept (ic_concept)
(3) consistency of a model (ic_model).
As will be shown in Section 5, a fourth level defines constraints associated
to the consistency between models, i.e., a method (ic_method). We next give
examples of constraints associated to each of these three levels.
1) ic_arg(class,’Class Name’,Name) :-
check_neg_refer_int(’Class Name’,Name,relationship(Name)).
2) ic_arg(participates,’Participant Name’,Name) :-
check_refer_int(’Owner Name’,Name,[class(Name),relationship(Name)]).
3) ic_concept(participates(_,_,MinCard,MaxCard,_)) :- MinCard > MaxCard,
error_msg(’Error’,[’The Maximal Cardinality must be greater than ’,
’or equal to the Minimal Cardinality.’]),!.
4) ic_concept(participates(RN,PN,_,_,R1)) :- participates(RN,PN,_,_,R2),
( R1=R2,
error_msg(’Error’,[’Class ’,PN,’ already participates in relationship ’,
RN,’ with the same role’])
; R1==’’,
error_msg(’Error’,[’Since Class ’,PN,’ already participates in relationship ’,
RN,’ then a value for role is required’])
; R2==’’,
error_msg(’Error’,[’Class ’,PN,’ already participates in relationship ’,
RN,’ with no role’])
),!.
5) ic_model(relationship(Rel)) :-
findall(Part,participates(Rel,Part,_,_,_),PartList),length(PartList,N), N<2,
error_msg([’Relationship ’,Rel,’ has less than 2 participating objects.’]).

9
 The first two constraints are attached to arguments of concepts. The first
one checks that the name of a class is not the same as the name of a relationship.
The second constraint checks that the participant of a participates predicate is
an existing class or relationship.
The third constraint is attached to predicate participates: it states that
the maximal cardinality must be greater than or equal to the minimal cardinal-
ity. The fourth rule defines a more complex constraint: when an object (or a
relationship) participates more than once in a relationship, each participation
must have a different role.
It is important to notice that ic_arg and ic_concept rules are fired when
the user wants to add or modify a fact from the concept repository using dialogue
boxes as those given in Figure 5. When the user press the OK button, each
argument is validated by firing the ic_arg rules; the third argument passed
to such rules is the value typed in the edit control. When all arguments are
validated individually, the ic_concept rules are then fired; the argument passed
to such rules is the fact the user wants to add to the concept repository.
The fifth constraint checks model consistency: it verifies that each relation-
ship has at least two participating objects.
Notice that when a constraint is violated, appropriate messages are displayed
in dialogue boxes through predicate error_msg.
In addition, each model must define a set of cascade rules that must be
enforced when the fact base is modified. These rules are defined by add_rule,
modify_rule, and delete_rule. For example:

1) modify_rule(class(OldName),class(NewName)) :-
modify_cascade(attribute(OldName,Attr,MinC,MaxC),
attribute(NewName,Attr,MinC,MaxC)).
2) modify_rule(relationship(OldName),relationship(NewName)) :-
modify_cascade(participates(OldName,PN,MinC,MaxC,R),
participates(NewName,PN,MinC,MaxC,R)).
3) delete_rule(class(Name)) :- delete_cascade(attribute(Name,_,_,_)).

The first rule is fired when a class name is changed: it replaces the new class
name in all associated attribute predicates. As shown by the second rule, similar
modify_rule predicates exist for all interelated model concepts. The third rule
is fired when a class name is deleted: it deletes in cascade all corresponding
attribute predicates.
The object model explained above is an example of a concrete model defined
using the primitives of the abstract model subsystem of the Yframe engine. As
already said, such primitives are applicable to different models. Examples of
such primitives are check_refer_int, modify_cascade, and delete_cascade
used by the rules of the concrete object subsystem, as explained above. They
are shown next.

10
 check_refer_int(Field,Value,Term) :-
not(lst(Term)),!,check_refer_int(Field,Value,[Term]).
check_refer_int(Field,Value,List) :- lst(List),not(exists_or_list(List)),
( List = [Term] -> error_msg([’The ’,Field,’ must be an existing ’,Term,’.’])
; List = [Term1,Term2] -> error_msg([’The ’,Field,’ must be an existing ’,Term1,
’ or ’,Term2,’.’])
; ext_pred(List,List1),error_msg([’The ’,Field,
’ must be one of the following ’,List1,’.’])
),!.

Predicate check_refer_int is used in concrete models to check – through

predicate exists_or_list – referential integrity between arguments of two con-
cepts. Another similar predicate check_neg_refer_int is used to avoid refer-
ential integrity between arguments of two concepts. As can be seen, messages
in dialogue boxes are displayed when the rule is violated in order to help the
user correct the fact base.
modify_cascade(OldTerm,NewTerm) :- OldTerm,OldTerm =..[Pred|_],
atom_string(Pred,PredStr),
write_msg1([’Modifying ’,PredStr,’ predicates ...’]),fail.
modify_cascade(OldTerm,NewTerm) :- retract(OldTerm),assert(NewTerm), fail.
modify_cascade(OldTerm,NewTerm).

delete_cascade(Term) :- Term,functor(Term,Pred),atom_string(Pred,PredStr),
write_msg1([’Deleting associated ’,PredStr,’ predicates ...’]),fail.
delete_cascade(Term) :- retract(Term),fail.
delete_cascade(Term).

Predicates modify_cascade and delete_cascade are typically abstract prim-

itives since they manipulate predicates given as arguments. They are totally
independent of concrete models and concepts.
Other examples of primitives are domain, default_value, and allow_nulls,
which were used above for defining the arguments of concepts. Also, several
ic_arg, ic_concept, and specific cascade rules are attached to the abstract
model subsystem. For example, one of them tests that the same fact is not
entered twice in the repository.

5 Method Subsystems
A concrete method associates a set of models to each phase of the development
life cycle. For example, the Fusion method associates to the analysis phase an
object model, a system object model, and an operation model. Further, the
concrete methods also determine the fourth level of integrity checking , i.e., the
constraints checking consistency between models. For example, the following
constraint
ic_method :- statechart(Statech),\+(attached(Statech,Class)),
error_msg([’Statechart ’,Statech,’ is not attached to a class in the object model.’]).

checks that every statechart defined in the dynamic model is attached to a

class defined in the object model, while the following constraint

11
 ic_method :- transition(Statech,TransEvt,Cond,Action,OrState,DesState),
attached(Statech,Class),\+(defined_operation(Action,Class)),
error_msg([’Action ’,Action,’ is not defined as an operation of class ’,Class ’.’]).

checks that every action defined in a statechart attached to a class is defined

as an operation in the interface of that class.
Each concrete method customizes its set of models according to the method
(and users’) specificities. For instance, the OMT method does not use de-
rived and subset relationships (defined in our object model) while the Relational
Database Design method integrates them as an essential mechanism to detect
relational redundancies. Therefore, each concrete method must determine the
concepts which are supported by its models.
Also, each method must determine the operations that can be performed in
each phase and model. For example, for the relational database design method,
one operation allows to automatically generate, from an object schema, a re-
lational database schema in Inclusion Normal Form These operations are de-
scribed in [KZ00]. In the same way, in the OMT method, an operation allows
to generate, from a statechart specification, the C++ code that realizes the
corresponding functionality. These operations are briefly described in Section
9.A complete presentation is given in [Zim95].
Finally, concrete methods define how to realize a report containing all knowl-
edge of the repository for a particular phase (e.g., analysis) and model (e.g., ob-
ject model). Such reports constitute the textual representation of the graphical
models.
The abstract method subsystem defines primitives available to all meth-
ods. Examples of such primitives are load_method and consistency_check
for firing the consistency check between models. Primitives choose_phase
and choose_model are used to change the current phase and model while
generate_report is used to generate a report.

6 Fact Base Manager

This subsystem is in charge of managing the fact base. In fact, there are two dif-
ferent fact bases. The concept repository contains facts such as class(employee)
and relationship(works_on). The graphics repository contains the graphical
representation of the repository concepts: it contains, e.g., the following predi-
cate
grafix(obj_window_1,123,[brsh(255,255,255,0),pen(0,0,0,1),rect(37,29,107,69),
font(gredit),trns(1),fore(0,0,0),text(40,29,’employee’)]

keeping the list of graphical commands that draw a rectangle and the text
employee on the graphical window ob_window_1. This is the graphical repre-
sentation of class(employee).
As already said, this separation of both repositories allows us to achieve
representational independence. However, it is necessary to have a predicate

12
gfx_conc that makes the correspondence between each concept and its graphical
representation. This predicate is used, e.g., when the user clicks the right button
on an graphical object, to determine the corresponding concept that is to be
modified.
Each graphical object has a unique Object Identifier (OID), kept in the
second argument of the grafix predicate. OIDs are necessary in particu-
lar to maintain connections between graphical objects. For example the fact
participates(works,employee,1,1,’’), linking employee with relationship
works is represented graphically with a line connecting the corresponding square
and diamond. Since all the caracteristics of the square and the diamond can
change (i.e., color, size, text annotation), OIDs allow to keep track of the con-
nection between them.
Predicates add_element, modify_element, and delete_element are avail-
able to modify the contents of the concept repository. However, when the
concept repository is modified, it must be ensured that it remains consistent.
As explained above, four levels of integrity checking are defined. The fact
base manager subsystem contains primitives for firing integrity checks with
predicates such as check_ic_arg, check_ic_concept, check_ic_model, and
check_ic_method. It also contains primitives for firing the cascade rules with
predicates fire_add_rules, fire_modify_rules, and fire_delete_rules.
Every modification of the concept repository (such as creating a new class,
connecting a class with a relationship) implies a graphical primitive to be ex-
ecuted on the corresponding window. However, some graphical operations do
not imply a modification of the repository (e.g., moving a class or a relationship
in a schema).
Predicates assert_grafix and retract_grafix are used to modify the con-
tents of the graphics repository. As a side-effect, these predicates draw and
delete the graphical objects in windows.
An important functionality concerning both repositories is to allow the
undo/redo capability when drawing schemas. For this purpose, to each win-
dow are associated two stacks (undo and redo) implemented using the retract
and assert predicates.
modify_repositories(Window,GfxObjs,NewGfxObjs,Concepts,NewConcepts) :-
retractall(redo(Window,_,_,_,_)),
asserta(undo(Window,GfxObjs,NewGfxObjs,Concepts,NewConcepts)),
retract_grafix(GfxObjs,Window),assert_grafix(NewGfxObjs,Window),
fire_del_rules(Concepts),fire_add_rules(NewConcepts).

The above predicate is used for every modification of the repositories. The first
argument states which window is concerned. GfxObjs and Concepts are the
lists of facts that has to be removed from, respectively, the graphics and the
concept repositories. Similarly, NewGfxObjs and NewConcepts are the list of
facts that has to be added to both repositories.
Thus, after the redo stack for the window has been cleared, an element
is pushed into the undo stack, the old graphical objects are deleted, the new
ones are added (using retract_grafix and assert_grafix), and the same is

13
done for the concepts (using fire_del_rules and fire_add_rules). If the
user wants to undo the operation that modified the repositories, the inverse
operation is realized, the new facts are removed from the repository, and the
old facts are reasserted.
Notice that the list of graphical objects/concepts to be deleted can be empty,
e.g., when adding a new entity or relationship. The same is true for the list
graphical objects/concepts that has to be added, e.g., when deleting an entity.

7 Graphics Subsystems
Any graphics application needs to maintain a logical representation of the image
in any window, so that it can be repainted when necessary. Operations such
as moving, scrolling, and resizing of windows can cause portions of graphics
regions to be uncovered and thus, the newly exposed areas to be redrawn. This
requires that the applications store a copy of every graphics operation so that it
can be repeated on demand. Such information is kept in the graphics repository
as explained in the previous section.
Prolog offers important advantages over conventional programming languages
for managing graphical objects, which are often complex and large data struc-
tures. The Prolog built-in knowledge base as well as its pattern matching and
backtracking mechanisms allow to realize graphical manipulations at a more
abstract level. Since Prolog is a dynamically typed language, complex terms
and structures representing graphical objects can be created and manipulated
without knowing their type. The memory required to operate on these struc-
tures is dynamically allocated and deallocated by the Prolog run-time system.
So, graphical objects can be manipulated in lists which can grow to an arbitrary
length.
For realizing equivalent manipulations in other imperative languages it is
necessary to use dynamic memory allocation as well as list traversals and mem-
ory pointers. Thus, programmers in C++-like languages must know everything
about memory allocation at compile and run time. This low-level programming
task is often hard and difficult and it requires experimented programmers. In
particular, a program can be correctly compiled and nevertheless contain errors
because some pointers do not point to data structures at run time.
Further, dynamic memory allocation in these conventional languages is not
really manageable because C++ does not provide any form of garbage collection
to reclaim the memory released by defunct objects. In the context of graphical
object manipulation, this can lead to memory overloading. On the contrary,
Prolog dynamically manages the system memory. Of course, such a mechanism
can be programmed in imperative languages but this increases the complexity
of development. Notice however that some dynamic OOPLs, for instance CLOS
[Kee89], also provide garbage collection.
It is in the development of the graphics subsystems, explained next, that
many of the advantages of Prolog turned out to be extremely important.
The abstract graphics subsystem defines primitives for manipulating graph-

14
ics objects independently of their shape. The particular visual appeareance and
the behaviour of objects is defined by concrete graphics subsystems. For exam-
ple, the Object graphics subsystem defines the size, color, shape, etc., of the
entities, relationships, as well as the lines connecting them. Furthermore, this
Object concrete subsystem also determines how these objects react when they
are manipulated, i.e., resized, selected, dragged.
The abstract graphics subsystem was developed with an object-flavored pro-
gramming style. As already said, each graphical object has a unique OID. In
addition, each predicate first checks the type of the object passed as argument:
if the predicate was defined for this type, the process goes on; otherwise, the
inference engine backtracking mechanism tries to match another predicate with
the same name and the same signature. This object-flavored programming
style combined with our abstract/concrete separation allows encapsulation, an
important advantage of Object-Oriented programming.
The abstract graphics subsystem contains typical low-level graphics primi-
tives not requiring information about objects. Examples are geometric primi-
tives for manipulating points, segments, rectangles, and so on. Some abstract
graphics primitives are the following.
A predicate eq_segm([X1,Y1,X2,Y2],[DY,DX,C]) computes the equation
of the segment determined by the points (X1,Y1) and (X2,Y2). Predicate
inters_segm([A1,B1,C1], [A2,B2,C2],[X,Y]) determines the intersection
point (X,Y) ot the two segments given as arguments. A predicate
distance([X1,Y1],[X2,Y2],Dist) computes the distance between two points.
Predicate sq_overlap([L,T,R,B],[L1,T1,R1,B1]) tests whether two squares
overlap. Predicate sq_inters([L1,T1,R1,B1],[L2,T2,R2,B2],[L,T,R,B])
computes the intersection of two squares.
Predicate add_connection(Id1,[Id2,X,Y]) allows to add to object Id1 a
connection with object Id2 at point (X,Y). It checks that the point (X,Y) belongs
to the object Id. Other similar rules are del_connection, modify_connection,
and retrieve_connection.
Predicate extent returns the physical extent of a graphics sequence, while
predicate shift_args shifts the graphics elements by a specified offset. There
are also predicates for manipulating the ”select” corners such as draw_corners,
delete_corners. A predicate test_objects is used to select the objects en-
closed by a rectangle drawn on the screen; these objects can then be moved,
deleted, or resized. Other predicates show and store status information, scroll
the image, move (drag) or resize a set of selected objects, magnify and reduce
the scale (zoom-in and zoom-out) of a window.
To facilitate the manipulation of lines a predicate incertitude determines
the sensibility area of the mouse cursor around a point. Indeed, a problem that
arises when manipulating lines is that it is difficult to place the cursor exactly
over the line (i.e., over the exact pixel). Therefore, a sensibility zone around
this line is declared with predicate incertitude.
Concrete graphics subsystems are defined for each model defining how ob-
jects are drawn, moved, selected, resized, shifted, etc. Some of the primitives
for the concept entity are explained next.

15
 Figure 3: Steps of a dragging operation

conc_color(class,’Analysis’,’Object’,0,0,0).
gfx_extent(Gfx,L,T,R,B) :- Gfx=[_Brsh,_Pen,rect(L,T,R,B),_Font,_Trns,_Fore,_Text],!.
hit(Gfx,X,Y) :- Gfx=[_Brsh,_Pen,rect(L,T,R,B),_Font,_Trns,_Fore,_Text],
L =< X, T =< Y, R >= X, B >= Y,!.
gfx_conc(_,_,Gfx,entity(Ent)) :- Gfx=[_Brsh,_Pen,rect(_,_,_,_),
_Font,_Trns,_Fore,text(_,_,Ent)],!.
shift_object(Gfx,Dx,Dy,NewGfx) :- Gfx = [Brsh,Pen,rect(|Corners),
Font,Trns,Fore,Text(X,Y,Name)],
shift_args(Corners,Dx,Dy,NewCorners), shift_args([X,Y],Dx,Dy,[X1,Y1]),
NewGfx=[Brsh,Pen,rect(|NewCorners),Font,Trns,Fore,Text(X1,Y1,Name)],!.
outline_object(Gfx,OutGfx) :- Gfx = [_Brsh,_Pen,rect(|Corners),_Font,
_Trns,_Fore,_Text],
OutGfx = [pen(0,0,255,-2),rect(|Corners)]),!.

Predicate conc_color states the color (a combination of R,G,B) used for

drawing concepts on the screen: e.g., classes are drawn in black. Predicate
gfx_extent states the smaller square enclosing the graphical representation
of concepts: for entities this is determined by the corners of the rectangle.
Predicate hit determines whether a point (X,Y) is situated over a graphical
object. Predicate gfx_conc allows to establish the correspondance between
a concept and its graphical representation: for entities it suffices to see the
text annotation inside the square. Predicate shift_object determines how to
shift objects: for classes both the corners of the rectangle and the point (X,Y)
of the text annotation must be shifted (with shift_args). Finally, predicate
outline_object states how objects are outlined when they are being dragged:
for entities, a dotted blue square is drawn on the screen.
Figure 3 shows an example of how the abstract and the concrete graphics
subsystems work together. In Figure 3 (a), the user selects an area in the screen
with the mouse cursor. All objects enclosed in the area are selected. For this, the
primitive for selecting an area (defined in the abstract subsystem) determines
the graphical objects to be selected.
Then, the dragging operation can be applied as shown in Figure 3 (b). Dur-
ing the dragging operation, at each mouse move, the outlines of the objects to
be moved must be drawn. As explained above, the concrete subsystems define

16
 Figure 4: Object Editor

how the objects are outlined. For example, the name of the entities and rela-
tionships, as well as the cardinalities of the participations are omitted in the
outlines.
Finally, when the dragging operation is completed the objects must be
shifted as shown in Figure 3 (c). Here also the abstract shifting primitive uses
the definition of how the different objects are shifted, as defined in the concrete
subsystems.

8 GUI Subsystems
The abstract GUI subsystem comprises primitives for manipulating GUI ele-
ments, such as menus, dialogue boxes, palettes, status bars and toolbars. This
includes, e.g., adding, removing, selecting and retrieving elements from list-
boxes, editing and retrieving edit controls, selecting radio buttons, and manip-
ulating palettes.
A concrete GUI component is associated to each model and to each method.
Such components use the primitives provided by the abstract component. For
instance, the general menus of Yframe as well as the Tasks menu associated to
the Object schema editor (shown in Figure 4) are defined using the predicate
menu_item as follows:

17
 menu_item(main_menu,’&Application’,appl_menu,enable,true).
menu_item(main_menu,’&Phase’,phase_menu,enable,true).
menu_item(main_menu,’&Model’,model_menu,enable,true).
menu_item(main_menu,’&Schema’,schema_menu,enable,true).
menu_item(main_menu,’&Edit’,edit_menu,enable,true).
menu_item(main_menu,’&Tasks’,tasks_menu,enable,true).
menu_item(main_menu,’&Help’,help_menu,enable,true).
menu_item(main_menu,’&Window’,window_menu,enable,true).

menu_item(tasks_menu,’&Clear Console’,1000,enable,clr_console).
menu_item(tasks_menu,’’,0,separator,true).
menu_item(tasks_menu,’List &Elements’,1001,enable,lst_elements).
menu_item(tasks_menu,’Chec&k Consistency’,1002,enable,chk_consist).
menu_item(tasks_menu,’Generate &Report’,1003,enable,gen_report).
menu_item(tasks_menu,’Generate &Logical’,1004,enable,gen_logical).
menu_item(tasks_menu,’Normalize &3NF’,1005,disable,norm_3NF).
menu_item(tasks_menu,’Normalize &BCNF’,1006,disable,norm_BCNF).
menu_item(tasks_menu,’Normalize &INNF’,1007,disable,norm_INNF).

For each menu item, the following are specified: parent menu, text to display,
either the identifier of the message generated by Windows or the submenu,
whether the menu is enabled, and the predicate to execute when the menu is
selected.
Other examples of concrete rules are palette definitions for a specific schema
editor. The Object palette given in Figure 1 is defined as follows:
pal(ob_pal,10,2,30,30).
default_btn(ob_pal,arrow_btn).
pal_btn(ob_pal,1,1,arrow_btn,two_state,select_object,’Ready’,0).
pal_btn(ob_pal,1,2,text_btn,two_state,add_text,’Add Text Annotation’,text_cursor).
pal_btn(ob_pal,2,1,class_btn,two_state,add_class,’Add Class’,class_cursor).
pal_btn(ob_pal,2,2,weak_cl_btn,two_state,add_weak_cl,’Add Weak Class’,weak_cl_cursor).
pal_btn(ob_pal,3,1,rel_btn,two_state,add_rel,’Add Relationship’,rel_cursor).
pal_btn(ob_pal,3,2,der_rel_btn,two_state,add_der_rel,’Add Deriv Rel’,der_rel_cursor).
pal_btn(ob_pal,4,1,partic_btn,two_state,add_partic,’Add Particip’,part_rel_cursor).
pal_btn(ob_pal,4,2,aggr_rel_btn,two_state,add_aggr,’Add Aggreg Rel’,aggr_rel_cursor).
[...]

The first line defines the Object palette as having 10 × 2 buttons, each of
30 × 30 pixels. Then each of the buttons is defined with predicate pal_btn.
It defines the bitmap to paint over the button, whether the button is one- or
two-state, the predicate to execute when the button has been pressed, the help
message painted in the status bar, and the cursor that has to be displayed.
As can be imagined, all the actions and graphical manipulations that must be
executed when a mouse button is clicked over a palette button are defined in the
abstract GUI subsystem, they are the same for all the palettes. In addition, the
abstract GUI subsystem also defines generic dialogue boxes for n-ary predicates.
For example, the dialogue box associated to predicate participates is shown
in Figure 5 (a).
These generic dialogue boxes provide basic functionality for modifying the
fact base. This is extremely useful in the first stages of method definition. The
method designer can define customized dialogue boxes for specific concepts,
thus enhancing the basic functionality. For example, the Object model defines
customized dialogue boxes several concepts, one of which is shown in Figure 5
(b).

18
 Figure 5: Two dialogue boxes for the Object editor.

9 Example Session
This section briefly presents an example session for the Statecharts model.
We refer to [Zim95] for a complete description of the model. Other com-
plete implementations for models and methods like the Object, Use Cases, or
DFD models, or the Relational DB design method and OMT can be found in
[Van97, ZK96, KZ98, DPZ99].
Statecharts [Har87] are an extension of finite state machines and diagrams,
with formal syntax and semantics used for describing system dynamics. Al-
though statecharts were originally proposed for describing hardware devices, the
dynamic models of OO methods, such as OMT, Booch, UML mand Catalysis
use the statechart formalism for modeling the temporal behaviour of a system.
Our implementation of the statechart model takes into account most of the
statechart concepts such as events, states, super- and substates, transitions
(simple, merging, concurrent, and splitting), conditions, actions, and history
enforcement. The module has the following functionalities. The dynamic be-
haviour of a system is specified as a collection of interacting statecharts, each
one attached to a class. These statecharts can be drawn on the screen via the
GUI and are validated with the integrity constraints. In addition, our module
allows to simulate the dynamic behaviour of the application to test whether it
behaves as expected. Finally, the system generates the C++ code implementing
the overall behaviour of the application.
Figure 1 shows the layout of the statechart schema editor. The tasks menu
is used for dynamic simulation. The first option allows to start an object of a
class by starting its associated statechart. Several objects of the same class can
be created, each one executing its own statechart. The second option of the
menu allows to stop an object. The third option shows the status of an object,
i.e., the active states of its associated statechart. The fourth option allows to
send an event to an object. The fifth option enables or disables the predicate
printing the status of an object after transitions.
Our C++ code generation for statechart classes is based on an inheritance
hierarchy comprising classes which can be partitioned in two groups: the state-
chart engine classes and the application classes. The first group implements the

19
semantics of the statecharts independently of any particular application while
the second group is specific to the application. For additional details of the
statechart implementation in C++, we refer to [Zim94].
To illustrate this C++ code generation, we explain the two top-level predi-
cates generating the C++ header file and the C++ code file.

gen_header_cpp(Class,StateCh,HFile) :- tell(HFile),
write(’#ifndef _H_’),writeU(StateCh),nl,write(’#define _H_’),writeU(StateCh),nl,
write(’#include <stddef.h>’),nl,write(’#include "statech.h"’),nl,nl,
write(’class ’),writeU(StateCh),write(’;’),nl,nl,
gen_g_state(Class,StateCh),get_states(StateCh,StateList),
gen_state_headers(StateList,Class,StateCh),nl,
gen_statech_header(StateList,StateCh),nl,write(’#endif’),nl,
told,tell(user).

Predicate gen_header_cpp generates the C++ header file. After writing the
preamble in the header file (HFile), it generates the header of the generic state
class (gen_g_state), constructs the list of states of the statechart (get_states),
generates the header for each state class (gen_state_headers), and generates
the header of the statechart class (gen_statech_header).
For instance, the header of the statechart class for a digital watch, generated
by gen_statech_header, is shown next.

class WatchSC: public StChart {

public:
MainState Main; AliveState Alive; DeadState Dead;
StopwatchState Stopwatch; HourState Hour; ResetState Reset;
OperationState Operation; TimerState Timer; DisplayState Display;
NormalState Normal; InsecState Insec; OnState On;
OffState Off;
void reactEvent(int Event);
WatchSC(); // constructor
};

Predicate gen_code_cpp generates the C++ code file.

gen_code_cpp(Class,StateCh,HFile,CFile) :- tell(CFile),
write(’#include <stdio.h>’),nl,write(’#include <iostream.h>’),nl,
write(’#include "statech.h"’),nl,write(’#include "’),write(HFile),write(’"’),nl,nl,
get_states(StateCh,StateList),
gen_state_impl(StateList,Class,StateCh),
gen_sc_constr(StateList,StateCh),told,tell(user).

After writing the preamble in the code file (CFile), it calls gen_state_impl
for generating the implementation of all the states of the statechart, and calls
predicate gen_sc_constr to generate the constructor of the statechart class.

10 Related Works
Research on automating software development with computerized tools has been
growing since the early 90’s. This section describes two representative and up-
to-date commercial CASE shells, comparying them with Yframe. However,
none of them integrate a declarative approach.

20
 MetaEdit+ [Tol99] is a OO metaCASE, developed in Smalltalk, supporting
multiple methods in a client-server environment. CASE tool support for devel-
oper’s own or customized methods can be built with the method workbench.
The system is based on the concept of representation independence which is simi-
lar to ours and uses the concept of what they call the graph-object-property-role-
relationship (GOPRR) metamodel. The GOPRR metamodel provides modeling
tools for most of the widely used system development models and methods. It
can support recursive structures for objects, OO hierarchies, interconnected
models and methods, polymorphic modeling concepts, multiple representation
of the same underlying conceptual description and rules for checking model in-
tegrity. This metamodel forms the basis on which various representations of
data, including graphical diagrams but also hypertext and matrix, are built.
Some of the OO methods supported by the tool are OMT, Fusion, Booch,
Coad/Yourdon, Moses and UML. Again, Yframe provides most of the function-
ality of MetaEdit+, excepted client-server support. We are currently making
a comparison of our current metamodel and the GOPRR metamodel to assess
their corresponding expression power. One of the further work in Yframe is to
extend this metamodel using Logtalk [Mou99] which a metaclass architecture
written in Prolog.
ObjectMaker [Sys99] addresses both project and CASE requirements and
supports several well-known object-oriented and structured methods like ER,
statecharts, DFD, uses cases, Petri nets, Booch, Coad/Yourdon, Shlaer/Mellor,
UML, OPEN OML and others. The system architecture lets the developer use
methods and integrate them with other tools, databases and frameworks. It
also allows the users to develop their own code generators and reverse tools for
the language of their choice.
Like Yframe, ObjectMaker allows the designer to select and customize de-
sign methods to match the specific development environment. Language mod-
ules provide both code generation and reverse engineering (automatic diagram
generation from source code). ObjectMaker’s reverse engineering capability can
facilitate reuse of existing source code, providing automatic documentation and
supporting the maintenance and re-engineering of legacy systems. Yframe pro-
vides most of the functionality of ObjectMaker, excepted the reverse engineering
capability. Due to the modularity of our system it should be relatively easy to
introduce such capability in Yframe.

11 Conclusion
Since the recognition of the software crisis, researchers have started to design
methods that help analysts and developers construct computerized applications
of increasing complexitiy. Object-oriented methods aim to cope with the in-
adequacy of structured methods and early attempts to solve the complexity at
the code level. This led to a new way of thinking about problems using mod-
els organised around a fundamental construct: the object. However, due to
the ever-increasing complexity of software development, researchers have also

21
focused on providing CASE and CAME environments helping designers build
applications in a more flexible way.
In this context, we have developed a declarative and modular tool in Prolog
that can be used for supporting both method engineering and object-oriented
development and including a sophisticated GUI. We explained how the declara-
tive nature of Prolog programming turned out to be extremely powerful for the
system architecture.
First, we showed that Yframe was conceived with a highly customizable
structure. The adaptability of Yframe helps the developer select and tailor anal-
ysis and design methods to match the specific development environment. Thus,
different abstraction mechanisms and models can be customized and combined
by the user, respectively, into a model and a method. Again, as the developer
updates and improves his/her processes and methods, our system provides an
incremental and extensible software engineering environment to fit the applica-
tion. In this context, an important feature of the tool is the representational
independence between the conceptual constructs and their (graphical) repre-
sentation. These features enable developers to be productive throughout the
development life cycle, from analysis and design to post-delivery maintenance.
Second, we showed that the use of Prolog as the only development language
for building an entire GUI is viable. We firmly believe that the use of only
Prolog for developing the core of the system and the GUI is more coherent than
using Prolog for the inference engine and a conventional imperative language
for the GUI.
Then, we showed the ease of using Prolog to develop a graphical environment.
For manipulating complex data structures like graphical objects, Prolog frees the
developer from low-level tasks such as (dynamic) memory allocation and pointer
management. We adopted an object-flavoured programming style using Prolog
built-in backtracking and pattern-matching mechanisms, to which we added a
unique Object Identifier mechanism. All these benefits lead to rapid prototyping
also favoured by the incremental development environment of Prolog which is
not allowed by imperative programming languages.
Several issues need to be further addressed. Our framework is currently
developed for Windows NT platforms using a LPA Prolog compiler. We are
planning to port the system to Unix operating systems (e.g., Solaris and Linux)
using the GTK+ GUI Toolkit [GM00] developed for the X Window System.
Our Prolog code, especially the code concerning the Yframe engine primitives,
is in fact as far as possible independent of the hardware/software configuration.
Thus, only the OS function calls should be modified.
Our tool provides a powerful testing environment to develop and implement
new modeling abstractions and conceptual languages describing an application
throughout the development life cycle. For instance, we already formalized a
mechanism for the description of object models, called materialization [DPZ99].
We have also formalized and defined X* [Kol99, Kol00], an original aggregation
model based on the part relationship concept. We are going to implement
these primitives in order to extend the current abstraction mechanisms of the
object model. Such primitives can also be considered as dynamic abstractions

22
and interacts with more behavioral primitives like those identified as analysis
[Fow97] and design patterns [Pre95] when taking into consideration the whole
software life cycle [MCP98]. So they could also improve the dynamic models of
our tool.
As said in Section 2, we are about to support latest OO methods and method-
ologies like UML or Catalysis. Integrations of other recent ones like OPEN OML
[HSSY99] as well as frameworks such as those defined for NFRs (non-functional
requirements) [CNYM00] are also being investigated.
As also said in Section 10, we are currently investigating the facilities pro-
vided by true run-time metalevels systems à la TELOS [MBJK90] or CLOS
[KdRB91]. Such levels are provided by Logtalk, a Prolog extension allowing
reflexion and reification not only for application concepts but also for models,
methods and system primitives themselves. As demonstrated in [Kol99], this
kind of architecture would sensitively improve flexibility, reuse, and modular-
ity. (See, for example, goal-driven software engineering frameworks like KAOS
[Dar93] or more recently TROPOS [MC00]). Moreover, they could lead us to
directly drive the software development process itself at run-time
This project started from different expert systems and Prolog algorithms
developed to test, prototype and evaluate original database design methods
[KZ95], dynamic specifications [Zim95], and new object modeling primitives
[PZMY94]. The second leg led to EROOS Case, a CASE tool in which a graph-
ical user interface was added and OO methods were about to be partially inte-
grated and implemented. The project evolved to become YEROOS Case [ZK95]
definitevely supporting methods integration [ZK96, KZ98]. Yframe is actually
the pause sign of this phase. The next and last leg should lead to AfterYf. The
design of a true dynamic metalevel will allow us to drive the different meth-
ods all along the software process in a single uniform way throught a unique
(meta)framework. That will be the most ambitious step of the whole project,
but it might surely be the most interesting.

Acknowledgements. The authors wish to thank YEROOS members, espe-

cially Alain Pirotte. Useful suggestions were also provided by John Mylopoulos,
Jaelson Castro and Paolo Giorgini.

References
[Boo94] G. Booch. Object-Oriented Analysis and Design with Applications. Ben-
jamin/Cummings, Second edition, 1994.
[Bra86] I. Bratko. Prolog Programming for Artificial Intelligence. Addison-Wesley,
1986.
[BRJ99] G. Booch, J. Rumbaugh, and I. Jacobson. The Unified Modeling Language:
User Guide. Addison-Wesley, 1999.
[CAB+ 94] D. Coleman, P. Arnold, S. Bodoff, C. Dollin, H. Gilchrist, F. Hayes, and
P. Jeremaes. Object-Oriented Development: The Fusion Method. Prentice
Hall, 1994.

23
[CM84] W.F. Clocksin and C.S. Mellish. Programming in Prolog. Springer-Verlag,
1984.
[CNYM00] L. Chung, B. A. Nixon, E. Yu, and J. Mylopoulos. Non-Functional Re-
quirements in Software Engineering. Kluwer Academic Publishers, 2000.
[Dar93] A. Dardenne. On the use of scenarios in requirements acquisition. Techni-
cal Report CSI-TR-93-17, University of Oregon, Computer and Informa-
tion Science Dept., August 1993.
[DPZ99] M. Dahchour, A. Pirotte, and E. Zimányi. Metaclass implementation
of materialization. Technical Report YEROOS TR-99/01, IAG-QANT,
Université catholique de Louvain, Belgium, February 1999. To be pub-
lished in IEEE Transactions on Knowledge and Data Engineering. At
http://yeroos.qant.ucl.ac.be/file.pdf/TR/TR-99-01.pdf.
[DW98] D.F. D’Souza and A.C. Wills. Objects, Components, and Frameworks with
UML: The Catalysis Approach. Addison-Wesley, 1998.
[Fow97] M. Fowler. Analysis Patterns: Reusable Object Models. Addison-Wesley,
1997.
[GM00] T. Gale and I. Main. The GIMP Toolkit. gtk.org, 2000.
[Har87] D. Harel. Statecharts: A visual formalism for complex systems. Science
of Computer Programming, 8(3):231–274, 1987.
[HSSY99] B. Henderson-Sellers, T. Simons, and H. Younessi. The OPEN Toolbox of
Techniques. Addison-Wesley, 1999.
[JCJO92] I. Jacobson, M. Christerson, P. Jonsson, and G. Overgaard. Object-
Oriented Software Engineering: A Use Case Driven Approach. Addison-
Wesley, 1992.
[KdRB91] G. Kiczales, J. des Rivières, and D. Bobrow. The Art of the Metaobject
Protocol. MIT Press, 1991.
[Kee89] S.E. Keene. Object-Oriented Programming in COMMON LISP: A pro-
grammer’s Guide to CLOS. Addison-Wesley, 1989.
[Kol99] M. Kolp. A Metaobject Protocol for Integrating Full-Fledged
Relationships into Reflective Systems. PhD thesis, INFODOC,
Université Libre de Bruxelles, Belgium, October 1999. At
http://yeroos.qant.ucl.ac.be/file.pdf/PhD-99-01.pdf.
[Kol00] M. Kolp. X*: an aggregation model based on part-relationship. Tech-
nical Report YEROOS TR-00/03, IAG-QANT, Université catholique de
Louvain, Belgium, March 2000.
[KZ95] M. Kolp and E. Zimányi. Relational database design using an ER ap-
proach and Prolog. In S. Bhalla, editor, Proc. of the 6th Int. Conf.
on Information Systems and Management of Data, CISMOD’95, LNCS
1006, pages 214–231, Bombay, India, November 1995. Springer-Verlag. At
http://yeroos.qant.ucl.ac.be/file.pdf/P-95-05.pdf.
[KZ98] M. Kolp and E. Zimányi. Prolog-based algorithms for database design. In
Proc. of the 6th Int. Conf. on Practical Applications of Prolog, PAP’98,
London, UK, March 1998. At http://yeroos.qant.ucl.ac.be/file.pdf/P-98-
01.pdf.

24
[KZ00] M. Kolp and E. Zimányi. Enhanced er to relational mapping and interrela-
tional normalization. Technical Report YEROOS TR-00/02, IAG-QANT,
Université catholique de Louvain, Belgium, March 2000. To be published
in Information an Software Technology.
[MBJK90] J. Mylopoulos, A. Borgida, M. Jarke, and M. Koubarakis. Telos: Rep-
resenting knowledge about informations systems. ACM Trans. on Office
Information Systems, 8(4):325–362, 1990.
[MC00] J. Mylopoulos and J. Castro. Tropos: A framework for requirements-
driven software development. Forthcomming, 2000.
[MCP98] C. Marcos, M. Campo, and A. Pirotte. Reifying design patterns as
metalevel constructs. In Proc. of the 2nd Argentine Symp. on Object
Orientation, ASOO’98, Buenos Aires, Argentina, August 1998. Pub-
lished in the Electronic Journal of SADIO (Argentine Society for In-
formatics and Operation Research), vol. 2, no 1, pp. 17–29. At
http://yeroos.qant.ucl.ac.be/file.pdf/P-98-10.pdf.
[MNS96] H. A. Muller, R. J. Norman, and J. Slonim. Computer Aided Software
Engineering. Kluwer Academic Publishers, 1996.
[MO92] J. Martin and J.J. Odell. Principles of Object-Oriented Analysis and De-
sign. Prentice Hall, 1992.
[MO98] J. Martin and J. Odell. Object-Oriented Methods: A Foundation - UML
Edition. Prentice Hall, 2 edition, 1998.
[Mos94] C. Moss. Prolog++: The Power of Object-Oriented and Logic Program-
ming. Addison-Wesley, 1994.
[Mou99] P. Moura. Logtalk 2.5 user manual. Center for Informatics and Systems,
University of Coimbra, Portugal, December 1999.
[Pre95] W. Pree. Design Patterns for Object-Oriented Software Development.
Addison-Wesley, 1995.
[PZMY94] A. Pirotte, E. Zimányi, D. Massart, and T. Yakusheva. Materialization: a
powerful and ubiquitous abstraction pattern. In J. Bocca, M. Jarke, and
C. Zaniolo, editors, Proc. of the 20th Int. Conf. on Very Large Data Bases,
VLDB’94, pages 630–641, Santiago, Chile, 1994. Morgan Kaufmann. At
http://yeroos.qant.ucl.ac.be/file.pdf/P-94-01.pdf.
[RBP+ 91] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W. Lorensen.
Object-Oriented Modeling and Design. Prentice Hall, 1991.
[Sys99] Mark V System. ObjectMaker User Manual. Mark V System, 1999.
[Tol99] J. V. Tolvanen. MetaEdit+. Metacase, 1999.
[Van97] B. Vandezande. Architecture d’interfaces graphiques pour modles bass sur
les objets. Mémoire d’ingenieur civil en informatique, Dept. d’ingénierie
informatique, Université catholique de Louvain, September 1997.
[Yu95] E. Yu. Modelling Strategic Relationships for Process Reengineering. PhD
thesis, University of Toronto, Department of Computer Science, 1995.
[Zim94] E. Zimányi. Statecharts and their implementation in C++. Technical
Report YEROOS TR-94/01, INFODOC, Université Libre de Bruxelles,
Belgium, April 1994.

25
[Zim95] E. Zimányi. Statecharts and object-oriented development: A CASE
perspective. In Proc. of the 3rd Int. Conf. on Practical Application
of Prolog, PAP’95, pages 697–718, Paris, France, April 1995. At
http://yeroos.qant.ucl.ac.be/file.pdf/P-95-01.pdf.
[ZK95] E. Zimányi and M. Kolp. Using Prolog to implement a CASE shell
for object-oriented development. In Proc. of the 8th Symposium and
Exhibition on Industrial Application of Prolog, INAP’95, pages 41–48,
Tokyo, Japan, October 1995. At http://yeroos.qant.ucl.ac.be/file.pdf/P-
95-03.pdf.
[ZK96] E. Zimányi and M. Kolp. A Prolog-based architecture for an object-
oriented CASE shell. In Proc. of the 4th Int. Conf. on Practical Ap-
plication of Prolog, PAP’96, pages 497–520, London, UK, April 1996. At
http://yeroos.qant.ucl.ac.be/file.pdf/P-96-01.pdf.

26