When to use Parametric vs Internal Block Diagram?

240 views
Skip to first unread message

brad

unread,
Nov 18, 2015, 7:55:04 AM11/18/15
to SysML Forum

I'm sure this is a rookie question, but at this point in my study of SysML, it's got me kind of hung up.  By my reading of OMG's SysML document, Parametric diagrams are more or less just a specialization of Internal Block diagrams.  Is there an accepted set of rules of thumb for when to use one over the other?

To be a little more concrete, I'm including a pseudo-diagram of a simple example along the lines of my current work.  In the example, the incoming values are arrays captured from analog-to-digital converters, and the rounded rectangles indicate calculations to be carried out on the data.  I find I could argue:


A) This is a system of values related (ultimately) only by equations...therefore, I should use a Parametric Diagram.


or


B) This is a system of flows of information (in a single, definite direction) between calculations that will be carried out as activities.  Further, these calculations couldn't possibly be traversed in the other direction.  Therefore, I have Flows between Activity Blocks, and not Connectors between Constraints, and I should use an Internal Block Diagram.


In short I'm confused, and any advice would be appreciated.  Thanks in advance for your time!


(Note, I am aware my situation might also recommend use of an Activity Diagram, but I'm ignoring that for the sake of sanity here.)









JP

unread,
Nov 23, 2015, 3:31:40 PM11/23/15
to SysML Forum
IBDs (Internal Block Diagrams) are generally meant to depict the connections and flow of information between parts of some block (hence the name internal block diagram). Of course, one can certainly also make an IBD that only shows associated blocks (thus, all blocks would be drawn with dotted lines and none of them would be internal to the parent block of the diagram).

Parametric diagrams are meant to specify variables and what equations they tie into. Or rather, they show the in-depth mathematical relations of your system.

At any rate, to answer your question, I would say there's no need to limit yourself to one diagram type. Why not model the structure of your system (with a Block Definition Diagram (BDD)) and have constraints (which may have parameters) on the relevant blocks, then model the object flows of information and actions performed in an activity diagram where the actions may be allocated to blocks from your BDD, and then make a parametric diagram (or diagrams if necessary for multiple constraints) to show an in-depth view of the mathematical relationships in your system?

geoff

unread,
Nov 25, 2015, 1:20:49 AM11/25/15
to SysML Forum
Rather than attempt to modify your perception of OMG's SysML specification in this overly constrained context, I'd suggest you avail yourself of the other reference resources on the SysML language.  Differentiating the concepts of "definition" and "usage" is key to understanding the roles of the different diagrams in providing views of the model's underlying information which is resident in the definition of its model elements.  In short, the diagrams of the SysML are intended to either convey the "definition" of a model element or its "usage" in the context of the modeled entity.

The OMG SysML specification will only take you so far in mastering the language and it is clear that at this juncture you have some developed an understanding of the language which is likely to create issues for you in your further mastery of the SysML.  Whilst it is true that the IBD and Parametric diagrams have commonality, they have a very different role syntax and diagram element syntax.  The role of the Block Definition Diagram is to provide a view of the "definition", hence its name, of the entities which constitute a model of an abstract definition of an entity.  The IBD's role is one of conveying the structural properties of an entity (Block), the IBD "uses" the model's defined model elements to portray structural connectedness.  In contrast the Parametric Diagram's role is one of conveying the usage of the "constraints" defined for an entity.  Chapter 8 & 10 of version 1.4 address the IBD and Parametric diagrams, but I'm sure you already are aware of that.  Apologies for restating what you already know.

But I would like to suggest that you avail yourself of the other resources to aide in your mastery of the SysML.  One "free" resource is the "cookbook" developed by the SysML working group of the German chapter of INCOSE (http://mbse.gfse.de/documents/faq.html).  There are a number of uses of the parametric diagram illustrated in the Cookbook Part 2 (SE2PracticesAndGuidelines_V759.pdf).  Another resource that you might consider is the reasonably priced work "SysML Distilled" by Lenny Delligatti.

The WWW holds many other "no cost" resources, but you may find they merely regurgitate the OMG SysML specification and add little to your understanding.

Best of Luck Brad

brad

unread,
Nov 25, 2015, 1:20:54 AM11/25/15
to SysML Forum
JP:  I can see that my original question was a little misguided, as it presumes a single master-diagram to be drawn up.  I think I've been a little soft in my understanding of the specific intended use of IBDs within SysML as well.  You're post got me up and moving in the right direction again though, and has given me some good food for thought.  Thanks a bunch for taking the time!
Reply all
Reply to author
Forward
0 new messages