5 Multi-User-Betrieb


[Seminarübersicht]...[CASE-Tool Rational Rose]...[Rational Rose/C++]...[6 Zusätzliche Tools]

  1. Path-Map-Mechanismus
  2. Controlled Units
  3. Multi-User-Betrieb mit integrierten Konfigurationsmanagement-System
  4. Beispiel zur Vorgehensweise


  1. Path-Map Mechanismus

    Das Konzept der Pfadzuordnung (Path Map) über virtuelle Pfadsymbole ist für die Unterstützung von paralleler Entwicklung von Modellkomponenten eingeführt worden.

    Die Einstellung dieser virtueller Pfadsymbole erfolgt über das Menü File-Edit Path.

    Dabei wird einem virtuellen Pfadsymbol ein physisch vorhandener Pfad zugeordnet.

    Das virtuelle Pfadsymbol wird mit einem $-Zeichen eingeleitet.

    Die Erstellung von virtuellen Pfadnamen haben keinen Einfluß auf die Konvertierung von physischen Pfadnamen in der Eigenschaften "Code-Generation". Sind virtuelle Symbole in den Eigenschaften gewünscht, so muß das explizit angegeben werden.

    Beim folgenden Aktionen werden zunächst die virtuellen Pfadsymbole in ihre physischen Pfadnamen zurücktransformiert :

    • beim Öffnen, Laden, Importieren und Anzeigen von Quell-Code
    • beim Aktualisieren der Modell-Dateien
    • Nutzung in den Code-Generation-Properties
      (Achtung: Werden in den Code-Generation-Properties virtuelle Sysmbole verwendet, so funktioniert das Anzeigen der generierten Source-Code-Dateien nicht mehr richtig, da die Skripts browse*.ebx nicht korrekt arbeiten. Die modifizierten Skripts browse*sg.ebx von mir lösen das Problem für die Ansicht der C++-Source-Dateien.)

    Beim Starten von Rational Rose werden für die virtuellen Pfadsymbole die Einträge des Abschnittes [Vitual Path Map] der Datei rose.ini verwendet.

    Die Definition von virtuellen Pfadsysmbolen hat zur Folge, daß in der Modelldatei relative Dateinamen zum Pfadsysmbol gespeichert werden.

    • Beispiel

      Eine Modelldatei modell1.mdl wurde auf Laufwerk L im Verzeichnis projekt\usr1 gespeichert.

      In der Modelldatei wird der Dateiname L:\projekt\usr1\modell1.mdl gespeichert.

      Es werden nun folgende virtuellen Pfadsysmbole definiert :

      • $project=L:\projekt
      • $mywork=$projekt\usr1

    Diese Definition hat zur Folge, daß in der Modelldatei der Dateiname L:\projekt\usr1\modell1.mdl in $mywork\\modell1.mdl konvertiert.


  2. Controlled Units
    • Begriff „Controlled Unit"

      Bei dem Erstellen von Controlled Units werden die Pakete (packages) aus der Modelldatei in unterschiedliche Dateien ausgelagert.

      Die Änderungen der Controlled Units werden überwacht. So können die verschiedenen Entwickler an unterschiedlichen Controlled Units arbeiten.

      Außerdem lassen sich für die Controlled Units bestimmte Eigenschaften einstellen, z.B ob auf diese Komponenten nur lesend zugegriffen werden kann usw..

    • Wie werden Controlled Units erstellt ?

      Das Menü Browse-Units öffnet die entsprechende Dialog-Box, in der die Controlled Units erstellt werden.

      Man wählt das entsprechende Paket und betätigt die Schaltfläche „Controll".

      Wurde das Modell für die Unterstützung der Mehrbenutzerentwicklung unterteilt, so entstehen für die Speicherung der Modellkomponenten folgende Dateitypen :

      • der Modellkern wird mit dem Dateinamen der Endung mdl abgespeichert
      • Controlled Units von Paketen (logical packages) des "logical views" und der Anwendungsfälle, werden in Dateien mit der Dateiendung cat gespeichert.
      • Controlled Units von Paketen (component packages) des "component views" , werden in Dateien mit der Dateiendung sub gekennzeichnet.
      • Controlled Unit, die dem "deployment diagramm" des Modells entsprechen, sind mit Dateinamen mit der Dateiendung prc gekennzeichnet.
      • Die Dateien mir der Dateiendung prp kennzeichnen die Code Generation Eigenschaften des Models.

    Im Abschnitt Dateien wurde bereits erwähnt, daß ein Dateityp ptl für Blatt-Dateien existiert.

    In diesen Dateien werden einzelne oder mehrere Komponenten des Modells gespeichert.

    Im Prinzip stellen alle bisher genannten Dateitypen petal-files dar. Die oben genannten Dateitypen werden gewählt, um deutlich hervorzuheben, daß es sich um Controlled Units handelt.


  3. Multi-User-Betrieb mit integriertem Konfigurationsmanagement-System

    Vollständigkeithalber sei im folgenden nur kurz das Vorgehen für die Nutzung eines Versionskontrollsystems (VCS) beschrieben.

    Rational Rose bietet die Möglichkeit, ein "Configuration Management System" (CM) bei der Entwicklung von Controlled Units zu integrieren.

    Dafür muß jedoch zunächst die Menüdatei angepaßt werden.

    Eine enstprechende Arbeitsanweisung befindet sich im Unterverzeichnis CM des Programmverzeichnisses. Ist dieses erfolgreich durchgeführt worden, so wird die Schaltfläche „CM" aus der Dialog-Box der Controlled Units aktiviert.

    Außerdem liefert die Firma Rational Rose eine Batch-Datei cm.bat mit. Diese muß eventuell auf das vorhandene CM-System für die entsprechenden Kommandos angepaßt werden.


  4. Beispiel zur Vorgehensweise

    Das folgende Beispiel versucht, die Vorgehensweise bei der Erstellung eines Multi-User-Modells aus einem Single-User-Modell zu erläutern.

    Ein Sngle-User-Modell model1.mdl beinhaltetet 3 logische Pakete und 3 physikalische Pakete, die in einem 3-er Team entwickelt werden sollen.

    1. Definition von virtuellen Pfadsymbolen

      Zunächst wird vorgeschlagen folgende Verzeichnisstruktur aufzubauen:

      • ein lokales Projekt-Verzeichnis, in dem das Modell model1.mdl gespeichert wird
      • jeweils ein Unterverzeichnis für die Controlled Units der verschiedenen Sichten
        • CATS für logische Pakete (logical packages)
        • SUBS für physische Pakete (component packages)
        • PROP für die cg-Properties
      • ein Unterverzeichnis für den generierten Source-Code
        • CODE für den generierten Source-Code

      Anschließend werden den physischen Dateipfaden virtuelle Pfadymbole zugeordnet :

      • Projekt-Verzeichnis erhält das Pfadsymbole $projekt
      • Unterverzeichnis CATS erhält das Pfadsymbol $category
      • Unterverzeichnis SUBS erhält das Pfadsymbol $subsys
      • Unterverzeichnis PROP erhält das Pfadsymbol $prop
      • Unterverzeichnis CODE erhält das Pfadsymbol $code

      Wird das Modell model1.mdl nun gespeichert, so wird in dem Dateinamen das virtuelle Pfadsymbol $projekt verwendet.

      Die Verzeichnisstruktur sollte bei jedem Entwickler ähnlich sein. Wichtig ist allerdings nur, daß dieselben virtuellen Pfadsymbole definiert werden, da in der Modell-Datei die Referenzen verwendet werden.

    2. Erzeugen von Controlled Units

      Anschließend werden die Controlled Units in die entsprechenden Verzeichnissen erzeugt, wie in Abschnitt 2 bereits erläutert.

      Dabei wird in der Modelldatei model1.mdl nicht mehr das komplette Modell mit ihren Paketen gespeichert, sondern nur der Modellkern mit den Verweisen auf eine Dateien, die die Pakete beinhalten.

    3. Nutzung des CM-Systems

      Dieser Vorgang setzt voraus, daß die Erweiterung für die Nutzung eines CM-Systems bereits vorgenommen wurde.

      Anschließend werden alle Controlled Units in das CM-System mit dem Kommando "check-in" registriert.

    4. "Arbeitsteilung defineren"

      Arbeitsteilung definieren ist so zu verstehen, daß jedem Entwickler nun mitgeteilt wird, welches logische Paket von ihm zu bearbeiten ist.

      Anschließend führt jeder Entwickler das Kommando "accept changes" durch, um ein identsiches Modell in seine Arbeitsumgebung zu erhalten. Dieses Modell ist schreibgeschützt.

      Als nächstes führt jeder Entwickler das Kommando "check out" für das Paket durch, für das er bestimmt wurde. Der Entwickler kann dieses Paket nun entsprechend modifizieren.

      Die anderen Pakete bleiben schreibgeschützt und können somit nicht modifiziert werden.

      Nach Beendigung muß die geänderte Version des Paketes erneut in dem CM-System mit dem Kommando "check in" zu registrien.


    [Seminarübersicht]...[Seitenanfang]
    Autor: Sven Garske
    Last Updated on Friday, 19 December, 1997