AP1 Lehrmaterial: Ergebnisse

In den vergangenen BMBF-Projekten SPES2020 und SPES_XT wurden eine Vielzahl von Konzepten, Techniken und Methoden zur modellbasierten Entwicklung eingebetteter Systeme erarbeitet. Zu Beginn von SPEDiT wurden in AP1 (Lernmaterial) zunächst diese Ergebnisse gesichtet und in einer so genannten "Methodenlandkarte" strukturiert zusammengetragen. Als Strukturierungshilfe wurde hier zwischen Konzept, Modell sowie Methoden/Techniken (konstruktiv/analytisch) unterschieden.

Parallel zur Aufbereitung der SPES-Ergebnisse, wurden die Anforderungen an das Lehrmaterial, die Profile der zukünftigen Nutzergruppen sowie die einzusetzenden Medien gemeinsam mit den Industriepartnern ermittelt.

Auf Grundlage dieser Arbeitsergebnisse wurden für fünf unterschiedliche Nutzergruppen bzw. Referenzpersonas (System Architect, System Requirements Engineer, Test Engineer, Software Architect, Software Developer) spezifiziert, welche SPES-Resultate für welche Nutzergruppen in Schulungsmodulen zur Verfügung gestellt werden sollen.

Die Schulungsmodule umfassen mehreren Lernblöcke, die aus jeweils eigenen Skripten, Lernkontrollfragen, Übungsaufgaben und Präsentationsvideos bestehen und in einer virtuellen Lernumgebung dem Schulungsteilnehmer zur Verfügung gestellt werden.

In dem ersten SPEDiT-Projektjahr wurden neben den oben genannten Aufgaben für das Schulungsmodul "System Architect" alle definierten Lernblöcke erstellt und stehen in der Lernumgebung zur Verfügung. Nachfolgend eine kurze Übersicht dieser Lernblöcke und deren Inhalt:

Der SPES Modeling Framework: Dies ist ein allgemeiner Überblick über die zentralen in SPES erarbeiten Konzept und Methoden. Im Fokus stehen dabei Viewpoints (Schemata zur Erstellung Stakeholder-spezifischer Modelle) sowie Granularitätsebenen. Aus der Kombination der beiden Konzepte ergibt sich die für den im Projekt verfolgten Ansatz eine zentrale "SPES-Matrix".

Kontextmodellierung: Dieser Block führt in das Thema der Kontextmodellierung ein. Hier geht es darum, dem Schulungsteilnehmer alles Nötige zu vermitteln, das notwendig ist, um verschiedene Diagrammtypen im Bereich Kontextmodellierung richtig interpretieren zu können. Weiterhin werden unterschiedliche Perspektiven, aus denen man den Kontext eines Systems betrachten kann, näher beschrieben.

Ziel- und Szenariomodellierung: Dieser Baustein macht den Lernenden mit der Nutzung von Zielen und Szenarien im Requirements Engineering vertraut. Insbesondere vermittelt er die Ziel-Modellierungssprache ITU Goal-Oriented Requirement Language und die Szenario-Modellierungssprache ITU Message Sequence Chart.

Spezifikation von Anforderungen: Anforderungen an ein System beschreiben, welche Fähigkeiten/Eigenschaften ein System aufweisen muss, um einen definierten Zweck zu erfüllen. Nur wenn alle Anforderungen an das System vollständig, korrekt, widerspruchsfrei sowie präzise formuliert werden, kann das zukünftige System die geforderten Fähigkeiten in der gewünschten Qualität erbringen. Dieser Baustein gibt einen Überblick über die Anforderungsmodellierung und welche Perspektiven bei der Modellierung sinnvoll sind. Weiterhin werden UML-Modellierungskonstrukte vorgestellt, um den Schulungsteilnehmer in die Lage zu versetzen, Anforderungsdiagramme richtig lesen zu können.

