download - SPES 2020

Weitere Magazine

Empfehlungen

Info

Kosimulation in SPES Abbildung 3.2: Der SPES Entwurfsraum. terogeneous” bezieht sich darauf, das verschiedene Aspekte typischerweise verschiedene Modellierungselemente verwenden. Eine Spezifikation definiert, was eine Komponente machen soll. In HRC werden Spezifikationen partitioniert in Aspekte, die funktionale und extra-funktionale Eigenschaften erfassen. Damit kann eine Komponente verschiedene Aspekt-Spezifikationen haben wie beispielsweise eine Real-Time oder eine Safety Spezifikation. Diese Spezifikationen werden durch Kontrakte erfasst, die wiederum in Form von Textmustern (Requirement Specification Language, kurz RSL) formuliert werden. Auf die Textmuster soll in diesem Deliverable jedoch nicht näher eingegangen werden. Weitere Details kann der interessierte Leser in [15, 4] finden. Kontrakt-basierte Spezifikation ermöglicht es, für jeden Aspekt den erlaubten Entwurfskontext eines Entwicklungsgegenstandes mittels strong Assumptions zu charakterisieren: Eine Verletzung dieser ist gleichbedeutend mit einer Verletzung der Nutzungsspezifikation, sodass für solche Fälle die Produkthaftung nicht mehr gewährleistet wird. Für erlaubte Entwurfskontexte charakterisiert die Guarantee eines Kontrakts sowohl funktionale als auch extra-funktionale Eigenschaften des Entwurfsgegenstandes. Der Annahme-Teil eines Kontrakts besteht neben der strong Assumption aus einer weak Assumption. Dieser partitioniert den erlaubten Kontext, der durch die strong Assumption definiert wird. Eine einzelne weak Assumption definiert damit nur einen Teil des erlaubten Kontexts und ermöglicht es somit, verschiedene Anwendungsfälle eines Entwicklungsgegenstandes zu definieren. Erfüllt dann der Kontext eine solche weak Assumption, kann der Entwicklungsgegenstand ein strengeres Verhalten garantieren. Neben der Spezifikation bieten HRCs Mittel um Aspekt-Realisierungen zu erfassen. Aspekt- Realisierungen definieren, wie eine Komponente sich konkret verhält. Die Realisierung eines konkreten Aspekts einer Komponente kann durch andere Formalismen außerhalb der SPES Entwurfsmethodik erfolgen, wie beispielsweise Programmcode oder ausführbare Modelle. Die HRCs bilden das Grundkonzept der SPES Entwurfsmethodik, auf dem der SPES Entwurfsraum aufbaut, der im nächsten Abschnitt eingeführt wird. 3.2 SPES Entwurfsraum Das Meta-Modell bietet Abstraktions- und Verfeinerungstechniken(↑) sowie Sichten (View(↑)) auf eine Architektur. Diese Entwurfsmethoden bilden den SPES Entwurfsraum, der in Abbildung 3.2 mit schemenhaften Modellen dargestellt ist. Im Folgenden wird auf die einzelnen 11/ 18
Kosimulation in SPES Begriffe näher eingegangen. Abstraktion im Allgemeinen erlaubt dem Entwickler, sich auf die wesentlichen Probleme in einem Entwurfsschritt zu konzentrieren und unnötige Details auszublenden. Das Meta-Modell bietet Abstraktionsebenen(↑) an, die es ermöglichen, einen Entwicklungsgegenstand mit einer bestimmten Granularität zu beschreiben. Die Granulatität ist dabei abhängig vom konkreten Entwicklungsprozess und erlaubt es, sich auf bestimmte Teile zu konzentrieren und zu einer bestimmten Entwicklungsphase irrelevante Details auszublenden. Die Anzahl sowie Benennung von Abstraktionsebenen ist dabei anwendungsabhängig und kann z. B. durch eine konkrete Suppy-Chain beeinflusst werden. Ein Modell eines zu entwickelnden Systems kann mit mehreren Viewpoints assoziiert werden, die Konstrukte und Regeln zum Beschreiben von unterschiedlichen Views des zu entwickelnden Systems bieten. Der Begriff der Views und Viewpoints bezieht sich hierbei auf den IEEE Standard 1471-2000 [14]. Das Meta-Modell bietet hierzu einerseits Viewpoints, die eine strukturell verschiedene Sichten auf das Modell realisieren - die sogenannten Perspektiven - und andererseits Viewpoints, die orthogonal zur Struktur des Systems stehen und verschiedene Aspekte von funktionalen und extra-funktionalen Eigenschaften des Entwicklungsgegenstandes beschreiben. Orientiert an weit verbreiteten Software-Engineering-Vorgehensweisen (z. B. [18]) berücksichtigt das Meta-Modell also verschiedene Perspektiven auf das zu entwickelnde System, um Sichten von lösungsunabhängiger Entwicklung bis hin zu konkreten technischen Lösungen zu unterstützen. Im Speziellen wurden die Perspektiven operationale, funktionale, logische, technische sowie geometrische definiert, die im Folgenden näher erläutert werden. In der operationalen Perspektive(↑) werden unabhängig von einer konkreten (technischen) Lösung der Kontext des zu entwickelten System betrachtet und Anforderungen an das zu entwickelnde System sowie die nötigen Schnittstellen des Systems zu seiner Umwelt festgehalten. Hierdurch wird eine frühe präzise Beschreibung der Anwendungsfälle des zu entwickelten Systems ermöglicht. Durch z. B. einer Validierung mittels Simulation von Szenarien kann in dieser Perspektive sehr früh erkannt werden, ob das richtige System entwickelt wird. Einen ganzheitlichen Ansatz zum modellbasierten Requirements Engineering bietet dabei ZP-AP2 an. Die operationale Perspektive stellt die Schnittstelle zu diesen Konzepten dar. In der funktionalen Perspektive(↑) erfolgt basierend auf den Anwendungsfällen und Anforderungen aus der operationalen Perspektive das Erfassen sämtlicher Funktionen, die das zu entwickelnde System anbieten soll. Top-Level Funktionen werden dabei durch Funktionsdekomposition in feingranularere Sub-Funktionen abgeleitet. Je nach Grad der Vollständigkeit der Funktionsbeschreibung können z. B. erste Überprüfungen hinsichtlich der Abhängigkeiten zwischen den verschiedenen Funktionen erstellt werden (z.B. mittels AutoFocus[1]). Die logische Perspektive(↑) erfasst die logische Architektur des Systems, die plattformunabhängig erstellt wird. Der Fokus liegt hier bei der Wiederverwendbarkeit der erstellten Komponenten. Plattformunabhängige Analysen können hier durchgeführt werden, um beispielsweise Fehler, die bei der Transformation auf plattformabhängige Spezifika entstehen, aufdecken zu können. Die technische Perspektive(↑) konkretisiert die logische Architektur. In dieser Perspektive werden Software/Hardware-Partitionierungsfragen geklärt. Beispielsweise kann eine logische Komponente in dieser Perspektive durch einen konkreten Aktor realisiert werden. Informationstechnisch gesehen stellt die technische Perspektive die plattformabhängige Modellierung des Systems dar. In der geometrischen Perspektive(↑) wird das Layout des Systems modelliert. Die geometrische Perspektive lag bisher nicht in dem Kompetenzbereich von SPES und wird daher in der in 12/ 18
Seite 1 und 2: Kosimulation im Kontext von SPES Ta
Seite 3 und 4: Inhaltsverzeichnis 1 Einleitung 1 2
Seite 5 und 6: Kosimulation in SPES ten Entwicklun
Seite 7 und 8: Kosimulation in SPES Abbildung 2.1:
Seite 9 und 10: Kosimulation in SPES Reihenfolge de
Seite 11 und 12: Kosimulation in SPES Abbildung 2.3:
Seite 13: 3 SPES Architektur Meta-Modell In d
Seite 17 und 18: 4 HLA im Kontext von SPES In [17] w
Seite 19 und 20: 5 Zusammenfassung und Ausblick In d
Seite 21: Kosimulation in SPES [13] Tayfun Ge

download - SPES 2020

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?