AnEdge – Analyse von TAA-Modulen

Das Werkzeug AnEdge prüft TAA-Module nach bestimmten, in den Analysemethoden festgelegten Kritierien.

Die Auswahl durchzuführender Prüfungen und zu prüfender Module ist zur Zeit nur über eine Batch-Schnittstelle möglich.

Als Ausgabe wird eine XML-Datei erstellt, wobei zusätzlich eine darauf anzuwendende XSL-Datei angegeben werden kann.

Die Überprüfung erfolgt – je nach SearchOrder-Angabe - auf Basis von Ressourcen-DLLs und/oder Rochade.

Syntax:

AnEdge [Optionen] [Aufgaben]

Optionen:

• -a Anwendung
• -s Stufe
• -g Auftrag
• -o Pfadname der Protokolldatei (.xml)
• -xsl Pfadname der auf das Protokoll anzuwendenden XSL-Datei
• -d SearchOrder (entsprechend der Angaben in der Registry, Wert 0 – 3)
• -e EdbAllowed (0 oder 1)
• -lo Pfadname LogDatei
• -ex Pfadname der Datei, in der die Aufgabenliste enthalten ist

Aufgaben:

Zu jeder Aufgabe sind – in dieser Reihenfolge – anzugeben:

<Bausteintyp> <Bausteinname> <Analysename>

Beispiel:

 AnEdge –a Test –o c:\analyse\a1.xml –d0 –lo c:\analyse\a1.log –ex c:\analyse\a1.anl

wobei Analyse.anl enthält:

STRG PG-TSTR-START Locuse
STRG PG-TSTR-START Event

Folgende Methoden sind im Moment implementiert (der Name entspricht dem in der Aufgabe anzugebenden Analysenamen):

Anwendbar für Bausteintyp: MODL

Überprüft, ob die in einer Modulschnittstelle verwendeten Zustände in der EDB definiert sind.

Für Steuerungen wird zusätzlich geprüft:

1. Usage: Werden in der Steuerung Zustände gesetzt, die nicht in der Schnittstelle angegeben sind?
   Wird ein Zustand von einem nicht aufgerufenen Modul abgefragt (WrongQuery)?
2. Unused: Sind in der Schnittstelle Zustände definiert, die nicht in der Steuerung verwendet werden?

Anwendbar für Bausteintyp: MODL

Überprüft, ob die in einer Modulschnittstelle verwendeten Ereignisse in der EDB definiert sind.

Für Steuerungen wird zusätzlich geprüft:

1. Usage: Werden in der Steuerung Ereignisse genutzt, die nicht in der Schnittstelle angegeben sind?
2. Unused: Sind in der Schnittstelle Ereignisse definiert, die nicht in der Steuerung verwendet werden?

Anwendbar für Bausteintyp: STRG

Überprüft Steuerung auf Abbruch- oder Endekonstrukte innerhalb von Parallelverarbeitungen.

In der Usage-Section der XML-Ausgabedatei werden die gefundenen Abbruchkonstrukte innerhalb von Parallelverarbeitungen aufgelistet.

Anwendbar für Bausteintyp: STRG, CTVK

Überprüft die Verwendung von Globalen Objekten. Bei dieser Überprüfung wird auch eventspezifisch die Verwendung der Globalen Objekte überprüft.

Als Ergebnis gibt es zwei Teilresultate:

1. WrongUsed: Pro Ereignis werden hier die Objekte aufgelistet, die nicht gemäß ihrer Rolle benutzt werden.
2. Unused: Hier werden pro Ereignis die Objekte aufgelistet, die nicht benutzt werden, obwohl sie in der Schnittstelle für das Ereignis definiert sind.

Für das WrongUsed Teilresultat gilt folgendes:

Für das WrongUsed Teilresultat gilt folgendes (nur für CTVK):

Anwendbar für Bausteintyp: STRG, CTVK

Überprüft die Verwendung von Parameterobjekten. Bei dieser Überprüfung wird auch eventspezifisch die Verwendung von Parameterobjekte überprüft.

Als Ergebnis gibt es zwei Teilresultate:

1. WrongUsed: Pro Ereignis werden hier die Objekte aufgelistet, die nicht gemäß ihrer Rolle benutzt werden.
2. Unused: Hier werden pro Ereignis die Objekte aufgelistet, die nicht benutzt werden, obwohl sie in der Schnittstelle für das Ereignis definiert sind.

