You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Here are two ideas to improve the existing graphical editors for SOA.
There are just prototyping.
Practices in common:
change the size of the font and the bold depending on the importance of the text
input are as bordered node on the left, output on the right
description in graphically shown inside the container
colors are only derivation of blue
use plain border for the main type of object and dash for less important objects
Operation Detail
This diagram is focus on one specific Operation. The goal is to show the tree of input/output data. If a primitive type is shown, I propose to use a decorator instead of the classical ": String" notation to make it more visual and easy to read. DTO are cascaded, with a visual recursivity if "isComposite" attribute is true. I didn't manage references between DTO (and any circular reference will generate an infinite loop).
Idea to improve this diagram:
manage references between DTO (with a graphical edge or with just a label?)
palette and tools
calculate vertical size of bordered node which represent DTO depending of the number of attribute isComposite reference
improve the auto layout
improve the location of icons for each Primitive Type to delegate this responsability to type library plugins
Service Contract
This representation shows all operations:
1st level of input/output variables
for DTO, show only the first level of structured objects. The contained DTO are just listed as a bordered node.
user can see which output can becoming the input of another operation
Here is the same modeler with the same data but with a hand made graphical positioning (I think I prefer the horizontal one):
The source code
I created a new odesign file to do this test autonomously. Here is the workspace with the VSM project and the sample demo (with ISD 1.9.0): workspace.zip
And here is the VSM file (rename the extension from .txt to .odesign): EJURest.txt
The text was updated successfully, but these errors were encountered:
Here are two ideas to improve the existing graphical editors for SOA.
There are just prototyping.
Practices in common:
This diagram is focus on one specific Operation. The goal is to show the tree of input/output data. If a primitive type is shown, I propose to use a decorator instead of the classical ": String" notation to make it more visual and easy to read. DTO are cascaded, with a visual recursivity if "isComposite" attribute is true. I didn't manage references between DTO (and any circular reference will generate an infinite loop).
Idea to improve this diagram:
This representation shows all operations:
Here is the same modeler with the same data but with a hand made graphical positioning (I think I prefer the horizontal one):
The source code
I created a new odesign file to do this test autonomously. Here is the workspace with the VSM project and the sample demo (with ISD 1.9.0):
workspace.zip
And here is the VSM file (rename the extension from .txt to .odesign):
EJURest.txt
The text was updated successfully, but these errors were encountered: