Architekturbeschreibungssprachen

Slides:



Advertisements
Ähnliche Präsentationen
Business Engineering Philipp Osl, Alexander Schmidt
Advertisements

Software Architektur Service­orientierte Architektur und Sicherheit
1 Referenzmodelle für HISinOne Dr. Uwe Hübner, 02. Juli 2009.
Stoff- und Energieumsatz in Lebewesen
Submodell Softwareentwicklung (SE)
Vorgehensmodell - Wasserfallmodell
K-Modeler Engineering
Von David Keß, Heinrich Wölk, Daniel Hauck
Das „Vorgehensmodell“
Methodik: Objektorientierte Analyse
WS 04/05 wiss. Übung: Systemanalyse und Softwaredesign
Manfred Thaller, Universität zu Köln Köln 28. Januar 2008
Anwendungsfalldiagramm
Anwendungsfalldiagramm
Anwendungsfalldiagramm
Ziel: externe Systemverhalten aus Anwendersicht
Objektorientierter Entwurf (OOD) Teil 3: Qualitätsmodell
Systemanalyse In der Systemanalyse wird aus den fachspezifischen Anforderungen das Systemmodell erstellt; im Systemmodell ist spezifiziert, was das System.
Universität Stuttgart Institut für Kernenergetik und Energiesysteme I nstitut für K ernenergetik und E nergiesysteme Rational Unified Process (RUP) - Definitionen.
Universität Stuttgart Institut für Kernenergetik und Energiesysteme System- und Abnahmetests Inhalt Testen des Systems unter Mitwirkung des Auftraggebers.
es gibt (fast) nichts, was nicht anders gemacht werden könnte
UML im Überblick – Dipl. Ing. Ulrich Borchert / FH Merseburg 1/22
Seminar Modellgetriebene Softwareentwicklung Einführung Seminar modellgetriebene Softwareentwicklung WS 05/06 Dipl.-Inf. Nadine Fröhlich Prof. Dr.-Ing.
Rational Unified Process (RUP) - Definitionen
Modellierung komplexer Realität mit Objekten
Vortrag 11: Reengineering - Refactoring
“Perspektiven der Klassifikationsentwicklung“
1 Dipl.-Inform. Christian Fuß Lehrstuhl für Informatik 3 an der RWTH Aachen 2. Übungsblatt Änderungen am ersten Entwurf und Entwurfsparadigmen 4. Mai 2006.
Theorie soziotechnischer Systeme – 12 Thomas Herrmann Informatik und Gesellschaft FB Informatik Universität Dortmund iundg.cs.uni-dortmund.de.
Datenmodellierung - Aufbau einer Datenbank -
Objektorientierte Analyse und Design mit der Unified Modelling Language (UML) Sandra Meißl
OO Analyse und Entwurf für Anwender
Grundschutztools
Rational Rose und UML: Erstellung einer Kontoverwaltung
UML Begleitdokumentation des Projekts
Vorlesung Gestaltung von soziotechnischen Informationssystemen - Grenzen soziotechnischer Modellierung - Gst-IS Thomas Herrmann Lehrstuhl Informations-
Vorgehensmodelle: Schwergewichtige Modelle
Spezifikation von Anforderungen
12. Vorlesung: Aktivitätsdiagramme
Unified Modeling Language Repetition / Einführung zu UML
REQUIREMENTS ENGINEERING
Software Architektur Service­orientierte Architektur und Sicherheit
Reasoner Semantische Interoperabilität
Software Architektur Service­orientierte Architektur und Sicherheit von Christian Schwerdtfeger & Matthias Folz.
Projektpräsentation der Bücherei
Musterlösungen Übungsblatt 5
Kompetenz -, Lern - und Prüfungsbereiche Anforderungsbereiche
UML-Kurzüberblick Peter Brusten.
UML Modellierung des Verhaltens von Klassen und Objekten
Fachkonzepte in der UML
MathCoach Ein web-basierter Mathematik-Tutor
Vienna University of Technology Pirker Simon 1. Überblick Definition Motivation Vorteile Entwurf von VP Pirker Simon 2.
1 Ausgangslage Vorgehensweise: Informell, pragmatisch, stark graphisch orientiert. Systemanalytischer Ausgangspunkt: Klassischer Systembegriff als Ansammlung.
Von UML 1.4 zu UML 2.0 InfoPoint vom Mittwoch
GIS Design: A Hermeneutic View (Michael D. Gould)
Thema Name des Vortragenden Ort, Datum
Software Engineering Strukturierte Analyse
Anwendungsfalldiagramm
WILLKOMMEN Daniel Matheis Betreuer: Birgitta König-Ries Michael Klein "Dezentrale Realisierung von Gruppendiensten in Peer-to-Peer-Umgebungen" Studienarbeiter:
Seminar Modellgetriebene Softwareentwicklung Thema 3: Metamodelle – MOF Michél Rieser Prof. Dr.-Ing. habil. Georg Paul
MDA – Model Driven Architecture
PowerPoint – Präsentationen
Name des Vortragenden ‌ Klasse ‌‌‌ Ort / tt.mm.jjjj Anwendungsfalldiagramm.
Qualitätshandbuch Drehscheibentag Aka Esslingen 25./ Herzlich willkommen zum Thema „Qualitätshandbuch“ Qualitätsentwicklung an Schulen Qualitätshandbuch.
Technische Universität München, Informatik XI Angewandte Informatik / Kooperative Systeme Verteilte Anwendungen: Entwurf Dr. Wolfgang Wörndl
A nwendungsfalldiagramm. Ü berblick  Allgemein  Anwendungsfalldiagramm in Stichpunkten  Zusammenhang  Anwendungsbereich  Diagramm.
 Präsentation transkript:

