Prof. Dr.-Ing. Dagmar Meyer Software Engineering 3 ARCHITEKTURENTWURF

Größe: px
Ab Seite anzeigen:

Download "Prof. Dr.-Ing. Dagmar Meyer Software Engineering 3 ARCHITEKTURENTWURF"

Transkript

1 3 ARCHITEKTURENTWURF

2 Hausbau - so? 2

3 oder so? 3

4 ... oder doch lieber so? 4

5 Dumme Frage! Wenn es um das Bauen von Häusern geht, besteht überhaupt kein Zweifel: ein guter Architekt muss her ohne Baupläne (Architektur) fängt kein Bauarbeiter mit seiner Arbeit an wie sollte er auch? nur gut durchdachte Baupläne garantieren ein ansprechendes Ergebnis Fehler bei der Erstellung der Pläne und der Statik, die nicht bemerkt werden, können im schlimmsten Fall zum Einsturz des Gebäudes führen Und wie sieht es mit dem Entwickeln von Software aus? 5

6 Eigentlich nichts Neues I am more convinced than ever. Conceptual integrity is central to product quality. Having a system architect is the most important single step toward conceptual integrity... After teaching a software engineering laboratory more than 20 times, I came to insist that student teams as small as four people choose a manager, and a separate architect. oder doch? Brooks, Frederick: The Mythical Man-Month (20th Anniversary Edition, 1995) Softwarearchitektur spielt eine zentrale Rolle für die erfolgreiche Erstellung, die Pflege und Wartbarkeit der Software. Die Möglichkeit der Wiederverwendung und der Wissensaufbau bzgl. Software im Unternehmen hängt davon ab. Die Softwarearchitektur ist Ihre Garantie für den Schutz Ihrer Investitionen in Softwareentwicklung. M. Broy et al: Manifest. Strategische Bedeutung des in Deutschland. In: Informatik Spektrum. Springer Verlag. Band 29, Heft 3, Juni

7 Klassische Architektur Die Architektur von Gebäuden wird beschrieben durch mehrere Sichten: Außenansicht, Grundrisse, Leitungspläne,... Architekturstile: romanisch, gotisch,... Stil und Engineering: Wie beeinflusst die Wahl des Baustils die Konstruktion des Gebäudes? Stil und Baumaterialien: Wie beeinflusst die Wahl des Baustils die verwendeten Baumaterialien? Diese Konzepte finden sich auch in SW-Systemen: es gibt Sichten: Kontrollfluss, Datenfluss, Modulstruktur, Verhaltensanforderungen,... Stile: Streams und Filter, objektorientiert, prozedural,... Engineering: Module, Filter, Nachrichten, Ereignisse,... Materialien: Kontrollstrukturen, Datenstrukturen,... 7

8 SW-Architektur oder Big Ball of Mud? Statt eine saubere Softwarearchitektur umzusetzen enden viele Softwaresysteme in einem Big Ball of Mud Mögliche Ursachen: Unterschätzung der Komplexität des Systems Fehlende Methodenkenntnis Mangelndes Durchsetzungsvermögen des Architekten Viele Köche verderben den Brei Abhilfe: Rolle des Architekten im Projekt fest verankern Methodenkenntnis + Erfahrung + Persönlichkeit sind der Schlüssel zum Erfolg 8

9 Warum Softwarearchitektur? Abhängigkeit der Gesellschaft von Software Software als Schlüssel für die Funktionsfähigkeit von Produkten Software wird zum marktunterscheidenden Element Wettbewerbsfähigkeit In vielen Branchen liegt ein Großteil der Wertschöpfung in den elektronischen und durch Software bestimmten Systemen Auch in Unternehmen des klassischen Maschinenbaus (Automobil, Werkzeugmaschinen, Anlagenbau, ) Softwaresysteme werden zunehmend komplexer Fehler können weitreichende Auswirkungen haben Online-Bank, deren Webportal ausfällt, hat plötzlich alle Filialen geschlossen Fehler im Flugsicherungssystem kann viele Menschenleben kosten Ausfall des Warenwirtschaftssystems kann ein Unternehmen Milliarden kosten (keine Bestellungen, kein Verkauf, ) 9

10 Architektur = Bauplan 10

11 Aussage von Bauplänen? Die Architektur beschreibt, Was gebaut werden soll Wie die Konstruktion im Groben aussieht Welche Materialien verwendet werden Wofür Fertigteile verwendet werden Die Architektur beschreibt nicht Wie der Maurer die Steine aufeinander schichten und miteinander verbinden soll In welcher Reihenfolge z. B. die Fenster eingesetzt werden müssen Von welchem Hersteller die Badewanne bezogen wird. Softwarearchitektur lässt dem Entwickler beim Design "seiner" Komponenten Freiräume Softwarearchitektur ist keine "Verfahrensanweisung" 11

12 Definition nach ANSI/IEE-Standard ANSI/IEE-Standard Recommended Practice for Architectural Description of Software-Intensive Systems Architecture is defined by the recommended practice as the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution. 12

13 Eine Definition in Kurzform Die Softwarearchitektur eines Programms oder Softwaresystems ist die Struktur oder sind die Strukturen des Systems, die Software-Komponenten die nach außen sichtbaren Eigenschaften dieser Komponenten und deren Beziehungen untereinander umfassen. Bass, L.; Clements, P.; Kazman, R.: Software Architecture in Practice. Addison-Wesley, Boston,

14 Komponenten: Beispiel Hafenrichter, B.: Die Struktursicht der Architektur. Vorlesungsskript, Hochschule Regensburg. Mögliche Komponenten einer Web-Anwendung 14

15 Bewertung einer Architektur? Die vorgestellte Definition lässt offen, ob eine Architektur gut oder schlecht ist. "Trial and Error" ist kein gangbarer Weg zur Auswahl einer geeigneten Architektur für ein System. Beliebige Architektur auswählen? System aufbauend auf dieser Architektur entwickeln? Hoffen, dass die Anforderungen erfüllt werden? Notwendigkeit der Entwicklung einer Architektur (Designprozess: Softwarearchitekturdesign) setzt Methodenwissen und Erfahrung(!) voraus 15

16 Eine gute Softwarearchitektur Ermöglicht dem System die Erfüllung seiner Qualitäts-, Lebenszyklus- und Verhaltensanforderungen Qualitätsmodell ISO

17 Detaillierungsgrad und Risiko Existieren kritische, anspruchsvolle Qualitätsanforderungen, muss Softwarearchitekturdesign in eine beachtliche Detailtiefe gehen, um kritische Teile des Systems zu betrachten. Der Detaillierungsgrad muss nicht für die gesamte Architektur gleich sein, sondern kann je nach Risiko für einzelne Bereiche variieren. Posch, T. et al: Basiswissen Softwarearchitektur. Verstehen, entwerfen, wiederverwenden. dpunkt.verlag, Heidelberg,

18 Zeitliche Einordnung in den Entwicklungsprozess Anforderungen Implementierung Strukturen und Beziehungen Definition der Anforderungen Software- Architektur Feindesign Implementierung Integration Test Reale SW-Entwicklung ist ein inkrementeller Prozess mit mehreren Iterationen 18

19 Zusammenfassung Softwarearchitektur ist die Zerlegung des Systems in seine Hauptbestandteile auf der obersten Ebene. Sie definiert die Architekturbausteine, deren Verantwortlichkeiten, Instanzen, Schnittstellen und wie diese miteinander interagieren. Softwarearchitekturdesign ist der zugehörige Designprozess. Softwarearchitektur manifestiert somit die frühesten und wichtigsten Designentscheidungen für das Softwaresystem. Posch, T. et al: Basiswissen Softwarearchitektur. Verstehen, entwerfen, wiederverwenden. dpunkt.verlag, Heidelberg,

20 Komponenten im Sinne der UML Komponente im Sinne der UML Bausteine, die eine bestimmte Funktionalität zum Beispiel die Kapselung der Zugriffe auf eine Datenbank bereitstellen Kommunikation mit anderen Bausteinen über eine definierte Schnittstelle Schnittstellenspezifikation bezieht sich auf statische Informationen (Signatur der erlaubten Operationen) und auf dynamische Informationen (Sequenz der erlaubten Aufrufe). Schnittstellenspezifikation legt fest: nach außen bereitgestellten Funktionalitäten bereitgestellte (engl. provided) Schnittstellen von der Umgebung geforderte Funktionalitäten benötigte (engl. required) Schnittstellen. 20

21 Komponentendiagramm Komponentendiagramm als Kontextsicht für eine Wetterstation Posch, T. et al: Basiswissen Softwarearchitektur. Verstehen, entwerfen, wiederverwenden. dpunkt.verlag, Heidelberg,

