Objecteering language

The “Objecteering language” is J: the scripting language built into Objecteering/UML, the CASE tool made by Softeam in Paris. Most CASE tools of the 1990s generated code with fixed templates or a separate macro language. In Objecteering the generators, model checks and model transformations were all ordinary J methods. They were attached to the classes of the UML metamodel itself (Class, Attribute, Operation, Package) and organised by UML profiles. Its manual calls J “an object language dedicated to handling models”, and that is where it differs from a general-purpose language. J could not define a new class. It could only add behaviour to the metamodel’s classes, then walk a user’s model and act on it.

J sits in this encyclopedia as an early working example of the model-driven ideas that the Object Management Group (OMG) later standardised as Model Driven Architecture (MDA) and UML profiles. Softeam was promoting that approach years before the OMG standardised it.

History & Origins

Softeam, Desfray and Class-Relation

Softeam was a French software house that built Objecteering around a method of its own called Class-Relation, associated with Philippe Desfray, Softeam’s head of R&D. According to the version history in Softeam’s own Objecteering/UML 5.2.2 documentation, Objecteering 3 was “created in 1992” as a UNIX workshop “based on an entirely generated code, and on the Class-Relation model”. In October 1992 Computergram reported Softeam taking Objecteering to the US market. The tool automatically generated C++ applications from Class-Relation models and also produced documentation, and it ran on Sun, Digital Equipment and Hewlett-Packard systems. In 1993 the tool was shown in the UK through the distributor Integral Solutions Ltd, by then on IBM hardware as well.

Desfray described the method in Object Engineering: The Fourth Dimension (Addison-Wesley, 1994). That book introduced hypergenericity: producing technical designs from analysis models by applying general transformation rules rather than by hand. This is the job J later did inside the tool. Secondary accounts of Class-Relation say the method defined a model-refinement language of its own. No primary source reached for this page establishes whether J descends directly from it, so this page makes no claim either way.

From Class-Relation to UML and J

The 5.2.2 version history describes Objecteering 4 as “a completely different architecture”: multi-formalism (OMT, UML and Class-Relation) and multi-platform (UNIX and Windows PCs). Later 4.x releases added UML 1.3 support, use cases, HTML documentation and configuration management. The 5.x line (Objecteering/UML 5.1, 5.1.1, 5.2, 5.2.1, 5.2.2) added Java, EJB, JUnit, Visual Basic and XMI modules, and Linux support arrived in 5.2 and 5.2.1.

The earliest dated reference to J by name found is a 1999 Softeam paper, UML Profiles and the J Language: Totally control your application development using UML. The exact release that first shipped J is not documented in any source reached for this page. The year above is therefore the year J is first documented, not a confirmed release date. The most detailed surviving description is the Objecteering/J Language User Guide, version 5.2.2, © 2003 Objecteering Software, which this page draws on throughout.

Design Philosophy

J was built on a few deliberate choices, all stated in its manual:

• Familiar syntax, narrow purpose. J has “a Java-like syntax”, and the manual assumes readers already know Smalltalk, Eiffel, C++ or Java. It leaves out much of Java on purpose: interfaces, packages and most Java libraries “cannot be handled”.
• The metamodel is the class library. J’s classes are the basic types (Object, String, boolean, int, float, streams) plus the Objecteering UML metamodel. A programmer adds methods to existing metaclasses but “cannot define new classes”.
• Profiles decide which method runs. The interpreter picks a method from two things: the class of the receiving object and the current UML profile. The manual calls this a “double look up mechanism”. It is how one generate() can mean C++ in one profile and documentation in another.
• Interpreted for fast turnaround. J is interpreted, so changes take effect immediately, and the language exposes an eval that executes a string of J code at run time.

Key Features

Methods on metaclasses

A J method is written as Metaclass:methodName(...) and runs with a model element as this. Attributes of the metamodel (Name, Visibility) are read directly, and roles are reached by joining the role name and the metaclass name. PartAttribute means “the attributes that are part of this class”. Here is the manual’s first example, which lists every class in a package with its public operations:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