Architekturbeschreibungssprachen HTW Software Architektur Architekturbeschreibungssprachen Sascha Reichert Andreas Kuntz Julian Crispo Herzlich Willkommen zur Präsentation über Architekturbeschreibungssprachen

Architekturbeschreibungssprachen Inhalt Aufgabenbeschreibung und Ziele Grundlagen Definitionen Warum wird modelliert? Vorgehensweise beim Modellieren Sprachen Formale, Informale, Semiformale Überblick über die Sprachen Beispiel Formale, Informale, Semiformale Sprache Vergleiche und Resümee Vergleichsversuch der Sprachen Fazit und Empfehlungen Ausblick © Hochschule für Technik und Wirtschaft des Saarlandes

Architekturbeschreibungssprachen Inhalt Aufgabenbeschreibung und Ziele Grundlagen Definitionen Warum wird modelliert? Vorgehensweise beim Modellieren Sprachen Formale, Informale, Semiformale Überblick über die Sprachen Beispiel Formale, Informale, Semiformale Sprache Vergleiche und Resümee Vergleichsversuch der Sprachen Fazit und Empfehlungen Ausblick © Hochschule für Technik und Wirtschaft des Saarlandes

Architekturbeschreibungssprachen Aufgabenbeschreibung und Ziele Erstellung einer Ausarbeitung und einer Präsentation zum Thema Grundlagen des Themas erörtern Aufzählung und Beschreibung der Sprachen Vergleiche ziehen Empfehlungen geben Eigenständig Wissenschaftlich und fundiert mit Quellenangaben Mittels des Themas genauer auswählen können für welche Sprache man sich entscheidet © Hochschule für Technik und Wirtschaft des Saarlandes

Architekturbeschreibungssprachen Inhalt Aufgabenbeschreibung und Ziele Grundlagen Definitionen Warum wird modelliert? Vorgehensweise beim Modellieren Sprachen Formale, Informale, Semiformale Überblick über die Sprachen Beispiel Formale, Informale, Semiformale Sprache Vergleiche und Resümee Vergleichsversuch der Sprachen Fazit und Empfehlungen Ausblick Dieses Kapitel beschreibt, weshalb man überhaupt in der Softwaretechnik modelliert und weshalb es für den Menschen wichtig ist. © Hochschule für Technik und Wirtschaft des Saarlandes

Grundlagen Definition Sprache Kommunikationsmittel des Menschen Verwendung von gesprochener oder geschriebener Symbole Festgelegte Bedeutung der Symbole Zeichensystem zum Zweck der Kommunikation Kommunikationsmittel des Menschen gekennzeichnet durch die Verwendung gesprochener oder geschriebener Symbole mit festgelegter Bedeutung. Sprache lässt sich definieren als Zeichensystem zum Zweck der Kommunikation. Einige Linguisten betrachten die Sprache als Form des Denkens und der Kognition. Siehe auch Semiotik Text von der Seite [ENCARTER] am 25.01.09 entnommen. © Hochschule für Technik und Wirtschaft des Saarlandes

