Diese Seite wird aktuell überarbeitet.

Die Schnittstelle von Bausteinen in der TAA

Die Schnittstelle eines Bausteins beschreibt alle Eigenschaften des Bausteins, die anderen Modulen bekannt sein müssen, um ihn richtig aufrufen zu können. Dabei spielt es - von einigen Ausnahmen abgesehen - keine Rolle, ob es sich um ein Steuerungsmodul oder einen anderen Baustein (autonome Funktion, Interaktion, Report, Datenzugriff) handelt. Die Schnittstellendefinition ist für alle Modultypen gleich.

Die Schnittstelle enthält:

  • Allgemeine Angaben zu dem Modul, wie Name, Typ, Anwendungszugehörigkeit, Version.
  • Die Operationen, die in dem Modul behandelt werden und die von aufrufenden Modulen ausgelöst werden können.
    Für Geschäftsvorfall-Steuerungen (GEVO) können keine Operationen definiert werden, da sie den Anfang der Aufruf-Kette bilden. Die einzige Operation, das diese Steuerungsmodule kennen, ist „UDEF“ (= „undefiniert“); diese Operation wird in GeVo-Steuerungen automatisch angelegt.
  • Die Zustände, die vor Verlassen des Moduls gesetzt werden können. Die aufrufenden Module können diese Zustände abfragen und - z.B. auf Verarbeitungsfehler - entsprechend reagieren.
  • Die Parameter, die beim Aufruf des Moduls übergeben werden müssen, und die Art ihrer Verwendung: werden Daten nur referenziert, oder geändert, erstmals angelegt, oder gar gelöscht? 1)
  • Die globalen Objekte, die ein Steuerungsmodul benutzt, und die Art ihrer Verwendung.
  • Eine Darstellung der Aufrufbeziehungen zu anderen Modulen.
  • Angaben zu Workflow-Eigenschaften.

Da für alle Module diese Schnittstelle einmalig definiert wird, können Sie von ControlEdge oder anderen Werkzeugen leicht überprüfen lassen, ob die Module sich gegenseitig mit korrekten und sinnvollen Argumenten aufrufen. Mancher schwer nachvollziehbare Fehler kann so schon bei der Programmdefinition vermieden werden.

Bearbeitung der Schnittstelle in ControlEdge

Allgemeine Eigenschaften festlegen

Jedes Modul hat bestimmte Eigenschaften, zum Beispiel einen Namen und die Zugehörigkeit zu einer Anwendung.

In der Regel sind diese Eigenschaften bereits in der EDB definiert, auch wenn das Modul ansonsten noch leer ist. Ist dies nicht der Fall, müssen Sie sie spätestens beim Anlegen des Moduls festlegen. Viele davon können sie später jederzeit noch anpassen, nicht aber Name, Anwendung und Typ (s. unten).

  • Name zeigt den Namen des Moduls. Das Feld ist nicht editierbar: Der Name wird i.d.R. bereits in der EDB festgelegt; er kann danach nicht mehr verändert werden.
  • Typ gibt an, um welche Art von Modul es sich handelt.
  • Anwendung gibt an, zu welcher Anwendung das Modul gehört.
  • Letzte Änderung durch zeigt an, ann und durch wen das Modul zuletzt geändert wurde.
  • Geladen ist i.d.R. angekreuzt und sagt aus, dass die Informationen über das Modul aus der EDB geladen wurden.
  • Schreibgeschützt ist angekreuzt, wenn das Modul explizit mit Schreibschutz geöffnet wurde, oder für Sie generell nicht editierbar ist, z.B. weil Sie für das Projekt keine Schreibberechtigung besitzen.
  • Modifiziert ist angekreuzt, wenn Sie bereits Änderungen vorgenommen haben, die noch nicht übernommen2) bzw. gespeichert3) wurden.

Darunter stehen mehrere Reiter:

  • Kommentar: Im Titel des Kommentars machen Sie in einer Zeile zusätzliche Angaben zur Aufgabe und Funktion des Moduls. Im Kommentar selbst können Sie die Funktionalität des Moduls ausführlich beschreiben.
  • Historie: Bei Verwendung von Rochade wird hier die fachliche Änderungshistorie des Moduls angezeigt.
  • Verwendet von: Hier ist aufgelistet, welche anderen Module dieses Modul aufrufen.
  • Rochade: Hier werden weitere, in Rochade verfügbare Attribute zu dem Modul angezeigt.

