Talk:Systems modeling language

Innovation?

The article says:

A notable innovation of SysML is support for requirements modeling.

But tools such as Vitech's CORE have supported system requirements modeling for years, so I fail to see how this is an "innovation" on SysML's part. --Allan McInnes (talk) 16:34, 14 June 2006 (UTC)

Not only CORE, but other modeling tools (e.g., Sparx Enterprise Architect) have previously supported visual requirements modeling. However, in the case of CORE, the modeling language is proprietary; in the case of EA, the requirements modeling support is a proprietary extension to UML. I propose that we replace the problematic sentence with something more accurate and less controversial: "A noteworthy improvement of SysML over UML is its support for requirements modeling." If no one objects to this recommendation over the next two weeks, I will make the modification. --Kobryn 17:56, 29 June 2006 (UTC)

Actually, I think you'll find that someone has already modified the sentence in question to read

A notable innovation of SysML over the UML is support for requirements modeling.

But if you feel that "improvement" is a better choice of words than "innovation" then by all means make that change. --Allan McInnes (talk) 18:56, 29 June 2006 (UTC)

Merge of open source, non-trademarked SysML with OMG SysML(tm) is problematic

"It has been suggested that OMG SysML be merged into this article (SysML) or section."

It is not a good idea to merge open-source, non-trademarked SysML with OMG SysML (tm), since they are related, but significantly different. Otherwise, why would the OMG have made the effort to trademark "OMG SysML" if it didn't recognize the need to brand its own version of this open source specification?

Originally SysML was developed by an open source project, and has been publicly available for download, including an open source license for distribution and use (|SysML Legal Notices) for more than 2 years. Open source SysML was intentionally not trademarked, so that organizations that wished to establish trademarks (e.g., OMG) for specification variations would distinguish them using a distinctive name (e.g., "OMG SysML"). This apparently is what has occurred, so we should clarify the distinction between open-source, non-trademarked SysML and OMG SysML(tm), rather than blur it by merging the two. Consequently, the OMG SysML specific content that is mixed into the current SysML page should be moved into the OMG SysML page to further clarify the differences. --Kobryn 18:58, 29 June 2006 (UTC)

I don't think it's necessary to have separate articles in order to make clear the differences between the trademarked and non-trademarked versions. I'd much rather see a single encyclopedic article that dicusses the the common parts of each version of SysML, and includes sections that describe whatever differences actually exist between the different versions (including other branded version that develop). If one of those sections grows large enough, it'd probably be worthwhile to spin it off into a separate article. Until then it seems more sensible to me to keep all of this information in one comprehensive article instead of having it spread across a bunch of stubs.

As an aside, SysML was developed in response to an RFP produced by the OMG Systems Engineering DSIG, and was influenced by earlier DSIG work on adapting the UML to systems engineering. So while it may be an independent "open source" project, it has always been closely aligned with OMG's requirements. --Allan McInnes (talk) 19:24, 29 June 2006 (UTC)

I am open to Allan's suggestion for one article, as long as we clarify that the open source, non-trademarked SysML preceded the OMG version by approximately 3 years, and we clearly summarize the technical differences between the two. BTW, the latter would be straightforward if OMG SysML abided with the open source regarding summarizing modifications: "All modified versions of this specification must include a prominent notice stating how and when the specification was modified." I cannot find such a "prominent notice" with OMG SysML (OMG doc# ptc/06-05-3). If that is the case, we will need to construct such a summary. --Kobryn 20:06, 29 June 2006 (UTC)

I'm all for clarifying the differences, and giving temporal precedence to the open source SysML. --Allan McInnes (talk) 20:14, 29 June 2006 (UTC)

Ironically, the OMG SysML spec appears to include the requirement to provide a "prominent notice", but to not actually follow that requirement itself. Quite disappointing. --Allan McInnes (talk) 21:16, 29 June 2006 (UTC)

I have merged what little content was in the OMG SysML article into a new section in this article, titled "OMG SysML". --Allan McInnes (talk) 21:11, 29 June 2006 (UTC)

