Software aus Fertigteilen "zusammenbauen"
statt neu programmieren

Zielgruppen

DLG ist für alle in Frage kommenden Zielgruppen geeignet:

• Professionelle Anwender

  Das sind jene Anwender, die Software nicht zum eigenen Gebrauch entwickeln, sondern in fremdem Auftrag (oder mitunter auch auf eigene Initiative), und sie danach verkaufen. Typischerweise also Software- oder Systemhäuser.

  Für sie zählt an DLG vor allem:

  • Mit wenigen Zeilen Code kann die Funktionalität von vorprogrammierten Modulen im Wert von einigen tausend Code-Zeilen genützt werden.
  • Mit weniger und weniger qualifizierten Programmierern kann eine durchschnittliche Applikation in ein paar Stunden bis Tagen erzeugt werden. (Zum Vergleich: In konventioneller Programmierung wären das einige Tage bis zu mehreren Monaten.) Eine erhebliche Kosteneinsparung!
  • Die Anschaffungskosten machen sich somit nach wenigen Verwendungen von DLG bereits bezahlt. Jede weitere Anwendung ist Reingewinn.
  • DLG ist im Vergleich zu konventioneller Programmierung etwa das, was jene um 1960 gegenüber der Assembler-Programmierung war.
  
  
• Semi-professionelle Anwender

  Das sind jene Anwender, bei deren Geschäft es um Produkte geht, zu denen Software mitgeliefert wird bzw. von dritter Seite zugekauft werden kann. Typischerweise also Händler von Computer oder Konsumelektronik. Firmen, deren Kunden immer wieder bestimmte Wünsche an Software haben. Nur - die "richtige" Software gibt's eben nirgends.

  Bis jetzt jedenfalls. Mit DLG können solche Firmen nun auch bei Software ihre eigenen "Hausmarken" herausbringen:

  • Mit DLG ähnelt die Software-Entwicklung dem Zusammenbau eines komplizierten Produkts aus Fertigteilen.
  • Konventionelle Programmierung ist eine konzentrierte Arbeit, bei der jede Störung verheerend sein kann. Doch Störungen gehören bei solchen Anwendern eben zum Alltag. Das geht nur mit DLG.
  • Konventionell programmierte Software greifen selbst Fachleute möglichst nie mehr an, wenn sie erst einmal funktioniert. Doch bei semi-professionellen Anwendern ist Software nun einmal etwas, was immer wieder neu modifiziert werden muss. Mit DLG "zusammengebaute" Software ist leicht zu lesen und zu überarbeiten.
  • Dazu braucht man keine hochqualifizierten Programmierer. Ein paar Mitarbeiter mit mittlerer Ausbildung genügen.
  
  
• 'Casual Users'

  Dieser schier unübersetzbare Ausdruck bezeichnet all jene Anwender, für die Software-Entwicklung nicht zur täglichen Arbeit gehört. Sie beschäftigen sich mit etwas anderem, bei dem aber Software immer wieder eine Rolle spielt. Typisch dafür sind Ingenieurbüros, die für ihre Arbeit nie so ganz die "richtige" Software finden. Andere Beispiele sind alle Hi-Tech-Anwender, Unternehmensberater oder auch Hobbyisten.

  Keiner weiß besser, was in einer Software drinstecken sollte, damit sie in der Praxis brauchbar ist. Anwender, die am liebsten ihre eigene Software entwickeln würden - nur war ihnen das bisher einfach zu aufwendig. Mit DLG können sie das nun:

  • Ein fast schon "klassisches" Problem bei konventioneller Programmierung ist die Vielzahl von komplizierten Formalismen, die dabei strikt eingehalten werden müssen. Das kann man aber nur, wenn man regelmäßig damit - und nur damit! - arbeitet. (Also genau das Gegenteil eines "casual users"!)
  • Bei DLG aber gibt es nur wenige Formalismen einzuhalten (siehe "Formalismen").
  • Darüber hinaus ist DLG weitgehend formatfrei.
  • Bei DLG werden sogar einige Freiheiten von C/C++ genützt, die bei konventioneller Programmierung häufig übersehen werden.
  
  

