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!