UML Anzahl der Instanzen einschränken

[Paule]

Hallo,

ich bin gerade dabei ein UML-Modell zu erstellen. Daraus entsteht dann mithilfe des EMF-Frameworks ein Editor.
Mir geht es hier eigentlich nur um eine Beziehung zwischen zwei Klassen und ob das überhaupt mit UML machbar ist.

Ein Bespiel: Ich habe drei Klassen -> State, Actor, Task. Dabei ist jedem State genau ein Task zugeordnet (Assoziation). Nun möchte ich aber, das die Anzahl der Tasks eingeschränkt wird, nämlich durch den Actor. Im Editor sollen nach Auswahl des Actors nur noch die Tasks eben dieses Actors zur Auswahl stehen.

Ich benutze Rational Rose, vielleicht kennt dort jemand eine Funktion, mit der man eine solche Einschränkung modellieren kann. Oder geht das gar nicht? Evtl. wäre OCL für solche Zwecke geeignet, aber werden die Constraints dann auch mit in den Editor übernommen? Als letzte Möglichkeit bleibt dann noch das abändern des generierten Editor-Codes.

Bin für jede Hilfe dankbar.

Gruß Paule!!!!

 

[Wildcard]

Redest du jetzt von der upper bound?
Stell's doch einfach direkt im EMF Ecore Editor ein ???:L

 

[maki]

Ist das was man im allgemeinen "kardinalität" nennt?

EDIT: So'n Quatsch, hier geht's um instanzen einer Klasse... einfach ignorieren..

 

[Wildcard]

Ist das was man im allgemeinen "kardinalität" nennt?

Genau das frage ich mich auch. Zumal es generell keine Möglichkeiten die Anzahl der möglichen Instanzen zu beschränken.

 

[Paule]

@wildcard Wie stelle ich das denn ganz einfach im Ecore Editor ein? Wenn Du jetzt nur den upper bound meinst, die Einstellungsmöglichkeit habe ich gefunden aber das ist glaube ich nicht das, wonach ich suche.

Hmm, vielleicht hab ich's auch schlecht erklärt. Also: Wieder die Klassen wie oben beschrieben. Jeder Actor führt gewisse Tasks aus. Jeder State ist einem Task zugeordnet. Wenn der Anwender später im EMF-Editor einen neuen State erstellt, soll er zuerst einen Actor wählen. Je nachdem, welchen Actor der Anwender ausgewählt hat, sollen in einer weiteren Auswahlliste nur die Tasks auswählbar sein, die von dem gewählten Actor ausgeführt werden.

Genau diesen Sachverhalt versuche ich zu modellieren, allerdings fällt mir keine wirklich gute Lösung ein bzw ich weiß nicht, ob es überhaupt möglich ist.

 

[Wildcard]

Im Editor kannst du die Kardinalität einer eReference/eAttribute einstellen. Aber darum scheint es dir ja nicht zu gehen.
Wie gesagt: es gibt in Java keine (sichere) Möglichkeit eine Obergrenze an Instanzen festzulegen.

 

[Paule]

Da war ich beim editieren meines vorherigen Posts wohl zu langsam

Evtl wird es damit etwas klarer ...

 

[byte]

Für mich klingt das auch nach Kardinalitäten.

Wie gesagt: es gibt in Java keine (sichere) Möglichkeit eine Obergrenze an Instanzen festzulegen.

Du kannst doch durchaus ähnlich wie beim Singleton nur eine bestimmte Anzahl von Objekterzeugungen zulassen.

 

[Wildcard]

Du kannst doch durchaus ähnlich wie beim Singleton nur eine bestimmte Anzahl von Objekterzeugungen zulassen.

Und wie implementierst du in Java ein Singelton das nicht umgangen werden kann?

 

[byte]

Naja, wenns danach geht, kannst Du in Java die gesamte OOP in die Tonne treten, denn mit Reflection kannst Du ja alles aushebeln. Oder worauf wolltest Du hinaus?

 

[Wildcard]

Was heißt in die Tonne treten? Es geht dem OP laut seiner Aussage darum die maximale Anzahl an Instanzen zu beschränken und das ist nicht (zuverlässig) möglich.

 

[ms]

Ich glaube es macht in diesem Fall gar keinen Sinn dies zu modellieren da die Kardinalität abhängig von Daten ist und nicht durch das Modell selbst festgelegt wird.

ms

 

[byte]

Es geht dem OP laut seiner Aussage darum die maximale Anzahl an Instanzen zu beschränken und das ist nicht (zuverlässig) möglich.

Ein Beispiel:

public class Foobar {
  private static final Foobar instance1 = new Foobar();
  private static final Foobar instance2 = new Foobar();

  private Foobar() {}

