Talk:Systems modeling language

message: 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)
replies: text: That section does have a reference to that source. -- Marcel Douwe Dekker (talk) 22:01, 10 September 2008 (UTC)
thread_title:  Copyvio? 

message: 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)
thread_title:  Delimination of SysML and UML is not clear enough 

message: 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)
thread_title:  Acceptance in the Field remains unclear 

message: 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)
thread_title:  No relation to the ML language 

message: 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)
thread_title:  Limitations and criticism