We introduce a domain-specific language for modeling AI engineering processes. The DSL enables you to describe how teams are developing AI-based software. As such, the DSL helps to clarify the process, simplify onboarding of new members and enables the analysis and enactment of the process.
We propose an extension to the OCL notation to be able to model constraints even when we do not have enough domain information to be completely precise about the rule we are modeling
Slides of my keynote presentation at EDOC 22 where I discuss recent advances on the modeling and generation of AI-enhanced software and how some of these advances could actually be helpful to speed up the development process itself
The advances in Artificial Intelligence and, in particular, in the Natural Language Processing (NLP) subfield, are becoming mainstream technology. For instance, NLP recent advances such as GPT-3 are able to produce human-like text to be used in copywriting,...
We often see many claims about the benefits of low-code platforms. Here we take a more systematic approach to come out with the most empirically-proven list of benefits (and limitations) of low-code
bigER is a free and open-source ER modeling tool supporting hybrid, textual- and graphical editing, multiple notations, and SQL code generation. The tool is available as an extension for Visual Studio Code.
DescribeML is a Visual Studio Code plugin to precisely describe machine learning datasets.
What are the core principles of a good concrete syntax? A famous mathematician lists his main principles. To take into account when designing your next DSL.
This is a recurrent question. Even if I barely teach right now, people keep asking me what tool would I recommend to teach UML courses. And it has also been a "hot" topic in our team, especially since NoMagic dropped the academic license for MagicDraw (or complicated...
Low-code platforms need to evolve from application-building platforms into platform-building platforms that enable the creation and evolution of complex software projects part of a larger ecosystem
How do real software projects deal with non-functional requirements? This paper sheds some light on this issue by talking with software architects