Positive Resonanz auf Vortrag zu FMC4SE beim Tag des Systems Engineering

“Modellbasiertes Systems Engineering ohne Anlernaufwand mit den Fundmental Modeling Concepts” lautete der Titel des Vortrags, den ich heute beim Tag des Systems Engineering (TdSE) in München halten durfte. Der Vortrag schilderte die positiven Erfahrungen mit dem Einsatz der Fundamental Modeling Concepts Modellierungsnotation im Systems Engineering, die über die letzten 3 Jahre gesammelt wurden. Dabei stellte sich FMC4SE als sehr intuitive und leicht verständliche Modellierungsnotation für Systemarchitekturen dar, als dies bei den aktuellen SysML-Diagrammen der Fall ist.

Die Resonanz auf den Vortrag fiel durchweg positiv aus. Es würde mich freuen, wenn es dazu beitragen würde, dass das hier beschriebene FMC4SE Plugin für Sparx Systems Enterprise Architect weitere Anwender findet. Vielleicht gibt es auch Anregungen und Kommentare zu dem Ansatz. Hier dürfen Sie sich gerne beteiligen und bei mir melden.

Neue Version und Installationsanleitung für FMC4SE

Im Zuge der Vorstellung von FMC4SE beim TdSE, habe ich außerdem die Gelegenheit genutzt kleinere Verbesserungen einzuarbeiten, sowie eine kurze Installationsanleitung zu erstellen. Sie finden das aktuelle Release, sowie weitere Infos auf GitHub unter https://github.com/oalt/fmc4se.

FMC4SE ist und bleibt Open Source und kostenlos nutzbar!

GitHub Projekte automatisch bauen und verteilen mit Azure DevOps

Mein letzter Blogeintrag liegt mehr als ein Jahr zurück. Ich hab es aus Zeitgründen einfach nicht geschafft im letzten Jahr mal etwas zu schreiben. Dies soll sich nun aber wieder ändern.

Ganz untätig war ich im letzten Jahr nicht, was das Thema Systems Engineering angeht. Dazu werden sicher noch ein paar Beiträge folgen. Seit Februar arbeite ich nun auch wieder als Systemingenieur bei Karl Mayer und daher steht das Thema bei mir täglich wieder mehr im Fokus, als dies die letzten zwei Jahre der Fall war.

Heute möchte ich jedoch darüber berichten, wie ich mein FMC4SE Enterprise Architect Plugin nun automatisch aus den Quellcodedateien in Github übersetzen (Contineous Integration, CI) und auch freigeben (Contineous Delivery, CD) kann.

Anforderungen

Was waren die Anforderungen an den CI/CD-Prozess?

Bisher hatte ich auf meinem Rechner zuhause einen Jenkins-Build-Server eingerichtet, der die Quelldateien aus GitHub bei Bedarf übersetzt und ein MSI-Setup daraus generiert hat. Dieses habe ich dann manuell wieder in GitHub hochgeladen.

Ziel war es nun, da die Quelldateien sowieso in GitHub öffentlich zugänglich sind auch den Build-Prozess auf einem Server in der Cloud durchzuführen. Ein automatisches Bereitstellen einer Softwarefreigebe in GitHub wäre natürlich auch super.

Zusätzlich sollte folgendes beachtet werden:

  • Die Versionsnummer des Builds soll sich aus 4 Stellen zusammen A.B.C.D, wobei A.B.C aus einer Datei kommt (version.txt), die man manuell im Projekt anpasst und eincheckt. Angewendet wird hierbei das Semantic Versioning. Die Stelle D soll ein Zähler sein, der bei jedem neuen gestarteten Build automatisch hochgezählt wird (1, 2, 3, ….)
  • Da die Applikation eine .NET Applikation ist, spielen hier die Versionsnummern der erzeugten Softwarekomponenten (DLLs) eine wichtige Rolle. Diese sind bei C#-Projekten über die Datei AssemblyInfo.cs gesteuert. Vor dem Übersetzten sollte also die aktuelle Version hier gesetzt werden.

Realisierung

Nach einer kurzen Recherche bei GitHub bin ich auf Azure DevOps von Microsoft gestoßen. Dieser Dienst ist für Open Source Projekte kostenlos und bietet die Möglichkeiten die oben genannten Anforderungen zu erfüllen. Genau genommen braucht man die Azure DevOps Pipelines.