Für das WrongUsed Teilresultat gilt folgendes:

Für das WrongUsed Teilresultat gilt folgendes (nur für CTVK):

Anwendbar für Bausteintyp: STRG (Ab Version 8.03 auch für CTVK)

Überprüft die Verwendung der lokalen Objekte. Objekte die definiert sind, aber nicht verwendet werden, werden aufgelistet.

(Ab Version 8.03) Analyse kann auch für CTV-Module verwendet werden.

Anwendbar für Bausteintyp: STRG (Ab Version 8.03 auch für CTVK)

Überprüft die Verwendung von Objekten, die nicht definiert sind.

1. WrongUsed: Hier werden pro Ereignis die Objekte aufgelistet, die verwendet werden, aber nicht definiert sind.

2. WrongUsed-ByVal: Hier werden die Objekte aufgelistet, die innerhalb von Schleifen in Bausteinaufrufen mit ByValue übergebenen werden.

3. Unused: Objekte, die definiert sind, aber nicht verwendet werden.

(Ab Version 8.03) Analyse kann auch für CTV-Module verwendet werden.

Anwendbar für Bausteintyp: STRG

Diese Analyse überprüft, ob bei Entscheidungen Bedingungscode vorhanden ist. Leere Bedingungen werden in der Usage Section aufgelistet. Auch Schleifen-Konstrukte ohne Bedingung werden erkannt.

Anwendbar für Bausteintyp: STRG

Überprüft die Verwendung von Lokalen Steuerungsteilen.

1. Unused: Es werden solche Steuerungsteile aufgelistet, die zwar in der Steuerung vorhanden sind, aber nie aufgerufen werden.
2. Missing: Hier werden Aufrufe von Steuerungsteilen aufgelistet, für die kein Name vergeben wurde.

Anwendbar für Bausteintyp: STRG

Diese Analyse überprüft, ob Objekte mit Rolle MOD auch wirklich modifiziert werden.

Anwendbar für Bausteintyp: STRG

Überprüft die Verwendung von Steuerungsvariablen:

1. Usage: Variablen die abgefragt werden, aber nie gesetzt werden.
2. Unused: Variablen die gesetzt werden, aber nie abgefragt werden.

Anwendbar für Bausteintyp: MODL

Überprüft, ob für das Modul eine Ityp- und Ispc-Angabe vorhanden ist.

Anwendbar für Bausteintyp: STRG

Überprüft die Verwendung von Schweben:

1. Usage: Prüft Namen und ob Datenobjekte zugeordnet sind.
2. WrongUsed: Prüft nicht abgeschlossene Schwebeklammern.
3. WrongUsedObject: Ermittelt Objekte, die in unterschiedlichen Schweben verwendet werden. Eine entsprechende Warnung wird aber nur dann in den Report aufgenommen, falls in der Steuerung keine MasterSchwebe verwendet wird, da es nur in diesem Fall zu Problemen kommen kann (Laufzeitabbrüche, weil u.U. versucht wird, mit zwei unterschiedlichen Unit-IDs Updates zu machen).

Außerdem wird eine Info erzeugt, wenn ein globales Objekt mit einer Schwebe verknüpft ist.

Anwendbar für Bausteintyp: STRG, CTVK

Diese Analyse überprüft, ob bei Aufrufen auch ein Modul angegeben ist und ob alle Parameter-Objekte bestückt werden. Es wird zusätzlich überprüft, ob es bei Aufrufen Objekte gibt, die mehreren Parametern (mehr als einem) zugewiesen wurden.

Es werden fehlende Objekt-Zuweisungen erkannt, wenn einem aufgerufenen Modul Parameterobjekte hinzugefügt wurden (Schnittstellenänderung) aber der Modulaufruf im Aufrufer noch nicht angepasst wurde.

Es werden überflüssige Objekt-Zuweisungen erkannt, wenn einem aufgerufenen Modul Parameterobjekte entfernt wurden (Schnittstellenänderung) aber der Modulaufruf im Aufrufer noch nicht angepasst wurde.

Es wird ebenfalls geprüft, ob ein Modul unerlaubterweise außerhalb der eigenen Anwendung aufgerufen wird.

