Ich werde kurz die Hauptaufgabe beschreiben
Es besteht darin, eine solche Programmiersprache zu erstellen, die sowohl zur Beschreibung des Domänenmodells als auch zur Arbeit damit geeignet ist. Um die Beschreibung des Modells so natürlich wie möglich, für den Menschen verständlich und nahe an den Spezifikationen der Software zu machen. Gleichzeitig muss es Teil des Codes in einer vollwertigen Programmiersprache sein. Dafür wird das Modell die Form einer Ontologie haben und aus konkreten Fakten, abstrakten Konzepten und Beziehungen zwischen ihnen bestehen. Fakten beschreiben die direkte Kenntnis des Themenbereichs sowie Konzepte und logische Beziehungen zwischen ihnen - seine Struktur.
Zusätzlich zu den Modellierungswerkzeugen benötigt die Sprache auch Werkzeuge zum Vorbereiten der Anfangsdaten für das Modell, zum dynamischen Erstellen seiner Elemente, zum Verarbeiten der Ergebnisse von Abfragen an das Modell und zum Erstellen der Modellelemente, die in algorithmischer Form bequemer zu beschreiben sind. All dies ist viel bequemer, wenn die Abfolge der Berechnungen explizit beschrieben wird. Zum Beispiel mit OOP oder einem funktionalen Ansatz.
Und natürlich müssen beide Teile der Sprache eng miteinander interagieren und sich ergänzen. Damit sie einfach in einer Anwendung kombiniert werden können und jede Art von Problem mit dem bequemsten Werkzeug lösen können.
Ich werde meine Geschichte mit der Frage beginnen, warum überhaupt eine solche Sprache geschaffen wird, warum eine hybride Sprache und wo sie nützlich wäre. In den nächsten Artikeln möchte ich einen kurzen Überblick über Technologien und Frameworks geben, mit denen Sie deklarativen Stil mit imperativem oder funktionalem kombinieren können. Darüber hinaus wird es möglich sein, die Sprachen zur Beschreibung von Ontologien zu überprüfen, die Anforderungen und Grundprinzipien einer neuen hybriden Sprache und vor allem ihre deklarative Komponente zu formulieren. Beschreiben Sie abschließend die grundlegenden Konzepte und Elemente. Danach werden wir untersuchen, welche Probleme auftreten, wenn das deklarative und das imperative Paradigma zusammen verwendet werden und wie sie gelöst werden können. Wir werden auch einige Probleme der Sprachimplementierung analysieren, zum Beispiel den Inferenzalgorithmus. Schauen wir uns zum Schluss eines der Anwendungsbeispiele an.
Die Wahl des richtigen Programmiersprachenstils ist eine wichtige Voraussetzung für die Codequalität
Viele von uns mussten sich mit der Unterstützung komplexer Projekte befassen, die von anderen Menschen erstellt wurden. Es ist gut, wenn das Team Leute hat, die mit dem Projektcode vertraut sind und erklären können, wie er funktioniert, es gibt Dokumentation, der Code ist sauber und verständlich. In der Realität geschieht dies jedoch häufig auf andere Weise: Die Autoren des Codes haben das Programm beendet, lange bevor Sie zu diesem Projekt gekommen sind, es gibt überhaupt keine Dokumentation, oder es ist sehr fragmentarisch und vor langer Zeit veraltet, und es geht um die Geschäftslogik der erforderlichen Komponente, eines Geschäftsanalysten oder eines Projekts - Der Manager kann nur allgemein sagen. In diesem Fall ist die Sauberkeit und Verständlichkeit des Codes von entscheidender Bedeutung.
Die Qualität des Codes hat viele Aspekte, einer davon ist die richtige Wahl der Programmiersprache, die dem zu lösenden Problem entsprechen sollte. Je einfacher und natürlicher ein Entwickler seine Ideen in den Code implementieren kann, desto schneller kann er das Problem lösen und desto weniger Fehler wird er machen. Wir haben jetzt eine ziemlich große Anzahl von Programmierparadigmen zur Auswahl, von denen jedes seinen eigenen Anwendungsbereich hat. Beispielsweise ist die funktionale Programmierung für rechnerorientierte Anwendungen vorzuziehen, da sie mehr Flexibilität beim Strukturieren, Kombinieren und Wiederverwenden von Funktionen bietet, die Operationen an Daten ausführen. Objekt orientierte Programmierungvereinfacht die Erstellung von Strukturen aus Daten und Funktionen durch Kapselung, Vererbung und Polymorphismus. OOP eignet sich für datenorientierte Anwendungen. Die Logikprogrammierung eignet sich für regelbasierte Probleme, bei denen mit komplexen, rekursiv definierten Datentypen wie Bäumen und Diagrammen gearbeitet werden muss, und eignet sich zur Lösung kombinatorischer Probleme. Auch reaktive, ereignisgesteuerte Multi-Agent-Programmierung hat ihren Umfang.
Moderne universelle Programmiersprachen können mehrere Paradigmen unterstützen. Die Kombination der funktionalen und OOP-Paradigmen ist seit langem zum Mainstream geworden.
Die hybride funktionale Logikprogrammierung hat ebenfalls eine lange Geschichte, ging jedoch nie über die akademische Welt hinaus. Am wenigsten wird auf die Kombination von logischer und zwingender OOP-Programmierung geachtet (ich plane, in einer der nächsten Veröffentlichungen ausführlicher darauf einzugehen). Obwohl meiner Meinung nach ein logischer Ansatz im traditionellen Bereich der OOP-Server-Anwendungen von Unternehmensinformationssystemen sehr nützlich sein könnte. Sie müssen es nur aus einem etwas anderen Blickwinkel betrachten.
Warum ich den deklarativen Programmierstil unterschätzt finde
Ich werde versuchen, meinen Standpunkt zu untermauern.
Überlegen Sie sich dazu, was eine Softwarelösung sein kann. Die Hauptkomponenten sind: der Client-Teil (Desktop-, Mobil-, Webanwendungen); Serverseite (eine Reihe separater Dienste, Mikrodienste oder eine monolithische Anwendung); Datenverwaltungssysteme (relationale, dokumentenorientierte, objektorientierte, Graphendatenbanken, Caching-Dienste, Suchindizes). Eine Softwarelösung muss mit mehr als nur Menschen interagieren - Benutzern. Die Integration mit externen Diensten, die Informationen über die API bereitstellen, ist eine häufige Aufgabe. Datenquellen können auch Audio- und Videodokumente, Texte in natürlicher Sprache, Inhalte von Webseiten, Ereignisprotokolle, medizinische Daten, Sensorwerte usw. sein.
Einerseits speichert eine Serveranwendung Daten in einer oder mehreren Datenbanken. Auf der anderen Seite reagiert es auf Anforderungen von API-Endpunkten, verarbeitet eingehende Nachrichten und reagiert auf Ereignisse. Die Strukturen von Nachrichten und Abfragen stimmen fast nie mit den in Datenbanken gespeicherten Strukturen überein. Eingabe- / Ausgabedatenformate sind für den externen Gebrauch konzipiert, für den Verbraucher dieser Informationen optimiert und verbergen die Komplexität der Anwendung. Gespeicherte Datenformate werden für ihr Speichersystem optimiert, beispielsweise für ein relationales Datenmodell. Daher benötigen wir eine Zwischenschicht von Konzepten, die es ermöglichen, die Eingabe / Ausgabe von Anwendungen mit Datenspeichersystemen zu kombinieren. In der Regel wird diese Middleware-Schicht als Geschäftslogikschicht bezeichnet und implementiert die Regeln und Prinzipien für das Verhalten von Domänenobjekten.
Die Verknüpfung von Datenbankinhalten mit Anwendungsobjekten ist ebenfalls nicht einfach. Wenn die Struktur der Tabellen im Speicher mit der Struktur der Konzepte auf Anwendungsebene übereinstimmt, können Sie die ORM-Technologie verwenden. Für komplexere Fälle als den Zugriff auf Datensätze über Primärschlüssel- und CRUD-Operationen müssen Sie jedoch eine separate Logikebene für die Arbeit mit der Datenbank zuweisen. In der Regel ist das Datenbankschema so allgemein wie möglich, sodass verschiedene Dienste damit arbeiten können. Jeder von ihnen ordnet dieses Datenschema seinem eigenen Objektmodell zu. Die Struktur der Anwendung wird noch verwirrender, wenn die Anwendung nicht mit einem Datenspeicher, sondern mit mehreren unterschiedlichen Typen arbeitet und Daten aus Quellen von Drittanbietern beispielsweise über die API anderer Dienste lädt.In diesem Fall ist es erforderlich, ein einheitliches Domänenmodell zu erstellen und Daten aus verschiedenen Quellen zuzuordnen.
In einigen Fällen kann das Domänenmodell eine komplexe mehrstufige Struktur aufweisen. Beispielsweise können beim Erstellen von Analyseberichten einige Indikatoren auf der Grundlage anderer erstellt werden, die wiederum eine Quelle für die Erstellung des dritten usw. darstellen. Außerdem können die Eingabedaten eine halbstrukturierte Form haben. Diese Daten haben kein striktes Schema, wie beispielsweise im relationalen Datenmodell, enthalten jedoch eine Art Markup, mit dem Sie nützliche Informationen daraus extrahieren können. Beispiele für solche Daten können Semantic Web-Ressourcen, Web Scraping-Ergebnisse, Dokumente, Ereignisprotokolle, Sensorablesungen, Vorverarbeitungsergebnisse für unstrukturierte Daten wie Texte, Videos und Bilder usw. sein. Das Datenschema dieser Quellen wird ausschließlich auf Anwendungsebene erstellt. Es wird auch einen Code geben,Konvertieren der Quelldaten in Geschäftslogikobjekte.
Die Anwendung enthält also nicht nur Algorithmen und Berechnungen, sondern auch eine große Menge an Informationen über die Struktur des Domänenmodells - die Struktur seiner Konzepte, ihre Beziehungen, Hierarchien, Regeln für die Erstellung einiger Konzepte auf der Grundlage anderer, Regeln für die Transformation von Konzepten zwischen verschiedenen Ebenen der Anwendung usw. Wenn wir eine Dokumentation oder ein Projekt erstellen, beschreiben wir diese Informationen deklarativ - in Form von Strukturen, Diagrammen, Aussagen, Definitionen, Regeln, Beschreibungen in natürlicher Sprache. Es ist bequem für uns, so zu denken. Leider ist es nicht immer möglich, diese Beschreibungen im Code auf dieselbe natürliche Weise auszudrücken.
Betrachten wir ein kleines Beispiel und spekulieren, wie die Implementierung unter Verwendung verschiedener Programmierparadigmen aussehen wird
Angenommen, wir haben 2 CSV-Dateien. In der ersten Datei:
Die erste Spalte enthält die Client-ID.
Die zweite enthält das Datum.
Im dritten - dem Rechnungsbetrag,
im vierten - dem Zahlungsbetrag.
In der zweiten Datei:
In der ersten Spalte wird die Client-ID
gespeichert . Im zweiten der Name. Der dritte ist die E-Mail-Adresse.
Lassen Sie uns einige Definitionen einführen:
Die Rechnung enthält die Kunden-ID, das Datum, den Rechnungsbetrag, den Zahlungsbetrag und die Schulden aus den Zellen einer Zeile der Datei 1.
Der Schuldenbetrag ist die Differenz zwischen dem Rechnungsbetrag und dem Zahlungsbetrag.
Der Kunde wird anhand der Kunden-ID, des Namens und der E-Mail-Adresse aus den Zellen einer Zeile in Datei 2 beschrieben.
Eine unbezahlte Rechnung ist eine positive Schuldenrechnung.
Konten sind über den Kunden-ID-Wert mit einem Kunden verknüpft.
Ein Schuldner ist ein Kunde, der mindestens eine unbezahlte Rechnung hat, deren Datum 1 Monat älter ist als das aktuelle Datum.
Ein böswilliger Schuldner ist ein Kunde, der mehr als 3 unbezahlte Rechnungen hat.
Darüber hinaus ist es unter Verwendung dieser Definitionen möglich, die Logik zu implementieren, eine Erinnerung an alle Schuldner zu senden, Daten über böswillige Säumige an Sammler zu übermitteln, eine Strafe für die Höhe der Schulden zu berechnen, verschiedene Berichte zu erstellen usw.
In funktionalen ProgrammiersprachenEine solche Geschäftslogik wird unter Verwendung einer Reihe von Datenstrukturen und -funktionen für ihre Transformation implementiert. Darüber hinaus sind Datenstrukturen grundsätzlich von Funktionen getrennt. Infolgedessen ist das Modell und insbesondere seine Komponente, wie z. B. die Beziehungen zwischen Entitäten, in einer Reihe von Funktionen verborgen, die über den Programmcode verschmiert sind. Dies schafft eine große Lücke zwischen der deklarativen Beschreibung des Modells und seiner Softwareimplementierung und erschwert sein Verständnis. Besonders wenn das Modell ein großes Volumen hat.
Programm objektorientiert strukturierenStil hilft, dieses Problem zu mildern. Jede Domänenentität wird durch ein Objekt dargestellt, dessen Datenfelder den Attributen der Entität entsprechen. Und Beziehungen zwischen Entitäten werden in Form von Beziehungen zwischen Objekten implementiert, teilweise basierend auf den Prinzipien von OOP - Vererbung, Datenabstraktion und Polymorphismus, teilweise - unter Verwendung von Entwurfsmustern. In den meisten Fällen müssen Beziehungen jedoch implementiert werden, indem sie in Objektmethoden codiert werden. Zusätzlich zum Erstellen von Klassen, die Entitäten darstellen, benötigen Sie Datenstrukturen zum Ordnen, Algorithmen zum Füllen dieser Strukturen und zum Suchen nach Informationen in ihnen.
Im Beispiel mit Schuldnern können wir Klassen beschreiben, die die Struktur der Konzepte "Konto" und "Kunde" beschreiben. Die Logik zum Erstellen von Objekten, Verknüpfen von Konto- und Kundenobjekten miteinander wird jedoch häufig separat in Factory-Klassen oder -Methoden implementiert. Für die Konzepte von Schuldnern und unbezahlten Rechnungen werden überhaupt keine separaten Klassen benötigt. Ihre Objekte können durch Filtern von Kunden und Rechnungen dort erhalten werden, wo sie benötigt werden. Infolgedessen werden einige Konzepte des Modells explizit, andere implizit, auf Objektebene in Form von Klassen implementiert. Einige der Beziehungen zwischen Konzepten befinden sich in den Methoden der entsprechenden Klassen, andere sind getrennt. Die Implementierung des Modells wird über Klassen und Methoden hinweg verschmiert, gemischt mit der Hilfslogik seiner Speicherung, Suche, Verarbeitung und Formatkonvertierung. Das Finden und Verstehen dieses Modells im Code erfordert einige Anstrengungen.
Der Beschreibung am nächsten kommt die Implementierung des konzeptionellen Modells in Wissensrepräsentationssprachen . Beispiele für solche Sprachen sind Prolog, Datalog, OWL, Flora und andere. Ich habe vor, in der dritten Veröffentlichung über diese Sprachen zu sprechen. Sie basieren auf Logik erster Ordnung oder ihren Fragmenten, beispielsweise beschreibender Logik. Diese Sprachen ermöglichen es in deklarativer Form, die Spezifikation der Lösung des Problems anzugeben, die Struktur des modellierten Objekts oder Phänomens und das erwartete Ergebnis zu beschreiben. Die integrierten Suchmaschinen finden automatisch eine Lösung, die die angegebenen Bedingungen erfüllt. Die Implementierung des Domänenmodells in solchen Sprachen wird äußerst präzise, verständlich und der Beschreibung in natürlicher Sprache nahe kommen.
Beispielsweise wird die Umsetzung des Problems mit Schuldnern in Prolog den Definitionen aus dem Beispiel sehr nahe kommen. Dazu müssen die Tabellenzellen als Fakten dargestellt und die Definitionen aus dem Beispiel als Regeln dargestellt werden. Um Konten und Kunden zu vergleichen, reicht es aus, die Beziehung zwischen ihnen in der Regel anzugeben, und ihre spezifischen Werte werden automatisch angezeigt.
Zunächst deklarieren wir Fakten mit dem Inhalt der Tabellen im Format: Tabellen-ID, Zeile, Spalte, Wert:
cell(“Table1”,1,1,”John”). Dann geben wir jeder der Spalten Namen:
clientId(Row, Value) :- cell(“Table1”, Row, 1, Value).Dann können Sie alle Spalten zu einem Konzept zusammenfassen:
bill(Row, ClientId, Date, AmountToPay, AmountPaid) :- clientId(Row, ClientId), date(Row, Date), amountToPay(Row, AmountToPay), amountPaid(Row, AmountPaid).
unpaidBill(Row, ClientId, Date, AmountToPay, AmountPaid) :- bill(Row, ClientId, Date, AmountToPay, AmountPaid), AmountToPay > AmountPaid.
debtor(ClientId, Name, Email) :- client(ClientId, Name, Email), unpaidBill(_, ClientId, _, _, _).Usw.
Bei der Arbeit mit dem Modell treten Schwierigkeiten auf: bei der Implementierung der Logik zum Senden von Nachrichten, zum Übertragen von Daten an andere Dienste und zu komplexen algorithmischen Berechnungen. Prologs Schwachstelle ist die Beschreibung von Handlungsabläufen. Ihre deklarative Umsetzung kann selbst in einfachen Fällen sehr unnatürlich aussehen und erfordert erhebliche Anstrengungen und Fähigkeiten. Darüber hinaus kommt die Syntax von Prolog dem objektorientierten Modell nicht sehr nahe, und Beschreibungen komplexer zusammengesetzter Konzepte mit einer großen Anzahl von Attributen sind ziemlich schwer zu verstehen.
Wie bringen wir die gängige funktionale oder objektorientierte Entwicklungssprache mit dem deklarativen Charakter des Domänenmodells in Einklang?
Der bekannteste Ansatz ist das objektorientierte Design (Domain-Driven Design). Diese Methodik erleichtert die Erstellung und Implementierung komplexer Domänenmodelle. Es schreibt vor, dass alle Modellkonzepte explizit in der Geschäftslogikschicht im Code ausgedrückt werden. Die Konzepte des Modells und die Elemente des Programms, die sie implementieren, sollten so nah wie möglich beieinander liegen und einer einzigen Sprache entsprechen, die sowohl für Programmierer als auch für Fachexperten verständlich ist.
Ein umfangreiches Domänenmodell für das Beispiel mit Schuldnern enthält zusätzlich Klassen für die Konzepte "Unbezahlte Rechnung" und "Schuldner", aggregierte Klassen zum Kombinieren der Konzepte von Konten und Kunden, Fabriken zum Erstellen von Objekten. Die Implementierung und Unterstützung eines solchen Modells ist zeitaufwändiger und der Code umständlich. Was zuvor in einer Zeile ausgeführt werden konnte, erfordert mehrere Klassen in einem umfangreichen Modell. In der Praxis ist dieser Ansatz daher nur dann sinnvoll, wenn große Teams an komplexen Modellen arbeiten.
In einigen Fällen kann die Lösung eine Kombination aus einer grundlegenden funktionalen oder objektorientierten Programmiersprache und einem externen Wissensrepräsentationssystem sein.... Das Domänenmodell kann auf eine externe Wissensdatenbank übertragen werden, z. B. in Prolog oder OWL, und das Ergebnis von Abfragen wird auf Anwendungsebene verarbeitet. Dieser Ansatz erschwert jedoch die Lösung. Dieselben Entitäten müssen in beiden Sprachen implementiert werden. Die Interaktion zwischen ihnen muss über die API eingerichtet werden, die zusätzlich vom Wissensrepräsentationssystem usw. unterstützt wird. Daher ist es nur gerechtfertigt, wenn das Modell groß und komplex ist und logische Schlussfolgerungen erfordert. Für die meisten Aufgaben ist dies übertrieben. Darüber hinaus kann dieses Modell nicht immer schmerzlos von der Anwendung getrennt werden.
Eine weitere Option zum Kombinieren von Wissensdatenbanken und OOP-Anwendungen ist die ontologieorientierte Programmierung.... Dieser Ansatz basiert auf den Ähnlichkeiten zwischen den Ontologiebeschreibungswerkzeugen und dem Objektprogrammiermodell. Klassen, Entitäten und Ontologieattribute, die beispielsweise in der OWL-Sprache geschrieben sind, können automatisch Klassen, Objekten und ihren Feldern des Objektmodells zugeordnet werden. Und dann können die resultierenden Klassen zusammen mit anderen Klassen der Anwendung verwendet werden. Leider wird die grundlegende Umsetzung dieser Idee in ihrem Umfang eher begrenzt sein. Ontologiesprachen sind sehr ausdrucksstark und nicht alle Ontologiekomponenten können auf einfache und natürliche Weise in OOP-Klassen konvertiert werden. Um eine vollständige Inferenz zu implementieren, reicht es nicht aus, nur eine Reihe von Klassen und Objekten zu erstellen. Er benötigt Informationen über die Elemente der Ontologie in expliziter Form, beispielsweise in Form von Metaklassen.Ich habe vor, in einer der folgenden Veröffentlichungen ausführlicher auf diesen Ansatz einzugehen.
Es gibt auch einen so extremen Ansatz für die Softwareentwicklung wie die modellgetriebene Entwicklung . Demnach besteht die Hauptaufgabe der Entwicklung in der Erstellung von Domänenmodellen, aus denen der Programmcode dann automatisch generiert wird. In der Praxis ist eine solch radikale Lösung jedoch nicht immer flexibel genug, insbesondere im Hinblick auf die Programmleistung. Der Schöpfer solcher Modelle muss die Rollen eines Programmierers und eines Geschäftsanalysten kombinieren. Daher konnte dieser Ansatz die traditionellen Ansätze zur Implementierung des Modells in universellen Programmiersprachen nicht verdrängen.
Alle diese Ansätze sind ziemlich umständlich und für Modelle mit hoher Komplexität sinnvoll, die häufig getrennt von der Logik ihrer Verwendung beschrieben werden. Ich hätte gerne etwas Leichteres, Bequemeres und Natürlicheres. Damit war es mit Hilfe einer Sprache möglich, sowohl das Modell in deklarativer Form als auch die Algorithmen für seine Verwendung zu beschreiben. Daher habe ich darüber nachgedacht, wie das objektorientierte oder funktionale Paradigma (nennen wir es die Berechnungskomponente ) und das deklarative Paradigma (nennen wir es die Modellierungskomponente ) in einer einzigen hybriden Programmiersprache kombiniert werden können . Auf den ersten Blick sehen diese Paradigmen einander entgegengesetzt, aber es ist umso interessanter, es zu versuchen.
Ziel ist es daher, eine Sprache zu erstellen, die für die konzeptionelle Modellierung auf der Grundlage von halbstrukturierten und unterschiedlichen Daten geeignet ist. Die Form des Modells sollte der Ontologie nahe kommen und aus einer Beschreibung der Entitäten der Domäne und der Beziehungen zwischen ihnen bestehen. Beide Komponenten der Sprache sollten eng integriert sein, auch auf semantischer Ebene.
Die Elemente der Ontologie sollten Entitäten der Sprache der ersten Ebene sein - sie können an Funktionen als Argumente übergeben, Variablen usw. zugewiesen werden. Da die Modellontologie zu einem der Hauptelemente des Programms wird, kann dieser Programmieransatz als ontologisch orientiert bezeichnet werden. Die Kombination der Beschreibung des Modells mit Algorithmen für seine Verwendung würde den Programmcode für eine Person verständlicher und natürlicher machen, ihn näher an das konzeptionelle Modell der Domäne bringen und die Entwicklung und Wartung von Software vereinfachen.
Zum ersten Mal genug. Im nächsten Beitrag möchte ich über einige moderne Technologien sprechen, die imperative und deklarative Stile kombinieren - PL / SQL, Microsoft LINQ und GraphQL. Für diejenigen, die nicht auf die Veröffentlichung aller Veröffentlichungen auf Habré warten möchten, gibt es einen vollständigen Text in wissenschaftlichem Stil in englischer Sprache unter dem Link:
Hybrid Ontology-Oriented Programming for Semi-Structured Data Processing .