Remarks about OCL and Django project generation
This issue feels more like a discussion, but I couldn't find a discussions tab on the BESSER repository, so I'll present it here instead.
On BESSER's documentation website, it states: “BESSER enables users to model, generate, and validate software systems.” “…The Web Modeling Editor allows users to design B-UML models and use the BESSER code generators.”
Currently, within WME, you can create a Class diagram and generate CRUD code from it (e.g., a Django project). This generates a working model of the domain model designed in the Class diagram. The generated project demonstrates the application’s basic functionality and supports functional testing of CRUD operations.
On the Class diagram, users can specify OCL constraints and validate them using the Quality Check menu option. However, there is currently no further implementation of these OCL constraints in the generated code.
In summary, while BESSER can create a functioning model of an application, it is not yet capable of generating a fully functional application. Generating an application directly from a UML model is known to be complex, and some argue that it might even be impossible. But perhaps it's worth attempting to push these boundaries.
For example, the Django project generation could be further elaborated. Django models offer various field options (e.g., primary_key, unique, default, etc.) that allow fine-tuning applications. These options could be implemented as:
-
Extensions to class attribute definitions,
-
OCL constraints,
-
Specifications during Django project generation.
Additionally, these configurations could be saved to a file (e.g., Django_options.json) for future reuse. Are there any plans to support such functionality?
Furthermore, writing OCL code is challenging. Are there any plans to introduce a wizard or provide example templates to simplify the process? Lastly, will these constraints ever be implemented in the generated code, such as in a Django project?
Yes, validation is one of the tasks BESSER aims to address. Right now, OCL constraint validation over an object model is possible using the B-OCL interpreter, but it’s not yet supported by the WME or the code generators.
For Django, these constraints can be translated into validators, handled in the clean method, or enforced at the database level.
Since BESSER already includes an OCL parser, extending the Django generator to support OCL constraints should be feasible. This would allow models to automatically incorporate these rules from the B-UML model definition.
One of our future steps is developing assistants to support modeling tasks, but while adding support for OCL definitions or providing templates is an interesting idea, but it's not currently in our roadmap.
We're continuously working to extend and improve BESSER in various ways, and since it's open-source, contributions are always welcome. If you're interested in contributing, we'd be happy to guide you.
Hi Iván,
Thank you for inviting me to contribute. I believe I’m already contributing by actively using WME and suggesting improvements. When the need arises to program directly in BESSER, I’ll reach out to you for guidance.
My current focus is on using WME to develop an application for editing a generated Django project. Once completed, I’ll share the results for potential implementation.
In your opinion, would presenting OCL constraints in a human-readable form enhance the clarity of the class diagram?
On Mon, 31 Mar 2025 at 23:13, Iván Alfonso @.***> wrote:
Yes, validation is one of the tasks BESSER aims to address. Right now, OCL constraint validation over an object model is possible using the B-OCL interpreter https://github.com/BESSER-PEARL/B-OCL-Interpreter, but it’s not yet supported by the WME or the code generators.
For Django, these constraints can be translated into validators https://docs.djangoproject.com/en/5.1/ref/validators/, handled in the clean method https://docs.djangoproject.com/en/5.1/ref/forms/validation/, or enforced at the database level.
Since BESSER already includes an OCL parser, extending the Django generator to support OCL constraints should be feasible. This would allow models to automatically incorporate these rules from the B-UML model definition.
One of our future steps is developing assistants to support modeling tasks, but while adding support for OCL definitions or providing templates is an interesting idea, but it's not currently in our roadmap.
We're continuously working to extend and improve BESSER in various ways, and since it's open-source, contributions are always welcome. If you're interested in contributing, we'd be happy to guide you.
— Reply to this email directly, view it on GitHub https://github.com/BESSER-PEARL/BESSER/issues/270#issuecomment-2767410844, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGT5N6KKK6JIYHT5L7IXYBT2XGVWFAVCNFSM6AAAAAB2ERFRQKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONRXGQYTAOBUGQ . You are receiving this because you authored the thread.Message ID: @.***> [image: ivan-alfonso]ivan-alfonso left a comment (BESSER-PEARL/BESSER#270) https://github.com/BESSER-PEARL/BESSER/issues/270#issuecomment-2767410844
Yes, validation is one of the tasks BESSER aims to address. Right now, OCL constraint validation over an object model is possible using the B-OCL interpreter https://github.com/BESSER-PEARL/B-OCL-Interpreter, but it’s not yet supported by the WME or the code generators.
For Django, these constraints can be translated into validators https://docs.djangoproject.com/en/5.1/ref/validators/, handled in the clean method https://docs.djangoproject.com/en/5.1/ref/forms/validation/, or enforced at the database level.
Since BESSER already includes an OCL parser, extending the Django generator to support OCL constraints should be feasible. This would allow models to automatically incorporate these rules from the B-UML model definition.
One of our future steps is developing assistants to support modeling tasks, but while adding support for OCL definitions or providing templates is an interesting idea, but it's not currently in our roadmap.
We're continuously working to extend and improve BESSER in various ways, and since it's open-source, contributions are always welcome. If you're interested in contributing, we'd be happy to guide you.
— Reply to this email directly, view it on GitHub https://github.com/BESSER-PEARL/BESSER/issues/270#issuecomment-2767410844, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGT5N6KKK6JIYHT5L7IXYBT2XGVWFAVCNFSM6AAAAAB2ERFRQKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONRXGQYTAOBUGQ . You are receiving this because you authored the thread.Message ID: @.***>
Hi,
In the past, I've done quite a lot of work on both "verbalizing" OCL constraints and, more importantly, on efficiently checking them at runtime (this was in fact my phd thesis, the methods were generic but could be adapted to the code generation on specific platforms).
So, this just to say that I'm indeed a fan of getting the most out of OCL. And we'll do some work on that but in a couple of months as our "OCL developer" is not available right now. Thanks for your suggestions!
I'm adding a couple of issues from this thread to the B-OCL repo