Man könnte mit Rose jederzeit ein sogennantes Package erstellen, das weitere Klassen oder Klassendiagramme enthält. Im Beispiel nebenan (siehe Abb. 12a) wird dieses Package (hier "Hilfstypen") durch ein Symbol im Hauptklassendiagramm dargestellt. Von dort aus gelangt man zu einem weiteren im Package enthaltenen Klassendiagramm "Hilfstypen" (das alles wurde freilich schon vorher definiert nur bisher verschwiegen). Dort finden sich nun auch die gesuchten Klassen Punkt und Farbe.
In Abb. 12b findet sich noch ein Beispiel für die Darstellung der Übergabeparameter, Rückgabewerte usw. der Methoden im Diagramm.
Zurück zum Hauptklassendiagramm. Hier kann ein Symbol für das Listentemplate hinzugefügt werden, was allerdings nur eine Repräsentation der schon bestehenden Klasse, nicht aber eine neue gleichnamige Klasse schafft (siehe Abb.15).
Die Liste wird jetzt parametrisiert oder instantiiert mit der Klasse "GeomObjekt", was durch die geschweiften Klammer im Namen der instantiierten Klasse "Liste{GeomObjekt}" und durch den "Instantiierungspfeil" auf die instantiierte Klasse Liste ausgedrückt wird (siehe Abb. 16).
Das Diagramm enthält jetzt also eine Containerklasse
für Instanzen der Klasse "GeomObjekt". Diese "enthalten sein"-Beziehung
nennt man Aggregation, und sie wird durch den Pfeil mit der
Raute an einem Ende symbolisiert (siehe Abb. 17).
Zusätzlich wurde an den Enden die sogennannte Kardinalität
eingetragen. Hierbei bedeutet dies, daß
es genau eine aggregierende aber 0-n (also beliebig viele) aggregierte
Klasseninstanzen geben darf.
Ein State Diagram kann an eine Klasse gebunden werden,
um das Verhalten aller Objekte dieser Klasse in einem Zustandsgraphen
darzustellen. Unter Zustand versteht man in diesem Zusammenhang idealisiert
die sinnvolle Teilmenge aller möglicher Wertekonfigurationen der Attribute
des Objektes.
Im Diagramm können ein Anfangszustand, ein oder
mehrere Zwischenzustände und ein oder mehrere Endzustände vermerkt
werden, die durch Zustandsübergänge verbunden werden. Ein Zustandsübergang
zeichnet sich zum Beispiel durch eine an ihn geknüpfte Bedingung,
wie etwa zum Beispiel einen bestimmten Attributwert des jeweiligen Objektes,
und eine Nachricht an das Objekt (Methodenaufruf) aus (siehe
Abb. 18).
Um auch hier Übersichtlichkeit zu erzielen, können
Zustandsgraphen ineinander verschachtelt werden. Der übergeordnete
Graph ist also noch weiter von einer Implementierung abstrahiert.
Im Component Diagram können Zuordnungen der Komponenten eines Projektes an Quellcodedateien getroffen werden. Es existieren Symbole für Hauptprogramm, Unterprogramm, sogenannte Component Packages und vieles mehr. So kann der Code logisch auf mehrere Dateien verteilt werden. Die Component Packages entsprechen in C++ beispielsweise den *.h-Dateien. Das Hauptprogramm unterscheidet sich von anderen Unterprogrammen, da die main()-Funktion in C++ keine Methode einer Klasse ist, und etwas aus dem OO-Rahmen fällt.
Beide Diagramme stellen die Interaktion von Objekten dar
und werden in Rose auch zusammenfassnd Interaction Diagrams
genannt. Sie greifen dabei auf dieselben Informationen zurück, stellen
diese nur auf verschiedene Weise dar.
Es soll hier nur beispielhaft ein Sequence Diagram dargestellt
werden (siehe Abb. 19).
In einem Sequence Diagram werden am oberen Rand die kommunizierenden
Objekte eingetragen, die Senkrechte stellt die Zeitachse dar, und die waagerechten
Verbindungen stehen für Methodenaufrufe oder Nachrichten zwischen
den Objekten. Wichtig ist, daß die absteigenden Reihenfolge der Nachrichten
die wirkliche Reihenfolge festlegt.
Diese Möglichkeiten sind aber relativ neu und nicht ursprünglich in Rational Rose enthalten gewesen. Da einige Informationen noch nicht vollständig in Code, aber auch einige Informationen des Codes nicht korrekt in Modelle abgebildet werden, kann dieser vollständige Entwicklungszyklus noch nicht sinnvoll angewandt werden. Trotzdem sind in jeder Spezifikation eines Elementes des Modells Informationen welche die Codegenerierung betreffen, enthalten. Zu jeder Klasse kann getrennt angegeben werden, ob gewisse Informationen wie Sichtbarkeit bei der Codegenerierung berücksichtigt werden sollen, oder aber es kann global geregelt werden ob etwa Konstruktor-, Destruktor- und Vergleichsoperationen standardmäßig eingefügt werden sollen.