Definition Modellierungssprachen Grundlagen Definition Modellierungssprachen Künstlich definierte Sprachen, zum Erstellen von Modellen Einsatz in der Softwareentwicklung zum modellieren von Ausschnitten aus der realen Welt. Präzisieren von Anforderungen an eine zu realisierende Software Modellierungssprachen sind künstlich definierte Sprachen Abstrahieren von Problemen Sie werden insbesondere im Rahmen der Softwareentwicklung eingesetzt, um Ausschnitte der realen Welt zu modellieren (z.B. Geschäftsprozessmodelle, Ist-Analyse), Anforderungen an eine zu realisierende Software zu präzisieren Entwurfs- und Architekturbeschreibungen zu erstellen. Text von der Seite [OBONLINE] mit Stichwort Modellierungssprache am 25.01.09 entnommen. © Hochschule für Technik und Wirtschaft des Saarlandes

Architekturbeschreibungssprachen Inhalt Aufgabenbeschreibung und Ziele Grundlagen Definitionen Warum wird modelliert? Vorgehensweise beim Modellieren Sprachen Formale, Informale, Semiformale Überblick über die Sprachen Beispiel Formale, Informale, Semiformale Sprache Vergleiche und Resümee Vergleichsversuch der Sprachen Fazit und Empfehlungen Ausblick Dieses Kapitel beschreibt, weshalb man überhaupt in der Softwaretechnik modelliert und weshalb es für den Menschen wichtig ist. © Hochschule für Technik und Wirtschaft des Saarlandes

Grundlagen Warum wird modelliert? Bessere Möglichkeit sich bestimmte Sachverhalte vorzustellen Unbekannte Dinge auf bekannte reduzieren „Teile und Herrsche“ – Prinzip Wieso wir überhaupt modellieren sollten. Ein Mensch kann sich besser Dinge vorstellen, wenn er sie vor sich sieht. Zudem können Menschen besser mit abstrakten Dingen umgehen, wenn man sie in eine Verpackung steckt die bekannt ist. Das beste Beispiel hierfür ist die objektorientierte Programmierung. Große komplexe Probleme sind für einen Menschen nicht leicht erfassbar und zu überblicken, somit bedient man sich in der Informatik sehr oft der Methode „Teile und herrsche“ und teilt große komplexe Probleme in mehrere kleinere weniger komplexe Probleme auf. © Hochschule für Technik und Wirtschaft des Saarlandes

Grundlagen Warum wird modelliert? Modellierung zum Zweck der Wiederverwendung Modellierung zum Zweck der Erweiterbarkeit Kunden bei der Modellierung einbinden Modellierung als Dokumentation Projektablauf und Planung nach Modellen Modellierung unnötiger Ballast! Firmen sehen keine Vorteile Was macht erfolgreiche Unternehmen aus? Konsistent hochwertige Produkte Wie erreicht man dies: Mehrere Punkte weshalb Unternehmen modellieren sollen aufzählen! Und erklären Wiederverwendung von Sachen: Logging Mechanismus z.b. Erweiterbarkeit kann besser eingeplant werden Dem Kunden das Modell zu zeigen kann enorme kosten sparen (ähnlich Prototyp) Doku halt eben! Anhand eines Modells das vorgehen planen! Modelle in die Vorgehensmodelle einplanen. © Hochschule für Technik und Wirtschaft des Saarlandes

Architekturbeschreibungssprachen Inhalt Aufgabenbeschreibung und Ziele Grundlagen Definitionen Warum wird modelliert? Vorgehensweise beim Modellieren Sprachen Formale, Informale, Semiformale Überblick über die Sprachen Beispiel Formale, Informale, Semiformale Sprache Vergleiche und Resümee Vergleichsversuch der Sprachen Fazit und Empfehlungen Ausblick Wie gehe ich beim Modellieren überhaupt vor, welche Punkte muss man beachten! © Hochschule für Technik und Wirtschaft des Saarlandes

