Dieser Artikel beschreibt die Definition und Nutzung von GDL-Standards bei b-prisma.

Einführung

Namensgebung

Grundsätzliches

Parameter

Parametertypen

Variablen

Stile

! ---------------------------------------------------------------------- ! !ABSCHNITTSBEGRENZUNG
! ---------------------------------------------------------------------- ! !------CODEBLOCK 001--->>
!Hier steht der Codeblock! 
!<<---CODEBLOCK 001---

Scriptüberschriften

! ---------------------------------------------------------------------- !
! -------- M A S T E R - S c r i p t --------------------------- !
! ---------------------------------------------------------------------- !

! ---------------------- E N D -------------------- !
! ---------------------- E N D -------------------- !

END ! END ! END ! END ! END ! END ! END

! ---------------------- E N D -------------------- !
! ---------------------- E N D ---------------------!

! ---------------------------------- !
! ---------------------------------- !
! Erzeugt ein 3D-Türband, 
! der bewegliche Teil folgt 
! in Subroutine 101
! übergebene Parameter
! _durchmesserBand
! _materialBand
! Rückgabewerte
! keine
! ---------------------------------- !

100: ! ------ T Ü R B A N D -------- !
    ! Subroutinencode ist eingerückt
RETURN
! ---------------------------------- !
! ---------------------------------- !

Dokumentation im Script

Einrückungen (Tab-Sprünge)

FOR i = 1 TO anz
    ADDx (i - 1) * A
    ! Codeblock
    DEL 1
NEXT i


IF strTypTuer = „Schwingtür“ THEN
    ! Codeblock
ENDIF


ADDx 1
ROTy 44
    ! Codeblock
DEL 2

Halbfertige Arbeiten (todos)

ADDx 1 ! TODO: temporäre Verschiebung; später wieder aufheben
! Codebereich
DEL 1

Markieren von zusammenhängenden Befehlen

ADDx _verschiebungRahmen ! ko-trafo 01
If Bedingung_1 THEN
    IF Bedingung_2 THEN 
        ! Größerer Codebereich
    ENDIF ! Bedingung_2
ENDIF ! Bedingung_1
DEL 1 ! ko-trafo 01

Parameter-Script

! Parameter-Script
if Bedingung_1 then
    str_TypFenster = „Holzfenster“
    PARAMETERS str_TypFenster = str_TypFenster
endif
! Master-Script
if Bedingung_1 then 
    str_TypFenster = „Holzfenster“
endif

3D-Script

3D-Darstellung: unbedingt alles im 3D-Kontext weglassen, was nicht sichtbar ist, aber eine hohe Polygonanzahl besitzt und somit Rechenleistung fordert.
Es gibt bestimmte Elemente, die nur im Schnitt sinnvoll sind, nicht jedoch in 3D.

Fehlerkontrolle

In viel verwendeten Bibliothekselementen sollten möglichst umfassende Fehlerkontrollen eingebaut werden, welche verhindern, dass bei Eingabe ungültiger Parameterwerte durch den Anwender keine Fehlermeldungen auftauchen oder sogar das Objekt nicht mehr angezeigt wird:
Einige Beispiele für Fehlerkontrollen:

! — PEN darf nicht kleiner als 1 in 2D sein
IF post_fill_pen < 1 THEN post_fill_pen = 1

! — prüfe, ob die „Misch-Schraffur 50 %“ existiert, dann ist rrr = 1
fill50 = IND(FILL,“Misch-Schraffur 50 %“)
framefill = fill50
rrr = REQUEST(„Name_of_Fill“, framefill, fillName)

HOTSPOTS

Sämtliche Hotspots sind mit einer ID zu versehen, auch die nicht beweglichen, damit bei Vermassungen diese dynamische bleiben; bei Hotspots ohne IDs kann es passieren, dass sich die Bemaßungen bei Änderungen der Objektgröße nicht dynamisch anpassen.
Es ist für jedes Objekt samt Makros und Submakros eine Dokumentation über die Verwendung der Hotspot-IDs anzulegen, damit sichergestellt ist, dass es in unterschiedlichen Skripten nicht identische Hotspot-IDs gibt.
Z.B. Hauptobjekt 3D. 1 – 99, Hauptobjekt 2D: 100 – 199
Makro 3D: 1001 – 1099, Makro 2D: 1100 – 1199
Alternativ kann bei Makros auch die ID per Übergabe durchgezählt und per Returned Parameters ins Hauptobjekt zurückgespielt werden, wo dann weitergezählt wird.
In sämtlichen Skripten ist ausschließlich ein einziger identischer Variablenname für das hochzählen von Hotspots einzusetzen. Diese Variable braucht abweichend nicht mit einem Unterstrich zu beginnen.
z.B.: htsp = 1
HOTSPOT2 A, B, htsp : htsp = htsp + 1

