generate code from opt, alt fragment

[rahejabharat]

How to generate code from sequence diagram which has alt and opt fragments.

[mbc]

As far as I am aware, EA can't generate any code from sequence diagrams.

Best regards,
Mikkel

[thomaskilian]

How should this work in general? A sequence diagram shows a possible object invocation, not a code piece.

[mikewhit]

Though a Google search shows that some people (Wei) are thinking about it ...

[thomaskilian]

Is it that Chinese are more used to graphical notation

[SF_lt]

come on, code could be (and should be) generated from a sequence diagrams.

What sequence diagrama represent - work algorithm, of course! what actions (sequences) are taken on various conditions (guard conditions in UML2).
Diagram must be drawn correctly, as it complement class diagram and vice versa. Classes methods actually are sequence diagram messages/signals, so by combining class and sequence diagrams a lot useful code should be generated

To provide complete algorithm for code generation from the sequence+class diagrams isn't an easy task, but it's doible.

There should be 2 (at least ) steps:
1) class diagram addition with the data from a sequence diagram (methods/atributes/associations) or sequence diagram addition with the data from a class diagram (methods/return values/parameters) or validation of class and sequence diagram with each other (there could be inconsistence with the diagram data)
2) when sequence and class diagrams conform each others data, generate code - static code framework from a class diagram and dinamic behaviour from a sequence diagram.

Of course, OCL2 constraints, state diagrams could provide data for more accurate code generation.

I believe, that this research direction is going in some universities (maybe companies) - this would beautifully integrate with the model-driven architecture (MDA).

[sargasso]

I'd love to see it!

Especially if the sequence diagram contains sets of asynch signal messages (events).



bruce

[mikewhit]

BUT if they have any spare time, I'd rather it went on Requirements/Test integration, a la Rhapsody !

[SF_lt]

code of asynchronous calls doesn't differ from the synchronous calls/signals - just calling other thread/process method

Though a little about class and sequence diagram synchronization - standard cases easily could be checked and synchronized.
signals/calls map to methods;
call/signal params map to dependencies/associations (need additional check for direction definition)
return values map to attributes;
guard conditions dissappear ;
entities as opt/alt/etc fragments dissappear (inside stuff remains and is mapped acording previous rules);
OCL2 constraints/expressions could provide multiplicity data, more check rules.

I think, that EA's feature to generate/sync sequence/class diagrams could be beneficial. It would be nice to get Sparx opinion on this subject

Further: sequence diagram could be synced with the state diagrams (remember guard conditions )

[mbc]

SF_It,

I agree that code could be generated from sequence diagrams that were drawn for that purpose. I also agree that it would be useful to have in EA - especially reverse engineering to sequence diagrams. But it would be difficult to make it work well in practice.

However, I would be less absolute than you are in several of your statements.

What sequence diagrama represent - work algorithm, of course!

No, not so. True, they can represent algorithms, but that is not the generalized purpose of a sequence diagram. A sequence diagram describes one way an interaction may occur. There is no requirement for a sequence diagram to completely describe all possible paths through an algorithm.

code of asynchronous calls doesn't differ from the synchronous calls/signals - just calling other thread/process method

That is your implementation-specific view of things. In my world, asynchronous communication takes place as signals, not method calls.

In short, code generation from sequence diagrams is possible, but it involves making some decisions that specialize the meaning of a sequence diagram compared to the general UML meaning. Therefore it is very difficult to implement a solution that satisfies everyone's needs.

Mikkel

[SF_lt]

devil lives in details  

Yeah, mbc is right - sequence diagram not always is an algorithm, may be only part of it. Even word algorithm isn't precise, doesn't cover all possible ways.

... but what is interaction - some part of the useful work done by the objects in simple words. Main word I would highlight - USEFUL. There is no point to show not useful interaction - objects work (interaction) is to perform certain actions to fulfil some useful functionality, which is required.
In other hand, what is algorithm - way how to achieve something: calculate square root, build bridge, call Paint() method and etc. Algorithm can take many steps to reach final point, but at the end we get what is planned.
Similar way sequence diagram represent steps to reach to something and this could be seen as an algorithm or part of it. Of course, algorithm could be very abstract or take only basic path - it depends on many things.

Signal isn't far away from the method/function calls. If to look more deeply, communication uses method/function calls + data (object as a whole consist of functions and data). To communicate using signal takes at least two method/function calls: send & receive + information on occured event. Signals carry information on occured event, but how such transfer is made? By synchronous/asynchronous method calls

[mbc]

SF_It,

Yes, I agree with everything you wrote in your last post.

Normally there is no need for a sequence diagram to be an exact definition of an algorithm in order for the sequence diagram to be useful. And normally it is not necessary to specify exactly which method calls your particular signalling mechanism uses. The most useful sequence diagrams are actually as abstract as possible showing only the information that they are intended to convey.

However, if you are to automatically generate code from a sequence diagram, then there is such a need. The algorithm that is to be generated must be described unambiguously.

Mikkel