Diverse Einstellungen

  • Automatisch verbinden mit:
  • erlaubte Nutzung:
    • in anderen Anwendunge: ist anzukreuzen, wenn es erlaubt sein soll, das das Modul von anderen Anwendungen aus aufgerufen wird.
    • als Einstiegsbaustein: ist anzukreuzen, wenn das möglich sein soll, das Modul als Folgesteuerung zu starten. Hierbei kann zusätzlich festgelegt werden, ob das Modul mit der zum Zeitpunkt des Starts aktuellen Anwendungsversion gestartet werden soll, oder mit der Version zum Zeitpunkt des Aufrufs.
    • darf Komponenten ohne Berücksichtigung der Aufrufstruktur verwenden: Dies sollte nur ausnahmsweise angekreuzt werden; es wird dann zur Laufzeit nicht überprüft, ob Module aufgerufen werden, die in der Aufrufstruktur nicht enthalten sind. 4)
    • Transaktioniert gemeinsam mit Workflow:

Implementierungsdetails

  • Domäne: Gibt an, welche Domäne für die Ermittlung der Ityp/Ispc-Angaben zu verwenden ist.
  • Implementierungstyp/Implementierungsspezifikation: Werden i.d.R. über das Konfigurationsmanagementsystem festgelegt.
  • Transaktionierung:

Änderung des Modultyps

Die Änderung des Modultyps ist nach Anlage eines Moduls im Schnittstellen-Dialog nicht mehr möglich. Nur durch Anpassung in Rochade kann der Modultyp nachträglich geändert werden.

Hinweise zur Modultyp-Änderung bei Geschäftsvorfall-Steuerungen Sie können eine GEVO in eine GVTL umwandeln, und umgekehrt. Bevor Sie aber eine GVTL in eine GEVO umwandeln, sollten Sie sehr genau prüfen, ob Sie dies wirklich möchten:

Bie der Umwandlung einer GeVo-Teilsteuerung in eine GeVo-Steuerung gehen alle Ereignisse - außer dem Ereignis „UDEF“ - sowie alle Parameterobjekte, die für die Teilsteuerung definiert waren, unwiederbringlich verloren, da eine GeVo-Steuerung weder Ereignisse noch Parameter haben kann.

Hinweis zur Modultyp-Änderung bei Funktionen, Datenzugriffen, Iterationen

Sie können generell GeVo-relevante Bausteine in elementare Bausteine umwandeln, und umgekehrt. Der wesentliche Unterschied ist die Aufrufbarkeit: Elementare Module können von Steuerungsmodulen und anderen Modulen aufgerufen werden, GeVo-relevante Module können nur von Steuerungsmodulen aufgerufen werden, da ihr Aufruf in der Steuerung sichtbar sein soll.

Auslösbare Operationen oder zurückgemeldete Zustände

Der Reiter Zustände ist für alle Modultypen verfügbar. Hier wird angezeigt, welche Zustände das Modul zurückmelden kann.

Der Reiter Operationen ist für alle Typen mit Ausnahme von Geschäftsvorfall-Steuerungen und Ntry-Modulen5) verfügbar. Hier wird angezeigt, welche Operationen zur Zeit in diesem Modul bekannt sind.

Sie können Ereignisse und Zustände hinzufügen, sie löschen, sowie Kommentar zu der Verwendung einer Operation oder eines Zustands in dem Modul eingeben.

Aufgerufene Module

Dieses Fenster für die Attributgruppe Aufrufbeziehungen zeigt an, welche Module von dem bearbeiteten Modul aufgerufen werden und ermöglicht, neue Aufrufbeziehungen anzulegen 6).

Welche Art von Modulen aufgerufen werden können, ist abhängig von der Art des gerade bearbeiteten Moduls und wird in einer Tabelle in der EDB festgelegt.

Die Liste gibt neben den Angaben zu dem aufgerufenen Modul in der Spalte „Aufrufart“ an, ob das Modul aufgerufen oder (als Folgesteuerung) gestartet wird, oder beides.

Sie können hier, sofern die Liste für das aktuelle Modul anpassbar ist, Modulaufrufe hinzufügen oder löschen. Außerdem können Sie Kommentar zu dem Zweck des Modulaufrufs eingeben.

Parameter-Objekte oder Globale Objekte

Im Reiter Schnittstellendaten wählen Sie aus, welche Parameter das Modul erwartet, wenn es für ein bestimmte Operation aufgerufen wird, auf welchem Objekttyp die jeweiligen Objekte basieren, und wie sie in dem Modul und für die verschiedenen Operationen verwendet werden („welche Rolle sie spielen“). 7)Die Reiter ist für die Hauptsteuerung einer Anwendung nicht verfügbar.

