OpenPonk (meta)modeling platform

Tweet about this on TwitterShare on FacebookBuffer this pageShare on RedditShare on LinkedInShare on Google+Email this to someone

OpenPonk is a free and open source experimental (meta)modeling platform built in the Pharo live environment aiming to create a live, programmable modeling platform for both serious work and fooling around.

The best way to explain this idea is to look at why we started OpenPonk and what we seek from it.

Why we started OpenPonk

OpenPonk was born in Centre for Conceptual Modelling (CCMi) at Faculty of Information Technology of Czech Technical University in Prague. CCMi is a research group concerned with conceptual modeling and the associated challenges. We are interested in designing, advancing, and utilizing models and notations; both mainstream ones (e.g. UML, BPMN), but more importantly domain-specific ones used in specialized environments.

This practically means that we often need a “poweruser” approach to (meta)modeling; we need to manipulate models and data in unexpected ways, easily prototype tools, “what-if” ideas, and generally have different perspectives (especially visual). From a tooling perspective, we also want a platform where a user can build easily and cheaply a solid foundation for their specific metamodels. It is not too uncommon for vendors to have half-baked solutions, especially true for non-software vendors. This is not surprising; building good tools is costly and requires extra expertise, that the user might not possess – their expertise lies elsewhere. We want to lower both the cost and the necessary complexity.

OpenPonk (meta)modeling platform

Metamodeling platform

At the moment we do not support ECore, (e/c)MOF, complete UML, or any other metametamodel to express metamodels in. This makes it much harder to add extensive and well-defined metamodels, and we would certainly like to make amendments in this area, however this hasn’t been an a primary concern so far. Existing models that we work with rarely have an explicit metamodel; in most cases the metamodel is inherently expressed in its actual implementation or semi-represented in some exported form, e.g. model saved in a custom XML file that has neither DTD nor schema. And yet we need to be able to work with such metamodels and create tools for them.

From this perspective, the aim of the platform is to reduce the complexity and the work necessary for creating usable modeling tools and editors even for non-systematic metamodels; after all, any object representation (in OO language) has an implicit metamodel and there may be value in visualizing it or managing it.

So practically speaking, at the moment the only way to add metamodels is through manual implementation in code in Pharo (or writing a code generator applicable to your metamodel).

Modeling tools

From the modeling tool perspective, we have several metamodels, notations, and operations in various stages of progress; some of it proof-of-concept, some for our custom needs, some for our business partners.


  • UML Class Diagrams – mostly for research related to Ontological UML
  • Finite-state machine – proof-of-concept and playground for ideas
  • Business Objects Relation Models (BORM) – one of our methodologies
  • DEMO (enterprise engineering process models), and
  • domain-augmented ER models

Plus some other toys to play with, like textual notation for UML Class Diagrams and BORM (both built with PetitParser, which provides a very agile way of creating grammars), with the ability to edit a diagram (and obviously the model behind) with both text and graphical editor at the same time.

Model non-exclusively editable via visual interface and text DSL side-by-side

Model editable both via visual interface and text DSL side-by-side


Importance of Pharo

We have to talk about the core environment where OpenPonk lives: Pharo; a modern, ever evolving Smalltalk dialect.

To people unfamiliar, Pharo (or Smalltalk in general) is sort of a programming language, IDE, execution environment and operating system rolled into one, where each part is deeply integrated with one another and all at your fingertips.

For a lack of better comparison, in a modern browser you can open console, play with a DOM, maybe execute some hand-written code. Imagine that you can do this with every aspect of the website, the application, the browser itself, and perhaps even parts of the operating system running it (during runtime, of course),  in a docker-like execution container. Pharo is that and much more.

But how does this help with modeling?

Pharo makes for a great platform for rapid prototyping thanks to the combination of a dead-simple language (the grandparent of OO languages), powerful metaprogramming capabilities and short feedback loops; hey, you can even write your entire application in a debugger.

Pharo also gives models life, in a sense. As I have mentioned earlier, any software representation is a model, so why treat models like something magical hidden behind layers of abstractions and queryable only via designated languages? Models are just objects, so we are free to look at them directly, manipulate them with regular code, and utilize their raw power.


A state machine model instantiated with regular code and opened in OpenPonk. With object inspection we can directly manipulate both the model and its visual counterpart.

Both OpenPonk and Pharo are open source and as noted earlier, the code is directly available and modifiable in the environment. This can be quite practical if when the platform itself wouldn’t be sufficient for a certain case; you can just open the appropriate class of OpenPonk (or Pharo) and modify the code live.

What about other tools?

What we are trying to do is hardly a novel idea, with the most relevant alternative being Eclipse and its Graphical Modeling Project. GMP was in fact the initial pick for our needs, and we built our first BORM editor (which is still being used at times). Although successful at first, with advancing needs we found the environment increasingly restrictive. Combined with a steep learning curve for new contributors, layers of abstractions to facilitate all the generic tools and needs, and overall architecture we simply didn’t see it as a good fit for our long-term needs. Information hiding, user hand-holding, and over-engineering are certainly valuable, if you seek a robust solution for end-users. But for a poweruser any non-essential complexity is problematic, or prohibits different use-cases (in part this also relates to Java).

Future plans

Just like any other project, we are limited by resources. We started as two person effort on a greenfield, with most of the codebase still written by me, but we are finally getting some traction. Several students have already finished theses on topics related to OpenPonk, and I am working on a OpenPonk-based modeling solution for one of our partners. Gaining traction also means that I need to invest much more energy into writing docs (as the current state is… not exciting to say the least), ideally in some interactive format.

Short-term perspective is always bound to the needs of a specific case; whether a thesis, or a solution for specific environment.

From mid-term perspective I want to move the platform from its current monolithic-ish and MVC-ish state to a dynamic environment that better accommodates CCMi’s needs. When I started, I was building just another diagramming tool, as that was most familiar to me. But now I am slowly drifting towards a more dynamic environment; I am learning a lot along the way, including learning what I am actually trying to do.

My own interest is in seeking bridges between code and models as a natural extension of one another. Maybe write some code here, generate a bit from model there. Live synchronization between code and models. Visual and text code editing side by side. Natural flow from code to model and back. OpenPonk and Pharo are a great place to explore such ideas and see how modeling can be introduced to everyday programming. As long as people re willingly writing just code, then the cost of modeling is too high.

Further reading

Tweet about this on TwitterShare on FacebookBuffer this pageShare on RedditShare on LinkedInShare on Google+Email this to someone
  1. rad9k
    • Jordi Cabot
  2. rad9k
    • Peter Uhnak
    • Jordi Cabot
  3. rad9k
    • Peter Uhnak
  4. Serge Stinckwich
  5. Igor Dejanović
    • Serge Stinckwich
    • Peter Uhnak


Your email address will not be published. Required fields are marked *