Zerlegung des Systems in Systemfunktionen: Hier wird beschrieben, was eine Systemfunktion ist und welche Rolle diese in der Systementwicklung spielt. Es wird gezeigt, wie sich Systemfunktionen von Anforderungen, internen Funktionen und logischen Komponenten abgrenzen. Ergänzend werden verschiedene Techniken zur Dokumentation von Systemfunktionen vorgestellt und dessen Anwendung näher erläutert.

Spezifikation von Systemfunktionen: Dieser Baustein beschreibt, wie sich Systemfunktionen über eine syntaktische Schnittstelle und ein Schnittstellenverhalten detailliert beschreiben lassen. Eine Schnittstelle wird direkt mit Hilfe von Zustandsmaschinen oder Code spezifiziert oder, alternativ, mit Hilfe einer White-Box-Architektur zerlegt. Am Endes dieser Lerneinheit wird gezeigt, dass ein sogenanntes "Mode Model" eine orthogonale Sicht auf Abhängigkeiten zwischen Systemfunktionen liefert, indem es Betriebszustände des Systems definiert.

Abbildung von Anforderungen auf Systemfunktionen: Hier wird gezeigt, dass Systemfunktionen Container für Anforderungen aller Art sind und diese gruppieren. Dieser Zusammenhang wird dokumentiert und nützt bei der Spezifikation von Systemfunktionen. Systemfunktionen können aus gegebenen Anforderungen abgeleitet werden.

Analyse der Funktionsarchitektur gegen Anforderungen: Dieser Baustein beschreibt eine Überprüfungsmöglichkeit, ob Systemfunktionen und ihre Architektur die Anforderungen an das System abdecken und in sich konsistent sind. Es werden sowohl syntaktische Checks, als auch semantische Analysen angewendet und automatisiert mit Hilfe von Tools durchgeführt.

Zerlegung von Systemen in Teilsysteme: Hier wird der sogenannte "Logical Viewpoint" der SPES-Matrix näher vorgestellt. In diesem Viewpoint werden Systeme in Form logischer Komponenten und Verknüpfungen dargestellt. Diese abstrakte Darstellung, ohne technische Details, ermöglich verschiedene Analysen des Systemverhaltens und der Erfüllung funktionaler und nicht-funktionaler Anforderungen. Diese Lerneinheit erläutert sowohl die Bestandteile einer logischen Architektur, als auch die Zerlegung von Systemen in Teilsysteme zur Erstellung einer logischen Architektur.

Analyse der logischen Architektur gegen die funktionale Architektur: Da eine logische Architektur schnell komplex werden kann, können leicht Fehler entstehen, die gravierende Einflüsse auf die Qualität des resultierenden Systems haben. Um diese Fehler so früh wie möglich zu erkennen, gibt es verschiedene Ansätze zur Analyse von logischen Architekturen. Der Baustein werden die folgenden vier Ansätze näher vorgestellt: Simulation, Model-Checking, Assume/Guarantee Reasoning und Verfeinerung.

Erstellung einer technischen Architektur: Die Spezifikation der technischen Architektur stellt einen Teil der sogenannten plattformspezifischen Modelle (PSM) im Gegensatz zu den plattformunabhängigen Modellen (PIM) dar. In einer technischen Architektur werden daher, im Gegensatz zur logischen Architektur, die plattformspezifischen Artefakte, Verbindungen und Eigenschaften eines Systems beschrieben. Dieser Baustein erläutert Möglichkeiten für diese Art der Beschreibung.

Verteilung der logischen Softwarekomponenten auf Hardwarekomponenten: Die Verteilung von logischen Softwarekomponenten auf physikalische Hardwarekomponenten entspricht einer Zuordnung von logischer Funktionalität hin zu tatsächlich realer Ausführung auf einer physikalischen Ressource (z.B. ECU = Electronic Control Unit). Damit müssen nicht nur die Verhaltensspezifikationen auf ausführbare Prozesse (Threads) abgebildet werden, sondern auch logische Schnittstellen (Input/Output) einer Software-Komponente ihrer physikalischen Repräsentanz (z.B. Sensorik, Aktuatroik) zugewiesen werden.