Grundlagen Warum wird modelliert? Auswahl der Modelle Detailgrad der Modelle Verknüpfung mit der Realität Mehr Modelle  mehr Sichten Beim Modellieren müssen vorher bestimmte Entscheidungen getroffen werden. Sehr entscheident welche Modelle man nimmt. Je nach Person andere Präferenzen und somit andere Modelle: Datenbankspezialist wird eine Software mehr in diese Richtung aufbauen als dies ein normaler Entwickler tut. Detailgrad der Modelle: Fürs Management das große Ganze um die Kosten schätzen zu können, für einzelne Entwickler ganz tief runter in einen Teilbereich und dann auch nur den! Geht man ins Detail, lässt man Programmierern keine Freiheiten mehr! Modellierer darf nicht den Bezug zur Realität verlieren, sonst könnten wichtige Details übersehen werden. Modelle dürfen zudem nicht die Wirklichkeit verschleiern. Probleme müssen von verschiedenen Sichten betrachtet werden. Schaut man sich z.B. ein Gebäude nur von vorne an, so wird man kaum abschätzen können wie im Inneren die Räume angeordnet sind. So ähnlich sieht das auch in der Softwareentwicklung aus! © Hochschule für Technik und Wirtschaft des Saarlandes

Architekturbeschreibungssprachen Inhalt Aufgabenbeschreibung und Ziele Grundlagen Definitionen Warum wird modelliert? Vorgehensweise beim Modellieren Sprachen Formale, Informale, Semiformale Überblick über die Sprachen Beispiel Formale, Informale, Semiformale Sprache Vergleiche und Resümee Vergleichsversuch der Sprachen Fazit und Empfehlungen Ausblick Wechsel mit Julian? Auf Sprachen eingehen Definition Formale Informale und Semiformale Überblick zeigen Beispiel für bestimmte Sprachen © Hochschule für Technik und Wirtschaft des Saarlandes

Formale, Informale, Semiformale Informal: keine Formale Syntax Sprachen Formale, Informale, Semiformale Informal: keine Formale Syntax Formal: spezifizierte Syntax und Semantik Semiformal: formal spezifizierte Syntax, fehlende formale Semantik Informale Beschreibungen verwenden natürliche Sprache und/oder Diagramme, denen keine formale Syntax zu Grunde liegt. - Verständlich - geriner Aufwand zur Erstellung - Zu großer Spielraum durch Mehrdeutigkeit Formale Sprachen zeichnen sich durch eine formal spezifizierte Syntax und Semantik aus - Umgekehrt zu Informal - Präzision - Erfordern mehr Kenntnisse - für sicherheitskritische Belange Eine semiformale Sprache verfügt über eine formal spezifizierte Syntax, nicht jedoch über eine formale Semantik Die Verwendung einer semiformalen Sprache verleiht einer Beschreibung eine definierte Struktur. Jedoch können, bedingt durch die informale Semantik, weiterhin Mehrdeutigkeiten auftreten.7 © Hochschule für Technik und Wirtschaft des Saarlandes

Architekturbeschreibungssprachen Inhalt Aufgabenbeschreibung und Ziele Grundlagen Definitionen Warum wird modelliert? Vorgehensweise beim Modellieren Sprachen Formale, Informale, Semiformale Überblick über die Sprachen Beispiel Formale, Informale, Semiformale Sprache Vergleiche und Resümee Vergleichsversuch der Sprachen Fazit und Empfehlungen Ausblick Überblick über die Sprachen! © Hochschule für Technik und Wirtschaft des Saarlandes

