Are stereotypes for software, hardware, and generic elements expendables?

[haarer]

We should not use stereotypes to classify physical blocks belonging to a certain engineering discipline.

See https://github.com/GfSE/SAF-Specification/blob/main/vp-examples/Physical-Structure-Viewpoint-secondary-example-1.svg for a diagram depicting the issue.

(i favored this a long time but now i think it was an error)

Instead of this, i propose to use a relationship to an "engineering discipline" element. This should carry a stereotype, e.g. SAF_EngineeringDiscipline.
Users of SAF create their own disciplines and assign physical blocks to one or more disciplines.
(We can provide some well known disciplines as library elements in the profile, e.g. mechanical, electrical, software..)

This should result in using only one stereotype for any kind of physical block.

[AckvaS]

Hi Alex,
link oben funktioniert nicht.
Understandiung you correct, a single stereotype and coming with it a tagged value to further specify if it is mechanical, electrical, software? (I have no issue to go with this)
Or do you talk about another (more general ME/SW/... block (also with stereotype engineering discipline) an use associations or generlizations? (wonder if this is overcomplicating things)

Cheers,
Sascha

[clalitsc]

https://github.com/GfSE/SAF-Specification/blob/main/diagrams/vp-examples/Physical-Structure-Viewpoint-secondary-example-2.svg

[haarer]

A tagged value, referencing one or more elements stereotyped by SAF_EngineeringDiscipline for example would work, yes.

[mleute]

One reason why using the stereotypes PhysicalHardwareElement and PhysicalSoftwareElement was the ability to assign different tagged values via the stereotape to those elements. For SW you probably have Version Numbers, Build Number while for HW you for example talk about revisions or even code the revision in the partnumber.
This is not possible if you only use a tagged value or at least it make the things more complicated.

[haarer]

Am 14. Oktober 2023 17:40:45 MESZ schrieb mleute ***@***.***>:

One reason why using the stereotypes PhysicalHardwareElement and PhysicalSoftwareElement was the ability to assign different tagged values via the stereotape to those elements. For SW you probably have Version Numbers, Build Number while for HW you for example talk about revisions or even code the revision in the partnumber. This is not possible if you only use a tagged value or at least it make the things more complicated. -- Reply to this email directly or view it on GitHub: #25 (comment) You are receiving this because you were assigned. Message ID: ***@***.***>

True, but i doubt that we can standardize Attributes Like those you mentioned. An other Option would be a pattern where the blocks inherit from a discipline specific block with a stereotype from SAF. Users could put own Attributes on those. And Override them in the specialisation. I Like this better. -- Gruß, Alexander

[haarer]

Am 14. Oktober 2023 17:40:45 MESZ schrieb mleute ***@***.***>:

One reason why using the stereotypes PhysicalHardwareElement and PhysicalSoftwareElement was the ability to assign different tagged values via the stereotape to those elements. For SW you probably have Version Numbers, Build Number while for HW you for example talk about revisions or even code the revision in the partnumber. This is not possible if you only use a tagged value or at least it make the things more complicated. -- Reply to this email directly or view it on GitHub: #25 (comment) You are receiving this because you were assigned. Message ID: ***@***.***>

And - while we're at it, i really really want to get rid of the different stereotypes for Physical system and Physical system Element. There shall be only a system stereotype, nothing else. Every system is also a system element - in an upper system. We have already a special stereotype for the role of a system as Part of an upper system.

…

-- Gruß, Alexander

[hugoormo]

I favor keeping stereotypes to a minimum. The disciplines are better handled with views. Several disciplines work with the same systems or system elements but from their own point of view, hence the convenience of keeping systems discipline-neutral.
A discipline may be Safety, that would take into consideration several systems and impose constrains on them. The very same systems will be constrained by other disciplines e.g. ergonomy/UI.
The final system is the result of superimposing all those discipline-views over the same set of physical Systems.

[hugoormo]

One reason why using the stereotypes PhysicalHardwareElement and PhysicalSoftwareElement was the ability to assign different tagged values via the stereotape to those elements. For SW you probably have Version Numbers, Build Number while for HW you for example talk about revisions or even code the revision in the partnumber.

This is not possible if you only use a tagged value or at least it make the things more complicated.

SW and HW are always physical. I'd rename them to hardware and software same as OOSEM.

[haarer]

Am 14. Oktober 2023 21:36:57 MESZ schrieb Hugo Ormo ***@***.***>:

I favor keeping stereotypes to a minimum. The disciplines are better handled with views. Several disciplines work with the same systems or system elements but from their own point of view, hence the convenience of keeping systems discipline-neutral. A discipline may be Safety, that would take into consideration several systems and impose constrains on them. The very same systems will be constrained by other disciplines e.g. ergonomy/UI. The final system is the result of superimposing all those discipline-views over the same set of physical Systems. -- Reply to this email directly or view it on GitHub: #25 (comment) You are receiving this because you were assigned. Message ID: ***@***.***>

The Idea is assigning a certain class of Things to the Block. Perhaps the Term discipline was misleading. E.g. Settings it to be a Software Item. -- Gruß, Alexander

[hugoormo]

Am 14. Oktober 2023 21:36:57 MESZ schrieb Hugo Ormo @.***>:

I favor keeping stereotypes to a minimum. The disciplines are better handled with views. Several disciplines work with the same systems or system elements but from their own point of view, hence the convenience of keeping systems discipline-neutral.

A discipline may be Safety, that would take into consideration several systems and impose constrains on them. The very same systems will be constrained by other disciplines e.g. ergonomy/UI.

The final system is the result of superimposing all those discipline-views over the same set of physical Systems.

--

Reply to this email directly or view it on GitHub:

#25 (comment)

You are receiving this because you were assigned.

Message ID: @.***>

The Idea is assigning a certain class of Things to the Block. Perhaps the Term discipline was misleading.

E.g. Settings it to be a Software Item.

--

Gruß,

Alexander

Let's let it be a value property. The type of it can be named e.g. Settings and it be as structured a type as needed. No need to build a template for the containing block at the framework level. Some teams may do it in the implementation and some others will specialize from an element's library. Then again, settings are part of the SW architecture that need be not in a system model in the first place. I like the approach of OOSEM with SW: just be an empty ref part as a placeholder for an element of the software architecture

[haarer]

But how does OOSEM specify that it there will be a Software, or hardware ? IIRC it does by using an additional stereotypes as they come along, without specifying Rules.

The OOSEM WG hasn't releases any Docs about that, AFAIK. Only some references, e.g. to friedenthals book.

An other aspect is, that we already know that software typically runs on hardware.
I Think SAF should honor this, and allow users to analyse it explicitly.

[AckvaS]

Following your arguments, in addition to a generic physical type a differentiation of physical sub-types (usual suspects: SW, HW,...) is deemed helpful. With those sub-types additional information may be adivisable to be captured.

Why not to have a generic physical type (block) and then a number of spezialisations, which can hold additional pieces of information (tag or value prop is TBD). So no problem to enhance by adding more specialisations are needed in a domain specific application of SAF. (as an alternative to adding stereotypes)

[clalitsc]

Systempartitionierung am Beispiel der Spiegelreflexkamera

Legende (Sub-types): Systemelemente und zugeordnete Domäne, Multidomänen-Elemente, Wandler-Elemente
Aus der dargestellten Struktur der digitalen Kamera wird ferner ersichtlich, dass durch die gewählte Partitionierung zwar eine mechanische Entkopplung der innerhalb der Kamera zu realisierenden Bewegungen erfolgt ist und zur Erzeugung dieser Bewegungen Einzelantriebe zum Einsatz kommen, eine Reihe von Funktionen jedoch noch immer mechanisch erfüllt werden. Mit Blick auf die Systempartitionierung stellt sich daher unter anderem die Frage, ob die gewählte Struktur als optimal anzusehen ist oder ob zukünftig mit einer weiteren Substitution der mechanischen Domäne durch die elektronische bzw. informationstechnische Domäne gerechnet werden kann. Etc., etc.

[clalitsc]

Wirkstruktur und Domänenstruktur am Beispiel eines Druckkopf-Positionier-Systems

[...] im Folgenden unter der Domänenstruktur eines mechatronischen Systems dessen Aufbau hinsichtlich der die einzelnen Teilsysteme bzw. Systemelemente dominierenden Domänen verstanden. Die Domänenstruktur beschreibt also, welche Teilsysteme mechanisch, elektronisch oder informationstechnisch realisiert sind und wie sie über Relationen miteinander in Beziehung stehen. Zur Kennzeichnung der verschiedenen Domänen dienen unterschiedliche Farbtöne bzw. graphische Symbole.
Disclaimer: Im Rahmen der Mechatronik wird synonym zum Begriff Disziplin häufig der Ausdruck Domäne verwendet.