DLG - Prinzip

1. Aufbau eines Grundgerüsts der Ziel-Applikation ("Application Framework") aus den DLG-Bausteinen.
   
   Dabei werden vom DLG-System erledigt:
   
   
   • Erzeugung der Benutzeroberfläche ("User Interface", UIF)
   • Routine-Operationen zur Abwicklung der Benutzereingriffe ("User Interactivity")


2. Feinabstimmung von UIF-Elementen und ihrem Verhalten über Option-Strings.
   
   In der Codierung sind das ganz normale Strings ("…"), bestehend aus einer beliebigen Zahl von Schlüsselwort-Parametern der Form:
   
    "Schlüsselwort=%format[,%format,…;]", argument[,argument,…;] 

   Das ist es, was DLG so besonders macht: Vorprogrammierte Module (sog. "Komponenten") gab es schon vor 1990. Aber sie hatten noch keine Feinabstimmung - sie "passten" entweder, oder eben nicht. Und deswegen waren sie in der Praxis ziemlich unbrauchbar.

3. Implementierung von applikations-spezifischen Operationen durch einfaches Programmieren (in sog. "Callback-Prozeduren"). Meist sind das nur wenige Zeilen Code in einfachem C/C++.
   
   Tatsächlich hat sich aus ersten praktischen Erfahrungen bereits eine Faustregel ergeben: "Wenn eine Callback-Prozedur einmal zu kompliziert wird, dann sollte man sich das 'Application Framework' noch einmal genauer anschauen. Wahrscheinlich findet man dann eine Möglichkeit, einen Teil der Funktionalität auf das DLG-System abzuschieben."

Bei DLG sind folgende Formalismen zu beachten:

• Das Schlüsselwort muss genau in der richtigen Schreibweise codiert werden.
  
  
• In jeder Option müssen genau so viele Argument-Werte angeführt werden, wie Format-Specifier  "%format"  auf das Schlüsselwort folgen. (Die meisten Optionen enthalten ohnehin nur 1 Argument.)
  
  
• Aufeinanderfolgende Optionen müssen durch mindestens ein Whitespace (Leerzeichen, Tabulator-Symbol, u.a.) getrennt werden.
  
  

Lieferumfang

Geliefert wird DLG in einem Paket, bestehend aus

• Bibliothek  Dlg.lib 
• Header-File  dlg.h 
• online-Dokumentation  Dlg.htm 
• Demo-Programm (Source-code)
• 3 Stunden persönliche Betreuung
  (jede weitere Stunde ist kostenpflichtig, sowie jede Stunde außerhalb von Wien)

Weiterführende Information, Email-Kontakt

Wer Genaueres wissen will (und kein Problem damit hat, einen englischen Text zu lesen), für den ist sehr empfehlenswert: http://www.Itspecial.org/1cd_dlg.htm

Oder senden Sie ein Email an: g.gerdenitsch@ITspecial.org

Hintergrund von DLG

Die vom DLG-System zur Verfügung gestellten Funktionen sind gewissermaßen die "Komponenten" einer Klasse von Applikationen.

Die Idee ist eigentlich recht einfach:

Allerdings ist das Konzept der "Komponenten", vor über 10 Jahren aufgebracht, inzwischen schon etwas in Misskredit geraten.

Inzwischen zeigte sich nämlich, dass Komponenten nur innerhalb eines sehr schmalen Bereichs von Anwendungen brauchbar sind. Liegt die Applikation nur ein wenig außerhalb dieses Bereichs, gibt es kaum mehr eine Chance zur Feinabstimmung der Komponenten. Ganz einfach deshalb, weil es mit den bisher üblichen Positionsparametern bei einer größeren Zahl von Parametern - mehr als 6 bis 8 - schon sehr leicht ist, die Übersicht zu verlieren. Für praktisch anwendbare Komponenten aber sind selbst in einfachen Fällen schon gut 20-50, bei größeren Komponenten sogar über 100 Parameter nötig.

