[SysML-Evaluators] Soliciting Input on Instance Diagram Issue

[Jeffrey A Estefan]

Colleagues,

 

I do not want to belabor this issue because I believe there are much more important areas to focus on; however, per Dave Oliver's request, I am soliciting input on the issue of Instance Diagrams for the SysML specification submission.  An Issue Statement is provided below that describes the nature of this discussion.

 

Please provide your comments to me directly vice sending broadcast messages to the SysML Evaluators Google groups e-mail distribution list.  My e-mail address is provided below.  I will synthesize your comments over the course of the next couple of weeks, recognizing that some of you will be on holiday. 

 

Interested review team members are welcome to respond as are submission team members.  I look forward to reading your comments.

 

Regards...

 

 - J.A.E.

 

Jeff A. Estefan

NASA/Jet Propulsion Laboratory

Office: (818) 393-5280, Fax: (818) 393-0028

Email: Jeffrey....@jpl.nasa.gov

 

Issue Statement:

 

It is widely recognized that representing "instances" (more formally, "Instance Specifications") in the form of a model is a very valuable element of the systems engineering process.  Therefore, the debate should not be centered around whether support for modeling instances should or should not be part of the formal release of the SysML specification; they in fact, should be supported.  The debate centers around whether a separate diagram type should be used to visualize instances.

 

The SST submission includes diagram elements and semantics for a new diagram type called the "Instance Diagram," which is the UML 2 Object Diagram, renamed Instance Diagram.  The SP submission does not include the notion of an Instance Diagram nor is it evident that support for modeling instances (or Instance Specifications) is described in the submission.

 

The problem with using the UML 2 Object Diagram as the foundation of a SysML Instance Diagram is that the UML 2 Object Diagram (OD) is a simple variant of the UML 2 Class Diagram.  ODs are useful in software systems modeling when class diagrams become large and complex with several interrelated classes.  Use of one or more ODs can be used to help the software designer better understand such complexities through representation of concrete objects or "instances."  It is not a significant stretch for a UML savvy software engineer who is versed in class diagram constructs to understand and articulate the object diagram.

 

In the case of the SysML, Roger Burkhart made the excellent recommendation of introducing the notion of "Blocks" to model the static structure of systems; something that was lacking in the v0.9 baseline SysML spec.  This resulted in the two post v0.9 submission teams adopting the concept of blocks and describing the diagram elements and semantics associated with two SysML-specific diagram types of the Block Definition Diagram and Internal Block Diagram.  Indeed, these two diagram types extend the constructs used in the UML 2 Class Diagram and Composite Structure Diagram, respectively; however, it is not a pre-requisite that the systems engineer be UML 2 class diagram savvy to model the static structure of systems since these constructs (class and composite structure) are not directly exposed.

 

In an effort to keep the SysML specification relatively lean by not introducing more diagram types than necessary [one could argue for parsimony here] yet still provide support for modeling instances, it is recommended that the diagram constructs for blocks be augmented to facilitate representing instance specifications on block diagrams rather than introduce another diagram type (Instance Diagram) that is effectively the same as the UML 2 Object Diagram (which in turn is a special case of a Class Diagram).  This would have been fine for the v0.9 baseline because the notion of "Classes" was defined as a behavioral construct in that revision of the spec, but it is not appropriate now that the concept of Blocks has been adopted.

 

Observation:

 

There is no Usage Example provided in the SST submission in the section describing Instance Diagrams under the Behavioral Constructs part of the spec submission (if the Instance Diagram is retained, there should be).  There is, however, an example of an Instance Diagram provided in the Sample Problem described in Appendix B (cf. page 177).  It could easily be argued that this diagram is a special case of the Internal Block Diagram shown on the bottom of page 174 that illustrates the relationship between various subsystems; the only difference is that serial numbers of specific parts are called out in the diagram with some additional notes to show how instances can be modeled.

 

 

 

 

 

 

 

 

 

 

[Michael Latta]

Jeff,

 

I will provide input on the issue.  I do however on principal object to any private collection of input resulting in a synthesized posting to the list.  I do not object to the synthesis and review thereof, but to the fact that the raw input would not be available for review by anyone that chose to do so.  For that reason I recommend that all input go to the list.  If you would prefer that we tag the input with some keyword to make them easier to locate that would be fine.

 

Michael

 

---

From: SysML-Ev...@googlegroups.com [mailto:SysML-Ev...@googlegroups.com] On Behalf Of Jeffrey A Estefan
Sent: Wednesday, December 21, 2005 11:21 AM
To: SysML-Ev...@googlegroups.com
Subject: [SysML-Evaluators] Soliciting Input on Instance Diagram Issue