Are stereotypes for software, hardware, and generic elements expendables? about saf-specification HOT 14 CLOSED

from saf-specification.

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

from saf-specification.

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

from saf-specification.

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

from saf-specification.

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.

from saf-specification.

from saf-specification.

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.

from saf-specification.

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.

from saf-specification.

from saf-specification.

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

from saf-specification.

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.

from saf-specification.

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)

from saf-specification.

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.

from saf-specification.

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.

from saf-specification.