22 Elemente des Komponentendiagramms Komponente Port repräsentiert ein komplettes System bzw. einzelne Architekturbausteine. Bei der Betrachtung des Systemkontexts werden Komponenten sowohl zur Darstellung für das zu erstellende System als auch für die Nachbarsysteme verwendet. definiert einen namentlichen Interaktionspunkt einer Komponente, dem bereitgestellte und benötigte Schnittstellen zugeordnet werden können. Eine Komponente kann mehrere Ports mit gleichen Schnittstellen besitzen, d. h., die gleiche Operation kann über verschiedene Ports aufgerufen werden und wird somit intern von der Komponente unterschiedlich behandelt. Schnittstelle beschreibt die möglichen Typisierungen von Ports und damit die erlaubten Eingangs- und Ausgangsnachrichten. Schnittstellen werden benannt und in bereitgestellte und benötigte Schnittstellen unterschieden. Konnektor (engl. connector) Kommunikationskanal zwischen Komponenten. 22

23 Ausführliche Schnittstellenbeschreibung Beschreibung der Schnittstelle "Temperatur" Posch, T. et al: Basiswissen Softwarearchitektur. Verstehen, entwerfen, wiederverwenden. dpunkt.verlag, Heidelberg,

24 Verteilungsdiagramm Beschreibung eines über Kommunikationskanäle verbundenen Systems aus verteilt angeordneten Bausteinen Beschreibung der Infrastruktur für Softwaresysteme Knoten (nodes) und Verbindungen Ausführungseinheiten (z. B. Prozessoren) Geräte (devices) wie z. B. Sensoren oder Aktuatoren Softwarekomponenten können innerhalb der Knoten dargestellt werden Zusammenhang zwischen Infrastruktur und Software verdeutlichen Artefakte spezifizieren physikalische Realisierungen der Komponenten DLLs Quelldateien 24

25 Verteilungsdiagramm: Beispiel Posch, T. et al: Basiswissen Softwarearchitektur. Verstehen, entwerfen, wiederverwenden. dpunkt.verlag, Heidelberg,

26 Elemente des Verteilungsdiagramms Knoten physikalische Verteilungseinheit mit anderen Einheiten über Kommunikationsbeziehungen verbunden Kommunikationsbeziehung Kommunikationskanal zwischen zwei Knoten, beispielsweise eine serielle Leitung, einen CAN-Bus oder TCP/IP Verteilungsbeziehung Zuordnungsbeziehung zwischen einem Knoten und einem auf diesem Knoten ablaufenden Artefakt. Artefakt physikalische Realisierung eines Bausteins 26

27 "The amateur software engineer is always in search of magic, some sensational method or tools whose application promises to render software development trivial." Grady Booch, 1994 "The process of object-oriented analysis and design cannot be described in a cookbook." Grady Booch,

28 Fundamentale Entwurfsprinzipien Fähigkeit des Menschen im Umgang mit Komplexität ist begrenzt Gleichzeitige Verarbeitung auf max. 7 ± 2 Informationen eingeschränkt 5 s für die Aufnahme einer neuen Informationseinheit Bewältigung komplexer Systeme nur durch Erhöhung des semantischen 1 Gehaltes jeder Information möglich Übernahme wichtiger Prinzipien aus dem objektorientierten Entwurf, der genau diese Ziele verfolgt 1 bedeutungsmäßig 28

29 Grundprinzipien: Abstraktion Abstraktion = idealisiertes, vereinfachtes Modell eines realen Objekts Abstraktion hilft, Gemeinsamkeiten zu erkennen Abstraktion in der Softwarearchitektur Beurteilung von Bausteinen grob nach Schnittstellen und Verantwortlichkeiten Hilfsmittel zur Bewältigung der Komplexität der Aufgabe Hilfsmittel für Abstraktion und Generalisierung sind Modelle und Sichten Elemente einer Modellierungssprache stellen Abstraktionen dar Abstraktion geschieht bei ihrer Verwendung bereits implizit Eine Abstraktion ist abhängig von der Sicht des Betrachters Grady Booch: Object-oriented Analysis and Desgin with Applications, Addison-Wesley Longman, Menlo Park,

30 Grundprinzipien: Kapselung Ursprung: Geheimnisprinzip (information hiding) Verstecken von Daten und ihren Zusammenhängen im Inneren eines Bausteins Objektorientierung kapselt zusätzlich das Verhalten des Objekts Kapselung in der Architektur Fundamentales Grundprinzip für die Einteilung eines Systems in Komponenten mit definierten Verantwortlichkeiten und Schnittstellen Grundlage für viele Architekturstile Beispiel Schichtenarchitektur Grundlegende Funktionalität zur Implementierung eines Bausteins wird in der darunter liegenden Schicht gekapselt z. B. Socket-Funktionalität beim TCP/IP- Protokoll Kapselung versteckt die Details der Implementierung eines Objektes Grady Booch: Object-oriented Analysis and Desgin with Applications, Addison-Wesley Longman, Menlo Park,

31 Grundprinzipien: Modularität Modularität = Eigenschaft eines Systems, das in eine Menge von in sich geschlossenen und lose gekoppelten Modulen zerlegt wurde Elemente innerhalb eines Moduls sollten eng, Module untereinander lose gekoppelt sein Modularität ermöglicht Arbeitsteilung während des gesamten Entwicklungsprozesses Softwarearchitekt muss modulare Strukturen definieren und manipulieren Modulare Operatoren Aufteilung eines Entwurfs in Module Ersetzen eines modularen Entwurfs durch einen Alternativentwurf Hinzufügen eines neuen Moduls zu einem bestehenden System Entfernen eines Moduls aus einem System Invertieren der Hierarchie eines modularen Systems Portierung eines Moduls Modularität fasst Abstraktionen zu diskreten Einheiten zusammen Grady Booch: Object-oriented Analysis and Desgin with Applications, Addison-Wesley Longman, Menlo Park,

32 Grundprinzipien: Hierarchiebildung Arten von Hierarchien Enthalten-in- bzw. Besteht-aus-Hierarchien (Struktur) Ist-ein-Hierarchien (Generalisierung, z. B. Vererbung) Substitutionsprinzip bei Vererbungshierarchien Ein abstraktes Element sollte jederzeit durch eine seiner Spezialisierungen ersetzt werden können! Hierarchie in der Architektur Komponentenzentrierter Ansatz Strukturelle Hierarchie verschachtelter Komponenten Generalisierung und Spezialisierung ist vielseitig anwendbar auf Anforderungen, Architekturen, Verantwortlichkeiten von Bausteinen, Schnittstellen Abstraktionen bilden eine Hierarchie Grady Booch: Object-oriented Analysis and Desgin with Applications, Addison-Wesley Longman, Menlo Park,

33 Grundprinzipien: Konzeptuelle Integrität "I will contend that conceptual integrity is the most important consideration in system design." Konzeptuelle Integrität bedeutet Frederick Brooks die durchgängige Anwendung von Entwurfsentscheidungen im gesamten System und damit die Vermeidung von Speziallösungen bzw. Verwässerung der originalen Konzepte. Voraussetzung Trennung von Architekturdesign und Implementierung Ein Architekt bzw. kleines Architekturteam Folge: Erhöhung des semantischen Gehalts von Informationen Entwurfsentscheidungen (z. B. interne Kommunikationsmechanismen) gelten für das gesamte System Übergreifender Informationsgehalt System wird leichter verständlich 33

34 Kopplung Kopplung: Beziehungen unter den Bausteinen einer Softwarearchitektur Kopplung charakterisiert die Interaktionen der Bausteine Einfache Metrik: Anzahl der Beziehungen eines Bausteins zu anderen Bausteinen Arten der Kopplung am Beispiel zweier Klassen mit Zugriff auf gemeinsame Daten Gegenseitiger Zugriff auf die gemeinsamen Daten keine der Klassen kann ohne Betrachtung der anderen geändert werden Kommunikation über eine globale Datenstruktur weniger starke Kopplung, aber Änderungen der globalen Datenstruktur betreffen alle Klassen, die damit arbeiten Kommunikation über Methodenaufrufe und entsprechende Parameter Geringere Kopplung, meist nur lokale Änderungen notwendig Metrik zur Laufzeit Objekt hat hohe Kopplung zu einem anderen, wenn es dessen Methoden häufig aufruft Begriff kann auf alle Arten von Architekturbausteinen abgebildet werden 34

35 Prinzip der losen Kopplung Ziel: Komplexität von Strukturen gering halten Geringe Kopplung zwischen Bausteinen ermöglicht Verständnis eines Bausteins ohne viele andere Bausteine verstehen zu müssen Erhöhung der Änderbarkeit der Architektur lose Kopplung ermöglicht Änderungen oder Austausch eines Bausteins ohne nennenswerte Rückwirkungen auf die übrigen Bausteine Gesetz von Demeter Ein Systembaustein sollte nur eng verwandte Bausteine benutzen ("Sprich nicht mit Fremden") 35

