TypeScript–das bessere JavaScript!

Ich habe mich mit Webprogrammierung immer schwer getan. Insbesondere mit JavaScript konnte ich mich nie richtig anfreunden. Warum das so ist? Na ja. Ich habe von Anfang an seit ich programmiere, immer mit streng typisierten Programmiersprachen wie Java oder C# gearbeitet. Hier ist alles genau definiert und man muss – zumindest vor der Einführung von var – immer angeben von welchem Typ genau eine Variable ist.

Auch die Eigenart von JavaScript die Sichtbarkeit von Variablen nicht an einen durch geschweifte Klammern definierten Block zu koppeln, ist etwas, was ich erst mal ungläubig zur Kenntnis nehme.

Ich habe schon ein paar Anläufe gemacht mich mit JavaScript näher zu befassen, aber irgendwie wurden wir nie richtige Freunde. Anfang des Jahres habe ich ein neues Projekt übernommen, bei welchem die JavaScript-Umgebung Node.js zum Einsatz kam. In dem Projekt wurde allerdings nicht mit JavaScript programmiert, sondern mit TypeScript. Diese Sprache kannte ich vorher nicht und ich musste mich erst mal schlau machen, um was es sich dabei handelt.

TypeScript ist eine von Microsoft vorangetriebene Programmiersprache und eine Obermenge von JavaScript. Das bedeutet, dass JavaScript komplett in TypeScript enthalten ist. Aber das tolle daran ist, dass TypeScript genau das bietet was Leute wie ich an JavaScript vermissten, nämlich die Möglichkeit der Typisierung, Blocksichtbarkeit von Variablen mit dem Schlüsselwort let, die Möglichkeit Klassen und Sichtbarkeiten zu definieren wie in einer objektorientierten Sprache und noch vieles mehr.

Der TypeScript-Compiler liest dann die TypeScript Dateien ein und macht daraus wieder JavaScript Code. Dieser kann ganz normal bei Webseiten, Servern oder in Node.js verwendet werden, denn alle erweiterten Konstrukte werden in pures JavaScript übersetzt.

Ich habe selbst mehrfach die Erfahrung gemacht mit JavaScript schier zu verzweifeln, aber mit TypeScript schneller und sauberer ein Ergebnis zu erreichen. Der Code ist dabei viel verständlicher und  besser wartbar als JavaScript mit der selben Funktionalität. Daher kann ich, sofern Sie es nicht bereits kennen und irgendetwas im JavaScript Umfeld machen wollen, nur empfehlen sich auf jeden Fall TypeScript einmal genauer anzusehen.

Hier noch ein paar Links:

Abstraktion und Dekomposition

In diesem und folgenden Artikeln möchte ich Ihnen ein paar grundlegende Erkenntnisse über (System-)modellierung beschreiben, die ich im Laufe der Jahre gewonnen habe.

Im ersten Blogartikel soll es um die beiden Hauptdimensionen in einer Systemmodellierung gehen: Abstraktion und Dekomposition. Dabei ist der Begriff des Systems immer auch allgemein gemeint. Es kann sich um ein mechatronisches System, bestehend aus Hardware- und Softwarekomponenten, oder auch um ein reines Software- oder Hardwaresystem handeln. Das grundlegende Prinzip in der Modellierung bleibt immer das gleiche. Ein Modell ist hier die abstrakte Beschreibung der Systemzusammenhänge mit Hilfe grafischer Elemente.

Es gibt verschiedene grafische Modellierungssprachen. Die am häufigsten eingesetzten sind sicherlich die Unified Modeling Langugae (UML) im Softwarebereich und die Systems Modeling Language (SysML) zur Beschreibung von mechatronischen Systemen.

Auch hier gilt, dass das Prinzip der verschiedenen Dimensionen eines Modells, welche ich Ihnen heute erläutern will nicht an die Modellierungssprache gekoppelt ist, sondern grundsätzlich gilt.

Modellierung der Systemstruktur

Um ein System abstrakt zu beschreiben bedarf es Modellteile, welche die strukturellen, statischen Aspekte des System beschreiben und Teilen, die die dynamischen Aspekte beschreiben. Die strukturelle Beschreibung bezeichnet man auch gerne als Architektur. Hierbei wird beschrieben, bzw. modelliert aus welchen Teilen ein System aufgebaut ist oder aufgebaut werden soll. Der strukturelle Teil des Modells besteht daher aus einer Darstellung der Komponenten. Zusätzlich können Schnittstellen von Komponenten hinzugefügt und diese durch Konnektoren verbunden werden. Dadurch entsteht ein Blockschaltbild – ähnlich einem Schaltplan in der Elektronik oder einem Regelkreisdiagramm in der Steuer- und Regelungstechnik. Eine solche Darstellung verdeutlicht folgende Zusammenhänge:

  • Aus welchen Komponenten besteht mein System.
  • Welche Schnittstellen stellen die einzelnen Komponenten bereit.
  • Welche Komponente kommuniziert mit einer anderen über eine Schnittstelle und tauscht Daten oder Material aus.