Build-Schritte mit YML beschreiben

Mit Hilfe von Skripten in der Sprache YML (YAML) kann man die Schritte beschreiben, um einen automatisierten Build-Prozess aufzusetzen. Leider ist die Dokumentation noch etwas verbesserungswürdig. Das Ganze Portal scheint auch aktuell noch stark erweitert zu werden. Daher hat es einige versuche bedurft, bis alles so funktioniert hat wie ich mir das gedacht hatte. Dieser Blog-Artikel soll daher auch ein bisschen helfen, wenn Sie vielleicht ähnliches vorhaben.

Wenn man eine neue Build-Pipeline anlegt, wird automatisch eine azure-pipelines.yml Datei angelegt, die die Prozessschritte beschriebt. Diese wird dann auch im GitHub Projekt eingecheckt. Das ganze hat auch den Vorteil, dass der Quellcode und die Vorschrift wie daraus ausführbare Software entstehen soll unter der gleichen Versionskontrolle steht.

Prozesschritte

Um das EA-Plugin zu erzeugen sind folgende Schritte notwendig:

  1. Holen der manuellen Versionsnummer aus der Datei version.txt und Zwischenspeicherung in einer Variablen
  2. Setzen der Build-Nummer aus der manuellen Versionsnummer und dem Build-Zähler
  3. Herstellung der benötigten Nuget-Pakete (referenzierte externe Bibliotheken)
  4. Update der Versionsnummer in den AssemblyInfo.cs Dateien
  5. Übersetzen der Software. Hierbei entsteht als Ergebnis eine Windows-Installationsdatei (.msi)
  6. Umbenennen der msi-Datei, damit auch die Versionsnummer im Dateinamen erscheint
  7. Publizierung der erzeugten msi-Datei, damit man diese nach Ende des Buid-Vorgangs auch manuell im Azure DevOps Portal herunter laden kann

Herausgekommen ist folgende YML-Datei, die man natürlich auch in GitHub ansehen kann.

# .NET Desktop
# Build and run tests for .NET Desktop or Windows classic desktop solutions.
# Add steps that publish symbols, save build artifacts, and more:
# https://docs.microsoft.com/azure/devops/pipelines/apps/windows/dot-net

trigger:
- master

pool:
  vmImage: 'VS2017-Win2016'

variables:
  solution: '**/*.sln'
  buildPlatform: 'Any CPU'
  buildConfiguration: 'Release'
  versionToBuild: ''
  
# Set name initialy to the BuildID (This is a counter, every time incremented when a build is started)
name: $(BuildID)

steps:

# read version from version.txt file and store it in a variable (versionToBuild)
- script: |
    set /p VER=<src/Plugin/version.txt @echo ##vso[task.setvariable variable=versionToBuild]%VER% # Print out the version to build and update the buildNumber - script: | echo The version from src/Plugin/version.txt is $(versionToBuild) @echo ##vso[build.updatebuildnumber]$(versionToBuild).$(build.buildnumber) # install nuget toolset - task: NuGetToolInstaller@0 # get the referenced nuget packages from nuget.org - task: NuGetCommand@2 inputs: restoreSolution: '$(solution)' # update assembly version in AssemblyInfo.cs with the buildNumber value - powershell: | function Update-SourceVersion { Param ([string]$Version) $NewVersion = 'AssemblyVersion("' + $Version + '")'; Write-output $NewVersion $NewFileVersion = 'AssemblyFileVersion("' + $Version + '")'; foreach ($o in $input) { Write-output $o.FullName $TmpFile = $o.FullName + ".tmp" get-content $o.FullName | %{$_ -replace 'AssemblyVersion\("[0-9]+(\.([0-9]+|\*)){1,3}"\)', $NewVersion } | %{$_ -replace 'AssemblyFileVersion\("[0-9]+(\.([0-9]+|\*)){1,3}"\)', $NewFileVersion } > $TmpFile

            move-item $TmpFile $o.FullName -force
        }
    }
    Write-output 'Modifiing AssemblyInfos.'
    foreach ($file in "AssemblyInfo.cs", "AssemblyInfo.vb" ) 
    {
        get-childitem -recurse |? {$_.Name -eq $file} | Update-SourceVersion $(build.buildnumber) ;
    }
   