MEHRSPRACHIGKEIT

Bei Aufträgen für international tätige Firmen sind immer von Anfang an die Grundlagen für eine Mehrsprachigkeit zu legen.
Folgende Dinge sind dabei zu beachten:
Anlegen eines Auswahlparameters für die Mehrsprachigkeit: int_language (1 = de, 2 = en, etc.)
Anlegen eines Makros für alle Sprachen oder je eines Makros für eine Sprache (Script abschließen mit END _durchgangsbreite, _durchgangshoehe etc. bzw. einfach mit END _translation)
Definition der Sprachpaare entweder als bekannte Variable oder als hochgezählte Arrayvariable, z.B.:
_durchgangsbreite = „durchgangsbreite“ (IF int_language = 1)
_durchgangsbreite = „egress width“ (IF int_language = 2)
_translation[int_language][1] = „durchgangsbreite“ (IF int_language = 1)
_translation[int_language][1] = „egress width“ (IF int_language = 2)Vorteile von Variante 1 ist die bessere Lesbarkeit beim Einsetzen der Variablen, Nachteil das wesentlich aufwändigere Script, da man in den Makros und in den CALL-Befehlen die einzelnen RETURNED_PARAMETERS einsetzen muss (Beispiel siehe unten)Vorteile von Variante 2 ist das einfacher zu erzeugende Script und die kürzeren Makro-Befehle, Nachteil die ziemlich schlechte Lesbarkeit beim Einsetzen der Variablen
Makroaufruf in etwa wie folgt:
a) Variablenverwendung:CALL „translation_object.gsm“ PARAMETERS RETURNED_PARAMETERS _durchgangsbreite, _durchgangshoehe etc.
b) Arrayverwendung:CALL „translation_object.gsm“ PARAMETERS RETURNED_PARAMETERS _translation
Bei vielen Werten sind die Wörter nach Themen bzw. inhaltlicher Bedeutung zu sortieren und zu kennzeichnen (z.B. UI-Texte, VALUES-Werte, etc.)

Spezifizierung (aus: Graphisofts® Library Specification)

Erste Voraussetzung bei der Erstellung eines GDL-Objektes ist, dass sein Zweck und seine Funktion klar definiert sind, um einen perfekten Überblick über die Funktion des Objektes zu bekommen: den Abstraktionsgrad, die Eigenschaften, 2D- und 3D-Darstellung, sowie die Darstellung in Schnitten und Ansichten. Eine der grundlegenden Fragen lautet: wozu soll das Objekt verwendet werden?
Hieraus werden vom GDL-Entwickler in Abstimmung mit dem Auftraggeber sämtliche Parameter und ihre hierarchische Struktur definiert. Die Logik der Parametrik muss sich in der Anordnung der Paarmeter widerspiegeln; die Parameter sollten in Gruppen angeordnet werden und die Verknüpfungen von Parametern untereinander muss klar definiert werden (und später im Parameter-Scipt ausgearbeitet werden). Um dies sicherzustellen, müssen Verbindungen von Parametern untereinander genauestens analysiert werden.
Vom Auftraggeber müssen Spezifizierungs-Zeichnungen erstellt werden, bevor mit der Erstellung eines neuen Bibliothekselementes begonnen wird. Spezifizierungs-Zeichnungen müssen jede Darstellungsvariante jedes Einzelobjektes – wie folgt beschrieben – enthalten:
diese müssen in unterschiedlichen Maßstäben gezeichnet sein, falls 2D und 3D ihre Darstellung in Abhängigkeit vom Maßstab ändern sollen
unabhängige Versionen müssen für Fenster/Türen gezeichnet werden, einmal mit und einmal ohne Zusatzelemente, wie Seitenlichter, Oberlichter, Riegel, Pfosten, Kämpfer, Wandanschlüsse etc.
diese sollten Grundrisssymbol, Schnitt- und Ansichtssymbole in durchgängig einheitlicher Darstellungsart enthalten
Sämtliche durch Parameter veränderlichen Werte sind mit einheitlichen Buchstaben (Grundriss, Schnitt, Ansicht) in Maßketten zu kennzeichnen; sämtliche Fixgrößen sind durch Zahlenwerte zu kennzeichnen
Der Programmierer sollte auch für Fixgrößen später im Script Variablen verwenden, um spätere Änderungen zu vereinfachen. Um unerwartete Probleme zu vermeiden, sollte für sämtliche Attribute (Stift oder Schraffur) ein zusätzlicher oder interner Parameter verwendet werden, den man von einer zur anderen Version leicht ändern kann.
Die Zeichnungen müssen das Modell in jedem Fall so zeigen, wie es hinterher aussehen soll. Um Missverständnisse zu vermeiden, können keine Skizzen akzeptiert werden, die weniger detailliert sind als das gewünschte Ergebnis.
Die Spezifizierungs-Zeichnungen müssen alles enthalten, das für den Auftraggeber wichtig ist. Der Programmierer kann Dinge, die nicht in den Spezifizierungs-Zeichnungen gezeigt werden, auch nicht mit in das Objekt einbauen.
Das Entscheidende ist eine gute Kommunikation zwischen Auftraggeber und Programmierer.Dies ist u.a. auch dafür wichtig, damit nicht schwerwiegende Änderungen in einer fortgeschrittenen Phase der Objekt-Entwicklung notwendig werden.

