Essential Elements of an UML Class Diagram

[odungern]

Which elements are essential for an overarching system concept? We don't want to generate software code or simulate, so not every detail of UML/SysML is needed.

So far, we are using:

• uml:Class
• uml:Property
• uml:Operation
• uml:Generalization
• uml:Composition
• uml:Aggregation
• uml:Association

Anything else needed for our purpose?

[odungern]

To be honest, I believe we can skip uml:Aggregation. Many don't make the difference between composition and aggregation. It is undoubtedly important for those who want to specify or even generate software code, but not for an overarching system model.

So I propose to translate an aggregation equally to a composition with a relation typed dcterms:hasPart.

The original type uml:Composition or uml:Aggregation can be added to the relation as a property typed dcterms:type.

[odungern]

Another topic to discuss is class vs. instance (see Example):

• Heat_Pump is obviously an instance of the system model representing a concrete device. However an uml:Class is used. (The same issue arises, when a sysml:Block is used, later on ...).
• At the same time Heat_Pump represents a series of identical heat pumps in the real world, so it can be considered to describe a class of real world devices.

[odungern]

Eine Einschätzung von BR mit meiner Antwort (OD) in kursiv aus einem e-mail Austausch:

(1)
Ein Klassendiagramm der UML hat tatsächlich eine etwas unpräzise Semantik, was aber weniger an der Sprache an sich liegt, sondern an den vielen verschiedenen Verwendungsformen. Ein Beispiel: Ein Klassendiagramm mit der Klasse "Person" kann unterschiedliche Bedeutungen haben. Manchmal meint man damit die Menge aller Personen in der realen Welt (insbesondere in analyse) während man manchmal die Softwareklasse "Person" meint. Und leider sind das unterschiedliche Dinge, die syntaktisch durch dasselbe Konstrukt dargestellt werden können.

OD> Das ist in der Tat wichtig. Unser Ansatz ist durch Nachschärfen der Definitionen die Semantik und die Verwendung der Konstrukte eindeutig zu machen (bzw. so gut es geht und nötig für eine Transformation).

Woran liegt das: Das hat damit zu tun, dass die UML (mehr noch als die SysML) eine universelle Modellierungssprache sein möchte, die in vielen verschiedenen Kontexten zum Einsatz kommen kann. So kann man damit Konzepte genauso modellieren, wie Sprachkonstrukte die Metamodelle wie die reale Welt oder Datenstrukturen oder eben auch Softwaresysteme. Das ist dem Klassendiagramm an sich nicht anzusehen, führt aber bei der Kombination mit anderen Modellierungstechniken zu völlig
unterschiedlichen Übersetzungen (Transformationen). und diese haben alle für sich ihre Berechtigung. Das hat in der Praxis dazu geführt, dass unterschiedliche Stakeholder jeweils unterschiedliche Transformationen haben wollen (und zwar berechtigterweise) und eine generelles Agreement über eine einheitliche Semantik nicht erreichbar war.

Konsequenz: abhängig von der Semantik, also der nutzungsform eines Klassendiagramm sind unterschiedliche Transformationen zu definieren und gewünscht. (und das kann sogar innerhalb eines Projekts so sein).

OD> Ja, einer vergleichbaren Herausforderung wir im Zusammenhang mit SpecIF bereits begegnet: Wir setzen das gleiche Basisformat (typisierte Knoten und Kanten eines Knowledge-Graphen mit gleichfalls definierbaren Regeln welche Kantentypen zwischen welchen Knotentypen verwendet werden dürfen) sowohl für die Ontologie als auch für das Modell selbst ein. Dabei werden aus der Ontologie die Typen und Regeln für das Modell erstellt.

Nach vielen anderen Publiaktionen zu dem Thema, haben wir in [HR04] das Ganze mal final aufgearbeitet. Siehe dazu: https://www.se-rwth.de/publications/ (u.a. Stichworte Semantik)

OD> Da werde ich gern weiter recherchieren. Nicos letzter Artikel zu MontiCore ist interessant!

(2)
Wenn man eine syntaktisch reichhaltige Notation, wie zum Beispiel UML Klassendiagramme in eine syntaktisch ärmere Notation oder semantisch ärmer definierte Domäne wie zum Beispiel FMC übersetzt, gibt es immer zwei Möglichkeiten: a) man ignoriert beim übersetzen nicht übersetzbare konstrukte und b) man "codiert" alle nicht direkt übersetzbaren Konstrukte.

OD> So sehen wir es auch. Nach aktuellem Denkansatz sollen

• hinreichend präzise Elemente (wie UML:Generalization) direkt übersetzt;
• schwach definierte Elemente durch Stereotypen (z.B. UML:Class oder UML:Association) gemäß vereinbarter Ontologie präzisiert und dann übersetzt;
• und übrige ignoriert (bzw. als unzulässig ausgewiesen) werden.

Glauben Sie, dass so eine hinreichend formale Sprache entstehen kann?

Sie haben wegen der Bidirektionalität wohl deutlich vor Variante B zu wählen. Abgesehen von eventuellen grundsätzlichen Problemen, dass sich zum Beispiel vielleicht Unterspezifikation, Parallelität, Liveness o. ä. gar nicht kodieren lässt, besteht das grundsätzliche Problem, das je größer die semantische Distanz ist, umso mehr Kodierungsaufwand entsteht. Was unterm Strich in einem multiplizieren Faktor bezüglich der Anzahl der zu verwendenden syntaktischen Elemente führt.