Da kann man vom Programmierer kaum mehr erwarten, dass er sich z.B. bei Parameter 87 nicht verzählt und statt dessen Parameter 86 codiert - worauf sich die Komponente vielleicht ganz anders verhält!]

In praktisch jeder Applikation kommen irgendwelche applikations-spezifische Features vor - für die es natürlich keine DLG-Bausteine gibt. Man kann sie also nur selber programmieren, um dieses  Custom Programming  dann irgendwie ins Application Framework einbinden. Aber wie? In reinen Komponenten-Systemen gibt es keine Möglichkeit dafür. - In DLG hingegen kann man beliebig viele "Callback-Prozeduren" einbauen. DLG kann also beliebig mit konventioneller Programmierung kombiniert werden.

Der Unterschied von DLG zu den konventionellen Komponenten ist also:

1. Strings von Schlüsselwort-Optionen zur Feinabstimmung der Komponenten
2. beliebig viele Callback-Prozeduren für applikations-spezifische Features
3. Im UIF-Design bietet DLG weit mehr Möglichkeiten als konventionelle Programmierung.

Je nach Betriebssystem können auch multimediale Präsentationen eingebaut werden. Zum Beispiel kann jedes Mal, wenn eine Ihrer Applikation aufgerufen wird, oder wenn ein bestimmter Button geklickt wird, ein bestimmter Sound. eine Tonfolge oder sogar eine Video-Sequenz abgespielt werden

Das können Sie z.B. benutzen, um Ihre Corporate Identity auf den Bildschirm des Benutzers zu bringen. So könnte etwa der Standard-Hintergrund mit dem Logo Ihrer Firma bemalt sein. Mit etwas mehr Aufwand können Sie sich sogar eine "akustische Corporate Identity" zulegen. (Mit etwas Phantasie könnte man hier auf die Idee eines eigenen "Firmen-Jingles" oder eines "Firmen-Videos" kommen …)

Die meisten heutigen Software-Entwickler (selbst die "Global Players") haben heute noch die langweilige graue Benutzeroberfläche. Bei Ihrer Software aber wäre auf den ersten Blick klar, aus welchem Haus sie kommt!

Schlüsselwort-Parameter

Erst mit den Schlüsselwort-Parametern von DLG ist es möglich, mit wenig Codieraufwand eine große Zahl von Parametern in einer dem Menschen leicht verständlichen Form an eine Komponente zu übergeben:

• Schlüsselworte machen Komponenten erst flexibel (= praktisch anwendbar!)
• Schlüsselworte haben geringen Codieraufwand (= Produktivität der Programmierung!)
• Schlüsselworte sind leicht lesbarer, erzeugen damit einen z.T. selbst-dokumentierenden Code (= Wartungsfreundlichkeit!)

Produktivitätssteigerung

Genaue Maßzahlen dazu gibt es bisher natürlich nicht - dafür ist DLG einfach noch zu neu. Nach ersten Erfahrungen aber lässt sich grob abschätzen, dass die Produktivität der Software-Entwicklung mit DLG auf das 2- bis 8-fache steigt. Je nachdem, wie viel Neu- und Wartungs-Programmierung bei einem Anwender gemacht wird, und wie groß der Anteil der Software-Entwicklung ist.

Es ist mit DLG eben wie bei jeder Innovation: Solange sie noch neu ist, weiß man nicht so genau, was sie wirklich bringt. Und wenn man's erst mal genau weiß - ist es eigentlich nicht mehr so wichtig. Dann ist es ohnehin schon zu spät, noch etwas damit anzufangen …

DLG ist ein "Preprocessor" für C/C++

Programmiertechnisch gesprochen, ist das DLG-System einfach ein Preprocessor zum konventionellen C/C++. Derzeit ist erst eine Version für MS-Visual C/C++ verfügbar, die heute wohl am weitesten verbreitete Entwicklungsumgebung.

Das DLG-Prinzip ist jedoch sprachunabhängig.

Sollte sich Bedarf an weiteren Versionen ergeben, dann wird es kein Problem sein, auch diese zu produzieren.

