Bei der Umsetzung von UML in EJB werden UML-Modellelemente (Unified Modeling Language) in Enterprise-Beans und Java-Code umgesetzt. Die Umsetzung von UML in EJB funktioniert wie die Umsetzung von UML in Java, sie kann aber auch aus UML-Elementen, die mit Stereotypen aus dem EJB-Umsetzungsprofil markiert sind, Enterprise-Beans generieren.
Sie sollten mit der Umsetzung von UML in Java vertraut sein, bevor Sie die Umsetzung von UML in EJB verwenden.
Konfigurationsregisterkarten für die Umsetzung von UML in EJB
Interpretation von Quellenobjekten
Unterstützung für einheitliche Umsetzungstechnologien
Integration in eine Teamfunktionalität
Sie können ein oder mehrere Elemente in der Modellexplorersicht als Quelle für die Umsetzung von UML in EJB auswählen. In der folgenden Tabelle werden die Elemente aufgelistet, die von der Umsetzung als gültige Quelle akzeptiert werden:
Quelle |
Ergebnis |
UML-Modell |
Setzt alle Pakete, Klassen und Schnittstellen im Modell um. |
UML-Paket |
Setzt das Paket und alle Klassen und Schnittstellen darin um. |
UML-Klasse |
Setzt die Klasse und alle Attribute, Operationen, Klassen und Schnittstellen in dieser Klasse um. Hinweis: Das übergeordnete Element der Klasse muss ein UML-Paket sein. |
UML-Schnittstelle |
Setzt die Schnittstelle und alle Attribute, Operationen, Klassen und Schnittstellen in dieser Schnittstelle um. Hinweis: Das übergeordnete Element der Schnittstelle muss ein UML-Paket sein. |
UML-Aufzählung |
Setzt die Aufzählung und alle Aufzählungsliterale um. Hinweis: Das übergeordnete Element der Aufzählung muss ein UML-Paket sein. |
Um aus einem Quellenmodell Enterprise-Beans zu generieren, muss auf das Quellenmodell das EJB-Umsetzungsprofil angewendet werden, und die Modellelemente müssen mit Stereotypen aus dem EJB-Umsetzungsprofil markiert werden.
Die Umsetzung von UML in EJB akzeptiert als Ziel ein einzelnes EJB-Projekt. Sie können das EJB-Projekt mit oder ohne Clientprojekt erstellen. Bei der Umsetzung wird der Code im ersten Quellenordner, der im EJB-Projekt gefunden wird (normalerweise 'ejbModule'), sowie im ersten Quellenordner generiert, der im Clientprojekt gefunden wird (normalerweise 'src'), wenn ein Clientprojekt existiert.
Die Version des EJB-Containers, der dem EJB-Projekt zugeordnet ist, wirkt sich auf die Umsetzung von UML in EJB aus. Für jede EJB-Containerversion gelten unterschiedliche Regeln, die befolgt werden müssen, damit die Umsetzung von UML in EJB ordnungsgemäß funktioniert und verarbeitet wird. In der folgenden Tabelle werden die Regeln aufgelistet, die unterschiedlichen EJB-Containerversionen zugeordnet sind:
EJB-Containerversion |
Regeln, die sich auf die Umsetzung auswirken |
2.1 |
CMP 1.1-Beans (Container-managed Persistence) dürfen nur mit fernen Schnittstellen generiert werden. |
2.0 |
CMP 1.1-Beans dürfen nur mit fernen Schnittstellen generiert werden. |
1.1 |
|
Wenn die oben genannten Regeln nicht befolgt werden, bevor die Umsetzung ausgeführt wird, wird das Quellenmodell bei der EJB-Umsetzung nicht verarbeitet und es findet keine Umsetzung statt.
Das EJB-Umsetzungsprofil definiert Stereotype, die bei der Umsetzung von UML in EJB interpretiert werden, um Enterprise-Beans zu generieren. In der folgenden Tabelle werden die Stereotype aufgelistet, die das EJB-Umsetzungsprofil definiert:
Stereotyp |
Zielelement |
Interpretation der Umsetzung von UML in EJB |
<<entity>> |
UML-Klasse |
Stellt eine Entity-Bean dar. |
<<service>> |
UML-Klasse |
Stellt eine Session-Bean mit der Stereotypeigenschaft "hasState" dar, die anfangs auf den Wert "false" gesetzt ist. Dies gibt an, dass die Session-Bean eine Session-Bean ohne Zustand (Stateless) ist. |
<<messageprocessor>> |
UML-Klasse |
Stellt eine nachrichtengesteuerte Bean dar. |
<<id>> |
UML-Attribut |
Stellt ein CMP- oder BMP-Feld dar, das als Teil des Primärschlüssels einer Entity-Bean verwendet werden soll. |
<<query>> |
UML-Operation |
Stellt eine Abfragemethode für eine Entity-Bean dar. |
Das EJB-Umsetzungsprofil definiert auch folgende Vorgaben:
Wenn Sie ein Modell mit dem EJB-Umsetzungsprofil prüfen, generieren diese Vorgaben Warnungen. Bevor Sie die Umsetzung von UML in EJB ausführen, sollten Sie die Probleme, durch die diese Warnungen generiert werden, korrigieren. Die Warnungen verhindern jedoch nicht die Ausführung der Umsetzung.
Das Konfigurationsfenster für die EJB-Umsetzung enthält sechs Registerkarten: Ziel, Entity, Session, Erweitert, Zuordnung und Allgemein. In diesem Abschnitt wird beschrieben, wie die ersten drei Registerkarten die EJB-Umsetzung beeinflussen.
Sie können die Registerkarte Ziel verwenden, um das EJB-Zielprojekt auszuwählen, in dem bei der EJB-Umsetzung die Ausgabedateien erstellt werden. Sie können einen neuen Zielcontainer erstellen, selbst wenn ein EJB-Projekt verfügbar ist. Jedes Projekt ist einem einzigen EJB-Container zugeordnet. Die EJB-Umsetzung unterstützt alle verfügbaren EJB-Containerversionen, die der EJB-Projektassistent bereitstellt.
Die Version des EJB-Zielprojektcontainers kann die Optionen einschränken, die auf den Registerkarten Entity und Session verfügbar sind. Weitere Informationen zu den Einschränkungen der einzelnen EJB-Containertypen finden Sie im Abschnitt über den EJB-Zielcontainer.
Sie können die Registerkarte Entity dazu verwenden, neu generierte Entity-Beans anzupassen. Auf der Registerkarte Entity können zwei unterschiedliche Optionen konfiguriert werden: Entity-Bean-Typ und Entity-Bean-Schnittstelle. Die folgende Abbildung zeigt die Registerkarte Entity im Konfigurationsfenster für die EJB-Umsetzung.
Je nach der Version des EJB-Containers im Projekt können Sie jeweils nur bestimmte Eigenschaftskombinationen auswählen, bevor Sie die EJB-Umsetzung ausführen können. In der folgenden Tabelle werden die Entity-Bean-Typen, die von der Umsetzung unterstützt werden, die Schnittstellen, die von den Entity-Beans unterstützt werden, und die jeweilige Standardauswahl für die Schnittstelle aufgelistet:
EJB-Containerversion |
Entity-Bean-Typ |
Unterstützte Schnittstellen für Entity-Beans |
Standardauswahl |
2.x |
CMP 2.x |
Lokal und fern |
Nur lokale Schnittstellen |
2.x |
CMP 1.1 |
Fern |
Nur ferne Schnittstellen |
2.x |
BMP |
Lokal und fern |
Nur lokale Schnittstellen |
1.1 |
CMP 2.x |
Keine |
N/V |
1.1 |
CMP 1.1 |
Fern |
Nur ferne Schnittstellen |
1.1 |
BMP |
Fern |
Nur ferne Schnittstellen |
Die Spalte mit der Standardauswahl in der Tabelle gibt das Standardverhalten des Assistenten für die Entity-Bean-Erstellung wieder.
Wenn Sie eine ungültige Kombination von Optionen auswählen, wird im oberen Bereich des Konfigurationsfensters für die EJB-Umsetzung eine Fehlernachricht angezeigt, und die Schaltfläche Ausführen, mit deren Hilfe die Umsetzung ausgeführt wird, ist nicht verfügbar. Wenn Sie eine gültige Kombination von Optionen auswählen, wird die Schaltfläche Ausführen verfügbar, und die Fehlernachricht wird nicht mehr angezeigt.
Sie können die Registerkarte Session dazu verwenden, die Generierung von Schnittstellen für neu generierte Session-Beans anzupassen. Die folgende Abbildung zeigt die Registerkarte Session im Konfigurationsfenster für die EJB-Umsetzung.
Je nach der Version des EJB-Containers im Projekt können Sie jeweils nur bestimmte Eigenschaftskombinationen auswählen, bevor Sie die EJB-Umsetzung ausführen können. In der folgenden Tabelle werden die Schnittstellen, die von der Umsetzung für Session-Beans unterstützt werden, entsprechend der Version des EJB-Containers sowie die jeweilige Standardauswahl für die Schnittstellen aufgelistet:
EJB-Containerversion |
Unterstützte Schnittstellen für Session-Beans |
Standardauswahl |
1.1 |
Fern |
Nur ferne Schnittstellen |
2.0 |
Lokal und fern |
Nur ferne Schnittstellen |
2.1 |
Lokal und fern |
Nur ferne Schnittstellen |
Wenn Sie eine ungültige Kombination von Optionen auswählen, wird im oberen Bereich des Konfigurationsfensters für die EJB-Umsetzung eine Fehlernachricht angezeigt, und die Schaltfläche Ausführen, mit deren Hilfe die Umsetzung ausgeführt wird, ist nicht verfügbar. Wenn Sie eine gültige Kombination von Optionen auswählen, wird die Schaltfläche Ausführen verfügbar, und die Fehlernachricht wird nicht mehr angezeigt.
Weitere Informationen zur Registerkarte Erweitert finden Sie in der Dokumentation zur Umsetzung von UML in Java.
In diesem Abschnitt wird beschrieben, wie die Umsetzung von UML in EJB die Elemente in einem UML-Modell interpretiert und was bei der Umsetzung als Ausgabe generiert wird.
Bei der Umsetzung von UML in EJB werden primitive Typen wie bei der Umsetzung von UML in Java interpretiert. Weitere Informationen hierzu finden Sie in der Dokumentation zur Umsetzung von UML in Java.
Bei der Umsetzung von UML in EJB werden Pakete wie bei der Umsetzung von UML in Java interpretiert: Sie werden in Java-Pakete umgesetzt. Weitere Informationen hierzu finden Sie in der Dokumentation zur Umsetzung von UML in Java.
Bei der Umsetzung von UML in EJB werden unmarkierte Klassen wie bei der Umsetzung von UML in Java interpretiert: Sie werden in Java-Klassen umgesetzt. Weitere Informationen hierzu finden Sie in der Dokumentation zur Umsetzung von UML in Java.
Wenn eine unmarkierte Klasse Attribute enthält, deren Typ eine Klasse mit dem Stereotyp <<entity>>, <<service>> oder <<messageprocessor>> ist, generiert die Umsetzung die Attribute nicht. Stattdessen wird bei der Umsetzung eine Nachricht in die Protokolldatei geschrieben, die angibt, dass das Quellenattribut nicht umgesetzt wird.
Bei der Umsetzung von UML in EJB werden unmarkierte Schnittstellen wie bei der Umsetzung von UML in Java interpretiert: Sie werden in Java-Schnittstellen umgesetzt. Weitere Informationen hierzu finden Sie in der Dokumentation zur Umsetzung von UML in Java.
Wenn eine unmarkierte Schnittstelle Attribute enthält, deren Typ eine Klasse mit dem Stereotyp <<entity>>, <<service>> oder <<messageprocessor>> ist, generiert die Umsetzung die Attribute nicht. Stattdessen wird bei der Umsetzung eine Nachricht in die Protokolldatei geschrieben, die angibt, dass das Quellenattribut nicht umgesetzt wird.
Bei der Umsetzung von UML in EJB wird die unmarkierte Aufzählung wie bei der Umsetzung von UML in Java interpretiert: Sie wird in Java-Schnittstellen umgesetzt. Weitere Informationen hierzu finden Sie in der Dokumentation zur Umsetzung von UML in Java.
Bei der Umsetzung von UML in EJB wird eine Klasse mit dem Stereotyp <<entity>> in eine CMP 2.x-, CMP 1.1- oder BMP-Entity-Bean umgesetzt. Der Name der Entity-Bean ist derselbe wie der Name der UML-Quellenklasse. Der Typ der generierten Entity-Bean entspricht der Option, die im Konfigurationsfenster für die EJB-Umsetzung auf der Registerkarte Entity ausgewählt wurde.
Bei der Umsetzung werden immer die folgenden Java-Klassen für Entity-Beans generiert:
Bei der Umsetzung werden die folgenden Java-Klassen generiert, wenn Sie auf der Registerkarte Entity auf Nur ferne Schnittstellen klicken:
Bei der Umsetzung werden die folgenden Java-Klassen generiert, wenn Sie auf der Registerkarte Entity auf Nur lokale Schnittstellen klicken:
Bei der Umsetzung werden die folgenden Java-Klassen generiert, wenn Sie auf der Registerkarte Entity auf Lokale und ferne Schnittstellen klicken:
Bei der Umsetzung werden alle Klassen in dem Paketordner generiert, der für das übergeordnete Paket der UML-Quellenklasse generiert wurde. Wenn Sie ein UML-Modell ohne Pakete erstellen, wird bei der Umsetzung ein Standardpaket mit dem Namen 'ejbs' generiert.
Bei der Umsetzung werden die Beanklassen- und Schlüsselklassendateien in der Quellenbaumstruktur des EJB-Zielprojekts generiert.
Bei der Umsetzung werden die vier Schnittstellendateien in der Quellenbaumstruktur des Clientprojekts des EJB-Zielprojekts generiert. Wenn kein Clientprojekt vorhanden ist, werden die Schnittstellendateien bei der Umsetzung im EJB-Zielprojekt generiert.
Bei der Umsetzung werden Daten, die die Entity-Bean definieren, zum Implementierungsdeskriptor (ejb-jar.xml) hinzugefügt.
Generalisierungsbeziehungen
Wenn die UML-Quellenklasse für die Entity-Bean eine Generalisierungsbeziehung (wie z. B. eine Erweiterungsbeziehung) zu einer anderen UML-Klasse mit dem Stereotyp <<entity>> aufweist, wird die Entity-Bean, die die Klasse darstellt, die EJB-Superklasse für die zu generierende Entity-Bean.
Beide Entity-Beans müssen denselben Typ aufweisen. Das heißt, beide Entity-Beans müssen den Typ CMP 2.x, CMP 1.1 oder BMP aufweisen. Wenn die Superbean beispielsweise eine CMP 2.x-Entity-Bean ist, müssen alle untergeordneten Beans CMP 2.x-Entity-Beans sein. Wenn die Superbean nicht denselben Typ wie die erwartete untergeordnete Bean aufweist, wird bei der Umsetzung die untergeordnete Bean ohne Generalisierungsbeziehung generiert.
Realisierungsbeziehungen
Wenn die UML-Quellenklasse für die Entity-Bean Realisierungsbeziehungen (zum Beispiel Implementierungsbeziehungen) zu Schnittstellenelementen aufweist, werden die Schnittstellen, die die Quellenschnittstellen darstellen, durch die vier Schnittstellen (fern, Home, lokal, lokales Home) implementiert.
Unmarkierte Attribute - CMP 2.x
Bei der Umsetzung werden Attribute der UML-Quellenklasse in CMP-Felder der Entity-Bean mit den Eigenschaften umgesetzt, die in der folgenden Tabelle aufgelistet werden:
CMP 2.x-Feldeigenschaft |
CMP-Feldwert |
Name |
Der Name des UML-Attributs, wobei das erste Zeichen des Feldnamens in einen Kleinbuchstaben geändert wurde. |
Typ |
Typ wird vom Attributtyp bestimmt (siehe Tabelle Typenzuordnung). |
Schlüsselfeld |
Falsch |
Feld in Beanimplementierungsklasse generieren |
Falsch |
Getter und Setter generieren |
Wahr |
Getter und Setter an lokale Schnittstellen hochstufen |
Wahr (wenn lokale Schnittstellen vorhanden sind) |
Getter und Setter an ferne Schnittstellen hochstufen |
Wahr (wenn ferne Schnittstellen vorhanden sind) |
IsArray |
Wahr, wenn das UML-Attribut einen endlichen Oberwert hat |
Wenn der Attributtyp der einer anderen CMP 2.x-Entity-Bean ist, wird das Attribut bei der Umsetzung nicht in ein CMP-Feld umgesetzt. Bei der Umsetzung wird dann davon ausgegangen, dass das Attribut Teil einer Assoziation ist, die in eine EJB-Beziehung umgesetzt werden soll. Wenn jedoch der Attributtyp der einer anderen Enterprise-Bean ist, die keine CMP 2.x-Entity-Bean ist, wird das Attribut bei der Umsetzung nicht in ein CMP-Feld oder in eine Assoziation umgesetzt. Stattdessen wird bei der Umsetzung eine Nachricht in die Protokolldatei geschrieben, die angibt, dass das Quellenattribut nicht umgesetzt wird.
Unmarkierte Attribute - CMP 1.1
Bei der Umsetzung werden Attribute der UML-Quellenklasse in CMP-Felder der Entity-Bean mit den Eigenschaften umgesetzt, die in der folgenden Tabelle aufgelistet werden:
CMP 1.1-Feldeigenschaft |
CMP-Feldwert |
Name |
Der Name des UML-Attributs, wobei das erste Zeichen des Feldnamens in einen Kleinbuchstaben geändert wurde. |
Typ |
Typ wird vom Attributtyp bestimmt (siehe Tabelle Typenzuordnung). |
Schlüsselfeld |
Falsch |
Feld in Beanimplementierungsklasse generieren |
Falsch |
Getter und Setter generieren |
Wahr |
Getter und Setter an lokale Schnittstellen hochstufen |
Falsch |
Getter und Setter an ferne Schnittstellen hochstufen |
Wahr (immer) |
IsArray |
Wahr, wenn das UML-Attribut einen endlichen Oberwert hat |
Wenn der Attributtyp der einer anderen Entity-Bean oder Enterprise-Bean ist, wird das Attribut bei der Umsetzung nicht in ein CMP-Feld oder in eine Assoziation umgesetzt. Stattdessen wird bei der Umsetzung eine Nachricht in die Protokolldatei geschrieben, die angibt, dass das Quellenattribut nicht umgesetzt wird.
Unmarkierte Attribute - BMP
Bei der Umsetzung werden Attribute der UML-Quellenklasse in BMP-Felder der Entity-Bean mit den Eigenschaften umgesetzt, die in der folgenden Tabelle aufgelistet werden:
BMP-Feldeigenschaft |
BMP-Feldwert |
Name |
Der Name des UML-Attributs, wobei das erste Zeichen des Feldnamens in einen Kleinbuchstaben geändert wurde. |
Typ |
Typ wird vom Attributtyp bestimmt (siehe Tabelle Typenzuordnung). |
Schlüsselfeld |
Falsch |
Feld in Beanimplementierungsklasse generieren |
Wahr |
Getter und Setter generieren |
Wahr |
Getter und Setter an lokale Schnittstellen hochstufen |
Wahr (wenn lokale Schnittstellen vorhanden sind) |
Getter und Setter an ferne Schnittstellen hochstufen |
Wahr (wenn ferne Schnittstellen vorhanden sind) |
IsArray |
Wahr, wenn das UML-Attribut einen endlichen Oberwert hat |
Wenn der Attributtyp der einer anderen Entity-Bean oder EJB ist, wird das Attribut bei der Umsetzung nicht in ein BMP-Feld oder in eine Assoziation umgesetzt. Stattdessen wird bei der Umsetzung eine Nachricht in die Protokolldatei geschrieben, die angibt, dass das Quellenattribut nicht umgesetzt wird.
<<id>>-Attribute - CMP 2.x und CMP 1.1
Bei der Umsetzung werden auch Attribute der UML-Quellenklasse, die mit dem Attribut <<id>> markiert sind, in CMP-Felder umgesetzt. Diese Attribute erhalten aber andere Eigenschaftswerte, die in der folgenden Tabelle aufgeführt sind. Diese CMP-Felder dienen zur Bildung des Primärschlüssels.
CMP 2.x- und CMP 1.1-Feldeigenschaft |
CMP-Feldwert |
Name |
Der Name des UML-Attributs, wobei das erste Zeichen des Feldnamens in einen Kleinbuchstaben geändert wurde. |
Typ |
Typ wird vom Attributtyp bestimmt (siehe Tabelle Typenzuordnung). |
Schlüsselfeld |
Wahr |
Feld in Beanimplementierungsklasse generieren |
Falsch |
Getter und Setter generieren |
Wahr |
Getter und Setter an lokale Schnittstellen hochstufen |
Falsch |
Getter und Setter an ferne Schnittstellen hochstufen |
Falsch |
IsArray |
Wahr, wenn das UML-Attribut einen endlichen Oberwert hat |
Wenn der Attributtyp der einer anderen Entity-Bean oder Enterprise-Bean ist, wird das Attribut bei der Umsetzung nicht in ein CMP-Schlüsselfeld oder in eine Assoziation umgesetzt. Stattdessen wird bei der Umsetzung eine Nachricht in die Protokolldatei geschrieben, die angibt, dass das Quellenattribut nicht umgesetzt wird.
<<id>>-Attribute - BMP
Bei der Umsetzung werden auch Attribute der UML-Quellenklasse, die mit dem Attribut <<id>> markiert sind, in BMP-Felder umgesetzt. Diese Attribute erhalten aber andere Eigenschaftswerte, die in der folgenden Tabelle aufgeführt sind. Diese BMP-Felder dienen zur Bildung des Primärschlüssels.
BMP-Feldeigenschaft |
BMP-Feldwert |
Name |
Der Name des UML-Attributs, wobei das erste Zeichen des Feldnamens in einen Kleinbuchstaben geändert wurde. |
Typ |
Typ wird vom Attributtyp bestimmt (siehe Tabelle Typenzuordnung). |
Schlüsselfeld |
Wahr |
Feld in Beanimplementierungsklasse generieren |
Wahr |
Getter und Setter generieren |
Wahr |
Getter und Setter an lokale Schnittstellen hochstufen |
Falsch |
Getter und Setter an ferne Schnittstellen hochstufen |
Falsch |
IsArray |
Wahr, wenn das UML-Attribut einen endlichen Oberwert hat |
Wenn der Attributtyp der einer anderen Entity-Bean oder Enterprise-Bean ist, wird das Attribut bei der Umsetzung nicht in ein BMP-Schlüsselfeld oder in eine Assoziation umgesetzt. Stattdessen wird bei der Umsetzung eine Nachricht in die Protokolldatei geschrieben, die angibt, dass das Quellenattribut nicht umgesetzt wird.
Wie die folgende Tabelle zeigt, werden die CMP- und BMP-Felder bei der Umsetzung mit Typen generiert, die auf den Quellenattributtypen basieren:
UML-Attributtyp |
CMP/BMP-Feldtyp |
boolean |
boolean |
byte |
byte |
char |
char |
float |
float |
int |
int |
long |
long |
short |
short |
Boolean |
java.lang.Boolean |
Byte |
java.lang.Byte |
Char |
java.lang.Char |
Float |
java.lang.Float |
Integer |
java.lang.Integer |
Long |
java.lang.Long |
Short |
java.lang.Short |
String |
java.lang.String |
Andere |
Vollständig qualifizierter Name |
Unmarkierte Operationen
Bei der Umsetzung werden unmarkierte Operationen in den UML-Quellenklassen in Geschäftsmethoden der Entity-Bean umgesetzt. Anfangs wird die Operation auf dieselbe Weise umgesetzt wie eine Operation für eine unmarkierte UML-Klasse. Bei der Umsetzung wird die Benennung in Kleinschreibung durchgesetzt, indem das erste Zeichen des Methodennamens in einen Kleinbuchstaben geändert wird, wenn es sich um einen gültigen Großbuchstaben handelt. Die umgesetzte Operation wird mit einigen Änderungen zu den Klassen hinzugefügt, die in der folgenden Tabelle aufgelistet sind.
Klasse |
Änderungen an der Methode |
Beanklasse |
Keine Änderung |
Lokale Schnittstelle |
Schnittstellenmethode |
Ferne Schnittstelle |
Schnittstellenmethode, löst "java.rmi.RemoteException" aus |
<<query>>-Operationen - CMP 2.x
Bei der Umsetzung werden <<query>>-Operationen in der UML-Quellenklasse in eine von zwei Abfragemethoden umgesetzt: Finder-Methoden und Select-Methoden. Select-Methoden gibt es nur in CMP 2.x-Entity-Beans.
Bei der Umsetzung werden Finder-Methoden mit einigen Änderungen in den Klassen generiert, die in der folgenden Tabelle aufgelistet sind:
Klasse |
Änderungen an der Methode |
Lokale Home-Schnittstelle (wenn lokale Schnittstellen vorhanden sind) |
|
Ferne Home-Schnittstelle (wenn ferne Schnittstellen vorhanden sind) |
|
Name der UML-Operation |
Name der Finder-Methode |
xxx |
findXxx |
findXxx |
findXxx |
FindXxx |
findXxx |
Analysierter Rückgabetyp der Java-Umsetzung |
Rückgabetyp der Finder-Methode |
Zugeordnete Sammlung (z. B. Collection, List, Set etc.) |
java.util.Collection |
<Quellenklassenname>[] |
java.util.Collection |
<Quellenklassenname> ODER void |
|
<Name des benutzerdefinierten Datentyps>[] |
java.util.Collection |
<Nicht-Quellenklassenname (z. B. String, Integer usw.)>[] |
java.util.Collection |
<Name des benutzerdefinierten Datentyps> |
Select-Methode anstelle einer Finder-Methode generieren |
<Nicht-Quellenklassenname (z. B. String, Integer usw.)> |
Select-Methode anstelle einer Finder-Methode generieren |
Bei der EJB-Umsetzung wird eine Task erstellt, die angibt, dass Sie manuell eine Abfrage zum Implementierungsdeskriptor für jede generierte Finder-Methode hinzufügen müssen.
Bei der Umsetzung wird eine Abfrageoperation in eine Select-Methode umgesetzt, wenn die Sichtbarkeit für die Operation "privat" ist oder wenn der Rückgabetyp sich vom Namen der UML-Quellenklasse unterscheidet und der Entity-Bean-Typ CMP 2.x ist.
Sichtbarkeit der Operation |
Rückgabetyp |
Methodentyp |
Privat |
Gleich dem Namen der Quellenklasse |
Select-Methode |
Nicht privat |
Gleich dem Namen der Quellenklasse |
Finder-Methode |
Privat |
Nicht Name der Quellenklasse |
Select-Methode |
Nicht privat |
Nicht Name der Quellenklasse |
Select-Methode |
Bei der Umsetzung werden die Select-Methoden in der Beanklasse mit folgenden Änderungen generiert:
Name der UML-Operation |
Name der Select-Methode |
xxx |
ejbSelectXxx |
selectXxx |
ejbSelectXxx |
SelectXxx |
ejbSelectXxx |
ejbSelectXxx |
ejbSelectXxx |
Analysierter Rückgabetyp der Java-Umsetzung |
Rückgabetyp der Select-Methode |
Zugeordnete Sammlung (z. B. Collection, List, Set etc.) |
Vollständig qualifizierter Name des Sammlungstyps (z. B. java.util.Collection) |
<Quellenklassenname>[] |
java.util.Collection |
<Quellenklassenname> ODER void |
Name der lokalen Schnittstelle |
<Name des benutzerdefinierten Datentyps>[] |
java.util.Collection |
<Nicht-Quellenklassenname (z. B. String, Integer usw.)>[] |
java.util.Collection |
<Name des benutzerdefinierten Datentyps> |
Name des benutzerdefinierten Datentyps |
<Nicht-Quellenklassenname (z. B. String, Integer usw.)> |
Nicht-Quellenklassenname |
Bei der EJB-Umsetzung wird eine Task erstellt, die angibt, dass Sie manuell eine Abfrage zum Implementierungsdeskriptor für jede generierte Select-Methode hinzufügen müssen.
<<query>>-Operationen - CMP 1.1
Bei der Umsetzung werden <<query>>-Operationen in der UML-Quellenklasse in einen einzigen Abfragemethodentyp umgesetzt: in Finder-Methoden. CMP 1.1-Entity-Beans unterstützen keine Select-Methoden, da diese nur für CMP 2.x-Entity-Beans verfügbar sind. Daher wird bei der Umsetzung unabhängig vom Rückgabetyp und der Sichtbarkeit der <<query>>-Operation immer eine Finder-Methode in der fernen Home-Schnittstelle der Entity-Bean generiert.
Wie die folgende Tabelle zeigt, werden bei der Umsetzung mit einigen Änderungen immer Finder-Methoden in der fernen Home-Schnittstelle generiert:
Klasse |
Änderungen an der Methode |
Ferne Home-Schnittstelle |
|
Name der UML-Operation |
Name der Finder-Methode |
xxx |
findXxx |
findXxx |
findXxx |
FindXxx |
findXxx |
Analysierter Rückgabetyp der Java-Umsetzung |
Rückgabetyp der Finder-Methode |
Zugeordnete Sammlung (z. B. Collection, List, Set etc.) |
java.util.Collection |
<Quellenklassenname>[] |
java.util.Collection |
<Quellenklassenname> ODER void |
Name der fernen Schnittstelle |
<Name des benutzerdefinierten Datentyps>[] |
java.util.Collection |
<Nicht-Quellenklassenname (z. B. String, Integer usw.)>[] |
java.util.Collection |
<Name des benutzerdefinierten Datentyps> |
Name der fernen Schnittstelle |
<Nicht-Quellenklassenname (z. B. String, Integer usw.)> |
Name der fernen Schnittstelle |
Bei der EJB-Umsetzung wird eine Task erstellt, die angibt, dass Sie manuell eine Abfrage zum Implementierungsdeskriptor für jede generierte Finder-Methode hinzufügen müssen.
<<query>>-Operationen - BMP
Bei der Umsetzung werden <<query>>-Operationen in der UML-Quellenklasse in einen einzigen Abfragemethodentyp umgesetzt: in Finder-Methoden. BMP-Entity-Beans aller Versionen unterstützen keine Select-Methoden, da diese nur für CMP 2.x-Entity-Beans verfügbar sind. Daher wird bei der Umsetzung unabhängig vom Rückgabetyp und der Sichtbarkeit der <<query>>-Operation in der Beanimplementierungsklasse immer eine Finder-Methode generiert. Bei der Umsetzung werden dann Finder-Methoden in den vorhandenen Schnittstellen der Entity-Bean generiert.
Wie die folgende Tabelle zeigt, werden bei der Umsetzung mit einigen Änderungen Finder-Methoden in den folgenden Klassen generiert:
Klasse |
Änderungen an der Methode |
Lokale Home-Schnittstelle |
|
Ferne Home-Schnittstelle (wenn ferne Schnittstellen vorhanden sind) |
|
Beanimplementierungsklasse |
|
Name der UML-Operation |
Name der Finder-Methode |
xxx |
findXxx |
findXxx |
findXxx |
FindXxx |
findXxx |
ejbFindXxx |
findEjbFindXxx |
EjbFindXxx |
findEjbFindXxx |
Name der UML-Operation |
Name der Finder-Methode |
xxx |
ejbFindXxx |
findXxx |
ejbFindXxx |
FindXxx |
ejbFindXxx |
ejbFindXxx |
ejbFindEjbFindXxx |
EjbFindXxx |
ejbFindEjbFindXxx |
Analysierter Rückgabetyp der Java-Umsetzung |
Rückgabetyp der Finder-Methode |
Zugeordnete Sammlung (z. B. Collection, List, Set etc.) |
java.util.Collection |
<Quellenklassenname>[] |
java.util.Collection |
<Quellenklassenname> ODER void |
|
<Name des benutzerdefinierten Datentyps>[] |
java.util.Collection |
<Nicht-Quellenklassenname (z. B. String, Integer usw.)>[] |
java.util.Collection |
<Name des benutzerdefinierten Datentyps> |
|
<Nicht-Quellenklassenname (z. B. String, Integer usw.)> |
|
Analysierter Rückgabetyp der Java-Umsetzung |
Rückgabetyp der Finder-Methode |
Zugeordnete Sammlung (z. B. Collection, List, Set etc.) |
java.util.Collection |
<Klassenname>[] |
java.util.Collection |
<Klassenname> ODER void |
Schlüsselklassenname |
Untergeordnete Klassen
Ignoriert.
Untergeordnete Schnittstellen
Ignoriert.
Bei der Umsetzung von UML in EJB wird eine Klasse mit dem Stereotyp <<service>> in eine containergesteuerte Session-Bean ohne Zustand (Stateless) oder in eine containergesteuerte Session-Bean mit Zustand (Stateful) umgesetzt. Der Name der Session-Bean ist derselbe wie der Name der UML-Quellenklasse. Bei der Umsetzung werden immer die folgenden Java-Klassen für Session-Beans generiert:
Bei der Umsetzung werden die folgenden Java-Klassen generiert, wenn Sie auf der Registerkarte Session auf Nur ferne Schnittstellen klicken:
Bei der Umsetzung werden die folgenden Java-Klassen generiert, wenn Sie auf der Registerkarte Session auf Nur lokale Schnittstellen klicken:
Bei der Umsetzung werden die folgenden Java-Klassen generiert, wenn Sie auf der Registerkarte Session auf Lokale und ferne Schnittstellen klicken:
Bei der Umsetzung werden alle Klassen in dem Paketordner generiert, der für das übergeordnete Paket der UML-Quellenklasse generiert wurde. Wenn Sie ein UML-Modell ohne Pakete erstellen, wird bei der Umsetzung ein Standardpaket mit dem Namen 'ejbs' erstellt.
Bei der Umsetzung wird die Beanklassendatei in der Quellenbaumstruktur des EJB-Zielprojekts generiert.
Bei der Umsetzung werden die vier Schnittstellendateien in der Quellenbaumstruktur des Clientprojekts des EJB-Zielprojekts generiert. Wenn kein Clientprojekt vorhanden ist, werden die Schnittstellendateien bei der Umsetzung im EJB-Zielprojekt generiert.
Bei der Umsetzung werden Daten, die die Session-Bean definieren, zum Implementierungsdeskriptor ("ejb-jar.xml") hinzugefügt.
Stereotypeigenschaft - hasState
Jede UML-Klasse mit einem Stereotyp <<service>> verfügt über eine Stereotypeigenschaft mit dem Namen "hasState". Wenn "hasState" den Wert "false" (falsch) hat, wird die betreffende UML-Klasse bei der Umsetzung als Session-Bean ohne Zustand (Stateless) generiert. Wenn der Wert von "hasState" umgekehrt "true" (wahr) ist, wird die UML-Klasse bei der Umsetzung als Session-Bean mit Zustand (Stateful) generiert.
Hinweis: Die Stereotypeigenschaft wirkt sich nur auf die UML-Klassen aus, die bei der Umsetzung als neue Session-Beans generiert werden.
Standardmäßig hat die Eigenschaft "hasState" den Wert "false". Dies entspricht den Standardeinstellungen im Assistenten für die Erstellung von Session-Beans.
Generalisierungsbeziehungen
Wenn die UML-Quellenklasse für die Session-Bean eine Generalisierungsbeziehung (wie z. B. eine Erweiterungsbeziehung) zu einer anderen UML-Klasse mit dem Stereotyp <<service>> aufweist und dieser Stereotyp denselben Eigenschaftswert "hasState" enthält, wird die Session-Bean, die die Klasse darstellt, die EJB-Superklasse für die zu generierende Session-Bean.
Realisierungsbeziehungen
Wenn die UML-Quellenklasse für die Session-Bean Realisierungsbeziehungen (zum Beispiel Implementierungsbeziehungen) zu Schnittstellenelementen aufweist, werden die Schnittstellen, die die Quellenschnittstellen darstellen, durch die vier Schnittstellen (fern, Home, lokal, lokales Home) implementiert.
Attribute
Bei der Umsetzung werden Attribute der UML-Quellenklasse in Java-Eigenschaften der Beanklasse umgesetzt. Weitere Informationen zur Umsetzung der Attribute finden Sie in der Dokumentation zur Umsetzung von UML in Java. Bei der Umsetzung wird die Benennung in Kleinschreibung durchgesetzt, indem das erste Zeichen des Eigenschaftsnamens in einen Kleinbuchstaben geändert wird, wenn es sich um einen gültigen Großbuchstaben handelt.
Wenn der Typ des Attributs zu einer anderen Enterprise-Bean gehört, wird bei der EJB-Umsetzung weder ein Feld noch eine Assoziation für die Session-Bean generiert. Stattdessen wird bei der Umsetzung eine Nachricht in die Protokolldatei geschrieben, die angibt, dass das Quellenattribut nicht umgesetzt wird.
Operationen
Bei der Umsetzung werden Operationen für die UML-Quellenklasse in Geschäftsmethoden der Session-Bean umgesetzt. Anfangs wird die Operation auf dieselbe Weise umgesetzt wie eine Operation für eine unmarkierte UML-Klasse. Bei der Umsetzung wird die Benennung in Kleinschreibung durchgesetzt, indem das erste Zeichen des Methodennamens in einen Kleinbuchstaben geändert wird, wenn es sich um einen gültigen Großbuchstaben handelt. Die umgesetzte Operation wird mit einigen Änderungen zu den Klassen hinzugefügt, die in der folgenden Tabelle aufgelistet sind.
Klasse |
Änderungen an der Methode |
Beanklasse |
Keine Änderung |
Lokale Schnittstelle |
Schnittstellenmethode |
Ferne Schnittstelle |
Schnittstellenmethode, löst "java.rmi.RemoteException" aus |
Bei der Umsetzung werden die folgenden Regeln angewendet, um den Operationsrückgabetyp auf der Basis der Operationsparameter festzulegen:
o Die Operation verfügt über Rückgabe- und Ausgabeparameter
o Die Operation verfügt über mehrere Ausgabeparameter
Untergeordnete Klassen
Ignoriert.
Untergeordnete Schnittstellen
Ignoriert.
Bei der Umsetzung von UML in EJB wird eine Klasse mit dem Stereotyp <<messageprocessor>> in eine nachrichtengesteuerte Bean umgesetzt. Der Name der Bean ist derselbe wie der Name der UML-Quellenklasse und sie enthält Standarddaten. Bei der Umsetzung werden folgende Java-Klassen generiert:
Bei der Umsetzung wird die Klasse in dem Paketordner generiert, der für das übergeordnete Paket der UML-Quellenklasse generiert wurde. Wenn Sie ein UML-Modell ohne Pakete erstellen, wird bei der Umsetzung ein Standardpaket mit dem Namen 'ejbs' erstellt.
Bei der Umsetzung wird die Beanklassendatei in der Quellenbaumstruktur des EJB-Zielprojekts generiert.
Bei der Umsetzung werden Daten, die die nachrichtengesteuerte JavaBean definieren, zum Implementierungsdeskriptor ("ejb-jar.xml") hinzugefügt.
Generalisierungsbeziehungen
Wenn die UML-Quellenklasse für die nachrichtengesteuerte Bean eine Generalisierungsbeziehung (wie z. B. eine Erweiterungsbeziehung) zu einer anderen UML-Klasse mit dem Stereotyp <<messageprocessor>> aufweist, wird die nachrichtengesteuerte Bean, die die Klasse darstellt, die EJB-Superklasse für die zu generierende Entity-Bean.
Realisierungsbeziehungen
Ignoriert.
Attribute
Bei der Umsetzung werden Attribute der UML-Quellenklasse in Java-Eigenschaften der Beanklasse umgesetzt. Weitere Informationen zur Umsetzung der Attribute finden Sie in der Dokumentation zur Umsetzung von UML in Java. Wenn der Typ des Attributs zu einer anderen Enterprise-Bean gehört, wird bei der EJB-Umsetzung weder ein Feld noch eine Assoziation für die Session-Bean generiert. Stattdessen wird bei der Umsetzung eine Nachricht in die Protokolldatei geschrieben, die angibt, dass das Quellenattribut nicht umgesetzt wird.
Operationen
Bei der Umsetzung werden Operationen für die UML-Quellenklasse in typische Java-Methoden umgesetzt, so als sei die nachrichtengesteuerte Bean eine Java-Klasse.
Untergeordnete Klassen
Ignoriert.
Untergeordnete Schnittstellen
Ignoriert.
Normalerweise werden bei der Umsetzung Assoziationen auf dieselbe Weise umgesetzt wie bei der Umsetzung von UML in Java: die Endpunktattribute werden in Java-Eigenschaften umgesetzt.
Wenn ein Endpunkt der Assoziation eine Klasse mit dem Stereotyp <<entity>>, <<service>> oder <<messageprocessor>> ist, wird dieser Endpunkt bei der Umsetzung nicht umgesetzt. Stattdessen wird bei der Umsetzung eine Nachricht in die Protokolldatei des Metadatenverzeichnisses geschrieben, die angibt, dass die Endpunkteigenschaft nicht umgesetzt wurde. Eine Ausnahme dazu gibt es, wenn die Assoziation zwischen zwei Klassen mit <<entity>>-Stereotypen besteht und beide Klassen als CMP 2.x-Beans erstellt werden. In einem solchen Fall wird die UML-Assoziation bei der Umsetzung in eine EJB 2.0-Beziehung umgesetzt, die auch als containergesteuerte Beziehung (Container-managed Relationship, CMR) bezeichnet wird. In der folgenden Tabelle werden die Zuordnungen zwischen Assoziationseigenschaften und EJB-Beziehungseigenschaften dargestellt:
Assoziationseigenschaft |
EJB-Beziehungseigenschaft |
End1 |
BeanA |
End2 |
BeanB |
End1-Name |
BeanB-CMR-Name |
End2-Name |
BeanA-CMR-Name |
Navigierbarkeit End1 |
Navigierbarkeit BeanB |
Navigierbarkeit End2 |
Navigierbarkeit BeanA |
|
|
|
|
Die folgende Abbildung zeigt zwei UML-Klassen mit <<entity>>-Stereotypen. Die Assoziation zwischen den Klassen wird in einer CMR generiert, wenn bei der Umsetzung beide Entity-Klassen als CMP 2.x-Entity-Beans generiert werden.
Nach der Umsetzung enthält der Implementierungsdeskriptor einen Eintrag, der die CMR zwischen AEntity und BEntity beschreibt. Wie die folgende Abbildung zeigt, kann der Implementierungsdeskriptor des Projekts die Assoziation zwischen den beiden CMP 2.x-Entity-Beans anzeigen:
In der folgenden Tabelle sehen Sie, wie die bei der Umsetzung Abhängigkeiten umgesetzt und EJB-Verweise für Klassen mit dem Stereotyp <<entity>>, <<service>> oder <<messageprocessor>> generiert werden.
UML-Abhängigkeitsquelle |
UML-Abhängigkeitsziel |
EJB-Ziel |
<<entity>>-Klasse |
<<entity>>-Klasse |
EJB-Verweis |
<<entity>>-Klasse |
<<service>>-Klasse |
EJB-Verweis |
<<messageprocessor>>-Klasse |
<<entity>>-Klasse |
EJB-Verweis |
<<messageprocessor>>-Klasse |
<<service>>-Klasse |
EJB-Verweis |
<<service>>-Klasse |
<<entity>>-Klasse |
EJB-Verweis |
<<service>>-Klasse |
<<service>>-Klasse |
EJB-Verweis |
Wenn ein J2EE-Zielprojekt (Java 2 Platform, Enterprise Edition) mindestens eine Bean mit demselben Namen und Namensbereich wie eine UML-Klasse in der Umsetzung enthält, kann es zu einem Szenario einer erneuten Anwendung kommen. Ein Szenario einer erneuten Anwendung bezieht sich auf den Fall, wenn der Typ der bestehenden Enterprise-Bean mit dem Typ der Enterprise-Bean übereinstimmt, die für die entsprechende Klasse im UML-Modell generiert werden soll.
Wenn der Typ der zu generierenden Enterprise-Bean nicht mit dem Typ der bestehenden Enterprise-Bean kompatibel ist, kommt es zu einem Kollisionsszenario. Bei einem Kollisionsszenario wird bei der Umsetzung von UML in EJB weder die bestehende Bean aktualisiert noch wird eine neue Enterprise-Bean generiert.
In der folgenden Tabelle wird die erwartete Antwort der Umsetzung auf mögliche Szenarios einer erneuten Anwendung für CMP 2.x-Entity-Beans aufgelistet:
Zu generierende Enterprise-Bean |
Bestehende Enterprise-Bean |
Erwartetes Szenario |
Umsetzungsantwort |
CMP 2.x |
CMP 2.x |
Erneute Anwendung |
CMP-Felder und -Methoden aktualisieren |
CMP 2.x |
CMP 1.1 |
Erneute Anwendung |
CMP-Felder und -Methoden aktualisieren, als ob es sich um ein reguläres CMP 1.1-CMP 1.1-Szenario einer erneuten Anwendung handeln würde |
CMP 2.x |
BMP |
Erneute Anwendung |
BMP-Felder und -Methoden aktualisieren, als ob es sich um ein reguläres BMP-BMP-Szenario einer erneuten Anwendung handeln würde |
CMP 2.x |
Session (mit oder ohne Zustand) |
Kollision |
Die Session-Bean unverändert lassen |
CMP 2.x |
Nachrichtengesteuert |
Kollision |
Die nachrichtengesteuerte Bean unverändert lassen |
In der folgenden Tabelle wird die erwartete Antwort der Umsetzung auf mögliche Szenarios einer erneuten Anwendung für CMP 1.1-Entity-Beans aufgelistet:
Zu generierende Enterprise-Bean |
Bestehende Enterprise-Bean |
Erwartetes Szenario |
Umsetzungsantwort |
CMP 1.1 |
CMP 2.x |
Erneute Anwendung |
CMP-Felder und -Methoden aktualisieren, als ob es sich um ein reguläres CMP 2.x-CMP 2.x-Szenario einer erneuten Anwendung handeln würde |
CMP 1.1 |
CMP 1.1 |
Erneute Anwendung |
CMP-Felder und -Methoden aktualisieren |
CMP 1.1 |
BMP |
Erneute Anwendung |
BMP-Felder, -Methoden und -Assoziationen aktualisieren, als ob es sich um ein reguläres BMP-BMP-Szenario einer erneuten Anwendung handeln würde |
CMP 1.1 |
Session (mit oder ohne Zustand) |
Kollision |
Die Session-Bean unverändert lassen |
CMP 1.1 |
Nachrichtengesteuert |
Kollision |
Die nachrichtengesteuerte Bean unverändert lassen |
In der folgenden Tabelle wird die erwartete Antwort der Umsetzung auf mögliche Szenarios einer erneuten Anwendung für BMP-Entity-Beans aufgelistet:
Zu generierende Enterprise-Bean |
Bestehende Enterprise-Bean |
Erwartetes Szenario |
Umsetzungsantwort |
BMP |
CMP 2.x |
Erneute Anwendung |
CMP-Felder und -Methoden aktualisieren, als ob es sich um ein reguläres CMP 2.x-CMP 2.x-Szenario einer erneuten Anwendung handeln würde |
BMP |
CMP 1.1 |
Erneute Anwendung |
CMP-Felder und -Methoden aktualisieren, als ob es sich um ein reguläres CMP 1.1-CMP 1.1-Szenario einer erneuten Anwendung handeln würde |
BMP |
BMP |
Erneute Anwendung |
BMP-Felder und -Methoden aktualisieren |
BMP |
Session (mit oder ohne Zustand) |
Kollision |
Die Session-Bean unverändert lassen |
BMP |
Nachrichtengesteuert |
Kollision |
Die nachrichtengesteuerte Bean unverändert lassen |
In der folgenden Tabelle wird die erwartete Antwort der Umsetzung auf mögliche Szenarios einer erneuten Anwendung für Session-Beans aufgelistet:
Zu generierende Enterprise-Bean |
Bestehende Enterprise-Bean |
Erwartetes Szenario |
Umsetzungsantwort |
Session (mit oder ohne Zustand) |
CMP 2.x |
Kollision |
Die CMP 2.x-Bean unverändert lassen |
Session (mit oder ohne Zustand) |
CMP 1.1 |
Kollision |
Die CMP 1.1-Bean unverändert lassen |
Session (mit oder ohne Zustand) |
BMP |
|
Die BMP-Bean unverändert lassen |
Session (mit Zustand) |
Session (nur mit Zustand) |
Erneute Anwendung |
Die Felder und Methoden der Session-Bean aktualisieren |
Session (mit Zustand) |
Session (nur ohne Zustand) |
Kollision |
Die Session-Bean ohne Zustand unverändert lassen |
Session (ohne Zustand) |
Session (nur mit Zustand) |
Kollision |
Die Session-Bean mit Zustand unverändert lassen |
Session (ohne Zustand) |
Session (nur ohne Zustand) |
Erneute Anwendung |
Die Felder und Methoden der Session-Bean aktualisieren |
Session (mit oder ohne Zustand) |
Nachrichtengesteuert |
Kollision |
Die nachrichtengesteuerte Bean unverändert lassen |
In der folgenden Tabelle wird die erwartete Antwort der Umsetzung auf mögliche Szenarios einer erneuten Anwendung für nachrichtengesteuerte Beans aufgelistet:
Zu generierende Enterprise-Bean |
Bestehende Enterprise-Bean |
Erwartetes Szenario |
Umsetzungsantwort |
Nachrichtengesteuert |
CMP 2.x |
Kollision |
Die nachrichtengesteuerte Bean unverändert lassen |
Nachrichtengesteuert |
CMP 1.1 |
Kollision |
Die nachrichtengesteuerte Bean unverändert lassen |
Nachrichtengesteuert |
BMP |
Kollision |
Die nachrichtengesteuerte Bean unverändert lassen |
Nachrichtengesteuert |
Session (mit oder ohne Zustand) |
Kollision |
Die nachrichtengesteuerte Bean unverändert lassen |
Nachrichtengesteuert |
Nachrichtengesteuert |
Erneute Anwendung |
Die Felder und Methoden der nachrichtengesteuerten Bean aktualisieren |
In der folgenden Tabelle wird die erwartete Antwort der Umsetzung auf mögliche Szenarios einer erneuten Anwendung für unmarkierte UML-Klassen aufgelistet:
Stereotyp in UML-Klasse |
Bestehende Enterprise-Bean |
Erwartetes Szenario |
Umsetzungsantwort |
Unmarkiert |
CMP 2.x |
Erneute Anwendung |
Die Felder und Methoden der CMP 2.x-Entity-Bean in der bestehenden fernen Schnittstelle aktualisieren |
Unmarkiert |
CMP 1.1 |
Erneute Anwendung |
Die Felder und Methoden der CMP 1.1-Entity-Bean in der bestehenden fernen Schnittstelle aktualisieren |
Unmarkiert |
BMP |
Erneute Anwendung |
Die Felder und Methoden der BMP-Entity-Bean in der bestehenden fernen Schnittstelle aktualisieren |
Unmarkiert |
Session (mit oder ohne Zustand) |
Erneute Anwendung |
Die Felder und Methoden der Session in der bestehenden fernen Schnittstelle aktualisieren |
Unmarkiert |
Nachrichtengesteuert |
Erneute Anwendung |
Eine typische Java-Klasse generieren |
In den Szenarios einer erneuten Anwendung für unmarkierte UML-Klassen können die Codeaktualisierungen für die ferne Schnittstelle der bestehenden Enterprise-Bean Erstellungsfehler im EJB-Projekt verursachen. Diese Erstellungsfehler treten auf, weil der aktualisierte Code in der fernen Schnittstelle nicht den EJB-Spezifikationen für ferne Schnittstellen entspricht. Wenn Sie die gesamte Enterprise-Bean überschreiben wollen, müssen Sie die bestehende Enterprise-Bean entfernen, bevor Sie die EJB-Umsetzung ausführen.
In diesem Abschnitt wird die Antwort der Umsetzung auf ein Szenario einer erneuten Anwendung detaillierter erläutert. Darüber hinaus werden weitere Informationen darüber angegeben, was von der Umsetzung nach der erneuten Anwendung erwartet werden kann.
Wenn ein Szenario einer erneuten Anwendung für eine CMP 2.x-Entity-Bean auftritt, kann es zu folgenden Änderungen kommen:
Folgende Änderungen sollten nicht auftreten:
Wenn ein Szenario einer erneuten Anwendung für eine CMP 1.1-Entity-Bean auftritt, kann es zu folgenden Änderungen kommen:
Folgende Änderungen sollten nicht auftreten:
Wenn ein Szenario einer erneuten Anwendung für eine BMP-Entity-Bean auftritt, kann es zu folgenden Änderungen kommen:
Folgende Änderungen sollten nicht auftreten:
Wenn ein Szenario einer erneuten Anwendung für eine Session-Bean auftritt, kann es zu folgenden Änderungen kommen:
Folgende Änderungen sollten nicht auftreten:
Wenn ein Szenario einer erneuten Anwendung für eine nachrichtengesteuerte Bean auftritt, kann es zu folgenden Änderungen kommen:
Folgende Änderungen sollten nicht auftreten:
Die folgende Tabelle zeigt, wie bei der Umsetzung von UML in EJB Beziehungen verarbeitet werden:
UML-Quellenelement |
Visualisiertes Zielelement |
Beziehungstyp |
Umsetzungsergebnis |
Klasse mit Stereotyp <<entity>> oder <<service>> |
Java-Schnittstelle (UML-Schnittstelle) |
Implementierung |
Generierte Enterprise-Bean implementiert die visualisierte Schnittstelle |
Klasse mit Stereotyp <<entity>> oder <<service>> |
Java-Schnittstelle (UML-Schnittstelle) |
Realisierung |
Generierte Enterprise-Bean implementiert die visualisierte Schnittstelle |
Klasse mit Stereotyp <<entity>> |
Visualisierte Entity-Bean (UML-Komponente) |
Assoziation |
CMR-Beziehung |
Klasse mit Stereotyp <<entity>>, <<service>> oder <<messageprocessor>> |
Visualisierte Entity-Bean oder Session-Bean (UML-Komponente) |
Abhängigkeit |
EJB-Verweis |
Die Umsetzung von UML in EJB unterstützt die Integration in die Teamfunktionalität. Wenn Sie eine Umsetzung mit einem Zielprojekt in einer Umgebung mit Quellcodeverwaltung ausführen, fordert das System Sie auf, neue Dateien zur Quellcodeverwaltung hinzuzufügen und vorhandene Dateien auszuchecken.
Die Umsetzung von UML in EJB unterstützt Zuordnungen ähnlich wie die Umsetzung von UML in Java. Informationen über die Konfiguration und Verwendung eines Zuordnungsmodells bei der Durchführung einer Umsetzung finden Sie in der Dokumentation zur Umsetzung von UML in Java.
Wenn Quellenklassen für die Umsetzung in Enterprise-Beans markiert sind, wird bei der Umsetzung der zugeordnete Name der Quellenklasse als Beanname für die generierte Enterprise-Bean verwendet.
Wenn das Feature Beziehungen von Quelle zu Ziel erstellen aktiviert ist, werden bei der Umsetzung Tags zu der API-Dokumentation der generierten Java-Klassen und -Schnittstellen hinzugefügt. Diese Tags enthalten Informationen, mit denen Tools einen Trace der generierten Dateien in den ursprünglichen UML-Quellenelementen durchführen können.
Bei generierten Enterprise-Beans zeigen die Tags für die Quelle-zu-Ziel-API-Dokumentation aller Java-Dateien, die bei der Umsetzung für eine Enterprise-Bean generiert werden, auf eine einzige UML-Quellenklasse.
Rechtliche Hinweise
| Feedback
(C) Copyright IBM Corporation 2004, 2005. Alle Rechte vorbehalten.