Context and History
If we want to think of
Code as a Model, we should also be able to understand
Model as Code -- manifesto with Steven Little, Veda Storey at al.
Oscar told us the history of software from object-oriented software modeled with UML, arriving at GORE, going through model-driven architecture, up to the need of ontologies to make the languages' and models' semantics precise.
From Oscar's PhD (1996) - OO-Method Approach (Problem Space level -- Automated Translation -- Solution Space Level (already doing Model-driven development, with automatic code generation).
At this time, he had also a solution to develop web-based systems, and he talked about the business layer (which includes services).
Old Metaphor: software as a
table with three legs: structure, behavior and interaction. This view is
still useful. Yesterday, he has seen presentations on the structural part (database schemes, information model etc.).
The MDD transformation may be in this direction:
roles, requirements -> conceptual schema -> code
Oscar thinks Information Systems engineering is more important than Software Engineering, because it is important to handle with socio-technical systems. In ISs, we have not only technical people working, but also lawyers, and other people from the social sciences.
There is an emerging need to focus on
interactive requirements - the main thing we must target is our perception of the world. There are different means of interaction between the analyst, the stakeholder and the world, so we must put lots of attention to interactive concepts and interactive requirements.
Since the beginning, Oscar's work focused on providing automation for the software development process, focusing on the whole life cycle. With Hugo and Alicia, he worked on what they called "a complete model based software production process."
Model-driven Engineering: a Practical Experience
He presented the usual MDA models and transformations, connecting them with RE (Computation Independent Model), Software Analysis (Platform Independent Model), Software Design (Platform Specific Model) and Implementation (Code).
He thinks that having an
OntoUML compiler that generates code directly could be a good idea.
For model transformation, there are several tools, both for the transformation itself and to each of the modeling languages we must apply. He showed a big list of existing tools.
Communication Analysis: a Requirements Engineering Method for Information Systems
Sergio España's PhD work: still ongoing in terms of using, improving and automating the method.
Oscar highlights that opposite to other kinds of models (such as data models, business process models etc.), there is no standard language for interaction/presentation model. Giancarlo highlights that there are some standard developed for protocol engineering which may be useful here: e.g. ISDL (see https://link.springer.com/book/10.1007%2F978-3-319-43298-4).
To add to the discussion, in the perspective of HCI, Eric mentions that possibly the work on ISDL cannot capture the complexities of human interaction. In fact, Giancarlo says, interactive and presentation modeling are two different things anyway. Oscar acknowledges that these two perspectives are sometimes inappropriately mixed.
Oscar has a strong opinion that if a software engineer does not have strong skills on abstraction, he/she should not have his/her degree. But in practice, he realizes that most of his students in the master level do not. For example, they mix in one model, things that belong to different abstraction levels. That is a big problem!
Oscar showed an example of a socio-technical system to motivate the use of communication analysis. The main problem in such scenarios is one of communication.
Deriving Conceptual Models from Req Specifications
They propose in OlivaNova (see
this article), a Requirements model is compiled into a conceptual model (composed of structural model, communication model and business model).
They apply conceptual schema to generate the class-diagrams they need. This is done interactively.
And in the end, they can also generate code and view the user application.
Linking Goal Models with Communication Analysis Models
Still, there is one missing dimension in this work:
the connection to goals, as they understand that the intentional dimension is important to understand why the business processes are executed.
Their work aims at connecting: intention + processes and communication + behavior + interaction
Advantages:
- integrated approach allows understanding the motivation for processes
- goals can be used to guide process design
- traceability is enhanced
- sustainability in organizations may be achieve
In this work, they apply a design science approach.
They use the FRISCO Ontology to connect
i* and communication analysis (the integration should be well founded in theory).
They provide some guidelines of how to go from
i* to the process and communication models.
Oscar says that there is an important issue to be targeted, which is the point that people prefer to use BPMN and not the business process modeling language that they propose.