Überblick über die Sprachen AADL ACME xADL AESOP ControlH + MetalH AADL (Architecture Analysis & Design Language): die Sicht von der Codeebene auf eine höhere grobkörnigere Ebene zu verlagern. Beschreibung und Analyse der Interaktion und Zusammenschluss größerer Elemente. ACME ist eine generische Architektur Beschreibung Sprache (ADL). Sie stellt den Anspruch „einfach“ zu sein. Dies begründet darauf das ACME eine Mischung aus unterschiedlichen ADLs ist. xADL, eine Auf XML basierende Sprache, anpassbar für den jeweiligen Einsatzort und Zweck! AEOSOP ist ein Framework zur Generierung neuer Softwarearchitekturkomponenten. Plattformunabhängig. Eingestellt. Bei MetaH handelt es sich um eine Domain-spezifische Beschreibungssprache für Avionik-Systeme Avionik: Die Avionik – zusammengesetzt aus Aviatik (von lat. avis = Vogel) und Elektronik – ist ein Begriff aus der Luft- und Raumfahrttechnik, eine Bezeichnung für die Gesamtheit der elektrischen und elektronischen Geräte an Bord eines Fluggerätes, einschließlich der Fluginstrumente. © Hochschule für Technik und Wirtschaft des Saarlandes

Überblick über die Sprachen Demeter FR – Functional Representation Gestalt Modechart Rapide Demeter: AOP FR: Baukasten Gestalt: ganzheitliches System Modechart: Realtimesysteme Rapide: EADL (Executable Architecture Definition Langage) © Hochschule für Technik und Wirtschaft des Saarlandes

Überblick über die Sprachen RESOLVE SysML UML UniCon Wrigth Resolve keine weiteren Informationen vorhanden, irgendwann zu SML umbenannt worden. SysML ist eine graphische Modellierungssprache. Sie dient zum Spezifizieren, Analysieren, Designen und Verifizieren von komplexen Systemen. Die vereinheitlichte Modellierungssprache UML ist eine standardisierte Sprache, die zum Anfertigen von Softwarebauplänen dient. UniCon ist eine Architekturbeschreibungssprache deren Fokus auf der Unterstützung verschiedenster Architekturkomponenten liegt. Sie besitzt hierfür nur zwei verschiedene Beschreibungselemente. Wright, Modellierung und Analyse (insbesondere, Deadlock-Analyse) von parallelen Systemen, meistens nur am Rande in Dokumentationen erwähnt, ansonsten keinerlei weitere Informationen! © Hochschule für Technik und Wirtschaft des Saarlandes

Architekturbeschreibungssprachen Inhalt Aufgabenbeschreibung und Ziele Grundlagen Definitionen Warum wird modelliert? Vorgehensweise beim Modellieren Sprachen Formale, Informale, Semiformale Überblick über die Sprachen Beispiel Formale, Informale, Semiformale Sprache Vergleiche und Resümee Vergleichsversuch der Sprachen Fazit und Empfehlungen Ausblick Beispiele für bestimmte Sprachen! © Hochschule für Technik und Wirtschaft des Saarlandes

Beispiel Semiformal – SysML Sprachen Beispiel Semiformal – SysML Graphische Sprache Dient zum Spezifizieren, Analysieren, Designen und Verifizieren von Systemen Beschreibt Hardware, Software, Informationen, Personen, Prozeduren und Einsatzumgebung Semantische Grundlage vorhanden Standardisierte Erweiterung von UML Durch ihre semantische Grundlage sollen Systemanforderungen zwischen verschiedenen Stakeholdern unmissverständlich kommuniziert werden. SysML besteht zum einen Teil aus einer Teilmenge der UML 2.0 und zum anderen Teil aus neu erstellten Erweiterungen um die obigen Anforderungen abbilden zu können. Zudem wird Modell und Datenaustausch mittels XML MetaData Interchange unterstützt. SysML wurde im September 2001 von OMG(Object Management Group) und INCOSE (International Council on System Engineering) als eine standardisierte Erweiterung der UML erstellt. Seid Mai 2003 gibt es eine Arbeitsgruppe die sich um die Verbesserung und Erweiterung von SysML kümmern. Folgende Firmen sind Mitglieder dieser Arbeitsgruppe: IBM, Telelogik, Motorola, Lockheed Martin und oose Innovative Informatik GmbH. © Hochschule für Technik und Wirtschaft des Saarlandes

Beispiel Semiformal – SysML Sprachen Beispiel Semiformal – SysML Unterschied SysML – UML UML  Konzeption von Software SysML  Konzeption von Systemen SysML beinhaltet neue Diagrammtypen Teilweise geänderte und verbesserte UML Diagrammtypen Der Hauptunterschied zwischen UML und SysML liegt darin, dass UML sich mehr auf die Konzeption von Software bezieht und SysML mehr auf die Konzeption von ganzen Systemen. SysML beinhaltet einige Modellierungstypen aus der UML 2.0 Spezifikation. Hinzu kommen ein paar weitere Anpassungen damit die oben genannten Aufgabenbereiche umgesetzt werden können. © Hochschule für Technik und Wirtschaft des Saarlandes

