Diskussionsbeitrag zum use-case-Diagramm für das RTK-Projekt,
sowie zu dessen Verfeinerung
 

Uli Sacklowski, 13.02.02


Gliederung

1. Prämissen
2. Strukturierung nach Schichten und Komplexität
3. Paketbildung
4. Aufzählung der Anwendungsfälle
5. Beispiele
 

1. Prämissen

1. Anwendungsfälle (AF) sollten so weit heruntergebrochen werden, daß Überschneidungen zwischen unseren groben Anwendungsfällen (Topogr., Diffr./Refl., Steuerung der Motoren, ...) sichtbar werden,  -> gute Voraussetzung für eine Arbeitsteilung/-abstimmung
2. Paketbildung wird empfohlen
3. Anwendungsfälle werden (aus physikalisch-fachlicher Sicht) strukturiert nach:
    a)  Schichten
    b)  Komplexität

2. Strukturierung nach Schichten und Komplexität

a) Äußere Schicht, - spezifische AF, die über die Benutzeroberfläche verfügbar sind.

Reihenfolge mit teilweise abfallender Komplexität.

   - AF mit komplexen Steuerabläufen  (z.B. Topogr., ... )
   - AF mit einfachen Steuerabläufen  (z.B. Motor-Kalibrierung)
   - AF ohne Steuerung  (z.B. Help)

b) Mittlere Schicht, - allgemeine AF, werden mehrfach von der äußeren Schicht benutzt (<<uses>>)

 Reihenfolge mit abfallender Komplezität

   - komplexe (realisiert über Makros)  (z.B. Anfahren Arbeitspunkt)
   - einfache  (realisiert über Makro-Befehle)  (z.B. Fahren zum Peak)

c) Unterste Schicht, - auf der Hardware aufsetzende AF

   - physikalisch:  Akteure :  Motor | Detektor
   - simulativ :  Motor | Detektor

3. Paketbildung

a) Für alle Teilkomplexe ist eine Paketbildung möglich (sinnvoll).
b) Falls keine Pakete, so sind die AF so zu gruppieren, daß sie paketähnlich erscheinen.

Anm.: Bei Paketbildung können Redundanzen in den AF auftreten, was aber wohl kein Problem ist.
 

4. Aufzählung der Anwendungsfälle (AF)

a) Spezifische AF

    - AF mit komplexen Steuerabläufen
        -- Topographie
        -- Diffr. / Refl. - Steuerung
        -- Manuelle Justage ???
        -- Automatische Justage
        -- individuelle Steuerabläufe  abarbeiten (Makros abarbeiten)

    - AF mit einfachen Steuerabläufen
        -- Motorsteuerung
                -- Kalibrierung
                -- Referenzpunktlauf
                -- Parametereinstellung (mit Endschalter)
                -- Verfahren nach Encoderschritten
                -- Optimieren
        -- Detektorsteuerung
                -- Zählerfenster (?)
                -- ...

    - AF ohne Steuerung
        -- Diff./Refl. - Ausgabe der Meßwerte (?)
        -- Diffr./Refl. - Verarbeitung der Meßwerte (Transformationen)
        -- Allgemeine Einstellungen
        -- Help
        -- individuelle Steuerabläufe  vereinbaren (Makros vereinbaren)

b) Allgemeine AF

    - komplexe (bereits realisiert über neun (?) Makros in den .mak-Files)
        -- HWB messen  (InquireHwb)
        -- Peak-Suche  (SearchReflection)
        -- Einstellen des Arbeitspunktes  (SetupTopography)
        -- ...

    - einfache  (bereits realisiert über neun (?) Makro-Befehle)
        -- Motor zu vorgegebener Position vorfahren  (MoveToPoint)
        -- Motor zu vorgegebenem Intensitätswert vorfahren  (GotoIntensity)
        -- Wahl einer Motorachse  (ChooseAxis)
        -- ...

c) Auf der Hardware aufsetzende AF

         -- physikalisch:  Akteure :  Motor | Detektor

         -- simulativ :  Motor | Detektor
 
 

5. Beispiele

a) Motor physikalisch/simuliert  (.pdf) (Detektor wäre entsprechend)
     Motor physikalisch/simuliert   (.fig)

b) use-case RTK: Gesamtübersicht   (.pdf)
     use-case RTK: Gesamtübersicht   (.fig)

c) Anwendungsfall Topographie als Paket   (.pdf) (Diff./Refl., ... entsprechend)
     Anwendungsfall Topographie als Paket    (.fig)
     Die Verbindungen sind nicht vollständig!!
     Problematisch ist die Vielzahl der Verbindungen!!  Wie können diese reduziert werden?  Z.B. zu der HW-nahen Schicht?