36 Prinzip der hohen Kohäsion Kohäsion 1 : Abhängigkeiten innerhalb eines Systembausteins Köhäsion innerhalb eines Bausteins soll möglichst hoch sein Beispiel: Anzahl der Methodenaufrufe innerhalb einer Klasse Anzahl der Methodenaufrufe zwischen Klassen, die zusammen einen Baustein bilden lokale Änderbarkeit einzelner Systembausteine wird verbessert Wechselbeziehung zwischen Kopplung und Kohäsion Je höher die Kohäsion individueller Bausteine ist, desto geringer ist die Kopplung zwischen den Bausteinen Elemente mit hohem Kommunikationsbedarf (z. B. Datenaustausch) sollten daher in einem Architekturbaustein zusammengefasst werden Geringe Kohäsion führt zu starker Kopplung 1 lat. cohaerere zusammenhängen Hohe Kohäsion führt zu loser Kopplung 36

37 Prinzip des Entwurfs für Veränderung Idee: Architektonische Vorausplanung vorhersehbarer Änderungen Wahrscheinliche Änderungen Erhebung und Beachtung weiter gehender Anforderungen Unklarheiten in der Anforderungsspezifikation können auf weiter gehene Funktionalitätsanforderungen hindeuten Geplante Weiterentwicklungen Erfahrungen aus dem Entwurf ähnlicher Architekturen Umgang mit diesen Änderungen setzt Erfahrung des Architekten voraus! Unerwartete Änderungen Vorsicht! Generelle Vorausplanung ist problematisch, weiter gehender Entwurf kann Zeit und erhöhten Implementierungsaufwand bedeuten Nachteile hoch flexibler Architekturen: höherer Ressourcenverbrauch Lose Kopplung Entwurf für Veränderung Einsatz vorzugsweise an "Hot Spots" Stellen, wo schon oft Änderungen aufgetreten sind Stellen, wo viele verschiedene Aspekte einer Architektur zusammenkommen 37

38 Separation-of-Concerns-Prinzip Trennung verschiedener Aspekte eines Problems und separate Behandlung jedes dieser Teilprobleme Zerlegung eines Softwaresystems in eine Struktur von Systembausteinen Separation-of-Concerns-Prinzip unterstützt die Modularisierung Dekompositionskriterien Funktionalität oder Wiederverwendung Trennung von fachlichen und technischen Teilen Trennung der fachlichen Abstraktion von ihrer konkreten technischen Umsetzung Negativbeispiel: Steuerung für CNC-Maschinen Monolithische Software Keine Trennung zwischen Algorithmen für die Bewegungsführung, Kommunikation mit dem GUI, Bearbeitung der CNC-Programme,... Portierung auf geänderte Systemplattform nahezu unmöglich Arbeitsteilung bei der Portierung nicht möglich keine Wiederverwendung von Systemteilen möglich 38

39 Geheimnisprinzip (Information-Hiding-Prinzip) Fundamentales Prinzip zum Verstehen komplexer Systeme Zeige einem Klienten nur das, was er für seine Aufgabe benötigt Anwendung des Prinzips z. B. in der Modularisierung Kapselung von Entwurfsentscheidungen in einem Systembaustein Bekanntgabe durch wohl definierte Schnittstellen Konzept der Sichtbarkeit in Objekt- und Komponentenkonzepten (public vs. private) Data Hiding Umsetzung durch Objektorientierung, Datenbankschnittstellen und Abfragesprachen Konzepte / Beispiele zur Umsetzung Information Hiding mittels Facade (Fassade) Information Hiding durch Schichtenbildung 39

40 Information Hiding Beispiele Information Hiding mittels Facade Information Hiding durch Schichtenbildung Software-Architektur. Grundlagen - Konzepte - Praxis. Spektrum Akademischer Verlag, Heidelberg,

41 Abstraktionsprinzipien für Schnittstellen Explizite Schnittstellen Anhand eines Systembausteins soll direkt erkennbar sein, mit welchen anderen er kommuniziert Explizite Bekanntgabe von Schnittstellen Entwurf der Softwarearchitektur soll auf Basis der Schnittstellen erfolgen Trennung von Schnittstelle und Implementierung Beschreibung der Schnittstellen separat von der Implementierung Klient kann sich ohne Kenntnis der Implementierungsdetails auf die Schnittstelle verlassen Ermöglicht z. B. parallele Verwendung unterschiedlicher Versionen eines Systembausteins ohne Änderung des Klienten Liskov-Substitutions-Prinzip Bei Vererbungsabstraktionen sollen erbende Klassen von Klienten durch die Schnittstelle der vererbenden Klasse aufrufbar sein. Klient kann sich darauf verlassen, dass alle Objekte eines Typs (also auch ererbte) die gleiche Schnittstelle unterstützen Schnittstellen-Segregations-Prinzip Ein Klient sollte nie auf einer Schnittstelle basieren, die er nicht benutzt Aufteilen (segregieren) komplexer Schnittstellen, auf denen mehrere Klienttypen basieren, in mehrere einzelne Schnittstellen 41

42 Rückverfolgbarkeits- und Selbstdokumentationsprinzip Rückverfolgbarkeit (traceability) Zuordnung von Anforderungen zu Systembausteinen Zuordnung von Umsetzung architektonischer Strukturen im Code zu Entwurfsmodell, Architekturbeschreibung etc. Abbildbarkeit verschiedener Entwurfssichten aufeinander Annotationen im Code konsequente Verwendung der gleichen Bezeichnungen Selbstdokumentationsprinzip Jede Information über einen Systembaustein sollte Teil des Bausteins sein Generierung von API-Beschreibungen möglich (z. B. JavaDoc, Doxygen) Erleichtert die Rückverfolgbarkeit 42

43 Weitere Architekturprinzipien Bezug zu Anwendungsfällen Architektur soll sich im Entwurf an relevanten Anwendungsfällen orientieren Architektur schießt nicht über das angestrebte und gewünschte Ziel des Systems hinaus Vermeidung überflüssiger Komplexität Unnötig komplexe Architekturen sind meist fehleranfällig und werden nur unzureichend verstanden. Konsistenz Durchgängiger, einheitlicher Satz von Regeln bezüglich Namensgebung, Kommunikation der Systembausteine, Struktur der Schnittstellen, Aufbau der Dokumentation Konventionen statt Konfigurationen Sinnvolle Standardannahmen treffen Nur notwenige Anpassungen müssen konfiguriert werden 43

44 Architekturstile Architekturarten, die häufig angewendet werden Globale Strukturierungs- bzw. Organisationsprinzipien für Softwarearchitekten Vermischung von Architekturstilen auf einer Abstraktionsebene sollte vermieden werden Verwendung unterschiedlicher Stile auf unterschiedlichen Abstraktionsebenen ist unproblematisch, verletzt aber das Prinzip der konzeptionellen Integrität des Entwurfs Wichtige Architekturstile Schichten (Layers ) Verbindungen und Filter (Pipes and Filters) Objektorientierung Impliziter Aufruf (Implicit Invocation) 44

45 Schichten (Layers) Horizontale Schichten Jede Schicht repräsentiert eine bestimmte Abstraktionsebene Verwendung von Operationen der darunter liegenden Schicht Bietet der darüber liegenden Schicht komplexere Operationen an Strikte Schichtenarchitekturen Vorteile Jede Schicht greift nur auf Operationen der darunter liegenden Schicht zu Verschiedene Abstraktionsebenen Portierung beschränkt sich auf Portierung der untersten Schicht Betriebssicherheit und Schutz von Einbrüchen in das System, weil Überwachungsschichten leicht eingezogen werden können Nachteile Mehrbedarf an Rechenzeit Risiko bezüglich der Performance Bei strikter Schichtenarchitektur viele Indirektionen layer bridging 45

46 Verbindungen und Filter (Pipes and Filters) Beschreibung Zusammenarbeit von Bausteinen in Form eines Datenflussgraphen Jeder Baustein hat Ein- und Ausgänge, über die ein Datenstrom durch den Baustein fließt und verarbeitet wird Pipes Verbindungen zwischen den Bausteinen Einsatz und Vorteile Sinnvoll bei Verarbeitung von kontinuierlichen Datenströmen Filterbausteine arbeiten asynchron und voneinander unabhängig Einfache Verteilung auf mehrere Entwickler Umkonfigurierung und Wiederverwendung der Bausteine leicht möglich Nachteile Leistung durch Umkopieren und Transport aller Daten Wartbarkeit, weil geänderte Anforderungen mehrere Bausteine beeinflussen Zuverlässigkeit : gesamte Kette ist genauso schwach wie ihr schwächstes Glied 46