Beispiel Semiformal – SysML Sprachen Beispiel Semiformal – SysML Aufbau SysML 1. Struktur Blockdefinitionsdiagramm Internes Blockdefinitionsdiagramm Paketdiagramm 2. Verhalten Aktivitätsdiagramm Sequenzdiagramm Zustandsdiagramm Anwendungsfalldiagramm 3. Anforderung 4. Parametrik 4 Säulen: SysML lässt sich in vier verschiedene Bereiche aufteilen. Ähnlich UML gibt es auch hier den Struktur und Verhaltensbereich. Daneben gibt es noch den Anforderungs- und Parametrik- Bereich. Geändert aus UML: Klassendiagramm -> Blockdefinitionsdiagramm Klassen -> Systembausteine Kompositionsdiagramm -> Internes Blockdefinitionsdiagramm Weggelassen aus UML: Verteilungsdiagramm Komponentendiagramm Kommunikationsdiagramm Interaktionsübersichtsdiagramm Objektdiagramm Zeitverlaufsdiagramm © Hochschule für Technik und Wirtschaft des Saarlandes

Sprachen Beispiel SysML Anforderungsdiagramm Zeigt die System-anforderungen auf und wie diese untereinander agieren. Anforderungsdiagramm Alternativ können die Anforderungen auch in einer Tabelle aufgezählt werden. © Hochschule für Technik und Wirtschaft des Saarlandes

Sprachen Beispiel SysML Zusicherungsdiagramm Diagramm zeigt die parametrisierten Zwänge zwischen den einzelnen Systembausteinen. Zusicherungsdiagramm Genauere Beschreibung welche Parameter Funktionen, Prozeduren, etc. benötigen. © Hochschule für Technik und Wirtschaft des Saarlandes

Beispiel Semiformal – SysML Sprachen Beispiel Semiformal – SysML Einsatzmöglichkeiten SysML Konzeption von Systemarchitekturen Mittels Anforderungsdiagramm ab Projektbeginn benutzbar Anstelle eines textuellen Anforderungsschreibens ein Diagramm einsetzbar Anerkannter Standard Die Einsatzmöglichkeiten von SysML sind vielfältig. Im Grunde genommen kann jeder Softwareentwurf damit gemacht werden. Durch das neu hinzugekommene Anforderungsdiagramm kann ab Projektbeginn damit begonnen werden sämtliche Teilaspekte des Projektes in SysML abzubilden. Es wird nicht mehr notwendig genauestens zu beschreiben welche Anforderungen gegebenen sind. Stattdessen wird ein standardisiertes Modell dieser Anforderungen erstellt. Standard wichtig für EU und Regierungsprojekte! © Hochschule für Technik und Wirtschaft des Saarlandes

Sprachen Beispiel – SysML Nachteile Vorteile und Nachteile Nicht weit verbreitet Gemeinsamer Einsatz mit UML kann durch die veränderten Modelltypen zu Problemen führen Sprachen Beispiel – SysML Vorteile und Nachteile Vorteile Bei UML Kenntnissen schnell zu erlernen Gibt durch neue Diagramme besseren Gesamtüberblick auf Systeme Kann mit UML zusammen benutzt werden Softwareunterstützung vorhanden © Hochschule für Technik und Wirtschaft des Saarlandes

Beispiel Semiformal – SysML Sprachen Beispiel Semiformal – SysML Tools Artisan (Studio) EmbeddedPlus (SysML Toolkit)3rd party IBM vendor No Magic (Magic Draw) Sparx Systems (Enterprise Architect) IBM / Telelogic (Tau and Rhapsody) TopCased Visio SysML template Folgende Tools gibt es für die Erstellung von SysML: © Hochschule für Technik und Wirtschaft des Saarlandes

