![]() | This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||
|
The article says:
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)
"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 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)
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)
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)
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)
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)
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.