Copyvio?

Large chunk of Introduction is from http://www.sysmlforum.com/FAQ.htm —Preceding unsigned comment added by 83.167.116.184 (talk) 11:07, 23 April 2008 (UTC)

That section does have a reference to that source. -- Marcel Douwe Dekker (talk) 22:01, 10 September 2008 (UTC)

Delimination of SysML and UML is not clear enough

Even though the specification of SysML is reusing UML to a significant extend (and even referencing it) it should be clearly said that both are modeling language on a "parallel" level and can be used stand-alone. In the article, is is mentioned that there are only two new diagrams. This is actually not true: A very basic element of SysML is the abstraction of "blocks" used in two new (!) diagram types, namely Block Definition Diagram and Internal Block Diagram. Even though they reuse some features of "classes" and "objects" both concepts are not compatible at all and they should never be mixed up. Core features of classes like inheritance and polymorphism are not considered/supported by blocks. The fact that some tools support the "block" abstraction by means of a stereotyped class definitions (<<block>>) is even increasing the mess of misperception. To my opinion, the inadequateness of classes to define a system structure/breakdown/architecture was one core motivation to derive a second standard SysML parallel (!) to UML. —Preceding unsigned comment added by 212.77.163.106 (talk) 12:34, 4 March 2011 (UTC)

Acceptance in the Field remains unclear

IMO the degree of adoption for daily use in the relevant industries could still be made clearer in this article. The language specs seem to still be under active development and nobody would question the success of UML (=used worldwide). However, it remains unclear whether or not this is also true for sysml. --[IP guest] — Preceding unsigned comment added by 193.110.102.2 (talk) 09:46, 4 October 2012 (UTC)

No relation to the ML language

The language name, ending in "ML", does not indicate any relation to the ML programming language. See What's in a name: SysML vs. ML at SysMLForum. Øyvind Teig (talk) 15:34, 13 June 2013 (UTC)

Limitations and criticism

I feel these critics should be moderated. I heard those critics once in a while, but I always question: compared to what?

The main message is the language is too complicated. It sounds like someone saying that algebra is too complicated or even English is too complicated. First SysML is as complicated as UML. Two, UML and SysML are complex because they are formal languages used to describe a complex reality. As a beginner, a modeler can use Light SysML or AgileML, but very soon, he needs more because he needs to express something more complex or more detailed. Any SysMl modeler will one day or another use UML elements outside of UML4SysML because he needs the full spectrum of both languages to represent the complexity of the reality.

The evolution of BPMN is a great example of how the modeling languages evolve. At the beginning, it was developed by a group looking for a simplified business representation of the processes, not as complex as UML or SysML activities. Today, BPMN 2.0 has gained a significant acceptance and could be used to generated actions in a BPMS platform, but it is far more robust than the first version. In my understanding, a BPMN process diagram is now far more complex than UML and SysML activity diagrams. This is normal. The designers of BPMN had the constraint to have a formal language that could generate a code and must represent all the situations known in the business workflow situations. A language can be improved by adding new symbols and new semantics, saving the modelers to use a lot of notes or approximate syntax and semantics.

Ishikawa cause and effect trees are mentioned as lacking. I have used them in different occasions and I found that they are not as formal as SysML and UML. The Ishikawa syntax is too imprecise to fit in this class of languages. It is easy to build a better Ishikawa model using a formal SysML stereotype. N2 charts are offered in most SysML tool in the form of a dependency matrix. Functional block diagrams are not recommended according to Friedenthal, Moore and Steiner (2016); formal blocks, use cases and activities are much better.

Another message is “Diagrams that respect the rules of SysML are often cluttered by useless or redundant pieces of information that impair their interpretation.” This kind of critic is like criticizing the English language for all the bad use of English even after a syntax check. When a modeler uses the proper modeling tools, the model is saved independently to the diagrams and an experienced modeler understand rapidly that the simplest diagrams are better to convey the sense.

domroy (talk) 02:57, 26 April 2016 (UTC)