Concept Modeling, Antoni Olivé and Software Concepts

After starting to read through the software concepts book, I spent some time studying the bibliography. I noticed that you did not include any of the European work on “conceptual modeling” that was started by Antoni Olivé and his students. Out of this school of concept modeling has come the system Integranova, which is effectively a general purpose 4GL.

The Integranova system has been used for production work for about 20 years now and it is highly rated by Capers Jones as being extremely productive. Much of this system’s power comes from doing the development at the conceptual level and separating out runtime system concerns from conceptual model concerns. For example, suppose you have a “customer list” as a conceptual model element: The user wants to do a number of sensible actions associated with this list, and independently the customer list maps differently to a set of UI elements for a desktop GUI app or for a mobile phone app.

While this body of research on conceptual modeling probably doesn’t map directly to your view on concepts, there is a great degree of overlap. There are some other areas of overlap I’ve come across, but this one in particular seemed good to bring to your attention because of how advanced the modeling tooling is in this one area.

If you are familiar with this work but have chosen to leave it out, I would be very interested to learn what deficiencies you identified that steered you away from this approach.

1 Like

This is a great question. I’ve been a big fan of conceptual modeling for many years. I’ve long been a believer in the idea of constructing an abstract data model that is independent of both the implementation structures and the representation in the user interface itself. This idea is central to formal methods (such as Z, VDM, B etc) too, and there has been mutual influence between the two fields, going back to Jean-Raymond Abrial bringing his knowledge of databases to the design of Z in the 1970s, and then back in the other direction, with (eg) attempts to formalize UML a few decades later.

My own language Alloy was very much inspired by conceptual modeling. Like the formal methods such as VDM, Z and B, it aimed to combine data modeling with behavioral modeling; but like the conceptual modeling work, it took relationships as primary, and dispensed with all the conventional abstract mathematical data structures (records, sets, sequences, etc) in favor of just using relations (taking as its inspiration Tarski’s theory of relations). What Alloy brought to conceptual modeling was the possibility of doing fully automatic analysis in the style of model checking, and for this reason quite a few researchers have built translations from UML to Alloy and have conducted case studies using Alloy as the basis of model-driven development or for analyzing ontologies.

So when I started the concept design work about ten years ago, I was generally well aware of work in conceptual modeling. What seemed to me missing in that work was primarily two things. First, although there was a notion of a conceptual model, there was no notion of a concept per se, and entities could not play this role (I mention this in my ACM tech talk). Second, there was no notion of behavior that was any different from the kind of behavior modeling done in formal methods, in which you associate a state transition system globally with the abstract data model. The result of these two omissions is that you can’t do the most important thing I wanted to do with concepts: namely, have the modularity you need to break a system into separately understandable pieces, and to identify patterns that can be reused across apps. (There is one example of doing this a bit with conceptual models and that is Martin Fowler’s analysis patterns.)

To achieve these goals, concept design offers two key innovations. One is to view the abstract data model not as a single model but as a pinning together of many local data models, each of which is polymorphic and instantiated according to context. The other is to associate behavior with the local data models. These data models and their behavior then comprise the concepts.

I had not been familiar with the work of Antoni Olivé and his students including Oscar Pastor, so I was very interested to see some of that. I haven’t read that much of it yet, but I did take a look at some papers, and they seem very interesting. They don’t seem to address the concerns I had in mind when I developed concepts. I looked at Pastor et al’s 2001 paper The OO-method approach for information systems modeling. What he seems to do there is to define behavior by associating it with classes (in an object-oriented sense).

This is a very different approach to concepts. I didn’t adopt this kind of approach, which is followed in other model-driven engineering projects, because in my view it forces you to move away from a true conceptual model to a more implementation-oriented one, and to make decisions about allocating functionality that don’t seem intuitive to me. I know some people have argued that the objects and classes of OOP are appropriate for modeling the real world, but they seem to me to embody implementation decisions (eg, in that the updating of a relationship between objects has to be cast as an update of one object or the other).

In Pastor et al’s example of the library model, for example, they allocate all the behavior associated with borrowing books to the reader, including punishment for lateness, but I don’t see a strong rationale for this, rather than associating behavior with the library, or the librarian, or even the book. In fact, the book might be seen as a more compelling entity to associate loans with, since it is within the scope of a single book that the ordering of loan events is defined. In approaches such JSD, the loan event would be part of the entity-life history of the book.

In concept design, I can sidestep this problem by associating loan behavior with the concept of a Loan that includes readers, books and libraries. Note also that in concept design the behavior associated with punishing readers would not need to be included along with the behavior of loans, but could be regarded as a distinct concept, so that you could describe designs that included loans but without punishments. Fees similarly would be factored out in a concept design, allowing you to decouple the understanding of fees and loans, and to charge fees for other services too.

I’d be very interested to hear reactions to this perspective from you and your colleagues in the conceptual modeling community!

1 Like

What is the best way to characterize the relationship between concepts and the schema (both entities and operations / behavior)? Each concept places constraints on the entities and operations or that each concept partially specifies the entities and operations?

As a hypothetical example: if we have a complete catalog of ready-made concepts to work from, then does a selected set of “concepts” needed to define our solution fully specify a schema or does it just place a bunch of “constraints” (non-functional requirements?) on whatever schema you want to create for the solution system?

Really, there are two parts to this question. One is whether a set of concepts for a solution like “Dropbox” is complete and covers all of the system functionality (whether exposed to the user or not). The other has to do with how concepts relate back to entities and operations - I would assume that a system designed with concepts would still end up having these “conceptual schema” constructs even though there is a complex relationship between the concepts and the entities/behaviors.

This paper seems to answer my follow up question:
Declarative Assembly of Web Applications from Predefined Concepts
S. Perez De Rosso, D. Jackson, M. Archie, C. Lao, and B. McNamara III. In Proceedings of the 2019 ACM International Symposium on New Ideas, New Paradigms, and Reflections on Programming & Software (Onward! 2019)

“A concept is a self-contained, reusable increment of functionality. Each concept includes both front-end and back-end functionality, and exports a collection of components—full-stack GUI elements, backed by application logic and database storage.”