Hi Frank, Yes, there is a complexity introduced by using a combination of arrows and column ordering. However, using only the column ordering can limit to expressiveness too much. On the other hand, if we always use arrows, we can avoid many of the confusions you have mentioned above. Only confusion left would be whether multiple incoming (or outgoing) arrows model a OR, XOR or AND semantic. We have to solve this even if we use column ordering.
I think we can use the OR semantic here (i.e. one or more predecessors have to complete). Thus, we can have more flexibility and the exact behavior can be captured at the next level of refinement. In this model, the user always to have to draw arrows and can use column ordering as an abstract way of visualizing relationships. We can provide a button to turn on/off arrows. When arrows are turned off, column ordering gives an abstract visualization of chevron relationships. When arrows are turned on, exact ordering can be viewed. Regards, Chathura On Sat, Dec 13, 2014 at 8:01 AM, Himasha Guruge <[email protected]> wrote: > > Hi Frank, > > Sure, we can set up a brief demo of the initial version next week. :) Let > me know a free slot from your schedule. > > Thanks & Regards, > Himasha > > On Fri, Dec 12, 2014 at 11:28 PM, Frank Leymann <[email protected]> wrote: >> >> Hi Himasha, >> >> in case you have an initial version of your code running, I would be glad >> to get a brief demo :-) >> >> >> Best regards, >> Frank >> >> 2014-12-12 9:44 GMT+01:00 Himasha Guruge <[email protected]>: >>> >>> Hi Frank, >>> >>> Thanks for the suggestion. As Chathura mentioned, will support both >>> approaches depending on the scenario. >>> >>> Thanks & Regards, >>> Himasha >>> >>> On Fri, Dec 12, 2014 at 1:57 PM, Chathura Ekanayake <[email protected]> >>> wrote: >>>> >>>> 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 <[email protected]> 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 <[email protected]>: >>>>> >>>>>> 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 >>>>>> [email protected] >>>>>> >>>>> >>>>> >>>> >>> >>> -- >>> Himasha Guruge >>> *Software Engineer* >>> WS*O2* *Inc.* >>> Mobile: +94 777459299 >>> [email protected] >>> >> > > -- > Himasha Guruge > *Software Engineer* > WS*O2* *Inc.* > Mobile: +94 777459299 > [email protected] >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