# build software
- task: VSBuild@1
  inputs:
    solution: '$(solution)' 
    msbuildArgs: '/p:installerFileVersion=$(build.buildnumber)'
    platform: '$(buildPlatform)'
    configuration: '$(buildConfiguration)'
    
# rename .msi file
- script: |
    cd src/Plugin/Setup/bin/Release
    ren FMC4SE-Plugin-Setup.msi FMC4SE-Plugin-Setup_$(build.buildnumber).msi
    cd ..
    cd ..
    cd ..
    cd ..
    cd ..

# copy build results
- task: CopyFiles@2
  inputs:
    contents: 'src/Plugin/Setup/bin/Release/*.msi'
    targetFolder: $(Build.ArtifactStagingDirectory)
    flattenFolders: true

# publish build results
- task: PublishBuildArtifacts@1
  inputs:
    pathtoPublish: '$(Build.ArtifactStagingDirectory)'
    artifactName: Output

 

 

Fallstricke

Folgende Dinge musste ich erst experimentell herausfinden, da mir hier die Dokumentation nicht so gut geholfen hat:

  • Der Zähler, der jedes mal wenn ein Build automatisch oder manuell angestossen inkrementiert wird, ist $(BuildID)
  • Die Build-Nummer kann man während des Buildvorgangs durch Setzen der Variablen build.updatebuildnumber setzen
  • Mir ist es nicht gelungen die Version in AssemblyInfo.cs mit einem speziellen task zu setzen. Daher das enthaltene PowerShell Skript. Vielleicht hat hier jemand eine bessere Lösung.
  • Es gibt einen task VSBuild für Visual Studio Build und einen für MSBuild, der steht für das Microsoft Build-Kommando. Bei beiden gibt es die Möglichkeit Parameter an MSBuild zu übergeben. Grosse Falle: Beim VSBuild-Task heißt der Eingabeparemeter msbuildArgs beim MSBuils-Task msbuildArguments.

Fazit

Am Ende funktioniert der automatische Build aber sehr gut. Damit ist das Thema CI erledigt. Wie man auch noch eine Softwarefreigabe per Knopfdruck auf GitHub in den Release-Bereich bekommt, beschreibe ich in einem Folgebeitrag demnächst.

Systemmodellierung – einfach und intuitiv

Nach über 10 Jahren praktischer Anwendung der Systemmodellierungssprache SysML, zwei Büchern rund um das Thema SysML und der Schulung von vermutlich über 1.000 Personen möchte ich in diesem etwas längeren Beitrag eine kleine auch vielleicht etwas kritische Bilanz ziehen und gleichzeitig eine Alternative vorstellen, auf die ich vor etwas mehr als einem Jahr gestoßen bin, und die meiner Ansicht nach das Potential hat, Systemmodellierung ohne großen Lern- und Schulungsaufwand für jeden einfach nutzbar und zugänglich zu machen: Die Fundamental Modeling Concepts.

Einleitung: Architekturmodellierung

Ein wesentlicher Teil eines Systemmodells bildet die Beschreibung der Architektur bzw. der Systemstruktur. Die Architektur beschreibt dabei Komponenten, deren Schnittstellen und welche Komponente Daten oder Material mit einer anderen Komponente austauscht. Gleichzeitig gibt es in der Architekturmodellierung auch immer eine Darstellung der Systemzerlegung (Systemdekomposition), so dass ersichtlich wird, welche Komponente Teil einer anderen Komponente ist.

Ein Architekturmodell gibt somit Antworten auf folgende Fragen:

  • Aus welchen Komponenten besteht mein System?
  • Wie stehen diese Komponenten hierarchisch zueinander? (Wer ist Unterkomponente von wem?)
  • Welche Schnittstellen haben die Komponenten um Daten oder Material untereinander auszutauschen und zu verarbeiten?
  • Wer tauscht mit wem Daten oder Material über Schnittstellen aus?
  • Ist eine Schnittstelle einer Komponente Ausgang, Eingang oder beides (Richtung der Schnittstelle)?

