Fachsprachen: Unterschied zwischen den Versionen
Pale (Diskussion | Beiträge) K (→Generationsentwicklung von Programmiersprachenstellungen von Fachsprachen: Überschrift entwurschtelt) |
Pale (Diskussion | Beiträge) K (Progmatik -> Pragmatik) |
||
Zeile 214: | Zeile 214: | ||
Nach /Feng./<br> | Nach /Feng./<br> | ||
* Graphische Beschreibungsmittel in ähnlicher Weise definiert | * Graphische Beschreibungsmittel in ähnlicher Weise definiert | ||
− | ** Alphabet, | + | ** Alphabet, Pragmatik, Semantik wie bei Programmiersprachen |
** Syntax in Erweiterung zur Sprachendefinition Regeln für mögliche Anordnungen und nicht nur Produktion von Zeichen | ** Syntax in Erweiterung zur Sprachendefinition Regeln für mögliche Anordnungen und nicht nur Produktion von Zeichen | ||
** → Sprache + Graphen BM für Ebenenentwurf | ** → Sprache + Graphen BM für Ebenenentwurf | ||
Zeile 467: | Zeile 467: | ||
#Syntax festlegen | #Syntax festlegen | ||
#Semantik festlegen | #Semantik festlegen | ||
− | # | + | #Pragmatik festlegen |
dabei muss man darauf achten das man eine einfach Sprache entwirft die dem Problem angepasst ist. | dabei muss man darauf achten das man eine einfach Sprache entwirft die dem Problem angepasst ist. | ||
== Welche Entwurfsebenen gibt beim Sprachen Wntwurf== | == Welche Entwurfsebenen gibt beim Sprachen Wntwurf== |
Version vom 20. Juli 2008, 14:23 Uhr
Einordnung
- Begriff: Fachsprache (FS) - kein Äquivalent in englischer Literatur
- ähnliche Begriffe: Spezifikationssprachen, Special Languages (triffts am ehsten), 4.GL
- es existieren Vielzahl von FS
grobes Schema:
Eigenschaften von FS:
- eindeutig
- widerspruchsfrei
- vollständige Problemlösung
Generationsentwicklung von Programmiersprachen \ Stellungen von Fachsprachen
Folie
I. Generation
- Niveau ist binärer Maschinencode
- Abstraktionsniveau = Flip Flop
- Maschinenkenntnisse erforderlich
- Sprache spiegelt Prozessorarchitektur wieder
II. Generation
- Strukturierungsmerkmale in Assemblersprache
- symbolische Namen für Operanden, Befehle
- erste Ansätze zur Modularisierung der Programme (Makroassembler, Binder, Lader)
- Abstraktionsniveau = Register, Menge von Flip Flops
- Maschinenkenntnisse erforderlich
- Sprache spiegelt Prozessorarchitektur wieder
III. Generation
- maschinenunabhängig
- höheres Abstraktionsniveau als Register
FORTRAN - Formula Translation
- keine while-Schleife
COBOL (1954) - Common Business Oriented Language
- sehr häufig eingesetzt
- immer höhere Abstraktion
- algebraische Schreibweise
- A = B(I) + C
ALGOL 60 - Algorithmic Language
- europäische wissenschaftlich-technische Anwendung
- richtungsweisende Eigenschaften:
- Bindung von Datenobjekten (Einführung Variable, Felder) an Datentypen
- rekursive Unterprogrammtechnik
- Vereinfachung strukturierte Programmierung (Zählschleifen, while-Klausel)
- Unterstützung Selbstdoku der strukturierten Programmierung
- keine größere Bedeutung
- aber positive Eigenschaften in PASCAL
Spezialsprachen
- anwendungsorientierte Programmiersprachen = FS
- für zeitkontinuierliche Simulation:
- CSMP - Contineous System Modelling Program
- CSML - Contineous System Modelling Language
- für zeitdiskrete Simulation
- GPSS - General Purpose Simulation System
C-Unix
- verbindet Eigenschaften von Assemblersprachen mit Eigenschaften von Hochsprachen (HS)
Java
IV. Generation
- notiere "was" !
- notiere nicht "wie" !
- interaktives Arbeiten
PROLOG - logische Programmierung
- Theorembeweise über Datenbasis
Programmiersprachen
- 60. Jahre - prozedurale Abstraktion
- 70. Jahre - strukturierte Programmierung
- 80. Jahre - Modularisierung
- 90. Jahre - objektorientierte Programmierung, HTML / XML
Aussage
→ tendenziell Sprachen I... IV geeignet für Fachsprachen-Entwurf im Sinne EZ-PDV-Systeme
- günstige Eigenschaften (speziell III Generation)
- geringer Kodierungsaufwand
- hohe Zuverlässigkeit der Programme
- stark verbsesserte Selbsdokumentation
- erfüllbare Hardwareanforderungen
- Mangel der Sprachen der III- Generation für PDV- Programmierung
- eingeschränkte bzw. keine EZ-Fähigkeit
- Compiler erzeugen meist ineffizienten Code
- Unzureichende Verarbeitung spezieller Operationen (Analogsignale/Binärsignale)
- Versuch der Lösung der EZ-Probleme
- Spracherweiterung für prozeßgekoppelte Datenverarbeitung
- Spracherweiterung im Sinne Parallelprogrammierung
- Implementierung von EZ-Verarbeitungen
Fazit:
- Erfordernis von Fachsprachen in EZ-Systemen
- angepaßte Fachsprachen nach Anwendungsfall
Rolle von Fachsprachen bei PDV-Systementwurf
Tendenz
- Embedet Systeme
- CAN-Bus
- EBS (1..20 Kb, Konfigurierbar)
- C-Compiler
- CPU
- 32-bit
- 64-256 kb Speicher
- AD/DA Kanäle
- CTC, Bin E/A
- Kommunikationskontroler
Anforderung an Fachsprachen der PDV aus Anwendersicht
- Realisierung EZ-Fähigkeit
- erhöhte Ausdrucksmächtigkeit
- Berücksichtigung der Entwurfs und Anwenderspezifikation
- Effizienz von Laufzeit und Speicher
- Komfortabel (analog Hochsprache)
- Funktionsoffen (Modularität, Erweiterbarkeit)
- einfache Erlernbarkeit, Anwendung
- Selbstdokumentation
- Verfügbarkeit/Preis
PDV System als Gegenstand der Fachsprachen Anwendung
- Aussage – PDV System – Struktur
- Aussage – Entwurf
- Anforderung + Eigenschaften von Fachsprachen
- exemplarische Fachsprachen
- Beachtung von Eigenschaften und Forderungen Allgemein → Ableiten einer verallgemeinerten Fachsprache
Allgemeine Aspekte der Begriffe, Automatisierung
- Nach Neumann:
- on-line Kopplung Automatisierungseinrichtungen → Prozess
- Echtzeit-Informationsgewinnung und Verarbeitung
- Forderung der Einhaltung und Prioritätsvorgaben
- Niveau der Automatisierungseinrichtung orientiert sich am Prozess
- Systemgedanke
- im Systemgedanken deutliche Niveaustufen möglich/sinvoll
Abgrenzung auf Problemklassen
- Alle Ebenen sind/bleiben berechtigt
- weiter auf 2.) konzentrieren
- Koppelbarkeit zu hierarchischen Systemen soll gegeben sein
- BILD: Kommunikation in PDV Systemen
Systemkommunikation
- Gewinnung und Darstellung von Informationen über Systemsignalen und Zustände der Automatisierungsanlage (AA) für Bediener und
- gezielte Beeinflussung dieser im Dialog
- Prozesskomunikation
- Signalwege und Darstellung der Größen des technischen Prozesses für Bediener
- Prozessbeeinflussung in Echtzeit und Dialogbetrieb
- Erforderlich weil:
- Realisierungsart, -tiefe von den Ebenen und den Anforderungen an die Kommunikation abhängig ist
Allgemeine Betrachtung zur Entwurfsmethodik
- Entwurf ist Festlegung der Struckturierung und Funktion des Systems
- Entwicklung ist die Kombination von Analyse und Synthese
- funktionelle Entwicklung → Abbildung von Eingangsfolgen auf Ausgangsfolgen
- strukturelle Entwicklung → Menge der Systeme realisierbarer Strukturelemente und deren Verkopplungen
- Funktion + Struktur = Architektur
<graphviz> digraph R {
node [shape=box];
Fachsprachen -> "Struckturentwurf (Methodik Hardwareentwurf)" Fachsprachen -> Funktionsentwurf } </graphviz>
Funktionsentwurf
- Konstruktionsprozess (detail Entwurf)
- Fertigungsentwurf (Kodeierung + Test)
Modellierung
- Modelle bezüglich des Fachgebietes
- Grundlage für die Ableitung einer speziellen FS
Strukturmodell
SM = (M, RM)
M... Menge der Modelle (Fertigungseinheit mit spezieller Funktion z.B. ADU)
RM ... Relation der Module (Aufrufer, Verbindungen, Benutzerelation)
Funktionsmodell
FM(A,D,U,DER,SFR,MR,DR)
- A ... Menge der Elemente vom Type Action
- D ... Menge der Elemente vom Type Daten
- U ... Menge der Elemente vom Type Umwelt
- DER ... Datenrelationen
- SFR ... Steuerflußrelationen
- MR ... Mittelrelationen
- Problem:
- kürzester Weg beim Entwurf erwünscht (bei häufigem Entwurf)
- effektiv für Struktur + Funktion mit angepaßten FS
Entwurf
Nach /Feng./
- Graphische Beschreibungsmittel in ähnlicher Weise definiert
- Alphabet, Pragmatik, Semantik wie bei Programmiersprachen
- Syntax in Erweiterung zur Sprachendefinition Regeln für mögliche Anordnungen und nicht nur Produktion von Zeichen
- → Sprache + Graphen BM für Ebenenentwurf
- Entwurfsmethodik zu Sprachen ist erst
- feste Regeln für den Entwurfsweg
- für jeden Schritt ein geeignetes (problembezogenes) BM
- Testmittel
- Zurverfügungstellen
Inhalt der Entwurfsmethodik
- charakterisiert:
- Auswahl der notwendigen Entwurfsebenen
- Def/Auswahö der BM für die Ebenen
- Breitstellung von Regeln zur Symatischen Bildung der Spezifikationsmegen
- Angaben von Analysemethoden zur Prüfung der Richtigkeit der Entwurfsschritte
- Ebeneneinteilung → Problem: virtuelle Maschine → vertikal
PDV-Systeme
- virtuelle Maschine für
- Monitor (Anzeige Bediener)
- Steuerprogrammsystem (BS)
- Anwenderprogramm (Anwender alg. Problemnotation)
Festlegung der Entwurfsebene
vertikale Systemzerlegung
(4) Geräte-Ebene
(3) Funktionsblock-Ebene
(2) Elementarprozess-Ebene
(1) Maschinen-Ebene (Prozess)
(0) Logikebene
Anforderung mittlerer PDV
- Anatomie (→ Anforderung an Prozesskomunikation)
- begrenzte Funktionsiffenheit (→ Anforderung an Systemkommunikation)
- Koppelbarkeit
→ Entwurf eines Systems bedeutet die Funktionsfestlegung über Systemstruktur für due Komponenten
- Verarbeitungsfunktioin
- Kommunikationsfunktion
- Synchronisationsfunktion
- Funktionen der Schaltungstechnik für betrachtete Klassen der PDV-Systeme
→ Schaltungstechnik:
- Vorraussetzungsmäßig vorkonfektionierte Systeme !
Grundhardware
- für ein Maximum/optimum vorbereitete Funktionsumfang
- Definierte Schnittstelllen zum erweitern/konfektionieren
- Entwurf auf Geräteebene
- E/A-Bus
- Signaldefinition
- Software für E/A-Transfer (z.B. lesen von analogen Werten von Knoten ADU)
Einsatz von Srpachen in den spezifischen Ebenen
- Sprachniveaus in den Entwurfsebenen (0) ... (4) sinvoll zuordenbar
- Beispiel für FS: CONTROLIC C, MPSS, PROGMAR
- Hochsprachen: Pearl, C, Form, ADA
- für Geräte-Ebene (4)
- → Entwurf auf FS-Niveau möglich/sinvoll
- Kennzeichen von Fachsprachen
Entwurf einer Fachsprache für die abgeleitete Problemklasse
- Fachsprache gekennzeichnet durch:
- Darstellung in für Fachmann eideutige interpretierbarer Form (Anweisung = problembezeichnende Grundfunktion)
- einfache Rückdarstellbarkeit durch genormte Darstellung
- Effizienz Speicher und Laufzeit
- erhöhte Programmsicherheit/nach einmaliger Herstellung nur Wiederverwendung
- einfache Übersetzungsstrukturen gegenüber Hochsprachen
- hoher Standardisierungsgrad der Anwendungdprogramme möglich
- Sprachelemete für Echtzeitverabreitung
- einfach Überarbeitbarkeit und Service
- Wunsch
- Verarbeitung (Funktion) orientierte Notation
- Steuerung, EZ-Ablauf implizit erfolgt
Spezifik beim Problementwurf mit FS
→ sinnvolle Ebenen für Probelmentwurf
- E0: Analyse un Notation des Problems am EWS bzw frei
- E1: Zwischenübersetzung in (nicht graphische) Zielsprache
- E2: Problemnotation auf EWS (Entwurfssystem)
- E3: Test bzw. Simulation auf EWS
- E4: Auslagern auf Zielsystem
- E5: Echtzeitsystem + Test am Zielsystem
- E6: Struktur-, Parameteranpassung am Zielsystem
- E7: Rückdokumentation und Erstellung Systemunterlagen
- E8: Emulation des Problems mit EWS
- Voraussetzung:
- Schnittstellen wie bei Zielsystem
- EZ-Verhalten wie bei Zielsystem
- Koppelbarkeit
- Voraussetzung:
Realisierung einer Beispiel Fachsprache
Abarbeitung von FS:
- nach Kompilation
- Interpretation
- Modulgedanke / Programmodul/ Komponente/Objekt Interpretation ist effizienter Weg zur Realisierung
Modulgedanke
- Standard
- Darstellbarkeit
- Überführbarkeit
- Selbsdokumentation
Organisation der Programm-Bausteine
- → Standard für Programm-Austausch
- [BILD Programm]
- S1: Nutzung des Programm-Bausteins im Anwenderprogramm nur über diese Schnittstelle möglich
- S2: Schnittstelle Modul zu UP-Bibliothek (Elementarprozess)
- Modul:
- Verarbeitungsfunktion
- Schnittstelle Organisieren
- Bereitstellen E-Parameter
- Verarbeiten A-Parameter
- def. Programmabsprung
- Fehlerbehandlung im PR Baustein
Übergabe der Prameter
- Organisation von Schnittstellen
- Übergabe von Parametern
- Übergabe von Parameter-Adresse (Zeiger)
Realisierungsstuktur für die Beispielfachsprache
- Interpreter FS
- Akkumulatorprinzip
- lineare Assembler Notation
- Prameter: Symbol (Pi)
- Variablen: Symbol (Xj)
- → Endlich
- [Programm + PAP]
Entwurf Systemkomponente Verarbeitungsfunktion
- Steuerfunktion (BS, ESBS)
- Monitor (Anzeige, Pedienung, Programme, Dialogeinheit)
- Verarbeitungsfunktion Problemnotation
Auswahl der Beschreibungssprache
- Viele Sprachniveaus
- Assembler
- Hochsprache
- Fachsprache
[BILD Sprachen]
Analyse von Fachsprachen zum Entwurf der Verarbeitungsfunktion
- Betrachtung bezüglich Domäne
- Verfahrenstechnischer Prozess
- Gebäudezentralisierung/Gebäudeautomatisierung
- Kraftstofftechnik
Auswahl der FS zur P-Notation über Merkmale
- Einsatz von Grafik
- bei Synthese
- bei Überführung des Problems auf EWS
- für Simulation
- für Anlagenzustände
- autonome/funktionsoffene koppelbare PDV-EZ-Systeme
== Anforderung an Steuerstruktur von FS für P-Notation
- a.) <graphviz>
digraph R {
node [shape=box];
S -> V } </graphviz>
- Trennung von Steuerfunktion und Verabeitungsfunktion
- S = BS-Funktion
- Zeitinterrupt Ts-Sprünge, Synchronisation
- V = Verarbeitungsfunktion (PID-Regler)
- b.)
- [BILD Verarbeitungsfunktionen]
- c.)
- [BILD Dynamische Steuerstruktur]
- Beschreibung
- V- Datenflußorientiert (FS)
- S- Netz (PN)
Strukturanforderung an FS aus Prozeßbedingungen
- Definition von drei Prozeßklassen sinnvoll:
- a.) geplante Prozesse
- laufen ab als Ergebnis einer Einplanung
- <graphviz>
- a.) geplante Prozesse
digraph R {
node [shape=box];
"aus Planungsfunktion" -> "Einplanung" "aus Planungsfunktion" -> "Ausplanung" }</graphviz>
- z.B. Führungswertvorgabe
- zeitplanung/zyklisch/Zeitpunktorientiert/n-malig
- z.B. Führungswertvorgabe
- b.) abfolgegesteuerte Prozesse
- Prozess läuft nach Beendigung des vorherigen
- c.) parallele Prozesse
- absolut parallel
- synchronisiert parallel
Anforderung aus Spezifikation der Verarbeitungsfunktion
- Zeitvariantes System
- Ts- als Parameter
- Zeitinvariantes System
- Ts- kein Parameter
- Definition der Abtastrate nach Prozesszustand
- Prioritäten Problem
- weitgehend offene Architektur
- A:= (S Fi and F,s)
- → mögliche Fachsprachen Modelle zur Erfüllung der Forderung
- Auswahl: allgemeine Steuerstruktur S und V
Steuerstruktur verarbeitender FS
- Effizienter Ansatz zur Beschreibung der Steuerstruktur von FS-Anwendungen ist Realisierung der Anwendung als Zustandsmaschine (ZM)
- endlicher (zyklischer) Automat
- Die Steuerstruktur (S' bzw S") ist als Kommunikationsnetz (KN) notierbar
- Definition von EZM und KN
- ZM= (P,T,F,ms) ist Zustandsmaschine
- p^k Element P^k ist Kommunikationsnetz
[viele unwichtige Formeln und son Kram]
- Einordnung:
- Aktivitäten → Platz (A1,A2)
- KN Kapazitäten >1 realisierbar
- Starten/Synchronisieren möglich
- Steuerstruktur realisiert grundlegende Anforderung an FS
- verteilte Algorithmen
- Unterscheidung von Eingabe und Ausgabe Tastzeiten
- Kommuniaktions-, Synchronisationsfunktion
- [BILD mögliche Notation]
- sinnvoll angepasste Steuersturktur (abweichend von Allgemein)
- Verarbeitung
- Planungsfunktion
- Ein/Ausgabedaten
programmtechnische Realisierung
- für aufwandsminimale Realisierung ist sinnvoll:
- Aktivitäten (FS-Makro) als auch Transitionen der EZM durch interpretativ abarbeitbare FS-Befehle (Elementare FS-Befehle) zu realisieren
- Elementar FS Befehle
- Algorithmen
- Trasitionsbearbeitung
- Zeigeroperationen
- def angepasster FS-Steruerstrukturen möglich durch Kombination der 3 Elementar FS-Befehle
- [Bild: Beispiel Template]
- Zeigerprozedur
- ermöglicht:
- Zusammenfassen von Knoten (FS-Anweisungen) zur Prioritätsebenen (Verarbeitungsketten)
- Kettenverzweigungen möglich
- ermöglicht:
Spezielle Steuerstrukturen und FS-Anweisungen
- Oberhalb des Grundmodells
- für aufwandsminimale Realisierung
- resultiert aus Prozessanfordrung an FS
- Ableitung aus Grundmodell durch:
- angepaßte Realisierung der Transition (t1..t3)
- angepaßte Realisierung der Aktivitäten (A1 .. A2)
- spezielle Anwendung Zeigerprozedur
- erforderliche Modelle für
- Verarbeitung
- Planung
- E/A Funktion
- → Bilder
Defintion einer Gerätefachsprache
Graphische Beschreibung
- V- Datenflußorientiert
- S- Netzstruktur
- → Beginn: Definition der Vollständigen Syntax
- → Bilder
FS FAQ
Was ist ein Fachsprache (FS)
Eine Fachsprache ist ein Programmiersprache die speziell an spezifische Probleme angepasst wurde. Mit ihr ist ein Experte in der Lage schnell Algorithmen zur Lösung der Probleme zu entwickeln.
Welche Notationen von FS gibt es
Fachsprache können in graphischer als auch in normaler Textueller form notiert werden.
Was kennzeichnet eine Fachsprache gegenüber einer Hochsprache
Fachsprachen sind grenzen sich von Hochsprache darin ab das sie:
- eine Darstellung nutzen die dem Experten geläufig ist so das er keine Einarbeitungszeit benötigt
- dem Programmiere viel Aufwand abnimmt durch Wiederverwenbarkeit von Modulen und Problemspezifischen Befehlen
- durch genormte Darstellung kann aus dem Programmcode gut der Entwurf zurückgewonnen werden
- sehr gute Selbstdokumentation
Wie entwerfe ich meine eigene FS
Eine Fachsprache wird Entworfen fast wie jede andere Sprache:
- Alphabet festlegen
- Syntax festlegen
- Semantik festlegen
- Pragmatik festlegen
dabei muss man darauf achten das man eine einfach Sprache entwirft die dem Problem angepasst ist.
Welche Entwurfsebenen gibt beim Sprachen Wntwurf
(4) Geräte-Ebene
(3) Funktionsblock-Ebene
(2) Elementarprozess-Ebene
(1) Maschinen-Ebene (Prozess)
(0) Logikebene
Welche sinnvollen Ebenen wähle ich beim Probelmentwurf mit Fachsprachen
- E0: Analyse un Notation des Problems am EWS bzw frei
- E1: Zwischenübersetzung in (nicht graphische) Zielsprache
- E2: Problemnotation auf EWS (Entwurfssystem)
- E3: Test bzw. Simulation auf EWS
- E4: Auslagern auf Zielsystem
- E5: Echtzeitsystem + Test am Zielsystem
- E6: Struktur-, Parameteranpassung am Zielsystem
- E7: Rückdokumentation und Erstellung Systemunterlagen
- E8: Emulation des Problems mit EWS
Warum sollte ich meine FS-Programm Modula aufbauen
- einfach standardisierbar
- Module können gut in Graphischen Elementen Dargestellt werden
- einfache Wiederverwendung möglich
- trägt zur Selbstdokumentation bei
Welche Funktionen sollte mein FS-Modul beinhalten
- Verarbeitungsfunktionen
- Funktionen zur Schnittstellenorganisation
- Bereitstellen von Eingabe Parametern
- Ausgabeparametern (Ergebnisse)
- Definiton von Programmeinsprungspunkten/Programmabsprunkgspunkte
- Fehlerbehandlung
Warum teile ich Programme in Steuerstrukturen und Verarbeitungstrukturen
- Steuerstrukturen sin einfach mit Petrinetzen darstellbar und lassen sich in einer Hochsprache deutlich besser realisieren oder man benötigt eine weitere Fs die spezielle Befehle zu Steuerung besitzt. Ausserdem werden die meisten Steuerfunktionen bereits vom BS übernommen.
- Verarbeitungssturkturen sind die Spezialität von Fachsprachen in ihnen ist die Verarbeitung von Eingabe in Ausgabeparameter leicht zu realisieren.