The Model Driven Software Network
Raise your level of abstraction
Behavioral modeling
Curious for the event announced by Ella Roubtsova on behavioural modeling, I have asked Ella and Mr Ashley Mc Neile on the subject, and their explanations I belive opens a critical aspect to discuss. The beginnings of the conversation was among ours, but in my opinion it values enough to open a thread apart.
I want to resume my point of view, as a practitioneer and an observer, and then the initial response from Ella and Ashley, in order to start a discussion.
Why I am interested in "behavioural modeling", repeating what said previously:
"I´m not using MDA, but another way to create applications from models. However, I have followed with entusiasm OMG and other efforts to develop a standard for modeling to generate applications. I agree strongly with the idea of model design at abstract level, separating for platform design. I have seen, passing years of different approaches, how UML have become a constraint for OMG standards. Here, repeatedly, the discussion falls on a critical separation: model transformations arriving to a static representation of the application, which requires code intervention. I have discussed this issue before, regarding colleagues working with Rose or AndroMda: the automation gets a limit, which requires code. Descriptions of EMF shows a similar process: at end of modeling, you need to add java code.
It seems to me an issue, an obstacle that must be faced. Mr Varnica mentions today two issues which relate to model integrity: how to assure that an object have a unique representation into the model (Vlad says "I mean that changing one element in one diagram would immediately update my other 1,000 diagrams which include this element"); and how to get traceability of the use of an object into the model ("know in which diagram my element is used"). Add this "frustration" to the fact that the behavior of the model is declared in java code. What propagation of changes could be made this way? What traceability? How if manual code introduces errors in mapping from model object to code?
I belive this is a critical issue for Model abstraction, and must be solved. Behavior of the model must be represented in its proper terms, and it must be generated from abstract definition, which maps strictly to model definition. It is the only way to support maintainbility, and not to fall in an early definition, which finally differs from the "live" application, which resides into the code.
In sum, it is my interest in your point of view, be it mature or immature. I belive that "behavioral modeling" sounds great.
Regarding participation on the workshop, I like it, but I´m more able to hear than to talk...I will be very interested in know its results, indeed."
Regarding Mr Mc Neile vision, maybe it´s preferable give him the right to explain himself. He will do it largely better than me...
I want to resume my point of view, as a practitioneer and an observer, and then the initial response from Ella and Ashley, in order to start a discussion.
Why I am interested in "behavioural modeling", repeating what said previously:
"I´m not using MDA, but another way to create applications from models. However, I have followed with entusiasm OMG and other efforts to develop a standard for modeling to generate applications. I agree strongly with the idea of model design at abstract level, separating for platform design. I have seen, passing years of different approaches, how UML have become a constraint for OMG standards. Here, repeatedly, the discussion falls on a critical separation: model transformations arriving to a static representation of the application, which requires code intervention. I have discussed this issue before, regarding colleagues working with Rose or AndroMda: the automation gets a limit, which requires code. Descriptions of EMF shows a similar process: at end of modeling, you need to add java code.
It seems to me an issue, an obstacle that must be faced. Mr Varnica mentions today two issues which relate to model integrity: how to assure that an object have a unique representation into the model (Vlad says "I mean that changing one element in one diagram would immediately update my other 1,000 diagrams which include this element"); and how to get traceability of the use of an object into the model ("know in which diagram my element is used"). Add this "frustration" to the fact that the behavior of the model is declared in java code. What propagation of changes could be made this way? What traceability? How if manual code introduces errors in mapping from model object to code?
I belive this is a critical issue for Model abstraction, and must be solved. Behavior of the model must be represented in its proper terms, and it must be generated from abstract definition, which maps strictly to model definition. It is the only way to support maintainbility, and not to fall in an early definition, which finally differs from the "live" application, which resides into the code.
In sum, it is my interest in your point of view, be it mature or immature. I belive that "behavioral modeling" sounds great.
Regarding participation on the workshop, I like it, but I´m more able to hear than to talk...I will be very interested in know its results, indeed."
Regarding Mr Mc Neile vision, maybe it´s preferable give him the right to explain himself. He will do it largely better than me...
Views: 9
Replies to This Discussion
-
Permalink Reply by Ashley McNeile on -
Hi Jorge and everyone.
Here is a comment I made to Jorge, specifically concerning the issue he raised about the issue of: "How to assure that an object has a unique representation into the model".
My views on this are:
1. UML developed as a collection of notations, and OMG have tried (not always very successfully) to bolt semantics on afterwards. But the notations were not, in the first place, intended to be a basis for execution or code generation and are not really very suitable for this purpose.
2. The right way to proceed is to start with behavioural semantics and define notations afterwards, as ways of expressing the semantics. But it is the semantics that are important, and these should be defined in a way that is notation independent.
I think that, if you have a single, common, semantic basis you can derive different views using different notations and know that they are compatible.
This is rather like the plan, side and front elevation of a building -- you know that are compatible if the three views are projected from a single definition of the underlying building.
If, on the other hand, you have three draftsmen working separately on the plan, side and front elevations of a building, without a single definition of the building, they will produce three diagrams that are (in general) incompatible and could not all represent any single building. It would be hard (and, I think, rather silly) to attempt to define "rules" that could be used to detect and correct the incompatibilities between the three views.
UML, in my view, tends to be used in a manner that corresponds to the second of these two approaches; and the problem you mention is akin to the problem of trying to reconcile the separately drawn pictures of a building. What I am suggesting is that we should try to move to the first approach.
Regards
Ashley
-
Permalink Reply by Pedro J. Molina on -
Hi everyone!
I totally agree with Ashley. Semantics should be defined in first place, and UML has specially a strong background doing it in the reverse direction.
Jorge commented on the issue about defining behaviour in code and the pity about doing it in Java, for example.
Again, I agree. When doing DSLs I try to avoid Java or C# or any other final language to maintain the model technology agnostic.
Quite often we need to defined behaviour semantics implementing algorithms. Algorithms and others related domains are better represented and maintained using textual languages rather than graphical ones.
If you are determined to keep your model technologically neutral, you are forced to use a DSL textual toolkit or grammar tools like Antlr, XText or Olso MGrammar, to cite a few of them.
Or course, it’s not a free choice, it has a cost. You need to develop a full working parser for your DSL and AST tree evaluation. But in my opinion is cleaner that using Java or any other implementation language. If the domain justifies the choice I prefer to describe the behaviour in an abstract language, providing only the tokens, syntactic and semantics needed for the intended purpose. And at the same time not allowing any Java construction, just the allowed ones for the behavioural domain we are considering.
Of course, this increases the complexity of the models. But nothing is for free! :)
Regards,
Pedro J. Molina
-
Permalink Reply by Jon Hurwitz on -
"If you are determined to keep your model technologically neutral, you are forced to use a DSL textual toolkit or grammar tools like Antlr, XText or Olso MGrammar, to cite a few of them."
I don't understand, Pedro. Why must the choice of language in which you implement the DSL be constrained by the target language? If you write the DSL behaviour in some DSL toolkit, the target language could be SQL, java or whatever, and if you write it in java, the target could still be SQL, C#, java or whatever. Of course, you need to be able to walk the AST and you can't mix the implementation with the target code, but why not pick the most appropriate language to handle your DSL - using the same sort of criteria you would for any other app?
-
Permalink Reply by Pedro J. Molina on
-
Sorry for this misunderstanding.
That’s not exactly what I want to say.
- The DSL must not be constrained by any target language.
- The DSL must be constrained only by the semantics of what you need to express in your model: in this case behavioural aspects.
Having such constrained language with a well-stated semantics it is possible to map and generate Java, SQL, etc. On the contrary, if you use Java to specify behavioural aspects, who is checking that the valid Java code is describing only behavioural aspects and not building an UI, for example?
Java is a general programming language and has multiples escapes and a myriad of libraries.
Of course, apart from creating your own textual DSL, it is perfectly possible to use SQL or OCL or any other pre-defined language to model your domain if it has the corresponding semantics needed for the task you are describing and nothing else.
My point is about not using Java or C# for modeling (without constraining them) because by their nature (general programming languages) are open to misuse.
Regards.
Pedro J. Molina
-
Permalink Reply by Ashley McNeile on
-
Hi all
We seem to have a reasonable common agreement that we need to have semantics as basis for behavioural modelling.
However I am not sure how this should be done. But here are some thoughts.
In my view, a model needs to be two things:
1. Abstracted. In the sense of "leaving things out". It must not be a complete represention of the solution, otherwise it is not different from the solution.
2. Formal. In the sense that you can use it to reason. In particular, you must be sure that the conclusions you reach from reasoning from the model will also be true of the final solution.
With this in mind, there is probably little difference between the concept of a "model" and the concept of a "contract" (in the software sense, as used in "Design by Contract", see Meyer etc.)
The traditional domain of contracts is that of functional algorithms, such as "square root" or "sort". It is easy to specify contracts for algorithms such as these in terms of pre- and post-conditions.
But while it works well for algorithms, I don't think that the traditional langauge used for contracts, using pre- and post-conditions, is well suited to capture "behaviour".
However it would be possible to view models based on UML Interaction Diagrams (Sequence and Collaboration Diagrams) that depict examples of execution (sample traces of object interaction) as a kind of contract. Only a solution that can exhibit the traces illustrated in the model "meets the contract".
These kinds of "exemplaric" contracts are not ideal. How can you be sure that you have captured all cases of interest? How do you reason about behaviour based on examples? How do you execute the model (in any way other than simply animating example traces, which is not very interesting)?
I am interested in the idea that behavioural modelling can be investigated and improved by thinking about the question: "How should we formulate Behavioural Contracts?". This is perhaps particularly important given the rise of SOA, where it is important to be able to specify the protocol with which one should interact with a service.
There are notions from Process Algebra that can be used to think about behavioural contracts. Here is a very simple one based on CSP that I like:
1. A contract is specified as a process, C.
2. A design, D, obeys the contract if and only if: C||D = D.
C does not need to say everything about D (so is an abstraction) and CSP supports reasoning very well. So this looks promising.
Moreover, if you can execute processes (which is not hard), you can execute C (the contract, or model).
However, Process Algebra is very abstract and not suitable for direct application to software development. But could the above idea, which is simple and powerful, be used as the basis of a form of behaviour model/contract that is applicable to software development?
I don't know the answer to this, but my hunch is that it is a useful line of enquiry.
Regards
Ashley
-
Permalink Reply by Ashley McNeile on
-
Hi all
I have been working more on the kind of behavioural contract idea that I mentioned in my previous post, so am uploading a short paper that describes the idea. I hope this may give some clue as to what I am talking about (athough it may not!).
This is the first time that I have tried uploading a file, and I not sure what will happen!
Regards
Ashley - Attachments:
-
-
Contv1.pdf, 330 KB
-
-
Permalink Reply by Jorge Ubeda on -
Downloaded and reading it, Ashley...
-
Permalink Reply by Ashley McNeile on
-
Hi Jorge
I hope it makes some sense! Please let me know.
Regards
Ashley
-
Permalink Reply by Ashley McNeile on
-
Hi Jorge
As a further comment, it seems to me that the concept of a “Behaviour Contract” as I described is very similar to the concept of an “Abstract Process” in BPEL. Below is an extract from an IBM website on BPEL:
* * * *
BPEL isn't just for specifying executable processes; you can also use it for specifying business protocols. A business protocol specifies the potential sequencing of messages exchanged by one particular partner with its other partners to achieve a business goal. In other words, a business protocol defines the ordering in which a particular partner sends messages to and expects messages from its partners based on actual business context.
Because a business protocol may be neither executable nor deterministic but still expressed as a process, BPEL refers to it as an abstract process. It abstracts away complex details of an internal executable process. In this sense, abstract processes may be perceived as simple or easy-to-comprehend processes. And while an abstract process is not guaranteed to be executable, abstract processes can be easily specified in such a manner that they are in fact executable! This allows beginning with simple variants of a process and refining them iteratively into the final complex business process.
(From: Business processes in a Web services world http://www.ibm.com/developerworks/library/ws-bpelwp/)
* * * *
However, as far as I know, BPEL does not define any means to establish (formally) whether an executable process conforms to an abstract process.
Regards
Ashley -
-
Permalink Reply by Jorge Ubeda on
-
Ashley
Thanks so much for your update...
Excuse my silence. I have spent more time than desirable, but in the meantime I had focus on this matter (you paper operated as a starting point for a broaden research to me) . I admit that even now it´s hard to me to figure out your vision, and would require to make a case (Remember I´m a practitioneer). However, it helped me to focus the problem.
By the way, it´s curious that few members of this network have expressed their point of view, given the case that indeed there is not a clear solution, or worst, a not-solved-problem.
A couple of days ago, I have visited the site of "The First Workshop on Behavioural Modelling in Model-Driven
Architecture", where you will participate, and saved the following comment, taken from its presentation:
The Model-driven Architecture (MDA) features the use of different kinds
of models during the software development process and automatic
transformations between them. One of the main ideas is the separation
between models that are platform independent (PIMs) and models that are
platform specific (PSM). From these models, some parts of the final code
can be automatically generated. Ultimately, the goal is to generate the
complete software fully automatically from these models.
To date, the fully automatic generation of the code from models is still
a dream and, if it works at all, restricted to specific application
areas. One of the main obstacles is the lack of adequate models for the
behaviour of the software and of mechanisms to integrate behaviour
models with structural models and with other behaviour models. There are
different approaches for modelling behaviour in the UML:
* Use UML Behavioural State Machines ("Executable UML"), which have
semantics that borrow largely from work in real-time systems.
* Use OCL to add behavioural information (such as pre- and
post-conditions) to other, more structural, types of UML model
* Not include behaviour in the PIM at all, but instead add it as
code to structural code skeletons later in the MDA process
* Strengthen the semantics of other UML notations (in particular,
Sequence Diagrams) so that these can be used to capture complete
behavioural information as part of the PIM.
* Transform Class and Sequence Diagrams into graphs using
graph-transformation rules in order to create a set of graphs that
represent the state-space of the bahaviour. Then, model checking
techniques are applied on this state-space to verify certain
properties of the UML models.
Although there are many different approaches for modelling behaviour, none of
them enjoys the same universality as the UML class diagrams do for the
structural parts of the software.
Further evidence of confusion about PIM level behavioural modelling is the lack
of agreement on what basic behavioural abstractions are required, and how these
behavioural abstractions should be used:
* Does the concept of "Component" have meaning at the PIM level, and
how should it be defined?
* Does the concept of "Active Objects" (as used in many real-time
modelling techniques) have meaning at the PIM level? And does it
only apply to real-time system modelling?
* What forms of composition should be used between behavioural
abstractions in the context of MDA?
* What role should Aspects play in PIM level behavioral modelling?
This workshop brings together people from academia and industry using MDA and
related approaches and, in particular, is concerned with behaviour models and
their integration with MDA. We are interested in submissions on topics relating
to MDA and PIM level behaviour modelling, including:
* Ontologies of behavioural abstractions and their applicability;
* Modelling languages that aim to capture PIM level behaviour;
* Composition and decomposition of behavioural models;
* Application of process algebraic techniques;
* Application of formal reasoning to PIM level behaviour models;
* Translation of PIM level behaviour to PSM and code;
* Method and Tool Support for building PIM level behavioural models;
* Case studies that relate to the use of PIM level behavioural
modelling.
The purpose is to better understand the problem with behavioural models, what is
needed to adequately model behaviour, and what is still lacking for universally
modelling the behaviour of software in such a way that the code can
automatically be generated from them. Based on that, the outcome of the workshop
will be a clearer vision of how modelling notations for behaviour and the
interfaces to structural models should look like.
>>
This is a fresh and stimulating point of view. Hope the workshop make progress in this first level issue. -
-
Permalink Reply by Ashley McNeile on
-
Hi Jorge
I am also puzzled as to why there is not more interest in improving the way we model software behaviour. Particularly as it seems key to the success of model driven approaches such as MDA.
In the context of MDA, I think there are a number of factors that inhibit progress:
1. The OMG spent a lot of time and effort in the creation of the UMLv2 standard which, as a result, is "set in concrete". People working on MDA generally have to take UML as fixed and use ad-hoc extensions and specialisations of what is in the standard rather than attempting any radical rethinking. However, UML was created by bringing together a host of different notations, none of which was originally devised with the intent of supporting model driven development and are arguably not suitable for it.
2. Fully achieving the vision of MDA, in my view, requires that behavioural and structural modelling are well integrated. However, the structural modelling in MDA (i.e., Class Diagrams) is very tightly tied to the features and semantics of OO programming languages - things like methods, inheritance, interfaces, etc. This works against MDA, as (in my view) the features and constructs of OO programming languages are not compatible with good behaviour modelling because they are at too low a level of abstraction.
3. An issue related to the above is that Object modelling (with Class Diagrams) and Process modelling (using process flow oriented techniques like BPMN and BPEL) have split from each other, and the whole business process automation/management has detached from the main body of UML as a separate area of standardisation. If MDA is to address SOA and business process management/automation this makes things difficult as two (possibly diverging or incompatible) areas of standardisation need to be embraced.
4. The OMG (from what I have seen) is dominated by vendors. When MDA appeared on the scene, many of these vendors already had products that generated code from some combination of UML diagrams and their own proprietary extensions for detailed behaviour specification. Their interests would be in protecting their investments in tools against becoming "non-standard", and this would limit their appetite for changing or extending the UML standard too far. (This, for instance, is why the "Action Language" in UML is defined with semantics but no syntax - different vendors already had their own syntax.)
It is for these reasons (and some others) that I don't take UML to be good place to start if you want crack the problem of how to model behaviour.
Regards
Ashley -
-
Permalink Reply by Ashley McNeile on
-
Hi Vlad
I am not actually using the UML Superstructure at all! I have been working with a behavioural model based on "protocol machines" to model both object and process behaviour.
My particular interest is in compositional modelling, in which complete behaviour is built by putting together machines that represent partial behavioural descriptions. Behavioural variants are created by composing different combinations of protocol machines. This technique is used for both objects and processes - and there is no real need to distinguish them.
To achieve this you need to define the semantics of the behavioural models so that parallel composition is possible. The UML semantics (of both Activity and State Diagrams) do not (unfortunately) allow parallel composition, so for my work I have had to forget UML and start again from scratch.
I have also used parallel composition technique in the context of defining "behavioural contracts" (as described in a previous post). Again, because UML does not have parallel composition, this kind of contract is not supported.
As you will have gathered, this is essentially a research project. Whether compositional modelling is such a good idea that it merits making a change to UML is a matter of debate. I happen to think it is very powerful and in some contexts, such as modelling behavioural variants and service based collaborations, perhaps essential.
I think the GOF got it right when they said: "favor composition over inheritance". I wish the OMG would take note of their advice!
Regards
Ashley
© 2012 Created by Mark Dalgarno.
Powered by
