Wie stellt man vorlagenbasierte starke ID-Typen, Typaliase und Datenstrukturen in einem UML-Klassendiagramm dar?C++

Programme in C++. Entwicklerforum
Anonymous
 Wie stellt man vorlagenbasierte starke ID-Typen, Typaliase und Datenstrukturen in einem UML-Klassendiagramm dar?

Post by Anonymous »

Ich erstelle ein UML-Klassendiagramm für ein C++-Projekt und möchte stark typisierte Bezeichner, die über Vorlagen und Typaliase implementiert werden sowie einfache Datenstrukturen (

Code: Select all

struct
) als Domänenobjekte verwendet[/b].
Im Code werden Bezeichner mithilfe einer Tag-basierten Vorlage implementiert, um Typsicherheit zu erreichen:

Code: Select all

template 
class Id {
// some fields
};

struct AxisIdTag {};
struct RunIdTag  {};
struct ReportIdTag {};
struct RecordIdTag {};

using AxisId   = Id;
using RunId    = Id;
using RecordId = Id;
using ReportId = Id;
Es gibt auch reguläre Domänentypen wie Aufzählungen und Datenstrukturen:

Code: Select all

enum class ErrorCode {
// some fields
};

struct Error {
ErrorCode code{};
std::string summary;
std::optional details;
std::optional axisId;
std::optional runId;
std::chrono::system_clock::time_point timestamp;
};
Ziel des Diagramms
Das Ziel des Klassendiagramms besteht nicht darin, die C++-Syntax eins zu eins wiederzugeben, sondern die Entwurfsabsicht zu kommunizieren:
  • dass AxisId, RunId usw. eindeutige Domänenkennungen sind,
  • dass sie alle auf einer gemeinsamen Id-Abstraktion basieren,
  • dass Typsicherheit ein bewusster Teil des Designs ist,
  • und dass einige Typen (z. B. Error) als Datenträger/wertähnliche Domänenobjekte gedacht sind.
Ich verstehe, dass UML keine direkte Vorstellung davon hat, wie C++ verwendet Aliase oder ein dediziertes struct-Konstrukt sind und dass es sich bei einigen dieser Elemente um Implementierungsdetails handelt. Ich möchte jedoch, dass das Diagramm das konzeptionelle Modell so genau wie möglich ausdrückt.
Frage
Was ist die idiomatische oder allgemein akzeptierte Möglichkeit, Folgendes in einem UML-Klassendiagramm darzustellen?
  • Vorlagenbasierte starke ID-Typen wie Id
  • Typaliase wie AxisId, RunId usw.
  • Einfache Datenstrukturen (

    Code: Select all

    struct
    ), die in erster Linie als unveränderliche oder halb-unveränderliche Datenträger fungieren
Zum Beispiel:
  • Soll Id als Vorlagenklasse mit Vorlagenbindungen angezeigt werden?
  • Sollten AxisId, RunId usw. als Vorlagenspezialisierungen, Stereotypen (z. B. ) oder weggelassen und über Notizen dokumentiert?
  • Sollte struct Error genau wie eine UML-Klasse modelliert oder mit einem Stereotyp wie oder , annotiert werden?
  • Gibt es eine bevorzugte Möglichkeit, die Klarheit des Domänenmodells gegen eine Überlastung des Diagramms mit C++-spezifischer Implementierung auszugleichen? Details?
Als Referenz ist hier ein Teil des Diagramms, mit dem ich gerade arbeite: image / PlantUML auf Pastebin
Ich würde mich über Hinweise dazu freuen, ob dieser Ansatz das beabsichtigte Design angemessen kommuniziert und welche Alternativen in UML klarer oder idiomatischer sein könnten.

Quick Reply

Change Text Case: 
   
  • Similar Topics
    Replies
    Views
    Last post