Die Systems Modeling Language (SysML) bietet verschiedene Modellelemente an, um solche Architekturmodelle aufzubauen. Da die SysML auf der Softwaremodellierungssparche UML (Unified Modeling Language) basiert und die UML dazu geschaffen wurde in erster Linie objektorientierte Software zu beschreiben, finden sich einige grundlegende Konzepte davon auch in SysML wieder. Insbesondere das Konzept von Klassen und Instanz findet sich auch in SysML, allerdings unter leicht abgewandelten Begriffen. Komponenten in SysML werden dabei durch so genannte Blöcke definiert. Die Blöcke entsprechen weitegehend den Klassen in UML, werden aber umbenannt. Wohl um auch Anwender ohne Hintergrund der Softwaretechnik einen einfachen Zugang zu gewähren.

Instanzen von Blöcken bilden dann die so genannten Property-Elemente. Mit Hilfe von Block- und Property-Elementen können nun Systemstrukturen (Komponenten) modelliert und grafisch dargestellt werden.

Zur Darstellung von Schnittstellen kennt die SysML das Element des Port, der grafisch als kleines Element auf der Kante einer Komponente dargestellt wird. In SysML ist hier durch einen Pfeil im inneren meist auch die Richtung der Schnittstelle vorgegeben.

Um eine Komponente modellieren zu können ist es gemäß SysML-Spezifikation zunächst notwendig Blöcke und die Daten- oder Materialtypen für die Ports zu definieren. Dies geschieht zumeist in einer zentralen Typenbibliothek im Modell.

Hat man diese Datentypen definiert, kann man darauf basierend mit der eigentlichen Systemmodellierung beginnen.

Einstiegshürden

Mehrere Möglichkeiten im Standard

SysML ist ein Standard, der an verschiedenen Stellen mehrere prinzipielle Möglichkeiten bietet, um ein Modellierungsproblem zu lösen. Hintergrund dabei ist vermutlich, dass sich bei der Standardisierung viele Parteien auf einen gemeinsamen Nenner einigen mussten. Jeder möchte dabei natürlich am liebsten das im Standard wiederfinden, was er oder sie bereits kennt oder schon einsetzt. Daher ist ein solcher Standard oftmals auch ein Kompromiss.

Ich selbst habe während meiner Zeit beim Automobilzulieferer Continental SysML maßgeblich als Systembeschreibungssprache etabliert und auch geschult. Dabei würde früh ersichtlich, dass es wenig Sinn macht die komplette SysML zu schulen und anzuwenden, sondern dass man sich auf eine praktikable Teilmenge beschränken sollte, die alle praxisrelevanten Modellierungsaufgaben unterstützt und leicht zu erlernen ist.

Weiterhin haben die wenigsten Kollegen im Umfeld wo mechatronische Systeme entwickelt werden Hintergrundwissen in der Softwaretechnik. Dies fand ich nicht nur bei Continental sondern auch bei den Schulungsteilnehmern immer wieder, die ich in meiner Zeit als Trainer und Consultant bei LieberLieber in modellbasierter Systementwicklung geschult habe. Auf die Frage wer denn die Konzepte der Objektorientierung kenne, meldeten sich zumeist nur 10-20% der Schulungsteilnehmer.

Man kann also nicht davon ausgehen, dass Konzepte wie Klasse und Instanz sowie die damit verbundenen Darstellungen der UML oder objektorientierter Programmiersprachen als bekannt vorausgesetzt werden können.

Dies führte zu einem pragmatischen Ansatz in der Form, dass ich bei SysML beispielsweise Blöcke nie direkt in Architekturdarstellungen verwende, sondern immer nur deren Instanz (Property-Elemente). Die Verwirrung ist nämlich erst mal sehr groß wenn man sich mit den Konzepten nicht auskennt und dann gesagt bekommt, man solle in manchen Fällen Blöcke, in anderen aber Instanzen von Böcken zur Darstellung von Systemkomponenten verwenden. Zudem sind die Beispiele im SysML-Standard in diesem Punkt auch nicht eindeutig.

Letztendlich wurden aus der Menge der SysML-Elemente nur genau 3 ausgewählt, um Architekturdarstellungen zu machen:

  • Property-Elemente als Instanzen von Blöcken für die Darstellung der Komponenten
  • Flow Ports zur Darstellung der Schnittstellen
  • Ein Item-Flow-Konnektor als durchgezogene Linie zwischen verbundenen Flow Ports

