Elemente können als Subelemente in andere Basiselemente beliebigen Typs eingebettet werden: Sie
repräsentieren dann das Superelement.
Subelemente können wiederum Subelemente enthalten: Sie bilden ein Subsystem.
Die Einbettungstiefe ist beliebig. Eine Einbettung ist durch einen Farbwechsel zu
kennzeichnen, den der Editor automatisch durchführt.
Durch Einbettung kann die Struktur einzelner Elemente dargestellt werden.
Ein Element sollte nur eingebettet werden, wenn dessen Instantiierung davon abhängt, dass
das übergeordnete Element ebenfalls instantiiert wird.
Sonst sollte man es separat darstellen.
Die Beziehung zwischen eingebettetem und übergeordnetem Element kann verschiedene Bedeutungen haben:
Einbettung von Rollen in Rollen kann insbesondere genutzt werden, um die Binnengliederung
einer Rolle,
also ihre Organisationsstruktur zu beschreiben.
Die übergeordnete Rolle trägt in der Regel
für ihre Subrollen Verantwortung.
Es ist sinnvoll, eine Aktivität in Rollen einzubetten, wenn diese eine organisatorische Einheit
repräsentieren,
deren Fortbestand oder Hauptaufgaben durch diese Aktivität gewährleistet wird (z.B. Teambesprechung in
Team einbetten).
Aktivitäten werden insbesondere eingebettet, wenn sie
nur von dieser Rolle ausgeführt werden und auch nur
diese beeinflussen
(z.B. Person und Denken).
Entitäten kann man in Rollen einbetten, wenn sie für den Erhalt oder das Verhalten
dieser Rolle benötigt werden und sie
(bzw. eine Instantiierung der Entität) auch nicht in
anderen Rollen enthalten sein kann. Das implizite Wissen
einer Person oder eines Teams kann z.B. eingebettet werden, um auszudrücken, dass es
nicht externalisiert vorliegt.
Eine Rolle sollte in eine Aktivität eingebettet werden, wenn sie nur exisitiert, um
diese Aktivität auszuführen
oder in einer sonstigen engen semantischen Verbindung mit dieser Aktivität steht oder wenn sie für alle anderen Aktivitäten eines Modells irrelevant ist.
Mit den eingebetteten Subaktivitäten werden alle Aktivitäten dargestellt, die (ggf. nur unter bestimmten
Bedingungen) benötigt werden, damit die übergeordnete Superaktivität
abgeschlossen werden kann.
Subaktivitäten, die nicht durch Relationen verbunden
sind, können in beliebiger Reihenfolge ausgeführt werden.
Rekursion ist möglich, d.h. dass die übergeordnete Aktivität sich selbst als Subaktivität enthalten
kann.
Eine Entität sollte in eine Aktivität eingebettet werden, wenn sie ausschließlich
zur Durchführung dieser Aktivität benötigt
wird oder ausschließlich von dieser verändert wird und wenn keine anderen Aktivitäten auf sie zugreifen,
oder wenn sie in sonstiger enger semantischer Verbindung mit der Aktivität steht (z.B. Schreiben und Schreibmaschine).
Eine Rolle bettet man zum einen in eine Entität ein, wenn sie nur mit dieser Entität in Zusammenhang steht und es ist nur die Entität (nicht die Rolle), die für die restlichen Elemente des Modells relevant
ist.
Zum anderen ist eine solche Einbettung sinnvoll, wenn die Entität einen Raum oder Ort repräsentiert (z.B.
Büro, Schiff, Krankenhaus) innerhalb dessen die Rolle
gemäß ihrer Definition aktiv ist.
Das Einbetten von Aktivitäten in
eine Entität ist sinnvoll, wenn sie
ausschließlich genutzt werden, um diese Entität
zu verändern oder wenn die Aktivität
ausschließlich von dieser Entität
ausgeführt wird.
Letzteres ist insbesondere der Fall, wenn Aktivität
die Zustandsänderungen eines Computersystems beschreibt.
Diese Art der Einbettung macht auch Sinn, wenn ein enger,
ausschließlicher Zusammenhang zwischen Entität
und Aktivität besteht.
Entitäten bettet man in eine Entität ein, wenn ein enger semantischer oder pragmatischer
Zusammenhang zwischen den beiden besteht
und die Subentität nicht mit dritten Entitäten
im selben Zusammenhang steht.
Die Eigenschaft der übergeordnete Entität sollte
die Einbettung der Subentitäten rechtfertigen.
Sie kann z.B. aus den Subentitäten zusammengesetzt sein, sie als Container enthalten, in
die Subentitäten unterteilt sein.
Die Subentitäten können auch Kategorien der übergeordneten Entität repräsentierten.
Um Basiselemente näher zu beschreiben, kann man Attribute definieren und sie in das Basiselement einbetten.
Attribute werden als Text dargestellt.
Ein Attribut besteht aus einem Attributnamen und dem bzw. den
Werten, die das Attribut bezogen auf die Entität hat.
Es gibt Standard-Attribute, z.B. NAME.
Man hat die Wahl, ob man die Eigenschaften eines Basiselementes mittels eines Attributs oder durch Relationen zu
anderen Basiselementen darstellt.
Falls eine große Zahl von Elementen oder auch Attributen in ein Basiselement
eingeordnet werden, kann es sinnvoll sein, diese zu ordnen.
Zu diesem Zweck kann man ein Basiselement durch waagerechte
Striche in Segmente zerlegen:
Der Modellierer ist frei in der Entscheidung, wie er das Ordnungsprinzip wählt, mit
dem er die Subelemente auf die Segmente verteilt. Ein typisches
Ordnungsprinzip, das bei der Modellierung von Klassen genutzt wird, ist eine Dreiteilung in
Name, Attribute, Methoden.
Man kann Segmente auch nutzen, um die Menge der Subrollen, Subaktivitäten und
Subentitäten getrennt darzustellen.
Außerdem kann man in verschiedenen Segmenten verschiedene Perspektiven bzw.
Möglichkeiten darstellen, wie man ein Basiselement in
Subelemente untergliedern kann:
Segmente können auch einen Namen haben.
Relationen, die mit dem Rand eines Basiselementes verbunden sind, beziehen sich in ihrer Bedeutung immer auch auf alle Subelemente dieses Basiselementes, sofern sie den gleichen Typ haben.
Eine Relation kann den Rand des Basiselementes auch schneiden, um direkt mit einem Subelement beliebigen Typs verbunden zu sein. Sie ist zwar dann auch mit dem Basiselement verbunden, aber nur in dem Sinne, dass sie sich in ihrer Bedeutung auf das ausgewählte Subelement dieses Basiselements bezieht.
Wenn man nicht angeben oder entscheiden will, ob sich eine Relation auf ein gesamtes Basiselement oder nur auf einen Teil seiner Subelemente bezieht, dann lässt man den Start- oder Endpunkt der Relation innerhalb des Basiselementes unspezifiziert.