Diese Informationen sind für die Entwicklung und die Realisierung eines Systems sehr wichtig, da man anhand dieser Informationen erstens einen Überblick über die gesamte Systemstruktur erhält und zweitens dies auch für die verteilte Entwicklung genutzt werden kann. So kann man einzelne Teile genau identifizieren und Zuständigkeiten zuordnen. Dies ist für eine Aufgabenverteilung beispielsweise für ein größeres Team sehr nützlich.

Der dynamische Teil des Systemmodells geht dann darauf ein, wie sich die einzelnen Komponenten oder das Gesamtsystem unter bestimmten Umständen verhalten. Zum Beispiel wird hier beschrieben, wann eine Komponenten mit einer anderen Daten oder Material austauscht, um eine gewünschte Funktionalität des Gesamtsystems zu erreichen. Auf die dynamische Modellierung möchte ich zu einem späteren Zeitpunkt genauer eingehen. Hier möchte ich Ihnen nun etwas über die beiden Dimensionen erklären, die man typischerweise im statischen Teil (Architekturteil) des Modells eines Systems oder Teilsystems hat und nutzt.

Abstraktion

Wenn man ein System modelliert kommt man früher oder später zu der Erkenntnis, dass man dessen Aspekte nicht mit einem einzigen Modell beschreiben kann, sondern dass das Gesamtmodell aus mehreren Einzelmodellen, den so genannten Abstraktionsebenen besteht. Unter Abstraktion versteht man das bewusste weglassen von Dingen der Realität zum Zwecke der Vereinfachung. Nehmen wir ein Beispiel aus dem Bauingenieurwesen her: Hier werden kleine Holzmodelle von Gebäuden genutzt, um die spätere Form der noch zu bauenden Gebäude sichtbar und im wahrsten Sinne des Wortes auch „begreifbar“ zu machen. Was allerdings hier sehr häufig weggelassen ist, sind die Darstellung der Fenstern und Türen oder auch die spätere Fassadendekoration. Diese Dinge werden bewusst „abstrahiert“ – also ausgeblendet, da es bei dem Modell vorwiegend um die geometrische Form des Gebäudes geht.

Diese Prinzip macht man sich nun auch in der Systemmodellierung zu nutze. Ein technisches System kann auch auf viele Arten abstrakter oder konkreter beschreiben. Beispielsweise könnte eine Bibliotheksverwaltung aus verschiedenen einzelnen Komponenten bestehen:

  • Benutzerverwaltung
  • Bücherverwaltung
  • Mahnwesen

Diese können auch in einem Modell als solche dargestellt werden. Dies stellt dann ein Modell auf dieser Ebene der Abstraktion dar. Das Modell beschreibt die Komponenten als Ganzes und ihren Platz im Gesamtsystem.


Um eine solche Bibliotheksverwaltung jedoch zu programmieren, braucht es detailliertere Beschreibungen, die vielleicht viel näher an der späteren Softwareprogrammierung angelehnt sind. Hier könnten dann auch Variablentypen und andere Softwaredetails dargestellt werden. Dies ist dann eine weitere Abstraktionsebene im Gesamtmodell. Man hat also eine komponenten-, eher funktional-orientierte Modellierung und eine andere eher technisch, realisierungsnahe Modellierung auf einer zweiten Abstraktionsebene. Zusammen ergeben diese dann ein Gesamtbild des Systems ab. Die Abstraktion ist daher die eine wichtige Dimension in einem Systemmodell.

Dekomposition

Innerhalb einer Abstraktionsebene gibt es eine weitere Dimension, die so genannte Dekomposition. Der Begriff Dekomposition meint das Auflösen von etwas in seine Bestandteile. Im Sinne der Modellierung meint dies die Zerlegung des Systems in seine Teilsysteme. Dekomposition ist etwas, was man aus der täglichen Erfahrung her kennt. Wenn man mit einem Werkzeug etwas zerlegt, zerlegt man es in seine Einzelteile. Das Gesamtsystem besteht aus Subsystemen und diese können wiederum aus Einzelteilen zusammengesetzt sein. Dadurch ergibt sich ein baumartige Struktur, die man in einem grafischen Modell sehr gut darstellen kann. Das grafische Modellierung aus dem UML-Umfeld kennt dafür die so genannte Kompositionsbeziehung (Schwarze-Raute-Beziehung). Dort wo die Raute dargestellt wird, ist die übergeordnete Komponente.

Die folgende Abbildung zeigt das Prinzip eines Dekompositionsdiagramms in einem grafischen Modell. Das Gesamtsystem (Top) untergliedert sich in zwei Subsysteme (Sub) und diese zerlegen sich weiter.

Eine solche Dekomposition lässt sich im Prinzip mit beliebigen Systemen vornehmen. Das Entscheidende dabei ist aber, dass eine solche Dekomposition immer innerhalb einer Abstraktionsebene stattfindet! Alle Komponenten werden im selben Abstraktionsgrad im Modell dargestellt und können daher auch untereinander interagieren.