OD> Hier will ich einen Ingenieur-Vorgehen wählen (auch wenn ein solches unter Mathematikern und Informatikern eher verpönt ist): Aus der Vielfalt theoretischer oder methodischer Möglichkeiten geeignete heraus suchen und gezielt für den Zweck einsetzen. Etwa Parallelität lässt sich klar in Petri-Netzen oder Harel State-Charts fassen und würde genutzt, andere Konzepte, die vielleicht für die Code-Generierung nützlich sind, doch nicht für die Beschreibung eines übergreifenden Systemkonzepts, würden ausgelassen. Das Einsatzspektrum für CoCoML und CASCaDE wäre natürlich deutlich kleiner als jenes von UML/SysML.

Wenn man nun in Gegenrichtung übersetzt, wird typischerweise noch mal codiert (den die Reidentifikation der alten "Muster" klappt leider bei zunehmender semantischer Distanz immer weniger). was dazu führt, dass einmal hin und her übersetzt zwar inhaltlich das gleiche Modell definiert werden würde, aber dieses mehr oder weniger in sich selbst codiert ist und deutlich aufgeblasener wirkt.

Beispiel: hat die rechte Seite kein Typsystem, so ist dies in dem Modell zu codieren, bei der Rückübersetzung wird dann ein in sich selbst kodiertes Typsystem erreicht.

OD> In der Tat, das gilt es zu beachten. Ich denke und hoffe jedoch, dass es bei ausreichender Formalisierung von CoCoML unter Verwendung bekannter UML Konstrukte gelingt eine round-trip fähige Transformation zu implementieren. Hier erscheint mir die recht verwachsene Datenstruktur von XMI, die ja aus einem CoCoML-Modell jm Zielformat zu erzeugen wäre, um vorhandene Tools zu nutzen, die größte Herausforderung zu sein. Minimalziel ist eine eindeutige Transformation von einem UML-Tool ins
Zielformat zu definieren.

Persönlich würde ich sttatt einer Rück-Transformation eher Aufwand in die Adaption eines graphischen Web-Editors (etwa aus dem Camunda-Software-Stack) stecken, als in die Erzeugung mehrerer XMI-Varianten je nach UML-Tool.

Deshalb hat bidirektionalität leider auch grundsätzliche Schwierigkeiten. ( diese kann man übrigens nur umgehen, indem man
akzeptiert nicht alles ineinander zu übersetzen, sondern jeweils die quasi "geteilten" syntaktischen konstrukte und damit auch akzeptiert dass beide Sprachen Relevanz haben in der Entwicklung.)

OD> Indeed. In meinen Augen (wieder aus Ingenieurs-Perspektive ;-) ist eine solche Beschränkung nicht nur zulässig, sondern angeraten.

(3)
Knowledegraphen sind eine syntaktisch sehr eingeschränkte, generische Modellierungstechnik, in der man sehr viel rein kodieren kann, aber eben auch muss.

OD> Sehe ich ebenso. Das erlaubt eine Trennung von Syntax und Semantik: Der Knowledge-Graph hat Knotentypen und Knoten sowie Kantentypen und Kanten (Syntax), wobei beide Typen und die Knoten Knoten sind und die Kanten Kanten. Die Typen werden gemäß der Ontologie definiert (Semantik).

Das Modell bedient sich beider. Dem Konzept folgt übrigens SpecIF. Diese Trennung von Syntax und Semantik ist Gold wert: Software kann entsprechend der Syntax gebaut werden und bedarf keiner Änderung, wenn die Semantik/Ontologie (gemäß bestimmter Regeln) geändert wird. Das kann bereits heute demonstriert werden.

FMC zum Beispiel basieren wohl darauf, dass die syntaktischen Elemente "Event", "State" und "Action" als atomar fixiert und semantisch bekannt angenommen werden, und von der Sorte benötigt es wahrscheinlich noch deutlich mehr. Das gleiche Spielchen kann ich aber auch mit anderen semantischen Domänen und Modellierungssprachen machen. ich könnte zum Beispiel in der UML eine Klasse "Action" hinzufügen oder als gegeben annehmen, um dann innerhalb der UML präzisere Semantik zu erreichen.

OD> Ich sehe es eher so: Knoten ("resources") und Kanten ("statements") sind syntaktische Elemente. Die fundamentalen Modellement-Typen nach FMC sind abstrakte semantische Elemente, denen andere als Spezialisierung untergeordnet sind: FMC:Actor als aktives Element etwa ist die Generalisierung von Organization, Person, Role, Component, Function, Activity und anderen, während FMC:State als passives Element als Form, Color, Information und anderen auftreten kann. Alle genannten, abstrakteren oder konkreteren Elemente wären entweder Stereotypen oder Spezialisierungen (tbd) von UML:Class.

Mit dieser zusätzlich notwendigen semantischen Kodierung macht man sich dann wieder angreifbar, denn auch hier muss Konsens und Eindeutigkeit herrschen -- was übrigens auch bei den drei oben genannten Begriffen schon gar nicht einfach ist.

OD> Stimme ganz und gar zu. Doch was heißt 'angreifbar'? Ich denke, wenn eine Einigung über Zweck und Begrifflichkeiten erzielt werden kann (—> Standard), dann ist ein wesentlicher Schritt im Reifeprozess der Disziplin erreicht. Es ist verdammt viel Aufwand, auch da stimme ich zu. Bin Praktiker: Klein anfangen und validieren, dann Schritt für Schritt Land gewinnen.

Wenn man das jetzt zusammenfasst:
Ich glaube die von Ihnen avisierte Arbeit ist deutlich hilfreich, aber nicht deswegen, weil es eine eindeutige Semantikdefinition und
bidirektionale Transformationen geben wird, sondern weil es eine Infrastruktur ist, in der unterschiedliche und auch notwendigerweise unterschiedliche Transformationen leichter und effektiver erstellbar sind. Diese sind dann in konkreten Projekten auch ernsthaft nützlich.

Ich hoffe, Ihnen damit geholfen zu haben.

OD> Auf jeden Fall!