Das folgende Bild zeigt ein Beispiel eines mit SysML erstellten Architekturmodells:

TSSC_SysML

Viele Elemente zur Typdefinition

In SysML gibt es verschiedene Elemente um Schnittstellen zu definieren. Damit kann man also festlegen welche Art von Daten oder Material aus einer Schnittstelle herauskommen oder hineinfließen. SysML kennt dabei mehrere Elemente um so etwas zu spezifizieren.

  • Quantity Kinds
  • Units
  • Flow Specifications
  • Data Types

Sie dürfen sich gerne im SysML Standard genauer anschauen, was diese Elemente alles bedeuten und für was diese nutzbar sind. Auf jeden Fall gab es mit diesen Typ-Elementen in der praktischen Anwendung – ob in den Schulungsbeispielen oder später – immer die meisten Fragen und Fehler. Zu allem Überfluss wurden diese Elemente in den verschiedenen Versionen des SysML-Standards auch gerne mal verändert, was dazu führt, dass einmal gelerntes wieder neu erlernt werden muss oder man sich entscheiden muss die Änderungen einfach nicht mitzugehen und bei der aktuellen Version der SysML zu bleiben.

Lücken in der SysML

Bereits kurz nach dem Aufbau der ersten Systemmodelle fiel auf, dass manche Aspekte, die man gerne im Modell wiedergefunden hätte im SysML Standard so nicht vorgesehen sind. Der wichtigste Punkt war dabei die Tatsache, dass SysML nun eine Art von Komponente kennt und man nicht unterscheidet zwischen Software-, Elektronik- oder Mechanikkomponenten.

Der Ansatz zur Lösung dieses Problems war, die SysML zu erweitern und solche spezifischen Komponenten einzuführen. Glücklicherweise ist die SysML als erweiterbare Sprache definiert. Somit lassen sich auch solche Lücken einfach füllen. Allerdings ist es dann eine angepasste SysML, die in anderen Modellen so nicht zum Einsatz kommt.

Werkzeughürden aufgrund verstreuter Daten

Eine große Schwierigkeit stellte und stellt für die Anwender auch die Tatsache dar, dass die Daten aufgrund der SysML-Spracharchitektur in den Modellierungswerkzeugen in verschiedenen Teilen verstreut abgelegt werden. SysML ist als so genanntes UML-Profil definiert. Profil wird der Erweiterungsmechanismus der UML genannt, mit dem man aus UML neue Sprachen ableiten kann. Die Nutzung von Profilen führt dazu dass die Anwender an mindestens zwei verschiedenen Stellen im Werkzeug Daten editieren müssen, um die gewünschten Einstellungen für die Modellelemente zu erreichen: In den Elementeigenschaften und in den sogenannten „Tagged Values“. Wer sich nie mit dem Thema UML-Profile näher beschäftigt hat, für den erschließt sich zunächst auch nicht, warum man einmal hier etwas einstellt, andere Dinge aber dort.

Dieses Problem sollte man nicht unterschätzen, da auch nicht alle Modellnutzer täglich mit dem Modellierungswerkzeug arbeiten und dann nach einiger Zeit auch oftmals nicht mehr wissen, wo nochmal genau eine Eigenschaft geändert werden muss. Dies führt dann zu Frustration und im schlimmsten Fall dazu, dass die Modelle gar nicht oder nur noch äußerst ungern weiter genutzt werden.

Doppelpunkte in Namen

Einige Elemente in SysML-Architekturmodellen sind Instanzen. Eine Instanz wird durch einen Text beschrieben, der aus dem Namen des Elements und dem Namen des klassifizierenden Elements (Blockname) besteht. Beide Begriffe werden dabei durch einen Doppelpunkt getrennt. Heisst der Block beispielsweise „Temperatursensor“, so heisst eine Instanz davon zum Beispiel „TS1 :Temperatursensor“, wobei „TS1“ hier der Name der Instanz ist. Diese Art der Darstellung ist auch nicht selbsterklärend und für viele Anwender verwirrend. Dies zeigt sich auch, wenn Anwender während einer Übung in einer SysML-Schulung gebeten werden zunächst auf dem Flipchart oder Whiteboard ein Modell hinzuzeichnen. So gut wie Niemand zeichnet auch die Doppelpunkte hin, obwohl dies vorher erklärt worden ist.