47 Beispiele: Compiler und Unix-Shell B. Anzeletti, W. Keller, R. Lewandowski, K. Messner: Vorlesung für große Informationssysteme, Technische Universität Wien, SS

48 Objektorientierung Zusammensetzung von Architekturen aus kooperierenden Objekten Objekte, die Daten kapseln Objekte, die als Manager und Controller agieren Komponenten verwalten ihre Daten und bündeln Verantwortung für Daten und Funktionalität Vorteile Trennung Implementierung Verwendung erleichtert Austauschbarkeit Wiederverwendbarkeit, etwa Klassenbibliotheken Nachteile Verwender müssen Objektidentität kennen Zerfaserung von Funktionalität auf viele Objekte 48

49 Impliziter Aufruf (Implicit Invocation) Bausteine versenden Ereignisse (events) Empfang und Bearbeitung durch ihnen unbekannte Bausteine Ereignisse sind asynchron, Ausführung empfangenden Baustein blockiert Sender des Ereignisses nicht Vorteile Nachteile Entkopplung von Bausteinen Wartbarkeit, Flexibilität Einsatz in verteiltem System möglich Overhead durch Kommunikationssystem Leistung Zusätzliche Strukturen zum Verständnis nötig (z. B. Protokolle) Beispiele Grafische Benutzeroberflächen (die Kontrollelemente wie Buttons, Slider etc. senden die Ereignisse) Eingebettete Systeme (Empfang interner und externer Ereignisse, Abarbeitung häufig in Echtzeit) 49

50 Architekturmuster Architekturstil = globales Strukturierungsprinzip für eine Softwarearchitektur Darüber hinaus: Querschnittsaspekte Nebenläufigkeit Persistenz Verteilung Betreffen die gesamte Architektur Sind unabhängig von der Wahl des Architekturstils Anwendung von Architekturmustern Architekturmuster betreffen technische Aspekte von Softwaresystemen Infrastrukturthemen Architekturmuster sind prinzipiell sprachneutral und plattformunabhängig. Konkrete Ausprägungen sind an ein bestimmtes OS oder eine Sprache gebunden, z. B. EJB oder.net. 50

51 Beispiel: Model View Controller Bei diesem Architekturmuster werden interaktive Applikationen aus drei Grundbausteinen zusammengesetzt. Die Kernfunktionalität und die Datenbasis werden im Modell (engl. model) zusammengefasst. Ansichten (engl. views) und Steuerungskomponenten (engl. controller) bilden die Benutzerschnittstelle. Dabei werden die Daten durch die Ansichten präsentiert und Eingaben durch die Steuerungskomponenten verarbeitet. Ein Notifikationsmechanismus ermöglicht die Konsistenz von Ansichten und Modell. 51

52 Heuristiken und Tipps für die Praxis (1) Heuristiken aus dem Projektumfeld Hinterfragen Sie Anforderungen! Betrachten Sie Use Cases! Nutzen Sie andere Systeme als Inspiration! Suchen Sie Feedback! Heuristiken für den Entwurf So einfach wie möglich! Bleiben Sie auf der richtigen Detailebene! Modellieren Sie angemessen komplex! Denken Sie in Verantwortlichkeiten! Nicht übergeneralisieren! Konzentrieren Sie sich auf die Schnittstellen! Entwerfen Sie so lokal wie möglich! 52

53 Heuristiken und Tipps für die Praxis (2) Heuristiken zur Beherrschung von Komplexität Teile und herrsche! Verstecken Sie Details! Kapseln Sie Risiken! Trennen Sie Funktionalität und Kontrolle! Trennen Sie Fachlogik und Infrastruktur! Heuristiken zur Arbeitsmethodik Beginnen Sie mit den schwierigsten Teilen! Verwenden Sie Prototypen! Werfen Sie Prototypen weg! Dokumentieren Sie Entscheidungen! 53

6 Architektur-Mittel (WOMIT)

6 Architektur-Mittel (WOMIT) 6 Architektur-Mittel (WOMIT) Abb. 6-1: Positionierung des Kapitels im Ordnungsrahmen. Dieses Kapitel befasst sich mit der WOMIT-Dimension des architektonischen Ordnungsrahmens, indem es grundlegende Konzepte

Mehr

Was ist Software-Architektur?

Was ist Software-Architektur? Was ist Software-Architektur? Stephan Schulze Martin Knobloch 28.04.2004 Seminar: Software-Architektur Humboldt Universität zu Berlin sschulze knobloch@informatik.hu-berlin.de Gliederung Begriffsbestimmung

Mehr

Software Engineering und Projektmanagement

Software Engineering und Projektmanagement Software Engineering und Projektmanagement Motivation! Fachliche Sicht trifft auf technische Realisierung Entwurf 2009W - 5. November 2009 Andreas Mauczka Email: andreas.mauczka@inso.tuwien.ac.at Web:

Mehr

Software Engineering. Grundlagen von Softwarearchitekturen

Software Engineering. Grundlagen von Softwarearchitekturen Software Engineering Grundlagen von Softwarearchitekturen Die Inhalte der Vorlesung wurden primär auf Basis der jeweils angegebenen Literatur erstellt. Darüber hinaus finden sich ausgewählte Beispiele

Mehr

Architektur und Qualität. Tjard Köbberling

Architektur und Qualität. Tjard Köbberling Architektur und Qualität Tjard Köbberling Gliederung Überblick Architektur und Qualität? Architekturentwurf Anforderungsanalyse Strukturierung Architekturbeschreibungen - Sichten Fallbeispiel 2 Architektur

Mehr

Gernot Starke. Effektive Softwarearchitekturen. Ein praktischer Leitfaden ISBN: 978-3-446-42728-0. Weitere Informationen oder Bestellungen unter

Gernot Starke. Effektive Softwarearchitekturen. Ein praktischer Leitfaden ISBN: 978-3-446-42728-0. Weitere Informationen oder Bestellungen unter Gernot Starke Effektive Softwarearchitekturen Ein praktischer Leitfaden ISBN: 978-3-446-42728-0 Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-42728-0 sowie im Buchhandel.

Mehr

vii Inhaltsverzeichnis 1 Einleitung 1

vii Inhaltsverzeichnis 1 Einleitung 1 vii 1 Einleitung 1 1.1 Softwarearchitektur als Disziplin im Software Engineering........ 2 1.2 isaqb International Software Architecture Qualification Board.......... 4 1.3 Certified Professional for Software

Mehr

Softwarearchitekten. Basiswissen für. dpunkt.verlag. Foundation Level

Softwarearchitekten. Basiswissen für. dpunkt.verlag. Foundation Level Mahbouba Gharbi Arne Koschel Andreas Rausch Gernot Starke Basiswissen für Softwarearchitekten Aus- und Weiterbildung nach isaqb-standard zum Certified Professional for Software Architecture - Foundation

Mehr

16 Architekturentwurf Einführung und Überblick

16 Architekturentwurf Einführung und Überblick Teil III: Software-Architekturentwurf 16 Architekturentwurf Einführung und Überblick 16.1 Software entwerfen Warum? Beim Arbeiten im Kleinen nicht oder nur ansatzweise (Detailentwurf) Größere Software

Mehr

Softwarearchitekturen I Softwareentwicklung mit Komponenten

Softwarearchitekturen I Softwareentwicklung mit Komponenten Softwarearchitekturen I Softwareentwicklung mit Komponenten Detlef Streitferdt Technische Universität Ilmenau TU-Ilmenau, Softwaresysteme / Prozessinformatik, KBSE Softwarearchitekturen I 1 Beispiel: Bibliothekssystem

Mehr

Grundlagen der Programm- und Systementwicklung

Grundlagen der Programm- und Systementwicklung Grundlagen der Programm- und Systementwicklung Technische Universität München Institut für Informatik Software & Systems Engineering Prof. Dr. Dr. h.c. Manfred Broy Unter Mitarbeit von Dr. Maria Spichkova

Mehr

Softwaretechnik (Allgemeine Informatik) Überblick

Softwaretechnik (Allgemeine Informatik) Überblick Softwaretechnik (Allgemeine Informatik) Überblick 1 Einführung und Überblick 2 Abstraktion 3 Objektorientiertes Vorgehensmodell 4 Methoden der Anforderungs- und Problembereichsanalyse 5 UML-Diagramme 6

Mehr

Software Engineering in der Praxis

Software Engineering in der Praxis Inhalt Nachlese Aufgaben Literatur Software Engineering in der Praxis Praktische Übungen Inhalt Nachlese Aufgaben Literatur Marc Spisländer Dirk Wischermann Lehrstuhl für Software Engineering Friedrich-Alexander-Universität

Mehr

1. Grundbegriffe des Software-Engineering

