To complement the UML models and be able to precisely specify complex business rules, we need to add some type of logic-based language. In the software modeling world, this language is typically the Object Constraint Language (OCL). OCL is a general-purpose (textual) formal language adopted as a standard by the OMG and used to define several kinds of expressions that complement the information of (UML) models. More details on OCL can be found here.
And while there are over a hundred institutions we know that teach UML and software modeling concepts, our “feeling” is that few of them cover OCL, despite its importance (again, “in our humble opinion”). Another “feeling” is that one of the reasons is the lack of OCL tools that are easy to use in class to let students “play” with OCL while providing useful feedback. Both at the parsing level, to help students write syntactically correct OCL expressions, and at the execution level, to help students understand the semantics. Unfortunately, the list of OCL tools is decreasing, something we are trying to counter with our Python-based OCL parser and interpreter.
Therefore, we would like to understand whether this is actually the case (i.e., there are indeed few courses where OCL is covered and that lack of proper tooling is part of the problem). In particular, we would like to know:
- For those that do teach OCL, what parts of OCL are covered and what OCL tools do you use in the course.
- For those that do NOT teach OCL, why is that. Do you teach some other logic-based language to express the business rules? Just natural language? And what are the reasons behind your decision? Is the lack of teaching material? The lack of tool support?
Share your insights
If you teach UML (Unified Modeling Language), software modeling or model-driven engineering, software design or any other related topic, we would like to invite you to answer this very short survey around the questions above: https://forms.gle/6f4oEn892fsbVSRu7
We are looking forward to your useful insights! And of course, we’ll share the results in this same blog.
Even in my humble opinion, teaching OCL is essential to providing future software engineers with the right concepts and tools to tackle complex software engineering projects. OCL was part of the books we wrote with colleagues on software engineering around 2010.
Dr. Birgit Demuth’s team developed a tool to convert OCL into Java code, but unfortunately, it was lost in future versions of Java. I have not yet tried the OCL and Python you guys have developed; thus, I cannot say anything, but I find it very useful to use OCL to express model constraints for all the good reasons we have known for a long time.
Congratulations on your excellent work!
Hello Thank you for your survey. I have taught for a long time UML and I just can say that my students are no more interested by OCL thinking they loose their timw with this Pseudo language.
Sure, students may think that but what do you think?
Hello, it’s an excellent provocation, in the modeling system class the spotlights go to UML and its tooling, it’s ok. But why not insert OCL to make business rules explicit while the student improves their logic?
This is a great idea! We are teaching UML as part of a Software System Analysis and Design graduate level course, but didn’t have a chance yet to include OCL as part of the course.
Was it because of lack of time to squeeze more content in the course? Or there are other reasons?
The reason is that I’m looking for more hands-on, precise, language-like material to add to the course.
I also responded to the survey, but will repeat some of what I said there: I am trying to incorporate OCL into our software modeling course (a new elective I taught over the summer, but based on a course I had taught elsewhere in the past), but the tools for it make it challenging. The OCL editor in Papyrus is horribly broken in a way that made it extremely frustrating for the students to use. Having a free tool that is easy for students to install and use (with instructor guidance) would make teaching OCL much easier.
You’re right. A big problem with OCL (or MDSE in general) relates to how people can use the tool (i.e. is the tool hard to use/comprehend). And even though Eclipse is the biggest “MDSE playground”, it’s has many drawbacks that makes us zoomers screech whenever we have to work with it: lacks of compatibility with other IDEs (most students use VSCode for now); the platform-dependent problem with Eclipse-runtime-based tools (which hard to translate into other platforms), ect.
Writing OCL in VSCode is indeed possible with https://github.com/BESSER-PEARL/B-OCL-Interpreter !
Haven’t tried it myself but soon I will. B-OCL along with BESSER seem promising and could be one of the new game changers for the modernization & mass adoption of MDSE tool. But as far as I know, there isn’t any vscode extension that support those tools right now, but I hope they would be available in the near future.
Edit: After trying out BESSER I can finally understand what it actually is. It’s not like some kind of Eclipse-like modelling tools, it’s actually embedded into Python as a framework. The problem with VSCode is not really matter since it’s all Python code!
However for special concepts like OCL expressions, current version of BESSER is still representing them as Pythonic `str`, which is still not very intuitive (tooling-wise and visually), but in general it’s far better than any “modelling tool” I wish Eclipse had.
Nghia, not sure I understand the “str” part for special concepts. The OCL expressions are parsed and stored as instances of the OCL metamodel. Can you be more specific so that I look into it?
Given an example constraint like this.
“`
constraintEmployeeAge: Constraint = Constraint(
name=”constraintEmployeeAge”,
context=Employee,
expression=”context Employee inv employeeMustBeAdult: self.age >= 18″,
language=”OCL”,
)
“`
What I mean is if you write a constraint like this, the OCL expression will be visually represented as a Python string, with no syntax highlighting or other advanced toolings for the OCL language itself.
Using OCL expressions as Python strings is understandable from a technical viewpoint, but I wish we can somehow have better tooling for this. I.e. a separated OCL language (with LSP and IDE supports) can be compiled down to its Pythonic representation.
One suitable way could be expanding the PlantUML-2-BUML transformation engine, as we make our own “BESSER” dialect for PlantUML to include OCL specifications too. The PlantUML+OCL file can then be converted into Python/BUML+BOCL.
Ah, I see. You mean to have better support when writing the constraints. I guess the easiest way for that would be to define the OCL grammar as a Langium grammar and generate a VSCode extension with that