Der Reiter enthält

  • eine Combobox zur Auswahl der Operation; wenn ein Objekt in allen Operationen genutzt werden soll, kann es unter der Operation [Allgemein] definiert werden.
  • eine Liste mit definierten Objekten. Die Liste zeigt durch ein Symbol, ob es sich um ein Einzel- oder Listenobjekt handelt.
    In der Spalte „Global“ erscheint ein Symbol, wenn es sich um ein globales Objekt handelt.
    In der Spalte „Operationsspezifisch“ erscheint ein Symbol, wenn das Objekt für diese Operation eine von „Allgemein“ abweichende Rolle hat.

    Diese Liste enthält immer die Objekte zu der in der Combobox ausgewählten Operation, oder, wenn [Allgemein] ausgewählt ist, alle Objekte, die nicht operationsspezifisch sind.

Sie können hier Parameter- oder globale Objekte hinzufügen oder löschen, sowie Kommentar zu deren Nutzung eingeben.

Im unteren Bereich des Reiters sehen Sie, wenn ein Objekt ausgewählt ist, zusätzliche Informationen zu diesem Objekt, z.B. den Objekttyp, sowie einen Verweis auf die Datenstruktur.

Wirkung des Löschens eines Objekts

Wenn Sie ein Objekt für alle Operationen in dem Modul entfernen möchten, wählen Sie das „Allgemein“. Falls es Operationen gibt, die dieses Objekt anders benutzen, wird es aus diesen Operationen nicht gelöscht.

Um ein Objekt in einer bestimmten Operation nicht mehr zu benutzen, wählen Sie die betreffende Operation aus. Wenn Sie in einer Operation ein Objekt löschen, dass aber unter „Allgemein“ noch definiert ist, so wird anstelle einer vollständigen Löschung die Rolle des Objektes für die gewählte Operation auf „NOP“ (= no operation, nicht benutzt) gesetzt.

Wenn Sie in einer Operation ein „allgemeines“ Objekt mit einer anderen Rolle (kann auch „NOP“ sein) benutzen als unter „Allgemein“, und dieses Objekt dann löschen, so wird das Objekt nicht gelöscht, sondern zunächst die Rolle in der Operation auf die angepasst, die in dem Ereignis „Allgemein“ für das Objekt angegeben ist. Wenn Sie dieses Objekt in der Operation danach nochmal löschen, wird die Rolle auf NOP gesetzt.

Workflow-Properties

Im Reiter „Workflow“ können Sie festlegen, welche Workflow-Properties in dem Modul verwendet werden. Nur die Eigenschaften, die eine andere Rolle als „NOP“ haben, können in dem Modul referenziert werden. Um eine Eigenschaft zu ändern, muss sie die Rolle „MOD“ haben.

Lokale Datenstrukturen

Dieser Reiter zeigt eine Liste aller in dem Modul verwendeten Datenstrukturen. Hierbei werden, falls dies aus der Implementierung abgeleitet werden kann 8) auch lokale Objekte berücksichtigt. Die Liste kann, sofern lokale Objekte nicht aus der Implementierung abgeleitet werden können, hier bearbeitet werden, d.h. es können Datenstrukturen hinzugefügt oder entfernt werden.

Meldungsgruppen

In dieser Liste können Sie angeben, welche Meldungsgruppen in dem Modul verwendet werden.

1)
Geschäftsvorfall-Steuerungen (GEVO) können keine Parameter haben, da sie den Anfang der Aufruf-Kette bilden.
2)
im Schnittstellen-Dialog
3)
z.B. in InterfEdge
4)
Für Steuerungsmodule nicht relevant, da die Aufrufstruktur aus der Implementierung abgeleitet wird.
5)
Da diese am Anfang der Aufrufkette stehen, erwarten sie keine Angabe einer Opertation.
6)
nicht in Steuerungs- oder CTV-Modulen: hier wird die Aufrufstruktur aus der Implementierung abgeleitet und ist nicth editierbar
7)
(( Der Reiter ist für Geschäftsvorfall-Steuerungen (GEVO), Hauptsteuerungen und Ntry-Module nicht verfügbar; diese können keine Parameter haben, da sie den Anfang der Aufruf-Kette bilden.
8)
z.B. bei Steuerungsmodulen
cedge:interface:edit · Zuletzt geändert: 12.11.2019 15:13

Copyright © 1992-2024 TeamWiSE Gesellschaft für Softwaretechnik mbH         Adressen |  Kontakt |  AGB |  Datenschutzerklärung |  Impressum