1. Grundbegriffe des Software-Engineering 1. Grundbegriffe Software Engineering 1 1. Grundbegriffe des Software-Engineering Was ist Software-Engineering? (deutsch: Software-Technik) Teilgebiet der Informatik, das sich mit Methoden und Werkzeugen

Mehr

Software-Architektur. Spektrum k_/takademischht VERLAG

Software-Architektur. Spektrum k_/takademischht VERLAG Oliver Vogel / Ingo Arnold /Arif Chughtai / Edmund Ihler/Uwe Mehlig/Thomas Neumann/ Markus Völter/Uwe Zdun Software-Architektur Grundlagen - Konzepte - Praxis ELSEVIER SPEKTRUM AKADEMISCHER VERLAG Spektrum

Mehr

Hochschule Darmstadt Fachbereich Informatik. Softwaretechnik II. 4.1 Darstellung der Architektur

Hochschule Darmstadt Fachbereich Informatik. Softwaretechnik II. 4.1 Darstellung der Architektur Hochschule Darmstadt Fachbereich Informatik Softwaretechnik II 4.1 Darstellung der Architektur Darstellung der Architektur Was macht ein Architekt? Viele Pläne! Endkunde Elektro Bauarbeiter Sanitär Softwaretechnik

Mehr

17 Architekturentwurf Vorgehen und Dokumentation

17 Architekturentwurf Vorgehen und Dokumentation 17 Architekturentwurf Vorgehen und Dokumentation 17.1 Einbettung Aber Erster Schritt der Lösung Wenn Anforderungsspezifikation vorliegt Vorgabe für Codierung Hierarchische Verzahnung von Anforderungen

Mehr

Interaktionen zwischen Objekten durch Senden von Nachrichten und Reagieren auf empfangene Nachrichten