Architekturbeschreibungssprachen Inhalt Aufgabenbeschreibung und Ziele Grundlagen Definitionen Warum wird modelliert? Vorgehensweise beim Modellieren Sprachen Formale, Informale, Semiformale Überblick über die Sprachen Beispiel Formale, Informale, Semiformale Sprache Vergleiche und Resümee Vergleichsversuch der Sprachen Fazit und Empfehlungen Ausblick Hier gibt es einen Vergleichsversuch der unterschiedlichen Sprachen. © Hochschule für Technik und Wirtschaft des Saarlandes

Vergleiche und Resümee Beispiel Semiformal – SysML Vergleichsversuch der Sprachen Vergleiche schwer machbar Zu unterschiedliche Aufgabengebiete Erscheinungsjahr spielt eine Rolle Vergleichen von ähnlich formalen Sprachen möglicher Vergleich der Sprachen auf Verständlichkeit Ähnlich formale Sprachen miteinander zu vergleichen ist wesentlich einfacher als unterschiedlich Formale. Semiformal und Semiformal oder Formal und Formal einfacher als Formal mit Semiformal oder Formal mit Informal vergleichen! © Hochschule für Technik und Wirtschaft des Saarlandes

Vergleiche und Resümee Beispiel Semiformal – SysML Vergleichsversuch der Sprachen mit Diagramm 1 – UML 2 – SysML 3 – UniCon Ähnlich formale Sprachen miteinander zu vergleichen ist wesentlich einfacher als unterschiedlich Formale. Semiformal und Semiformal oder Formal und Formal einfacher als Formal mit Semiformal oder Formal mit Informal vergleichen! © Hochschule für Technik und Wirtschaft des Saarlandes

Architekturbeschreibungssprachen Inhalt Aufgabenbeschreibung und Ziele Grundlagen Definitionen Warum wird modelliert? Vorgehensweise beim Modellieren Sprachen Formale, Informale, Semiformale Überblick über die Sprachen Beispiel Formale, Informale, Semiformale Sprache Vergleiche und Resümee Vergleichsversuch der Sprachen Fazit und Empfehlungen Ausblick Fazit aus dem Projekt und Empfehlungen © Hochschule für Technik und Wirtschaft des Saarlandes

Vergleiche und Resümee Beispiel Semiformal – SysML Fazit und Empfehlungen Interessantes Thema mit viel Potenzial Je nach Anwendungsfall ist erneut zu überlegen welche Sprache eingesetzt wird Zumindest UML sollte genutzt werden SysML sehr interessant Architekturbeschreibungssprachen / Modellierungssprachen nehmen im Nachhinein eine Menge Arbeit ab © Hochschule für Technik und Wirtschaft des Saarlandes

Architekturbeschreibungssprachen Inhalt Aufgabenbeschreibung und Ziele Grundlagen Definitionen Warum wird modelliert? Vorgehensweise beim Modellieren Sprachen Formale, Informale, Semiformale Überblick über die Sprachen Beispiel Formale, Informale, Semiformale Sprache Vergleiche und Resümee Vergleichsversuch der Sprachen Fazit und Empfehlungen Ausblick Was für Sprachen sollen kommen, was benötigt man als Entwickler © Hochschule für Technik und Wirtschaft des Saarlandes

Vergleiche und Resümee Beispiel Semiformal – SysML Ausblick und Wünsche Generell sinnvoll eine leichtgewichtige UML / SysML zu schaffen Kundenorientiertere standardisierte Sprachen schaffen Entwickler sollten in Firmen auf die Modellierung bestehen Leichtgewichtig: Anstatt 13 Diagrammtypen eine informelle aber standardisierte Sprache zum schnellen erstellen von Diagrammen Kopplung mit dem SysML Anforderungsdiagramm Kundenorientierte Sprache: Damit könnte man Kunden wesentlich besser Systeme erklären und verkaufen, Einfache Strukturen die man auch als BWLer verstehen kann. Auf Modellierung bestehen: Viele firmen denken halt das Modellierung und Dokumentation unnötiger Balast sind. Jedoch bekommt man eben gerade durch das Modellieren ein Gefühl für die Größe eines Systems und den Umfang. © Hochschule für Technik und Wirtschaft des Saarlandes

Vielen Dank für Eure Aufmerksamkeit © Hochschule für Technik und Wirtschaft des Saarlandes