  public static Foobar getInstance1() {
    return instance1;
  }

  public static Foobar getInstance2() {
    return instance2;
  }
}

Was ist daran nicht zuverlässig? Der einzige Knackpunkt ist doch Reflection. Aber dann kannst Du z.B. auch sagen: In Java kann man nicht (zuverlässig) die Sichtbarkeit von Membern/ Methoden einschränken.

 

[Wildcard]

Was ist daran nicht zuverlässig? Der einzige Knackpunkt ist doch Reflection. Aber dann kannst Du z.B. auch sagen: In Java kann man nicht (zuverlässig) die Sichtbarkeit von Membern/ Methoden einschränken.

XMLEncoder, Serialisierung, clone,...

 

[SnooP]

und dann? Wenn man irgendwas machen will, dann kann man es auch machen? Irgendein Klassendesign heißt nie, dass man es nicht auch umgehen könnte, aber dafür ist es ja auch nicht da... ich geh ja nicht an eine Aufgabe ran und überlege mir dann, wenn ich bestimmte Sachen nicht auf dem normalen Weg hinbekomme, dass ich mal eben per Reflection oder copy-by-serialization das ganze löse - und wer das macht bzw. sich Gedanken darüber macht, dass man da ja machen könnte, der braucht sich dann auch nicht weiter über UML Gedanken zu machen *g*

 

[Wildcard]

Mein Hauptproblem mit der Anforderung ist folgendes:
Mir fällt nicht der geringste Grund ein wo es sinnvoll sein könnte ein Klasse global auf maximal n-Instanzen festzulegen.
Lediglich der Spezialfall Singelton greift in einigen wenigen Anwendungsfällen.

 

[byte]

XMLEncoder, Serialisierung, clone,...

Meine Beispielklasse implementiert weder Serializable noch Cloneable. Und XMLEncoder funktioniert nur mit Serializables.

... wer das macht bzw. sich Gedanken darüber macht, dass man da ja machen könnte, der braucht sich dann auch nicht weiter über UML Gedanken zu machen *g*

Eben! Wenns danach geht, kannst Du alle Factories, Sichtbarkeiten von Membern, Methoden, ... in die Tonne treten.

Umgehen kannst Du vieles. Aber eben nicht mit den standardmäßigen Mitteln der OOP. Und es geht doch hier gerade um einen objektorientierten Entwurf mit UML.

 

[Wildcard]

XMLEncoder, Serialisierung, clone,...

Und XMLEncoder funktioniert nur mit Serializables.

Nö.

public class NotSerializable
{
    private String foo;

    
    public NotSerializable(){
        
    }
    
    public NotSerializable(String foobar){
        foo = foobar;
    }

    public String getFoo()
    {
        return foo;
    }


    public void setFoo(String foo)
    {
        this.foo = foo;
    }


    public static void main(String[] args)
    {
        XMLEncoder enc;
        try
        {
            enc = new XMLEncoder(new FileOutputStream(new File("bar.xml")));
            enc.writeObject(new NotSerializable("bar"));
            enc.close();
            
            XMLDecoder dec = new XMLDecoder(new FileInputStream(new File("bar.xml")));
            NotSerializable o = (NotSerializable)dec.readObject();
            System.out.println(o.getFoo());
        }
        catch (FileNotFoundException e)
        {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }
    }
}

 

[Paule]

Vergesst doch bitte mal die Kardinalitäten Ich möchte NICHT im Modell festlegen, dass es nur x Instanzen einer Klasse geben darf.
Ich denke ms hat die Problematik verstanden. Ok vielleicht war der Titel dieses Threads etwas schlecht gewählt aber mir geht es vielmehr um die Abhängigkeit eines Objektes von einem anderen.
OK, ich versuchs nochmal, diesmal etwas schematischer:

vorhandene Klassen: Actor, TaskModel, Task, State
Beziehnungen (wie ich sie bis jetzt habe):
Actor ->(Assoziation) TaskModel
TaskModel ->(Aggregation) Task
State ->(Assoziation) Task

Wenn ich durch das EMF Framework nun für dieses Modell den Code generieren lasse, dann habe ich bei der Erstellung eines States im Editor alle Tasks, d.h. die Tasks jedes Actors zur Auswahl. Ich möchte die Auswahlmöglichkeit nun dahingehend einschränken, dass man zuerst einen Actor wählt und dann nur noch die Tasks des gewählten Actors zur Auswahl hat.
D.h., falls überhaupt möglich, müsste ich den Actor noch in die Beziehung des States mit dem Task einbringen. Genau an dieser Stelle weiß ich nicht, wie ich das anstellen soll.

 

[Wildcard]

Warum gibst du Actor nicht eine eReference auf Task und setzt das Containment Feature auf true?