Interaktionen zwischen Objekten durch Senden von Nachrichten und Reagieren auf empfangene Nachrichten Objekt Objekt kapselt Variablen und Routinen Interaktionen zwischen Objekten durch Senden von Nachrichten und Reagieren auf empfangene Nachrichten Eigenschaften jedes Objekts: Identität (identisch = mehrere

Mehr

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert The Rational Unified Process Eine Einführung von T. Langer und A. Nitert Übersicht Einleitung Probleme der SW-Entwicklung, Best Practices, Aufgaben Was ist der Rational Unified Process? Struktur des Prozesses

Mehr

Informationswirtschaft II Rational Unified Process (RUP)

Informationswirtschaft II Rational Unified Process (RUP) Informationswirtschaft II Rational Unified Process (RUP) Wolfgang H. Janko, Michael Hahsler und Stefan Koch Inhalt Historische Entwicklung Kennzeichen von RUP Lebenszyklus und Phasen Arbeitsabläufe Das

Mehr

Informationswirtschaft II

Informationswirtschaft II Rational Unified Process (RUP) Informationswirtschaft II Wolfgang H. Janko, Michael Hahsler und Stefan Koch Seite 1 Inhalt Historische Entwicklung Kennzeichen von RUP Lebenszyklus und Phasen Arbeitsabläufe

Mehr

Inhaltsverzeichnis. xiii

Inhaltsverzeichnis. xiii Inhaltsverzeichnis 1 Einleitung... 1 1.1 Ausgangslage und Zielsetzung des Buches...2 1.2 Was ist Software-Architektur?...8 1.3 Leser-Leitfaden... 11 1.3.1 Buchaufbau... 11 1.3.2 Zielpublikum... 15 1.3.3

Mehr

Client/Server-Systeme

Client/Server-Systeme Fachbereich Informatik Projektgruppe KOSI Kooperative Spiele im Internet Client/Server-Systeme Vortragender Jan-Ole Janssen 26. November 2000 Übersicht Teil 1 Das Client/Server-Konzept Teil 2 Client/Server-Architekturen

Mehr

Klassenentwurf. Wie schreiben wir Klassen, die leicht zu verstehen, wartbar und wiederverwendbar sind? Objektorientierte Programmierung mit Java

Klassenentwurf. Wie schreiben wir Klassen, die leicht zu verstehen, wartbar und wiederverwendbar sind? Objektorientierte Programmierung mit Java Objektorientierte Programmierung mit Java Eine praxisnahe Einführung mit BlueJ Klassenentwurf Wie schreiben wir Klassen, die leicht zu verstehen, wartbar und wiederverwendbar sind? 1.0 Zentrale Konzepte

Mehr

Architekturmuster. Übung MSE, 04.11.2014

Architekturmuster. Übung MSE, 04.11.2014 Architekturmuster Übung MSE, 04.11.2014 Architekturmuster Schichtenarchitektur Kontext Dekomposition großer Systeme Probleme Abhängigkeit zwischen High- und Low-Level-Funktionalität Austauschbare Komponenten

Mehr

Softwarearchitektur und Qualitätsszenarien

Softwarearchitektur und Qualitätsszenarien Softwarearchitektur und Qualitätsszenarien Mechanismen, um Qualitätsmerkmale zu erreichen Burkhardt Renz Institut für SoftwareArchitektur der Technischen Hochschule Mittelhessen Sommersemester 2015 Übersicht

Mehr

Software Engineering in der Praxis

Software Engineering in der Praxis Software Engineering in der Praxis Praktische Übungen Meitner, Spisländer FAU Erlangen-Nürnberg Objektorientiertes Design 1 / 16 Objektorientiertes Design Matthias Meitner Marc Spisländer Lehrstuhl für

Mehr

Bekannte Lösungen für bekannte Probleme benutzen. Entwurf auf höherer Abstraktionsebene als bei Programmiersprachen

Bekannte Lösungen für bekannte Probleme benutzen. Entwurf auf höherer Abstraktionsebene als bei Programmiersprachen Michael Saecker Bekannte Lösungen für bekannte Probleme benutzen Entwurf auf höherer Abstraktionsebene als bei Programmiersprachen Gemeinsames Vokabular für Designer 2 http://www.clickpix.de/sommer/architektur.jpg

Mehr

Systemanalyse I Software-Entwicklung. Die Phase Design.? Prof. Dr. Susann Kowalski

Systemanalyse I Software-Entwicklung. Die Phase Design.? Prof. Dr. Susann Kowalski Die Phase Design Design Entwerfen der Benutzeroberfläche, des Bedienablaufs und der Softwarearchitektur Umsetzen des fachlichen Modells auf technische Möglichkeiten; Spezifikation der Systemkomponenten

Mehr

Unified Modeling Language (UML)

Unified Modeling Language (UML) Kirsten Berkenkötter Was ist ein Modell? Warum Modellieren? Warum UML? Viele, viele Diagramme UML am Beispiel Was ist ein Modell? Ein Modell: ist eine abstrakte Repräsentation eines Systems, bzw. ist eine

Mehr

2.Strukturdiagramme. 2.5 Das Komponentendiagramm 2.6 Das Verteilungsdiagramm. Prof. Mario Jeckle

2.Strukturdiagramme. 2.5 Das Komponentendiagramm 2.6 Das Verteilungsdiagramm. Prof. Mario Jeckle 2.5 Das Komponentendiagramm 2.6 Das Verteilungsdiagramm Prof. Mario Jeckle Fachhochschule Furtwangen mario@ http://www. Fachhochschule Furtwangen, Sommersemester 2004 Das Komponentendiagramm Dient Darstellung

Mehr

Kapitel 1 Applikations-Architektur II

Kapitel 1 Applikations-Architektur II Kapitel 1 Applikations-Architektur II Software Engineering FS 2015 Prof. Dr. Jana Köhler jana.koehler@hslu.ch Gesamtüberblick I. Software Architektur Grundbegriffe II. Prinzipien & Taktiken III. Stile

Mehr

EINFÜHRUNG IN DIE WIRTSCHAFTSINFORMATIK -ÜBUNGEN- Marina Tropmann-Frick mtr@is.informatik.uni-kiel.de www.is.informatik.uni-kiel.

EINFÜHRUNG IN DIE WIRTSCHAFTSINFORMATIK -ÜBUNGEN- Marina Tropmann-Frick mtr@is.informatik.uni-kiel.de www.is.informatik.uni-kiel. EINFÜHRUNG IN DIE WIRTSCHAFTSINFORMATIK -ÜBUNGEN- Marina Tropmann-Frick mtr@is.informatik.uni-kiel.de www.is.informatik.uni-kiel.de/~mtr FRAGEN / ANMERKUNGEN Vorlesung Neue Übungsaufgaben MODELLIERUNG

Mehr

Softwarearchitekturen für das Internet der Energie

Softwarearchitekturen für das Internet der Energie Softwarearchitekturen für das Internet der Energie Herausforderungen und Anforderungen an die Architektur aus Sicht der Informatik Manfred Broy Lehrstuhl für Software & Systems Engineering Technische Universität

Mehr

OO Design. welche Methoden in welcher Klasse sind, und. diese Interagieren

OO Design. welche Methoden in welcher Klasse sind, und. diese Interagieren Design: GRASP 1 OO Design Definition Objektorientiertes Design: After identifiying your requirements and creating a domain model, then add methods to the software classes, and define the messaging between

Mehr

SWE5 Slide 1. Software-Engineering. Vorlesung 5 vom 15.11.2004 Sebastian Iwanowski FH Wedel

SWE5 Slide 1. Software-Engineering. Vorlesung 5 vom 15.11.2004 Sebastian Iwanowski FH Wedel SWE5 Slide 1 Software-Engineering Vorlesung 5 vom 15.11.2004 Sebastian Iwanowski FH Wedel SWE5 Slide 2 Software-Engineering Vorlesungsthemen: 1. Überblick über das Thema und die Vorlesung 2. Grundlegende

Mehr

Software Engineering

Software Engineering Literatur Gliederung Software Engineering Herbert Kuchen Universität Münster Di+Fr 14:15-15:45, M2 Wintersemester 2009/2010 1 Literatur Gliederung Basis-Literatur H. Balzert: Lehrbuch der Software-Technik,

Mehr

Inhaltsverzeichnis. Gernot Starke. Effektive Softwarearchitekturen. Ein praktischer Leitfaden ISBN: 978-3-446-42728-0

Inhaltsverzeichnis. Gernot Starke. Effektive Softwarearchitekturen. Ein praktischer Leitfaden ISBN: 978-3-446-42728-0 sverzeichnis Gernot Starke Effektive Softwarearchitekturen Ein praktischer Leitfaden ISBN: 978-3-446-42728-0 Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-42728-0 sowie im

Mehr

Langlebige Softwarearchitekturen

Langlebige Softwarearchitekturen Langlebige Softwarearchitekturen Dr. Carola Lilienthal Carola.Lilienthal@wps.de www.wps.de //// Hans-Henny-Jahnn-Weg 29 //// 22085 HAMBURG Die zwei Architekturziele für diesen Vortrag Architekturziel 1:

Mehr

Einflussfaktoren auf eine Softwarearchitektur und ihre Wechselwirkungen Entwurfsentscheidungen systematisieren

Einflussfaktoren auf eine Softwarearchitektur und ihre Wechselwirkungen Entwurfsentscheidungen systematisieren 1 Einflussfaktoren auf eine Softwarearchitektur und ihre Wechselwirkungen Entwurfsentscheidungen systematisieren W3L AG info@w3l.de 2011 2 Agenda Softwarearchitektur und Architekturentwurf Definition Überblick

Mehr

Agenda. Clients aus drei verschiedenen Perspektiven: Was ist ein Dialog? Komponentenarchitektur innerhalb eines Dialoges

Agenda. Clients aus drei verschiedenen Perspektiven: Was ist ein Dialog? Komponentenarchitektur innerhalb eines Dialoges Komponentenbasierte Client-Architektur Hamburg, 16.11.2007 Bernd Olleck IT-Beratung Olleck Agenda Clients aus drei verschiedenen Perspektiven: Technische Infrastruktur Fachliche Sicht Aufgaben eines Clients

Mehr

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme Tillmann Schall, anaptecs GmbH : Agenda Grundlagen modellgetriebener Entwicklungsprozesse Schritte zur Einführung Erfahrungen

Mehr

Einführung in Generatives Programmieren. Bastian Molkenthin

Einführung in Generatives Programmieren. Bastian Molkenthin Einführung in Generatives Programmieren Bastian Molkenthin Motivation Industrielle Entwicklung *!!*,(% % - #$% #!" + '( & )!* Softwareentwicklung Rückblick auf Objektorientierung Objektorientierte Softwareentwicklung

Mehr

Übungsklausur vom 7. Dez. 2007

Übungsklausur vom 7. Dez. 2007 Übungsklausur vom 7. Dez. 2007 Ein Lösungsmuster Teilbereiche der Softwaretechnik Software Anforderungen Software Entwurf Software Konstruktion Software Test Software Wartung Software Konfigurationsmanagement

Mehr

Objektorientierte Programmiersprachen

Objektorientierte Programmiersprachen Objektorientierte Programmiersprachen 1960 Algol 1970 Simula Pascal 1980 Smalltalk C Ada 1990 C++ Eiffel Eine ovale Box symbolisiert eine objektorientierte Programmiersprache. Eine rechteckige Box steht

Mehr

Software-Engineering

Software-Engineering FH Wedel Prof. Dr. Sebastian Iwanowski SWE2 Folie 1 Software-Engineering Sebastian Iwanowski FH Wedel Kapitel 2: Grundbegriffe und Prinzipien FH Wedel Prof. Dr. Sebastian Iwanowski SWE2 Folie 2 Grundbegriffe

Mehr

OOD. Objektorientiertes Design. Peter Coad und Edward Yourdon. Prentice Hall Verlag

OOD. Objektorientiertes Design. Peter Coad und Edward Yourdon. Prentice Hall Verlag OOD Objektorientiertes Design Peter Coad und Edward Yourdon Prentice Hall Verlag New York, London, Toronto, Sidney, Tokio, Singapur, München, Mexiko Vorwort 9 Vorwort der Übersetzer 11 Danksagungen 13

Mehr

VBA-Programmierung: Zusammenfassung

VBA-Programmierung: Zusammenfassung VBA-Programmierung: Zusammenfassung Programmiersprachen (Definition, Einordnung VBA) Softwareentwicklung-Phasen: 1. Spezifikation 2. Entwurf 3. Implementierung Datentypen (einfach, zusammengesetzt) Programmablaufsteuerung

Mehr

Modellierungstechniken im Softwaredesign. Praxisprojekt [ai] Control WS 2011/2012 Lara Baschour und Anne Heiting

Modellierungstechniken im Softwaredesign. Praxisprojekt [ai] Control WS 2011/2012 Lara Baschour und Anne Heiting Modellierungstechniken im Softwaredesign Praxisprojekt [ai] Control WS 2011/2012 Lara Baschour und Anne Heiting Was ist Modellierung? Modell = Ein Modell ist eine Repräsentation eines Systems von Objekten,

Mehr

09.01.14. Vorlesung Programmieren. Unified Modeling Language (UML) Unified Modeling Language (UML) Unified Modeling Language (UML)

09.01.14. Vorlesung Programmieren. Unified Modeling Language (UML) Unified Modeling Language (UML) Unified Modeling Language (UML) Vorlesung Programmieren Unified Modeling Language (UML) Prof. Dr. Stefan Fischer Institut für Telematik, Universität zu Lübeck http://www.itm.uni-luebeck.de/people/fischer Unified Modeling Language (UML)

Mehr

Vorlesung Programmieren

Vorlesung Programmieren Vorlesung Programmieren Unified Modeling Language (UML) Prof. Dr. Stefan Fischer Institut für Telematik, Universität zu Lübeck http://www.itm.uni-luebeck.de/people/fischer Unified Modeling Language (UML)

Mehr

Struktur und Architektur

Struktur und Architektur Struktur und Architektur Grundlagen der Software-Architektur: Vorarbeit für die Komponentenentwicklung (c)schmiedecke 07 SE1-10 - Struktur und Architektur 1 Vom Analysemodell zur Anwendungssoftware Analysemodell

Mehr

Die Inhalte der Vorlesung wurden primär auf Basis der Vorlesung Software Engineering von Prof. Dr. Faustmann (FHW Berlin Fachbereich II) erstellt.

Die Inhalte der Vorlesung wurden primär auf Basis der Vorlesung Software Engineering von Prof. Dr. Faustmann (FHW Berlin Fachbereich II) erstellt. Software Engineering Dokumentation von Softwarearchitekturen Die Inhalte der Vorlesung wurden primär auf Basis der Vorlesung Software Engineering von Prof. Dr. Faustmann (FHW Berlin Fachbereich II) erstellt.

Mehr

Software Engineering I. Architektur

Software Engineering I. Architektur Skript zur Vorlesung Basiskonzepte Statik Dynamik Logik Funktionen Daten Datenstrukturen Kontrollstrukturen Zustände Prozesse Zeitliches Verhalten Abhängigkeiten Entscheidungstabellen Mathematik Regeln

Mehr

Einführung in die Programmierung mit Java. Hörsaalübung

Einführung in die Programmierung mit Java. Hörsaalübung Einführung in die Programmierung mit Java Hörsaalübung Folie 1 Grundlagen der Objektorientierung Seit Anfang der Neunzigerjahre Standardmethode der Softwareentwicklung. Die OOP Objektorientierte Programmierung

Mehr

Objektorientierter Software-Entwurf Grundlagen 1 1. Analyse Design Implementierung. Frühe Phasen durch Informationssystemanalyse abgedeckt

Objektorientierter Software-Entwurf Grundlagen 1 1. Analyse Design Implementierung. Frühe Phasen durch Informationssystemanalyse abgedeckt Objektorientierter Software-Entwurf Grundlagen 1 1 Einordnung der Veranstaltung Analyse Design Implementierung Slide 1 Informationssystemanalyse Objektorientierter Software-Entwurf Frühe Phasen durch Informationssystemanalyse

Mehr

Ostfalia Hochschule für angewandte Wissenschaften Fakultät Elektrotechnik

Ostfalia Hochschule für angewandte Wissenschaften Fakultät Elektrotechnik Ostfalia Hochschule für angewandte Wissenschaften Fakultät Elektrotechnik Prof. Dr.-Ing. D. Meyer Software Engineering SS 2013 Bearbeitungszeit Kurzfragenteil: 30 Minuten Hilfsmittel: keine Name Vorname

Mehr

Die Macht, die uns umgibt. Design Prinzipien. Schneller und besser Software entwickeln. 2012 Jörg Bächtiger

Die Macht, die uns umgibt. Design Prinzipien. Schneller und besser Software entwickeln. 2012 Jörg Bächtiger Die Macht, die uns umgibt Design Prinzipien Schneller und besser Software entwickeln 2012 Jörg Bächtiger Joerg.Baechtiger@Abraxas.ch http://www.xing.com/profile/joerg_baechtiger Übersicht geben Zusammenhänge

Mehr

Grundlagen Software Engineering

Grundlagen Software Engineering Grundlagen Software Engineering Rational Unified Process () GSE: Prof. Dr. Liggesmeyer, 1 Rational Unified Process () Software Entwicklungsprozess Anpassbares und erweiterbares Grundgerüst Sprache der

Mehr

Software-Engineering

Software-Engineering SWE5 Slide 1 Software-Engineering Sebastian Iwanowski FH Wedel Kapitel 5: Systementwurf SWE5 Slide 2 Systemanalyse vs. Softwareentwurf Systemanalyse beschreibt das System der Anwendung, für das eine Aufgabe

Mehr

Probeklausur. Lenz Belzner. January 26, 2015. Lenz Belzner Probeklausur January 26, 2015 1 / 16

Probeklausur. Lenz Belzner. January 26, 2015. Lenz Belzner Probeklausur January 26, 2015 1 / 16 Probeklausur Lenz Belzner January 26, 2015 Lenz Belzner Probeklausur January 26, 2015 1 / 16 Definieren Sie Software Engineering in Abgrenzung zu Individual Programming. Ingenieursdisziplin professionelle

Mehr

Objektorientiertes Software-Engineering

Objektorientiertes Software-Engineering Objektorientiertes Software-Engineering Vorlesung VIII Inhalt der Vorlesung Wiederholung Vorlesung VII Factory Method Observer s Übung Vorstellung des (Gruppe Jukebox) Folie 2 Definiert ein Objekt zur

Mehr

Objektorientierte Programmierung OOP

Objektorientierte Programmierung OOP Objektorientierte Programmierung OOP Objektorientierte Programmierung OOP Ronja Düffel WS2012/13 08. Oktober 2013 Objektorientierte Programmierung OOP Objektorientierte Programmierung Objektorientierte

Mehr

Code wiederverwenden: Objektorientierte Programmierung (OOP) sinnvoll nutzen Roland Wagner Automatisierungstreff IT & Automation 2015

Code wiederverwenden: Objektorientierte Programmierung (OOP) sinnvoll nutzen Roland Wagner Automatisierungstreff IT & Automation 2015 Code wiederverwenden: Objektorientierte Programmierung (OOP) sinnvoll nutzen Roland Wagner Automatisierungstreff IT & Automation 2015 CODESYS a trademark of 3S-Smart Software Solutions GmbH Agenda 1 Warum

Mehr

Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I)

Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I) Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I) Historisch Kulturelle Informationsverarbeitung Hauptseminar: KLIPS 2.0 Dozent: Prof. Dr. Thaller Referent:

Mehr

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 1 17. Oktober 2002 www4.in.tum.de/~rumpe/se

Mehr

Softwaretechnik. Fomuso Ekellem

Softwaretechnik. Fomuso Ekellem WS 2011/12 Inhalt Entwurfsphase Systementwurf Software Architektur Entwurf Software Komponenten Entwurf Struktur Verhalten OO Entwurf (OOD) 2 Entwurfsphase 3 Entwurfsphase Lernziele Aufgaben der Entwurfsphase

Mehr

PIWIN II. Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler II. Vorlesung 2 SWS SS 08

PIWIN II. Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler II. Vorlesung 2 SWS SS 08 PIWIN II Kap. 3: Verteilte Systeme & Rechnernetze 1 PIWIN II Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler II Vorlesung 2 SWS SS 08 Fakultät für Informatik Technische

Mehr

Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1

Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1 Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1 Die Unified Modeling Language Die UML (hier in der Version 0.9) ist ein Satz von Notationen zur Beschreibung objektorientierter Softwaresysteme.

Mehr

Konzept / Architektur Diagramme

Konzept / Architektur Diagramme Architektur-Modell Konzept / Architektur Diagramme Im Übergang Analyse Design wird das System konzipiert und seine Architektur entworfen: Subsystem-Modell (execution view) UML 1.x Package Diagram «subsystem»

Mehr

Willkommen zur Vorlesung. Objektorientierte Programmierung Vertiefung - Java

Willkommen zur Vorlesung. Objektorientierte Programmierung Vertiefung - Java Willkommen zur Vorlesung Objektorientierte Programmierung Vertiefung - Java Zum Dozenten Mein Name: Andreas Berndt Diplom-Informatiker (TU Darmstadt) Derzeit Software-Entwickler für Web- Applikationen

Mehr

Design Patterns. 5. Juni 2013

Design Patterns. 5. Juni 2013 Design Patterns 5. Juni 2013 Überblick Was sind Design Patterns? Welche Design Patterns gibt es? Wann sollte man Design Patterns einsetzen? Refactoring und Design Patterns: Welchen Zusammenhang gibt es

Mehr

Vorlesung Software-Reengineering

Vorlesung Software-Reengineering Vorlesung Software-Reengineering Prof. Dr. Rainer Koschke Arbeitsgruppe Softwaretechnik Fachbereich Mathematik und Informatik Universität Bremen Wintersemester 2008/09 Überblick I 1 1 Softwarearchitektur

Mehr

Reengineering und Refactoring von Softwarearchitekturen

Reengineering und Refactoring von Softwarearchitekturen Methodische und Praktische Grundlagen der Informatik 3 Reengineering und Refactoring von Softwarearchitekturen Steffen Helke Technische Universität Berlin Fachgebiet Softwaretechnik WS 2008/2009 Lernziele?

Mehr

Inhaltsverzeichnis. Vorwort...XIII. Aufbau des Buches...

Inhaltsverzeichnis. Vorwort...XIII. Aufbau des Buches... Inhaltsverzeichnis Vorwort...XIII Aufbau des Buches............................................... XV 1 Von der Idee zur Software..................................... 1 1.1 Beispielanwendung... 1 1.2 Schritte

Mehr

Vom dem was Autos und Software GEMEINSAM haben. Diskussionsbeitrag zur Software-Industralisierung. Guido Brune

Vom dem was Autos und Software GEMEINSAM haben. Diskussionsbeitrag zur Software-Industralisierung. Guido Brune Vom dem was Autos und Software GEMEINSAM haben Diskussionsbeitrag zur Software-Industralisierung Guido Brune Gesellschaft für Informatik e. V. Regionalgruppe Dortmund 14. März 2011 Gliederung E I N L E

Mehr

Behavioral Patterns. Seminar Software-Entwurf WS 04/05. Przemyslaw Dul

Behavioral Patterns. Seminar Software-Entwurf WS 04/05. Przemyslaw Dul Behavioral Patterns Seminar Software-Entwurf WS 04/05 Przemyslaw Dul Gliederung Design Pattern (Wiederholung) Einordnung Übersicht über die Kategorien: Creational,Structural,Behavioral Übersicht über die

Mehr

Design Pattern - Strukturmuster. CAS SWE - OOAD Marco Hunziker Klaus Imfeld Frédéric Bächler Marcel Lüthi

Design Pattern - Strukturmuster. CAS SWE - OOAD Marco Hunziker Klaus Imfeld Frédéric Bächler Marcel Lüthi Design Pattern - Strukturmuster CAS SWE - OOAD Marco Hunziker Klaus Imfeld Frédéric Bächler Marcel Lüthi Agenda Einleitung Strukturmuster Fassade Model View Controller Vergleich 2 Einleitung Strukturmuster