Auf einer anderen Abstraktionsebene kann es auch wieder eine Dekomposition der Systemteile, die dort dargestellt sind geben.

Damit ergeben sich für ein Systemmodell die beiden Dimensionen, die bei struktureller Modellierung immer vorkommen:

  • Abstraktion: Stellt das System von einem bestimmten Blickwinkel aus mehr oder weniger abstrakt dar.
  • Dekomposition: Stellt die Zerlegung des Systems in Teilsysteme innerhalb einer Abstraktionsebene dar.

Das folgende Diagramm zeigt noch einmal Schematisch wie Abstraktion und Dekomposition zusammen spielen. Dabei repräsentieren die Paketsymbole die Abstraktionsebenen als Teil eines Gesamtmodells (vertikal dargestellt). Im inneren jedes Teilmodells/jeder Abstraktionsebene existiert eine eigene Dekomposition (horizontal dargestellt).

Mir war es wichtig diese Zusammenhänge hier ausführlich darzustellen, da die beiden Konzepte sehr oft durcheinander geworfen werden. Diese zu verstehen erleichtert ungemein das Verständnis für die grafische Modellierung und grafische Modelle, da darauf auch viele weitere Konzepte aufbauen.

Ich hoffe ich konnte Ihnen diese Grundbegriffe verdeutlichen. Weitere Konzepte wie z.B. die im Diagramm oben angedeutete Allokation, werde ich sicher in einem Folgebeitrag nochmal näher erläutern. Bis dahin viel Spaß bei der Modellierung. Bleiben Sie neugierig!

Herzlich Willkommen!

Herzlich Willkommen zum MDD4All Blog. Mein Name ist Dr. Oliver Alt. Ich bin promovierter Elektroingenieur mit einer Vorliebe für Informatik und modellbasiertem Systems Engineering.

Fast mein gesamtes Berufsleben habe ich mich mit dem Thema modellbasierte Softwareentwicklung und modellbasierte Systementwicklung beschäftigt. Meine Erfahrungen und Erkenntnisse, die ich dabei gewonnen habe, sind in zwei Büchern auch veröffentlicht worden: Zum Einen in meiner Doktorarbeit, in der ich mich mit dem Thema modellbasiertes Testen und Testfallgenerierung aus Modellen beschäftigt habe, und zum Anderen im Buch „Modellbasierte Systementwicklung mit SysML“ in dem ich meine Erfahrungen in der Anwendung der so genanten Systems Modeling Langugage (SysML) im praktischen Umfeld beschreibe. Auch eine Methodik, die sogenannte „Wirkkettenmethodik“ für die Erstellung vom Modellen für mehatronische Systeme wird dort beschrieben.

Seit das SysML-Buch erschien, habe ich mich zwei mal beruflich verändert. Im Jahre 2012 bin ich als Consultant zur Firma LieberLieber gegangen. In meiner Zeit dort, habe ich vorwiegend Schulungen rund um SysML bei Kunden im europäischen Raum gehalten. LieberLieber ist Partnerfima der Firma SparxSystems Central Europe, welche ein sehr beliebtes und weit verbreitetes Modellierungswerkzeug vertreibt und schult: Enterprise Architect. Ich selbst habe inzwischen 13 Jahre Erfahrung damit und halte es nach wie vor für eines der besten Werkzeuge im Umfeld von modellbasierter Entwicklung, wenn es um die Nutzung von Modellierungsstandards im Umfeld der Object Management Group (OMG) geht.

Seit Anfang 2017 bin ich nun als Entwicklungsingenieur für die Polygon – Produktdesign, Konstruktion und Herstellung GmbH tätig. Meine tägliche Arbeit dreht sich nun wieder mehr um die Entwicklung selbst und weniger um Consulting und Training. Trotzdem habe ich auch weiterhin ein Interesse im Themenfeld der modellbasierten Systementwicklung. Daher habe ich mich entschieden im Rahmen dieser Webseite und des Blog in unregelmäßigen Abständen – soweit es meine Zeit erlaubt – Erkenntnisse und Erfahrungen rund um die Themen

  • Modellbasierte Entwicklung
  • Software und Systems Engineering
  • Trends und aktuelle Entwicklungen in der IT, die ich interessant finde

hier zu publizieren und zur Verfügung zu stellen. Unter dem Motto oder der Hoffnung: „Modellgetriebene Entwicklung für Alle!“ – MDD4All. Vielleicht wird das ja irgendwann mal flächendeckend Realität.

Ich würde mich jedenfalls freuen, wenn meine Beiträge für den Einen oder die Andere von Interesse sind. Ihnen wünsche ich nun schon mal viel Spaß beim Lesen der zukünftigen Beiträge und viel Erfolg in der Anwendung der vielleicht dadurch gewonnenen Erkenntnisse.

Dr. Oliver Alt