Für die Praxis ist es für den großen Teil der Anwender wichtig zu sehen, welche Art von Schnittstelle hier genutzt wird. Dafür genügt zum Verständnis auch eine einfache Darstellung ohne Instanzname und Doppelpunkt.

Fundamental Modeling Concepts

Auf die so genannten Fundamental Modeling Concepts (FMC) wurde ich aufmerksam durch ein Gespräch, das ich auf dem Tag des Systems Engineering (TdSE) 2016 mit Dr. Oskar von Dungern während einer Kaffeepause führte.

Er erzählte mir, dass er eine Initative für ein Datenformat zum Austausch von Systemspezifikationen ins Leben gerufen habe, dass es auf einfache Art und Weise ermögliche komplette Systemspezifikationen, bestehend aus Anforderungen, Architektur und Verhaltensbeschreibungen auszutauschen und aus verschiedenen Quellen zu integrieren: SpecIF (Specification Integration Facility). Als Beschreibungssprache für Architekturen benutze er dabei die Fundamental Modeling Concepts.

Meine Neugierde war geweckt. Nicht nur an SpecIF, sondern auch an FMC. Ich wollte mir das ganze mal näher anschauen, auch im Hinblick darauf, wie sich das evtl. mit SysML kombinieren oder vereinbaren lässt.

Bereits auf dem Rückweg schaute ich mir im Zug seinen Beitrag zum TdSE 2016 dazu an. Ich fand es dahingehend sehr interessant, da FMC einiges davon vereinte was ich mit meinem praxisbezogenen Einsatz von SysML auch getan hatte:

  • Konzentration auf die wesentlichen, wenige Elemente
  • Intuitive Darstellung um den Anlernaufwand gering oder gegen Null zu halten

Im weiteren Verlauf schaute ich mir FMC noch genauer an: Die Grundlagen der Fundamental Modeling Concepts wurden bereits Ende der 1970er Jahre von Prof. Siegfried Wendt entwickelt. Die Weiterentwicklung zum heute bekannten Stand erfolgte dann durch ihn und seine Mitarbeiter in den darauffolgenden Jahren.

Besonders interessant daran finde ich, dass dort Dinge, die in UML und SysML immer wieder wieder zu Problemen führen, bereits analysiert und gelöst worden sind. Leider ist der Ansatz so gut wie kaum bekannt und wurde vorwiegend im Umfeld des Instituts von Prof. Wendt am Hasso Plattner Institut gelehrt und eingesetzt. Eine genaue Beschreibung des gesamten Konzeptes findet sich im Buch Fundamental Modeling Concepts, das 2005 – also bereits 2 Jahre vor dem ersten offiziellen SysML-Standard – bei Wiley erschienen ist.

FMC_Book

Das was sich mit den SysML-Architekturdiagrammen beschreiben lässt, lässt sich auch mit dem Compositional Structures Diagramm des FMC beschreiben. Grund genug für mich einmal zu untersuchen, ob es nicht möglich ist FMC für das Modellierungswerkzeug Enterprise Architect von Sparx Systems nutzbar zu machen.

In meinem Urlaub Anfang 2017 fand ich etwas Zeit dazu mir darüber Gedanken zu machen und etwas umzusetzen. Entstanden daraus ist ein UML-Profil und ein kleines Plugin für Enterprise Architect, welches FMC für das Systems Engineering mit Enterprise Architect nutzbar macht: FMC4SE.

Fundamental Modeling Concepts for Systems Engineering (FMC4SE)

FMC4SE besteht aus zwei Teilen: Einem MDG-UML-Profil für Enterprise Architect, das es erlaubt FMC Compositional Structure Modelle mit Enterprise Architect zu erstellen und diese so wie von FMC vorgesehen aussehen zu lassen.

Der zweite Teil ist eine Software für Enterprise Architect (Plugin), die es dem Anwender einfacher machen soll FMC Modelle zu erstellen. Dabei werden beispielsweise die Standarddialoge zum Bearbeiten der Elementeigenschaften durch eigene Dialoge ersetzt, die nur die wesentlichen Dinge an einer zentralen Stelle anzeigen. Dadurch entfällt für den Anwender das fehlerträchtige Editieren an mehreren Stellen im Werkzeug.