Prototypen (aus: Graphisofts®Library Specification)

Normalerweise ist es unmöglich, eine klare Spezifizierung für eine bisher noch nicht vorhandene Funktionalität im Voraus aufzustellen. Prototypen sind daher eine gute Lösung für Auftraggeber und Programmierer, um die Anforderungen und Spezifizierungen untereinander zu kommunizieren. Um die Anforderungen und deren mögliche Lösungen in einer fortgeschrittenen Form darzustellen, sollten ein Prototyp-Objekt für ein Objekt bzw. für grundlegende Objekttypen einer Bibliothek erzeugt werden.
Prototypen müssen vom Auftraggeber sehr genau geprüft werden. Sie sollten sämtliche Parameter, Optionen und Eigenschaften des fertigen Bibliothekselementes enthalten. Sehr oft ist dies in einer frühen Phase der Entwicklung nicht möglich, so dass Bibliothekselemente so vorzubereiten sind, dass Modifikationen leicht möglich sind. Aus diesem Grund sollte ein Bibliothekselement niemals als die ultimative Lösung für die Anforderungen des Auftraggebers in Betracht gezogen werden.

Qualitätsmanagement

Je umfangreicher ein Projekt oder Objekt ist, desto wichtiger ist ein umfassendes Qualitätsmanagement zur Erzielung eines gleichmäßig hohen Qualitätsstandards und zur Beseitigung von unvermeidlichen Bugs.
Qualitätssicherung ist nicht das letzte Glied der Entwicklungskette, es ist ein Schritt im fortlaufenden Prozess der agilen Softwareentwicklung. Testing findet in jeder Entwicklungsphase statt. Entsprechend muss Software-Testing als ein regelmäßiger und fortlaufender Entwicklungsschritt in den alltäglichen Entwicklungsprozess integriert werden.
Wichtige Teile des Qualitätsmanagements sind das Vorgeben von Standards, eine Checkliste zum Abarbeiten von Standards, die Überprüfung der Einhaltung der Standards, eine sorgfältige nachvollziehbare Dokumentation des Entwicklungsprozesses mit Dokumentationstemplates, ein ausführlicher Betatest mit Bugreporting und Bugfixing.
Elemente eines Standard-Betatests:
Standardfragenkatalog: Geometrie
Standardfragenkatalog: Logik
Standardfragenkatalog: User Interface
Standard: Sind Fehleingaben ausgeschlossen?
Projektfragenkatalog: Produktlogik, wurden die Vorgaben umgesetzt?
Testen in unterschiedlichen Umgebungen: 2D, 3D, Schnitt, Ansicht, Rendering, Hotspot-Editing, Listenauswertung, Geschosse, Modelldarstellungen
Tests auf Windows und MAC