Mehr

1. Java ist... 2. Stammbaum der Programmiersprachen 3. Die "Softwarekrise"

1. Java ist... 2. Stammbaum der Programmiersprachen 3. Die Softwarekrise im Überblick im Überblick Inhalt 1. Java ist... 2. Stammbaum der Programmiersprachen 3. Die Softwarekrise 1. Merkmale von Software 2. Fortlaufende Veränderungen 3. Erschwerte Rahmenbedingungen bei der

Mehr

Software Engineering. Fakultät Elektrotechnik Bachelor-Studiengänge, 4. Semester Prof. Dr.-Ing. Dagmar Meyer

Software Engineering. Fakultät Elektrotechnik Bachelor-Studiengänge, 4. Semester Prof. Dr.-Ing. Dagmar Meyer Fakultät Elektrotechnik Bachelor-Studiengänge, 4. Semester Vorausgesetzte Kenntnisse Allgemeine Kenntnisse aus dem Bereich der Softwareentwicklung - Programmierkenntnisse (Java, C) - Beherrschung der notwendigen

Mehr

17 Komponentenbasiertes Software-Engineering

17 Komponentenbasiertes Software-Engineering 17 Komponentenbasiertes Software-Engineering 17.0 Einführung Lernziele Grundlagen, Prinzipien und Probleme des CBSE 17.1 Komponenten und Komponentenmodelle Komponenten und ihre Eigenschaften Komponentenmodelle

Mehr

Software Engineering Analyse und Analysemuster

Software Engineering Analyse und Analysemuster Software Engineering Analyse und Analysemuster Prof. Adrian A. Müller, PMP, PSM 1, CSM Fachbereich Informatik und Mikrosystemtechnik 1 Klassendiagramme in der Analyse Im Rahmen der Anforderungsanalyse

Mehr

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung Block R (Rahmen): SE Aktivitäten 21.10.04 1 Vorlesung Methoden des Software Engineering Block R Rahmen Aktivitäten der Software-Entwicklung Martin Wirsing Einheit R.2, 21.10.2004 Block R (Rahmen): SE Aktivitäten

Mehr

Whitepaper. The Big Ball of Mud. Flexible Architekturen (Stand: August 2009)

Whitepaper. The Big Ball of Mud. Flexible Architekturen (Stand: August 2009) Whitepaper Flexible Architekturen (Stand: August 2009) The Big Ball of Mud The most frequently deployed software architecture: the Big Ball of Mud, so haben Foote und Yoder das Ergebnis von 30 Jahren Software-Engineering

Mehr

Kapitel 2: Der Software-Entwicklungsprozess

Kapitel 2: Der Software-Entwicklungsprozess Wie konstruiert man Software? Kapitel 2: Der Software-Entwicklungsprozess SoPra 2008 Kap. 2: Der Software-Entwicklungsprozess (1/10) Der Software-Entwicklungs-Prozess Historisches 1960JJ adhoc Techniken

Mehr

Praktische Softwaretechnologie

Praktische Softwaretechnologie Praktische Softwaretechnologie Martin Giese Johann Radon Institute for Computational and Applied Mathematics Österr. Akademie der Wissenschaften Linz PSWT 2006 p.1/31 Organisation PSWT 2006 p.2/31 Bestandteile

Mehr

Timo Wagner & Sebastian Kühn Entwurf einer Multi-Tier Anwendung in ASP.NET

Timo Wagner & Sebastian Kühn Entwurf einer Multi-Tier Anwendung in ASP.NET Timo Wagner & Sebastian Kühn Entwurf einer Multi-Tier Anwendung in ASP.NET Überblick 1.Einfürung in die Multi-Tier Architektur 2.Ausgangspunkt und Probleme 3.Rundgang durch die Architektur 4.Architektur

Mehr

Objektorientierte Programmierung

Objektorientierte Programmierung Teil D Objektorientierte Programmierung Kapitel D 2001 Prof. Dr. Rainer Manthey Informatik I 1 Teil D Grundlagen der objektorientierten Programmierung 2001 Prof. Dr. Rainer Manthey Informatik I 2 Objektorientierung

Mehr

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering mit Übungen Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering 2 Organisation Ort: Seminarraum 05.002, Spiegelgasse 5 Ablauf: 15:15 Vorlesung Prüfung: Schriftlich,

Mehr

Guido de Melo 5.2.2007 Fachvortrag, Uni Ulm UML 2.0. Für den Einsatz in der Praxis

Guido de Melo 5.2.2007 Fachvortrag, Uni Ulm UML 2.0. Für den Einsatz in der Praxis Guido de Melo 5.2.2007 Fachvortrag, Uni Ulm UML 2.0 Für den Einsatz in der Praxis Seite 2 Überblick 1. Ziele 2. Warum das alles? 3. Was ist UML 4. Diagrammarten 5. Umfeld Seite 3 1. Ziele 1. Ziele dieses

Mehr

ActiveCharts. Verknüpfung von Modellen und Code bei der modellgetriebenen Softwareentwicklung mit UML 2.0

ActiveCharts. Verknüpfung von Modellen und Code bei der modellgetriebenen Softwareentwicklung mit UML 2.0 Jens Kohlmeyer 05. März 2007 Institut für Programmiermethodik und Compilerbau ActiveCharts Verknüpfung von Modellen und Code bei der modellgetriebenen Softwareentwicklung mit UML 2.0 Seite 2 Übersicht

Mehr

1 Problematik eines uneinheitlichen Verständnisses der SOA... 201. 2 SOA als unternehmensweites Architekturkonzept... 203

1 Problematik eines uneinheitlichen Verständnisses der SOA... 201. 2 SOA als unternehmensweites Architekturkonzept... 203 Mehr als alter Wein in neuen Schläuchen 199 1 Problematik eines uneinheitlichen Verständnisses der SOA... 201 2 SOA als unternehmensweites Architekturkonzept........... 203 3 Struktur einer SOA..................................

Mehr

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 8 10. Dezember 2002 www4.in.tum.de/~rumpe/se

Mehr

Architekturbeschreibung im C2-Stil

Architekturbeschreibung im C2-Stil Architekturbeschreibung im C2-Stil Architekturbeschreibungssprachen Tobias Melzner Fachgruppe Spezikation und Modellierung von Softwaresystemen Fakultät für Elektrotechnik, Informatik und Mathematik Universität

Mehr

Some Software Engineering Principles

Some Software Engineering Principles David L. Parnas: Some Software Engineering Principles Marco Oppel 30.06.2004 Seminar Software-Architektur Institut für Informatik Humboldt Universität zu Berlin 1 Problemstellung Software Engineering Multi-Personen

Mehr

Agenda. Einführung und Motivation. Verteilte Objekte und Komponenten. Verteilte Softwarearchitekturen. J2EE-Plattform

Agenda. Einführung und Motivation. Verteilte Objekte und Komponenten. Verteilte Softwarearchitekturen. J2EE-Plattform Agenda Einführung und Motivation Verteilte Objekte und Komponenten Verteilte Softwarearchitekturen J2EE-Plattform J2EE-basierte Softwarearchitektur Aspekte der Verteilung von J2EE-Anwendungen 21 Ziele

Mehr

Integrating Architecture Apps for the Enterprise

Integrating Architecture Apps for the Enterprise Integrating Architecture Apps for the Enterprise Ein einheitliches Modulsystem für verteilte Unternehmensanwendungen Motivation und Grundkonzept Inhalt Problem Ursache Herausforderung Grundgedanke Architektur

Mehr

Software-Evolution im Staged Lifecycle Model

Software-Evolution im Staged Lifecycle Model Unterstützung evolutionärer Softwareentwicklung durch Merkmalmodelle und Traceability-Links Matthias Riebisch Technische Universität Ilmenau, matthias.riebisch@tu-ilmenau.de Arbeitsgruppe Software-Wartung

Mehr

Requirements Management mit RequisitePro. Rational in der IBM Software Group. Der Rational Unified Process als Basis für die Projektarbeit

Requirements Management mit RequisitePro. Rational in der IBM Software Group. Der Rational Unified Process als Basis für die Projektarbeit IBM Software Group IBM Rational mit RequisitePro Hubert Biskup hubert.biskup@de.ibm.com Agenda Rational in der IBM Software Group Der Rational Unified Process als Basis für die Projektarbeit mit Rational

Mehr

46 Softwarearchitektur mit dem Quasar-Architekturstil

46 Softwarearchitektur mit dem Quasar-Architekturstil 46 Softwarearchitektur mit dem Quasar-Architekturstil Prof. Dr. U. Aßmann Technische Universität Dresden Institut für Software- und Multimediatechnik Lehrstuhl Softwaretechnologie http://st.inf.tu-dresden.de

Mehr