Hi Chathura, yes, I fully agree: that's what I meant :-) We keep it simple and use "column ordering" as default but allow separate arrows to override the former semantics.
But we need to refine now what the "successor relationship" means (see next
figure "Chevron Relations and Arrows"):
1. Chevrons 1 and 3 succeed chevron 4, but 2 does not succeed 4.
1. Does that mean that 2 can take place in parallel to 4?
2. Does that mean that 2 is not required to execute in order to
perform 4?
3. Does not mean that 2 is not required to complete (but must be
performed and may fail) before 4?
2. Chevron 5 precedes chevron 6, but 5 does not precede 7. Similar as
before:
1. Does that mean that 7 may happen even in case 5 (a) did not take
place; (b) took place but failed?
2. May 6 take place even if 5 failed?
We need to understand this in order to support the correct refinement in
case the chevrons are substituted by executable process models at the next
level of refinement. Thus, we have to describe what the semantics is even
if we don't support refinement into executable process models in our first
release
How are arrows considered when a chevron is refined:
1. If chevron 4 is refined, will the incoming arrows (logically) target
all chevrons of the first column of the refined diagram?
2. Or may the modeler decide that only a subset of the chevrons of the
first column of the refined diagram become target?
3. May the modeler target the arrows at any chevron of the refined
diagram or only at chevrons of the first column of the refined diagram?
4. ...and similar questions for refining chevron 5, but now for the
source ends of the arrows...
Thus, arrows are very helpful but raise the bar in terms of their
semantics...
Best regards,
Frank
2014-12-12 9:27 GMT+01:00 Chathura Ekanayake <chath...@wso2.com>:
>
> Hi Frank,
>
> Yes, it is better to let users to draw chevron diagrams without arrows
> whenever possible. However, if there is a scenario where only some chevrons
> in a column succeeds a chevron in its previous column, we can let users to
> indicate that using arrows. Therefore, we can support a combination of
> column ordering and arrows to capture predecessor/successor relationships.
> i.e. if arrows are not drawn, all chevrons in a column are in successor
> relationship with all chevrons in its previous column.
>
> Regards,
> Chathura
>
> On Thu, Dec 11, 2014 at 11:50 PM, Frank Leymann <fr...@wso2.com> wrote:
>
>> Hi Himasha,
>>
>> very good idea :-) Let me suggest a little variation:
>>
>> People modeling Chevron Diagrams are not really used to use arrows to
>> connect the individual chevrons to indicate (control or data) flow. The
>> flow is defined by the orientation of the diagram (i.e. horizontal or
>> vertical). This would imply to avoid arrows as long as possible - but folks
>> MAY use arrows if they want e.g. because of clarity and comprehensibility.
>>
>> Let's assume a horizontal orientation: each chevron in a column of your
>> grid will be a successor of all chevrons in the immediate preceding column.
>> And all chevrons in the same column can be performed in parallel. And all
>> chevrons of certain column must be "ready" before the chevrons of the
>> succeeding column can be activated. And, yes, this is not really
>> satisfactory because not all chevrons in a certain column have to be
>> performed - but that's an inherent imprecision of Chevron Diagrams because
>> they don't have an operational semantics (by will ;-)).
>>
>> Thus, the Chevron Diagram you draw would be equivalent to the following
>> (ChevronRelations):
>>
>>
>>
>>
>>
>> Best regards,
>> Frank
>>
>> 2014-12-11 7:45 GMT+01:00 Himasha Guruge <himas...@wso2.com>:
>>
>>> Hi All,
>>>
>>> The idea is to support multiple relations for the chevrons in initial
>>> chevron diagram editor. As the initial step, the editor canvas will include
>>> a virtual grid [1] where the chevron elements can be dropped into.
>>>
>>> When a chevron is dropped to the canvas most suitable cell location will
>>> be retrieved by checking the center position of the chevron. In such a
>>> scenario where the most suitable cell is already occupied by another
>>> chevron element, it will be placed in the next most suitable location.
>>> Once a chevron element is added, it can be swapped between different
>>> cells as long as they are not already occupied.
>>>
>>> Any suggestion/feedback on building the virtual grid would be
>>> appreciated.
>>>
>>> [1] chevronEditor_virtualGrid_mockup
>>> <https://docs.google.com/a/wso2.com/drawings/d/1CJwFQrm4FjKSLS23I0iXWZwLg_D4ddramm62c0q3lAw/edit?usp=sharing>
>>>
>>> Thanks & Regards,
>>>
>>> Himasha Guruge
>>> *Software Engineer*
>>> WS*O2* *Inc.*
>>> Mobile: +94 777459299
>>> himas...@wso2.com
>>>
>>
>>
>
Chevron Relations and Arrows.pptx
Description: MS-Powerpoint 2007 presentation
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