PropertyDialog

Leichte Adaption des FMC-Konzepts

An einer Stelle bin ich bei der Umsetzung der FMC-Profils von der in der Literatur beschriebenen Form abgewichen: Bei FMC werden Kommunikationskanäle durch einen Konnektor mit einem Kreis in der Mitte dargestellt. Ich nutze hingegen den Kreis bei Quelle und Ziel des Kommunikationskanals analog zu einem Port in UML oder SysML. Dies ermöglicht es eine Komponente auch aus einem Gesamtsystem herauszuschneiden, ohne die Schnittstellen zu verlieren, das diese nicht nur am Konnektor “hängen”, sondern an der Komponente selbst definiert und mit dieser implizit verbunden sind.

Kommunikationskanaldarstellung

Der im FMC-Standard vorgesehene Kreis zur Darstellung eines Kommunikationskanals wird also praktisch nur verdoppelt. Ansonsten werden die Elemente so wie bei FMC beschrieben umgesetzt.

Modellierungsassistent

Zur Verbesserung der Benutzerfreundlichkeit dient das erstellte Plugin. Hierbei wird ein Modellierungsassistent umgesetzt der es ermöglicht bei Anlegen neuer Elemente bereits alle wesentlichen Daten wie Typ der Komponente, Name, Art der Komponente (Elektronik, Software, Mechanik etc.) und Beschreibung der Komponente auszuwählen bzw. einzugeben. Ein besonderes Augenmerk gilt dabei der Festlegung des Typs. Auch die Umsetzung der FMC4SE nutzt die zur Verfügung gestellten Konzepte von Klasse und Instanz. Allerdings wird dies durch das Plugin für den Anwender vereinfacht.

TypeAutoComplete

Der Dialog für die Eigenschaften enthält eine Auto-Vervollständigung die automatisch beim Tippen bereits existierende Komponenten- oder Schnittstellentypen (Type) anzeigt. Wird eine existierende ausgewählt wird diese automatisch zugewiesen. Existiert keine passende, kann der Anwender mit der „+“-Knopf eine neue erzeugen. Diese wird direkt als Klassen- (für Komponenten) oder Interface-Element in eine zentrale Typenbibliothek einsortiert. Ein Hantieren mit verschiedenen, verwirrenden Datentypen wie bei SysML entfällt damit.

Die Zuordnung der Komponentenart (Kind) wird über farbliche Kennzeichnung erreicht. Damit kann man auf den ersten Blick eine Software- von einer Hardwarekomponente unterscheiden.

FMC4SE ist Open Source und kostenlos

Die FMC4SE Technologie und das Plugin für Enterprise Architect stelle ich als Open Source unter der MIT Lizenz auf Github kostenlos zur Verfügung: https://github.com/oalt/fmc4se. Auch ein kleines Beispielmodell für Enterprise Architect findet sich hier.

Einen Installer für Windows mit dem ersten Release gibt es ab sofort hier (Version 2.2.2.22 – Diese Versionsnummer ist tatsächlich reiner Zufall Smile).

Der Installer Installiert das Plugin vollautomatisch. Die Definition der MDG Technology (.xml-Datei) und das Beispielmodell (.eap-Datei) werden unter C:\ProgramData\MDD4All\FMC4SE  installiert. Sie können diese MDG Technology über die entsprechenden Menüs in jedes Enterprise Architect Modell laden und damit die FMC-Unterstützung aktivieren. Die Software lässt sich über die Systemsteuerung komplett wieder deinstallieren. Daher ist es einfach möglich auch FMC4SE nur mal kurz auszuprobieren. Da es sich um ein Enterprise Architect-Plugin handelt sind zur Installation Administratorrechte notwendig, da die Softwarekomponenten eine Windows COM-Registrierung benötigen.

TSSC_FMC4SE

Das im Beispielmodell enthaltene Modell der “Temperatursensorsignalkette” sehen Sie im Bild oben. Auffällig ist die viel weniger überladene Darstellung im Vergleich zu SysML oben. Trotzdem sind meiner Ansicht nach aller wesentlichen, zum Verständnis notwendigen Inhalte vorhanden.