Ursprünglich war DLG für die Programmierung von Windows-Applikationen gedacht. Inzwischen jedoch erwies es sich als universell anwendbar. Bei Bedarf sollte es daher keine Schwierigkeit sein, ein DLG-System für eine neue Klasse von Applikationen herzustellen.

DLG in der Applikations-Programmierung

Der Programmierer muss dann einfach nur

1. die Entwicklungseingebung so einstellen, dass neben den diversen Standard-Laufzeitbibliotheken von C/C++ auch  Dlg.lib  automatisch nach Externals durchsucht wird
   
   
2. am Beginn des Source-Codes eine Zeile einfügen:
   
   #include <dlg.h>
   
3. Nun können die verschiedenen DLG-Prozeduren aufgerufen werden, genau so wie die üblichen Laufzeit-Funktionen von C/C++. Im Unterschied zu diesen aber sind 1 oder 2 Parameter Option-Strings (siehe Einleitung)

DLG entspricht dem menschlichen Denken

Die Ansteuerung der DLG-Prozeduren entspricht eigentlich sehr gut dem menschlichen Denken:

• Dem Menschen ist es eher fremd, eine größere Zahl von Dingen in einer bestimmten Reihenfolge behandeln zu müssen.
  
  In DLG können Schlüsselwort-Parameter in einer beliebigen Reihenfolge kodiert werden (bis auf einige wenige Ausnahmen, auf die in der Dokumentation speziell hingewiesen wird.)
  
  
• Besonders "un-menschlich" ist es, vom Programmierer zu erwarten, für die im jew. Fall nicht benötigten Parameter "0" (oder irgendeinen anderen Default-Wert) einzusetzen.
  
  In DLG können nicht benötigte Parameter einfach weggelassen werden.
  
  
• Wer schon einmal selbst programmiert hat, der weiß, dass man da vieles "iterativ" kodieren muss: Erst einmal schreibt man etwas "versuchsweise" hin, dann muss man's wieder aus-kommentieren - aber so, dass man's jederzeit wieder aktivieren kann …
  
  In DLG können Sie jede Option in eine eigene Zeile schreiben, bei Bedarf aus-kommentieren, diese Zeile dann später wieder aktivieren, … Und wenn Sie letztlich einen kompakten Code haben wollen, dann schieben Sie zum Schluß alle Optionen dicht nebeneinander, nur durch eine Leerstelle getrennt.
  
  
• Beliebige Teile des Codes können auch in externe Files ausgelagert werden. Zum Beispiel könnte man jede Callback-Prozedur in ein eigenes File schreiben, und sie später vom Linker wieder zusammenbinden zu lassen (Stichwort: Codefragment-Technik).
  
  
• Im Gegensatz zu konventioneller Programmierung ist dank der Optionen und Callbacks von DLG auch eine variable Benutzeroberfläche möglich. Zum Beispiel könnte man den Benutzer wählen lassen, wie viele Faktoren in eine Operation eingehen sollen. Im nächsten Schritt erscheinen ebenso viele Input-Felder auf dem Bildschirm.
  
  

vorherige Seite    nächste Seite    Anfang



































Codefragment-Technik

• Das bekannte  #include -Statement kann man nicht nur benützen, um Header-Files in einen Source-code einzubeziehen. Ebenso könnte man damit auch z.B. die Beschreibung der UIF-Elemente (die sog. "Control Descriptions") auslagern. Zum Beispiel:

  Codieren Sie die Control Descriptions einer Applikation In einem File (z.B.  Ctrls.frg.cpp ):

  {stc1, "Static", … … … … … }, {edt1, "Edit", … … … … … }, :

  Mitten im Source-code inkludieren Sie dieses File ganz einfach:

  #include <dlg.h> : int WINAPI WinMain ( … ) { : CTRLDESCR Ctrls [] = { #include "Ctrls.frg.cpp" 0}; : MainWnd (…, …, Ctrls, … ); : }

  Auf diese Weise können Sie z.B. leicht mehrere Versionen einer Applikation in verschiedenen Sprachen erzeugen. Der Source-code bleibt dabei immer gleich, er wird einfach re-kompiliert mit verschiedenen Versionen von  Ctrls.frg.cpp  .