Umsetzung UML in EJB

 

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.

 

Umsetzungsdetails

 

Umsetzungsquelle

Umsetzungsziel

EJB-Zielcontainer

EJB-Umsetzungsprofil

Konfigurationsregisterkarten für die Umsetzung von UML in EJB

Registerkarte 'Ziel'

Registerkarte 'Entity'

Registerkarte 'Session'

Registerkarte 'Erweitert'

Interpretation von Quellenobjekten

Primitive Typen

Pakete

Unmarkierte Klassen

Unmarkierte Schnittstellen

Unmarkierte Aufzählung

<<entity>>-Klassen

<<service>>-Klassen

<<messageprocessor>>-Klassen

Assoziationen

EJB-Verweise

Szenarios erneuter Anwendung

Unterstützung für Verarbeitungsbeziehungen zwischen UML-Elementen und visualisierten Enterprise-Beans oder Java-Klassen

Unterstützung für einheitliche Umsetzungstechnologien

Integration in eine Teamfunktionalität

Umsetzungszuordnung

Quelle-Ziel-Beziehungen

 

 

Umsetzungsquelle

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.

 

Umsetzungsziel

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.

 

EJB-Zielcontainer

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

  • CMP 2.x-Beans können nicht generiert werden.
  • CMP 1.1-Beans dürfen nur mit fernen Schnittstellen generiert werden.
  • BMP-Beans (Bean-managed Persistence) dürfen nur mit fernen Schnittstellen generiert werden.
  • Session-Beans dürfen nur mit fernen Schnittstellen generiert werden.
  • Nachrichtengesteuerte Beans können nicht generiert werden.

 

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.

 

EJB-Umsetzungsprofil

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.

 

Konfigurationsregisterkarten für die Umsetzung von UML in EJB

 

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.

 

Registerkarte 'Ziel'

 

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.

 

Registerkarte 'Entity'

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.

 

Registerkarte 'Session'

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.

 

Registerkarte 'Erweitert'

Weitere Informationen zur Registerkarte Erweitert finden Sie in der Dokumentation zur Umsetzung von UML in Java.

 

Interpretation von Quellenobjekten

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.

Primitive Typen

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.

 

Pakete

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.

 

Unmarkierte Klassen

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.

Unmarkierte Schnittstellen

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.

Unmarkierte Aufzählung

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.

 

<<entity>>-Klassen

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.

 

CMP- und BMP-Feldtypzuordnung

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 von 'findXxx' (Siehe Tabelle Finder-Name.)
  • Löst "javax.ejb.FinderException" aus.
  • Löst "java.rmi.RemoteException" aus

 

Finder-Name

 

Name der UML-Operation

Name der Finder-Methode

xxx

findXxx

findXxx

findXxx

FindXxx

findXxx

 

Finder-Rückgabetyp der Home-Schnittstelle

 

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 lokalen Schnittstelle
  • 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>

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:

 

Select-Name

 

Name der UML-Operation

Name der Select-Methode

xxx

ejbSelectXxx

selectXxx

ejbSelectXxx

SelectXxx

ejbSelectXxx

ejbSelectXxx

ejbSelectXxx

 

Select-Rückgabetyp

 

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

 

Finder-Name der fernen Home-Schnittstelle

 

Name der UML-Operation

Name der Finder-Methode

xxx

findXxx

findXxx

findXxx

FindXxx

findXxx

 

Finder-Rückgabetyp der fernen Home-Schnittstelle

 

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
(wenn lokale Schnittstellen vorhanden sind)

Ferne Home-Schnittstelle

(wenn ferne Schnittstellen vorhanden sind)

Beanimplementierungsklasse

 

Finder-Name der Home-Schnittstelle

 

Name der UML-Operation

Name der Finder-Methode

xxx

findXxx

findXxx

findXxx

FindXxx

findXxx

ejbFindXxx

findEjbFindXxx

EjbFindXxx

findEjbFindXxx

 

Finder-Name der Beanklasse

 

Name der UML-Operation

Name der Finder-Methode

xxx

ejbFindXxx

findXxx

ejbFindXxx

FindXxx

ejbFindXxx

ejbFindXxx

ejbFindEjbFindXxx

EjbFindXxx

ejbFindEjbFindXxx

 

Finder-Rückgabetyp der Home-Schnittstelle

 

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 lokalen Schnittstelle
  • 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 lokalen Schnittstelle
  • Name der fernen Schnittstelle

<Nicht-Quellenklassenname (z. B. String, Integer usw.)>

  • Name der lokalen Schnittstelle
  • Name der fernen Schnittstelle

 

Finder-Rückgabetyp der Beanklasse

 

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.

 

<<service>>-Klassen

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:

 

Untergeordnete Klassen

Ignoriert.

 

Untergeordnete Schnittstellen

Ignoriert.

 

<<messageprocessor>>-Klassen

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.

 

Assoziationen

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

  • End1 Oberwert = 1
  • End1 Oberwert = -1
  • BeanB Multiplizität = 1
  • BeanB Multiplizität = -1, BeanA-CMR-Type = java.lang.Collection
  • End2 Oberwert = 1
  • End2 Oberwert = -1
  • BeanA Multiplizität = 1
  • BeanA Multiplizität = -1, BeanB-CMR-Typ = java.lang.Collection

 

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:

 

 

 

 

 

EJB-Verweise

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

 

 

 

 

Szenarios erneuter Anwendung

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.

 

Detaillierte Erläuterung der Umsetzungsantwort

 

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.

 

CMP 2.x-Entity-Beans

 

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:

 

CMP 1.1-Entity-Beans

 

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:

 

 

BMP-Entity-Beans

 

Wenn ein Szenario einer erneuten Anwendung für eine BMP-Entity-Bean auftritt, kann es zu folgenden Änderungen kommen:

 

Folgende Änderungen sollten nicht auftreten:

 

Session-Beans ohne und mit Zustandsaufzeichnung

 

Wenn ein Szenario einer erneuten Anwendung für eine Session-Bean auftritt, kann es zu folgenden Änderungen kommen:

 

Folgende Änderungen sollten nicht auftreten:

 

Nachrichtengesteuerte Beans

 

Wenn ein Szenario einer erneuten Anwendung für eine nachrichtengesteuerte Bean auftritt, kann es zu folgenden Änderungen kommen:

 

Folgende Änderungen sollten nicht auftreten:

 

Unterstützung für Verarbeitungsbeziehungen zwischen UML-Elementen und visualisierten Enterprise-Beans oder Java-Klassen

 

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

 

Unterstützung für einheitliche Umsetzungstechnologien

 

Integration in eine Teamfunktionalität

 

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.

Umsetzungszuordnung

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.

Quelle-Ziel-Beziehungen

 

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.