Package:listClasses ()
{
  OwnedElementClass              // every class owned by the package
  {
    StdOut.write(NL, "CLASS:", Name);
    PartOperation.<select (Visibility == Public)
    {
      StdOut.write(NL, " Public method:", Name);
    }
  }
}

Sets, diffusion and anonymous methods

Sets carry most of the work in J. A role such as PartOperation returns a typed set (Operation[]), and J offers several ways to act on one:

The manual shows the same filter written three ways:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

// 1: anonymous method
PartOperation.<select(Visibility == Public)
{
  display ();
}

// 2: message diffusion
PartOperation.<select(Visibility == Public).<display ();

// 3: through a variable
Operation [] E;
E = PartOperation.<select(Visibility == Public);
E.<display();

The language has very few control structures besides these. The manual lists only if, message sending, and the set structures (select, while, diffusion and anonymous methods). There is no for loop, and sets cannot be indexed with E[i]. Element access goes through library calls such as getItemSet and setItemSet.

Polymorphism and super

Methods are polymorphic over the metamodel’s own inheritance tree, and super reaches the parent metaclass’s definition:

1
2
3
4
5
6
7
8
9

String Feature:format()
{
  return Name;
}

String Attribute:format()
{
  return "(Attribute) " + super.format;
}

UML profiles as method namespaces

Every J method belongs to a UML profile. Profiles form a hierarchy rooted at default, written as a path:

1
2
3
4
5

Package:default#documentation#generate()
{ ... }

Package:default#Cxx#generate()
{ ... }

This is how users customised the generators that shipped with the tool. The manual gives three steps:

1. Define a sub-profile under the generator’s profile (for example Cxx#Specific).
2. Redefine the method to change (for example Attribute:Generate) in that sub-profile.
3. Run generation from the new profile.

Introspection and eval

All J classes are instances of Metaclass, so a program can ask any element for its metaclass and that metaclass’s parents. The manual likens this to Java introspection. Changing the metamodel itself is not allowed. eval runs a string as J statements in the current context. The manual’s example writes i1 = 15; s1 = "hello"; b1=false to a file, reads it back and evals it to restore three local variables.

Command-line execution

The objingcl command runs J outside the graphical tool. Its “project” mode runs a J command against a model, such as code generation. Its “administration” mode was meant for automated scripts. The manual’s example starts C++ generation on a work product:

1

objingcl -db myBase -prj myProject -mdl CxxModule -cmd generate::*::MpcCodeCxx:A_cxx

Evolution

The 5.2.2 manual set documents J itself in three books: the J Language User Guide, the J Libraries / Metamodel guide, and the UML Profile Builder guide.

Current Relevance

J is a historical language. Modelio, its successor, has been distributed since January 2009 by Modeliosoft and Objecteering Software. Modelio reportedly reuses Objecteering’s architectural core, but its configuration and MDA support are based entirely on Java, and its scripting console runs Jython. Modelio’s core was released as open source under the GPLv3 on 5 October 2011. J was never released, so it survives only in old Objecteering installations and in the PDF manuals, some of which are still hosted by a university computer science department.

Why It Matters

J is a compact example of an idea that later went mainstream: code generators as ordinary, overridable object-oriented programs over a metamodel. Several of its features predate the standards that later named them. Profiles act as namespaces with inheritance. Diffusion sends one message to every element of a set. Generators are customised by subclassing a profile and overriding one method. The OMG later standardised the same pieces as UML profiles, model transformations and MDA tooling. Softeam itself, by its own account an OMG voting member since 1994, describes Objecteering/UML as the first CASE tool to support the MDA approach.

J also shows the trade-off that domain-specific languages built into a tool still face. Because the classes were fixed by the metamodel, J was very concise at walking models. The same design meant it could not be used outside Objecteering, and it disappeared when the tool did.