Shortki Community
August 20, 2018, 09:47:17 PM *
Welcome, Guest. Please login or register.

Login with username, password and session length
News: inShort 1.2.1 for Mac OS. Locations..
 
   Home   Help Search Calendar Login Register  
Pages: [1]
  Print  
Author Topic: I'm a bit confused by drill down ...  (Read 16057 times)
EmirFassad
Newbie
*

Karma: +0/-0
Posts: 2


View Profile
« 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


View Profile
« 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


View Profile
« 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



View Profile Email
« 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  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.20 | SMF © 2006-2011, Simple Machines Valid XHTML 1.0! Valid CSS!