Blocks and ‘Components’ in SysML

[avi-mak]

 

Hi,

   re: Blocks and ‘Components’ in SysML

I see on SysML forums it is often pointed out that the ‘block’ concept has too many uses. ‘Block’ is used for defining structural elements, and used also for defining ‘flow’ elements or ‘type’ elements, e.g., for defining the type and / or data items flowing along a communication path. 

In UML there was a Component element. I personally never modeled using UML, so the ‘Component’ name has no attraction for me. However, very many modelers started out with UML  and so they are astonished that there is no ‘Component-level’ element. (I will leave aside the issue of whether a UML Component diagram defines definitions (like BDD) or it defines usages.)

But I also feel the lack of a specific element to act as a ‘large structural element’, e.g., module or sub-system. And it is needed especially for communicating with old-time UML modelers.

Of course, one can create one or more stereotypes to deal with this. But it will not be pure SysML.

Does SysML v1.7 or SysML 2.0 offer any generic constructs to address this most basic of structural issues?

If there is no planned higher level structural element in SysML:

(1) What would be the motivation of this? (Of not providing a higher level structural element.)

(2) Is there a standard legend that is being promoted by leading SysML modelers – e.g., <<system>> , <<sub-system>>? This is although I appreciate the simplicity of SysML’s block concept and the advantage of reducing the number of diagram types and basic element types from that in UML.

Thanks

Avi

 

[Stephan Roth]

Hi Avi,

I do not know the exact reasons why the UML Component Diagram was not included in SysML 1.x. But since I also work with UML, I can tell you that the UML component (metaclass: «component») takes a very "software-heavy perspective" on that thing that can be regarded as a component. And by the way: in the UML meta-model, the metaclass component is a specialization of the metaclass class.

In Software Engineering, a component is regarded as a module, whose interfaces are stable, but whose manifestation can be exchanged. Usually they are regarded as a compound of collaborating classes with a certain, common responsibility, having provided and required interfaces to interact with their environment.

From my point of view, the SysML block is sufficient to introduce all imagineable concepts of modularization in a model: the whole system, system elements, components, smaller parts, ... Of course, if you want to distinguish them in the model, you have to define stereotypes. But that's the way how it works. And by the way: stereotypes are pure SysML! It is the intended, standard-compliant concept for making semantic precisions of a SysML base element.

Best regards,

Stephan

[jozsef bedocs]

In SysML and the early days of systems modelling, our model structures typically followed product structure and so components and deployment diagrams were duplicative.  Much has changed since then and fewer models follow those practices.  Package conventions and stereotypes are the only mechanisms to make the distinctions that you describe.  The use of stereotypes are my preference. Using stereotypes does not make it non-SysM:;but it can break data exchange mechanisms.  

[avi-mak]

Hi Stephen,

Thank you for the answer.

>> Of course, if you want to distinguish them in the model, you have to define stereotypes. But that's the way how it works. And by the way: stereotypes are pure SysML! It is the intended, standard-compliant concept for making semantic precisions of a SysML base element. 

Are you aware of movement towards a generally accepted set of stereotypes for software development? 

I would be interested to hear the opinion of forum users about the idea of defining a Component stereotype? What characteristics would it have? 

Thanks in advance,

Avi

[Eran Peleg]

Hi Avi

As you know, I have a full set of Stereotypes for defining components.  As you may wrote the other day, there are different type of components, such as System level, Subsystem, Component, Generic components or Utility, Physical vs. Logical components, LRU vs. SRU, etc.  If you like each kind to have a different icon, you may define a “family” of component stereotypes.  On the physical one, you may like to have a “weight” and “height”  Tags and on the logical one you like to put its Risk level, etc.

Bottom line, it is a “family” of component types, different set of Tags for each type, and also different Relationships or Connectors.  That way a full components DSL is created.

 

Good luck with profiling …

Eran

 

===================

Eran Peleg, CEO

Metaphor Vision Ltd.

www.metaphor.co.il

+972545346060

epe...@metaphor.co.il

===================

--
--
You received this message because you are subscribed to the Google
Groups "SysML Forum" group.
Public website: http://www.SysMLforum.com
To post to this group, send email to sysml...@googlegroups.com
To unsubscribe from this group, send email to
sysmlforum+...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sysmlforum?hl=en_US?hl=en
---
You received this message because you are subscribed to the Google Groups "SysML Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sysmlforum+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sysmlforum/02dd5e6d-2bf2-470e-ae15-3f59c8895d61o%40googlegroups.com.