Für CTV-Module werden auch Modulaufrufe im Pseudocode geprüft.

Anwendbar für Bausteintyp: GSTR

Überprüft, ob für das Modul ein Gevo-Ende Konstrukt vorhanden ist.

Anwendbar für Bausteintyp: STRG

Überprüft die Verwendung von Transaktions-Konstrukten innerhalb einer Steuerung. Alle möglichen Pfade einer Steuerung werden für jedes Ereignis durchlaufen, um zu überprüfen, ob die Anzahl Begin-Transaktions-Konstrukte und Ende-Transaktions-Konstrukte (und auch Rollback) richtig ist. Auch wird die Verwendung von Transaktions-Konstrukten in Parallel-Pfaden untersucht. Bei der Verwendung von Transaktions-Konstrukten innerhalb von Schleifen wird eine Warnung generiert, da die korrekte Verwendung hier erst zur Laufzeit festgestellt werden kann. Es könnte ja z.B. sein, dass ein Transaktionsabbruch aufgrund der Schleife versehentlich mehrmals durchlaufen wird, wenn die Verarbeitung nicht rechtzeitig beendet wird.

Um feststellen zu können, ob unterhalb eines Arbeitsgangs Transaktionierungen laufen, listet diese Analyse auf, ob die Steuerung transaktioniert und welche Module in dieser Steuerung aufgerufen werden. Mit diesen Daten sollte es möglich sein, Anwendungskomponenten von Rochade aus zu analysieren.

Anwendbar für Bausteintyp: MODL

Überprüft, ob für das Modul in der Schnittstelle ein Kommentar angegeben wurde.

Für Steuerungen wird für alle Konstrukte geprüft, ob ein Kommentar angegeben wurde. Für ein Bausteinaufruf-Konstrukt wird zusätzlich geprüft, ob in der Modul-Schnittstelle ein Kommentar angegeben wurde.

Anwendbar für Bausteintyp: MODL

Diese Analyse überprüft, ob Namen für Module, Parameterobjekte, globale Objekte, etc. einer Vorgabe (Namenskonvention) entsprechen. In einer EDB-Tabelle (ANNC) können Regeln für Namenskonventionen baustein- und anwendungsspezifisch aufgenommen werden. Es müssen reguläre Ausdrücke für die Vorgabe von Modulnamen, Namen für Parameterobjekte oder globale Objekte, etc. angegeben werden.

Syntaxbeschreibung für reguläre Ausdrücke Sprachelemente für reguläre Ausdrücke – Kurzübersicht

Anwendbar für Bausteintyp: STRG

Diese Analyse überprüft, ob CTV-Konstrukte mit Drucken auf Nicht-GeVo-Ebene verwendet werden. Es geht darum, dass verhindert werden soll, Dokumente ggf. mehrmals zu Drucken. Wenn das Drucken z.B. in einem Arbeitsgang stattfinden würde und dort anschließend der Arbeitsgang unterbrochen wird, dann würden die Dokumente beim Wiederanstarten wieder ausgedruckt werden.

Anwendbar für Bausteintyp: STRG (Ab Version 7.07)

Diese Analyse überprüft, wenn für die Steuerung „UseWorkflowTransaction“ konfiguriert ist, ob für ein Ereignis möglicherweise problematische Konstrukte verwendet werden (Interaktionsbausteine oder Manuelle Entscheidungen).

Anwendbar für Bausteintyp: CTVK

Diese Analyse überprüft die Verwendung von CTV-Variablen:

1. Usage: Werden in dem CTV-Baustein CTV-Variablen verwendet, die für den Baustein nicht bekannt sind?
2. Unused: Sind für den CTV-Baustein CTV-Variablen definiert, die im Baustein nicht verwendet werden?

Anwendbar für Bausteintyp: CTVK

Diese Analyse überprüft verschiedene Angaben in OpenXML-Bausteinen, die ggf. bei der Montage zu Problemen führen können:

1. Papiergröße: Für andere als A4-Seiten wird eine Warnung ausgegeben.
2. OLE-Objekte: Wenn OLE-Objekte im OpenXML vorhanden sind, wird dafür eine Warnung ausgegeben. Nicht alle OLE-Objekte können beim Druck oder bei der Konvertierung nach PDF verarbeitet werden.
   OLE-Objekte, die als Verknüpfung im Baustein vorhanden sind, werden als Fehler gekennzeichnet, weil die Verknüpfung nicht funktionieren wird, wenn der Baustein auf einem anderen Rechner verwendet wird als wo er mit KnowlEdge erstellt wurde.
3. Word-Felder: Bestimmte Felder können nicht verwendet werden. Es gibt drei Kategorien für Felder: Felder, von denen bekannt ist, dass sie funktionieren, werden nur als „Info“ aufgelistet. Felder, von denen bekannt ist, dass sie zur Laufzeit nicht funktionieren werden, werden als Fehler gemeldet. Felder, von denen nicht bekannt ist, ob sie zur Laufzeit funktionieren werden, werden als Warnung gemeldet.
4. Platzhalter-Format: Platzhalter mit Fehler in der Format-Angabe werden hier aufgelistet.
5. Text-Richtung: Bestimmte PDF-Konverter haben ein Problem mit gedrehtem Text in einem Baustein. Diese werden hier deshalb als Fehler aufgelistet.

Anwendbar für Bausteintyp: SSBS

Diese Analyse überprüft Textbausteine auf die Benutzung von erlaubten Schriftarten und Schriftgrößen. Bei der Verwendung von nicht erlaubten Schriftarten und Schriftgrößen wird eine Warnung generiert. Bei Bausteinen, die zur Laufzeit nicht editierbar sind, wird falls diese Bausteine analysiert werden auch die Verwendung geprüft, aber nicht als Warnung, sondern als Information.

Anwendbar für Bausteintyp: STRG

Diese Analyse überprüft die Verwendung von manuellen Entscheidungen in Steuerungen:

1. UndefinedUsed: Ist in einer Bedingung eine manuelle Entscheidung angegeben, die in der Steuerung nicht als Konstrukt existiert? Ist in einer Bedingung eine Antwort angegeben, die für die manuelle Entscheidung nicht definiert ist?

Anwendbar für Bausteintyp: STRG

Diese Analyse überprüft die Verwendung von Workflow-Eigenschaften in Steuerungen:

1. Usage: Werden in der Steuerung Workflow-Eigenschaften abgefragt, die generell unbekannt oder nicht in der Schnittstelle angegeben sind?

Anwendbar für Bausteintyp: STRG

Diese Analyse überprüft die Attribuierung von Konstrukten in Steuerungen:

1. HistoryLogging: Werden in der Steuerung bei Aufrufen desselben Bausteins manchmal Attribute für die Protokollierung im Geschichtsbuch gesetzt und manchmal nicht, wird eine Warnung ausgegeben.
2. HistoryLoggingDifferent: Werden in der Steuerung für bestimmte Bausteinaufrufe unterschiedliche Attribute für die Protokollierung im Geschichtsbuch gesetzt, wird eine Info-Meldung ausgegeben.

Das Ergebnis-XML besteht aus einem AnalysisReports Tag. Unterhalb von diesem Tag gibt es (eventuell mehrere) Analysis Tag(s). Eine Analysis besteht aus Name, Methode und Datum. Auch sind in einer Analysis ein AnalysisHeader und ein ComponentHeader enthalten. Neben einigen analysebezogenen Ergebnissen gibt es ein ResultCount. Die analysebezogenen Ergebnisse werden weiter unten beschrieben. Hier folgt zunächst ein XML-Ausschnitt ohne die Ergebnisse:

<?xml version="1.0" encoding="ISO-8859-1" standalone="yes" ?>
<AnalysisReports>
  <Analysis>
    <Name>States</Name>
    <Method>Analyse</Method>
    <DateofAnalysis>2003-05-20-16.11.45.071360</DateofAnalysis>
    <AnalysisHeader>
      <AnalysisName>STATES</AnalysisName>
      <Description>Checking validity of states used</Description>
      <Version>1.0</Version>
    </AnalysisHeader>
    <ComponentHeader>
      <ModuleType>GK-TEST-ANEDGE</ModuleType>
      <ModuleType>SSTR</ModuleType>
      <Application>test</Application>
      <ModificationDate>20030514115732</ModificationDate>
    </ComponentHeader>
    <ResultCount>0</ResultCount>
  </Analysis>
  <Analysis>
    <Name>ParEnd</Name>
    <Method>Analyse</Method>
    <DateofAnalysis>2003-05-20-16.11.50.728361</DateofAnalysis>
    <AnalysisHeader>
     <AnalysisName>PAREND</AnalysisName>
     <Description>Checking for End or Abbruch in Processes</Description>
     <Version>1.0</Version>
   </AnalysisHeader>
   <ComponentHeader>
     <ModuleType>GK-TEST-ANEDGE</ModuleType>
     <ModuleType>SSTR</ModuleType>
     <Application>test</Application>
     <ModificationDate>20030514115732</ModificationDate>
   </ComponentHeader>
   <ResultCount>0</ResultCount>
 </Analysis>