Warum nur FMC Compositional Structures?

FMC definiert neben dem Compositional Structures Diagramm auch noch zwei weitere weitere Diagramme zur Beschreibung von dynamischem Verhalten angelehnt an Petri-Netze und Entity-Relationship-Diagramme zur Beschreibung und Definition von Datenstrukturen.

Diese Diagramme wurden bewusst nicht umgesetzt, da ich persönlich finde, dass hier im Umfeld der UML/SysML mit dem Aktivitätsdiagramm im Bereich dynamische Modellierung und dem Klassendiagramm im Bereich Beschreibung von Datenstrukturen bereits sehr weit etablierte Diagrammarten zur Verfügung stehen, die soweit auch schon bei vielen Anwendern bekannt sind oder bereits angewendet werden. Für mich sind die dazu im FMC-Bereich definierten Notationen weniger intuitiv zugänglich und daher würde ich in von mir verantworteten Modellen immer eine Kombination von FMC Compositional Structures sowie UML/SysML-Klassen- und Aktivitätsdiagrammen vorziehen. Das darf aber jeder gerne halten wie er mag.

Erfahrungswerte

Wie bereits oben erwähnt, habe ich die MDG-Technology und das Plugin bereits Anfang 2017 erstellt. Seit Februar 2017 arbeite ich bei der Firma Polygon – Produktdesign, Konstruktion, Herstellung als Entwickler. Ich setze modellbasierte Entwicklung nicht mehr täglich ein, erstelle jedoch von Zeit zu Zeit ein Modell wenn ich es als hilfreich für meine Arbeit erachte. Für das Modell nutze ich dazu von Beginn an FMC4SE. Meine Kollegen sind größtenteils Maschinenbauingenieure, Designer und Elektroingenieure. Es wurde von meiner Seite her keinerlei Schulung oder Einführung in die Modellnotation durchgeführt, sondern ich habe es einfach genutzt und die Reaktionen beobachtet. Die mit der FMC-Notation erstellten Modelle und Diagramme wurden dabei immer sofort von den Kollegen akzeptiert in Diskussionen und Präsentationen verwendet und verstanden.

Damit kann ich zwar nicht repräsentativ behaupten, dass jeder einen grundsätzlichen intuitiven Zugang zu dieser Modellierungsnotation hat, aber für mein Umfeld kann ich es voll bestätigen. Ich werde daher – bis ich vielleicht noch etwas besseres und intuitiveres finde – die Architekturmodellierung mit FMC4SE und nicht mehr mit SysML-Notation machen. Es ist sehr leicht SysML-Modelle in FMC zu überführen und auch umgekehrt. Daher wäre es jederzeit auch möglich wieder umzusteigen. Ich folge immer meinem Grundsatz “Nur so komplex wie nötig und so einfach wie möglich”. Viel Spaß mit FMC4SE.

Resourcen

Crowdfunding für ein neues Windows Phone

Die Firma Trekstor hat auf der Croudfunding Plattform  Indiegogo eine Aktion gestartet um ein neues Windows Phone auf den Markt zu bringen. Ich finde die Idee gut und habe mich daran beteiligt. Es ist meiner Ansicht nach  nämlich äußerst schade, dass  Microsoft die Idee des Windows Phone praktisch aufgegeben hat. Windows Phone hat für mich viele Dinge, die ich bei iPhone und bei Android vermisse oder nicht so intuitiv finde. Insbesondere die Live-Kacheln ermöglichen mir einen viel schnelleren Überblick über aktuelle Dinge als ich dies bei den andern beiden Plattformen kennen gelernt und ausprobiert habe.

Falls Sie auch schon mal ein Windows Phone hatten oder nach einer Alternative zu Android und iOS suchen und etwas dazu beitragen wollen, dass es vielleicht doch noch ein Umdenken bei  Microsoft und den Hardware-Herstellern gibt, dann schauen Sie sich die Aktion doch mal an und machen sie vielleicht mit: https://www.indiegogo.com/projects/trekstor-winphone-5-0-smartphone-phone#/

Ist natürlich alles ne Geschmackssache und bleibt jedem selbst überlassen. Die Aktion läuft einen Monat. Bin sehr darauf gespannt wie es ausgeht…

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