Shortki Community
October 02, 2023, 11:03:59 AM
Welcome,
Guest
. Please
login
or
register
.
1 Hour
1 Day
1 Week
1 Month
Forever
Login with username, password and session length
News
:
inShort 1.2.1 for Mac OS. Locations.
.
Home
Help
Search
Calendar
Login
Register
Shortki Community
>
General Category
>
inShort
>
I'm a bit confused by drill down ...
Pages: [
1
]
« previous
next »
Print
Author
Topic: I'm a bit confused by drill down ... (Read 17436 times)
EmirFassad
Newbie
Karma: +0/-0
Posts: 2
I'm a bit confused by drill down ...
«
on:
January 18, 2012, 03:47:44 AM »
1) When I create a drill down structure within a parent entity must I implicitly reference the inputs & outputs to the parent entity via proxies?
2) How does an interative link work?
Logged
charlali
Newbie
Karma: +0/-0
Posts: 2
Re: I'm a bit confused by drill down ...
«
Reply #1 on:
June 19, 2015, 07:26:40 PM »
I too have a similar problem - I have a sub process that creates outputs which are used in my main process but I can't find a way to reference these - please could you help?
Logged
UsableThought
Newbie
Karma: +0/-0
Posts: 1
Re: I'm a bit confused by drill down ...
«
Reply #2 on:
January 24, 2018, 08:34:12 AM »
This is an old thread - I'm not trying to revive it, but just in case anyone is searching the forum to find if anyone has asked a similar question about nested diagrams & any resource they may produce (whether represented by a terminal object or not) - a simple answer is "proxies are not required."
A longer answer:
I asked a similar though not identical question of Jury Shortki in an email (I hadn't yet registered on the forum otherwise I would have asked it here). Here is my question as I worded it: "I am looking for a good example diagram that better illustrates creating nested diagrams - in particular, how the terminal object in the nested diagram relates back to the parent diagram."
And here is what he wrote back to me: "The encapsulation principle operates in the application - the parent diagram 'does not know' the features of the nested structure. For the parent chart, only the nested state is important."
Note that the above refers to execution only: all that the parent diagram requires of a nested diagram is that it be 100% completed for the parent diagram to then resume with its next execution step. (Not sure if I phrased that correctly, but hope it's close).
Now, as to how exactly the achieved goal (resource created) belonging to a nested diagram is represented
visually
- well, this seems to be user choice: you can have the nested diagram terminate in a process or a resource object as you wish; it's up to you. For that matter you can insert a resource into the parent diagram immediately after the nested diagram, representing the goal of the nested diagram; again, the application won't care. It's more a matter of how you want to show things. Probably what matters most is that you are consistent in how you represent such things, so as not to confuse the reader of the diagram (which might be someone else, or might be your future self).
«
Last Edit: January 24, 2018, 08:38:28 AM by UsableThought
»
Logged
shortki
Administrator
Hero Member
Karma: +16/-0
Posts: 566
Re: I'm a bit confused by drill down ...
«
Reply #3 on:
January 24, 2018, 04:41:10 PM »
That's right.
I want to supplement, sometimes subtasks are completed regardless of the result of the process performed in them. In such a situation, it is logical to connect the criterion for completing the diagram to processes.
Logged
Pages: [
1
]
Print
« previous
next »
Jump to:
Please select a destination:
-----------------------------
General Category
-----------------------------
=> inShort
===> workflow.link
===> Your diagrams
===> Suggestions for improving the program
===> F.A.Q.
===> Bug reports
=> tr.en.d
===> Suggestions for improving the program
===> F.A.Q.
===> Bug reports
=> General Discussion
Loading...