</AnalysisReports>

Die analysebezogenen Ergebnisse können aus mehreren Teilergebnissen bestehen. Als Beispiel folgt hier ein Ergebnis für die „States“-Analyse. In diesem Beispiel sind drei Teilergebnisse zu erkennen: Interface, Used und Unused. Im Interface-Teilergebnis werden die im Modul-Interface gefundenen Fehler aufgelistet (Zustände, die im Modulinterface benutzt werden, aber nicht mehr in der Zustandstabelle vorhanden sind). Im Usage-Teilergebnis wird die Benutzung von Zuständen im Modul ermittelt. Aufgelistet wird, wo ein Zustand gesetzt wird, der nicht im Modul-Interface angegeben ist. Als letztes werden im Unused-Teilergebnis die nicht benutzten Zustände aufgelistet:

<Interface>
  <Results>
    <State>NICHT-OK</State>
    <State>OK</State>
  </Results>
  <ResultCount>0</ResultCount>
</Interface>
<Usage>
  <Results>
    <Steuerungsteil>
      <Cedge>
        <Name>empty</Name>
        <Type>2</Type>
      </Cedge>
      <ResultCount>0</ResultCount>
    </Steuerungsteil>
    <ResultCount>0</ResultCount>
  </Results>
</Usage>
<Unused>
  <Results>
    <NotUsed>
      <Reason>Component defined but never used</Reason>
      <Severity>Info</Severity>
      <Name>ABBRUCH</Name>
      <Type>State</Type>
      <DefinedIn>GK-TEST-ANEDGE</DefinedIn>
    </NotUsed>
    <ResultCount>1</ResultCount>
  </Results>
</Unused>
<ResultCount>1</ResultCount>

Beim Unused-Teilergebnis wird im obigen Beispiel ein im Modul-Interface beschriebener, aber nicht verwendeter Zustand gemeldet. Dies wird mittels eines Standard XML-Teils angegeben:

<NotUsed>
  <Reason>Component defined but never used</Reason>
  <Severity>Info</Severity>
  <Name>ABBRUCH</Name>
  <Type>State</Type>
  <DefinedIn>GK-TEST-ANEDGE</DefinedIn>
</NotUsed>

Severity kann folgende Werte haben: Info, Warning, Error, Severe und Abortive.

Bei der Analyse von Steuerungen werden zu jedem gefundenen Fehler auch Angaben zum Konstrukt geschrieben. Dies ist zu sehen in folgender Conditions-Analyse:

<Usage>
  <Results>
    <Steuerungsteil>
      <Cedge>
        <Name>empty</Name>
        <Type>2</Type>
      </Cedge>
      <Missing>
        <Reason>Missing information in Expression</Reason>
        <Severity>Error</Severity>
        <What>Empty</What>
        <Where>Expression</Where>
        <Cedge>
          <ConsID>5</ConsID>
          <ConsName>empty</ConsName>
          <ConsText>Bedingung</ConsText>
        </Cedge>
      </Missing>
      <ResultCount>1</ResultCount>
    </Steuerungsteil>
    <ResultCount>1</ResultCount>
  </Results>
</Usage>
 <ResultCount>1</ResultCount>

Konstrukte werden im XML mit einem ConsType Attribut generiert.

<Cedge>
  <ConsID>16</ConsID>
  <ConsName>empty</ConsName>
  <ConsText>Iterationsabbruch SCHLEIFE</ConsText>
  <ConsType>515</ConsType>
</Cedge>

Auflistung von Konstrukt-Typen