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

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

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

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

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 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Effektive Architekturdokumentation mit arc42

Effektive Architekturdokumentation mit arc42 01 Whitepaper: Technologie > Architekturdokumentation Cofinpro die Experten für Kredit und Wertpapier Effektive Architekturdokumentation mit arc42 Inhalt 1 Software-Architektur mit arc42 2 2 arc42 2 3

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

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

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

Service-Orientierte Architekturen

Service-Orientierte Architekturen Hochschule Bonn-Rhein-Sieg Service-Orientierte Architekturen Kapitel 2: Einführung in Service-Orientierte Architekturen Vorlesung im Masterstudiengang Informatik Sommersemester 2010 Prof. Dr. Sascha Alda

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

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. Alexander Malkis,

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

Software-Design. Definition Der Prozess Prinzipien Strategien und Methoden Notationen. Aufgabe. HS Mannheim

Software-Design. Definition Der Prozess Prinzipien Strategien und Methoden Notationen. Aufgabe. HS Mannheim Software- Der Strategien und ist der zum Definieren der Architektur, der Komponenten, der Schnittstellen und anderer Charakteristika (Datenstrukturen, Algorithmen etc.) eines Systems oder einer Komponente

Mehr

Hochschule Darmstadt Fachbereich Informatik. Softwaretechnik II. 4. Software-Architektur

Hochschule Darmstadt Fachbereich Informatik. Softwaretechnik II. 4. Software-Architektur Hochschule Darmstadt Fachbereich Informatik Softwaretechnik II 4. Software-Architektur Häufige Mängel in Software-Projekten sind vermeidbar Softwaretechnik II, Prof. Dr. Ralf Hahn, WS2007-08, h_da, Fachbereich

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

Softwaretechnik (Medieninformatik) Überblick: 6. Objektorientiertes Design

Softwaretechnik (Medieninformatik) Überblick: 6. Objektorientiertes Design Softwaretechnik (Medieninformatik) Überblick: 6.1 Einleitung 6.2 Verfeinerung des Klassenmodells 6.3 Sequenzdiagramme 6.4 Umsetzung der Analysekonstrukte in das Design 6.5 Fallstudie 6.6 Software Kontrakte

Mehr

Tier-Konzepte. Vertiefungsarbeit von Karin Schäuble

Tier-Konzepte. Vertiefungsarbeit von Karin Schäuble Vertiefungsarbeit von Karin Schäuble Gliederung 1. Einführung 3. Rahmenbedingungen in der heutigen Marktwirtschaft 3.1 Situation für Unternehmen 3.2 Situation für Applikationsentwickler 4. Lösungskonzepte

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

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

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

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

A classification and comparison framework for software architecture description languages

A classification and comparison framework for software architecture description languages A classification and comparison framework for software architecture description languages Christian Gerth Seminar Architekturbeschreibungssprachen Prof. Dr. Heike Wehrheim Fachgebiet Spezifikation und

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

OOAD Richtlinien & Tips

OOAD Richtlinien & Tips Software-Architekturen Sommersemester 2002 Prof. Dr. Wolfgang Pree Universität Salzburg www.softwareresearch.net/swa 1 OOAD Richtlinien & Tips 2002, W. Pree, Software-Architekturen, SS2002; Teil I 2 Metriken

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

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

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

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

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

Programmierung von Steuerungen künftig objektorientiert?

Programmierung von Steuerungen künftig objektorientiert? 1 Programmierung von Steuerungen künftig objektorientiert? R. Hungerbühler, Dozent BFH R. Hungerbühler Dozent Automation BFH 2 Sichten auf Fragestellung Wissenstand Mitarbeiter /Ausbildung Entwickler,

Mehr

Stichwortverzeichnis. Effektive Softwarearchitekturen (6. Auflage)

Stichwortverzeichnis. Effektive Softwarearchitekturen (6. Auflage) Stichwortverzeichnis zu Effektive Softwarearchitekturen (6. Auflage) von Gernot Starke ISBN (Buch): 978-3-446-43614-5 ISBN (E-Book): 978-3-446-43653-4 Weitere Informationen und Bestellungen unter http://www.hanser-fachbuch.de/978-3-446-43614-5

Mehr

Einführung in die SWE

Einführung in die SWE Einführung in die SWE Inhalte der Vorlesung Allgemeine Ziele der Lehrveranstaltung Entwickeln einer kleinen Applikation nach professionellem Vorgehensmodell Erlernen des objektorientierten Herangehens

Mehr

Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich

Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich Andreas Armbrecht Siemens AG Darmstadt, 01. 02. Dezember 2009 Business Unit Rail Automation Systeme der Eisenbahnautomatisierung

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

1 Objektorientierte Software-Entwicklung

1 Objektorientierte Software-Entwicklung 1 Objektmodellierung 1 Objektorientierte Software-Entwicklung Prof. Dr. Heide Balzert Fachbereich Informatik Fachhochschule Dortmund Heide Balzert 2000 2 Lernziele Wissen, was unter objektorientierter

Mehr

Bedeutung von Interoperabilität und Standards in Grid Infrastrukturen

Bedeutung von Interoperabilität und Standards in Grid Infrastrukturen Bedeutung von Interoperabilität und Standards in Grid Infrastrukturen LMU SS 2012 Grid Computing Morris Riedel Federated Systems and Data Jülich Supercomputing Centre Forschungszentrum Jülich m.riedel@fz-juelich.de

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

Definition: Software-Entwurf (SW Design) Vorlesung Softwaretechnik Software-Entwurf Dr. Lutz Prechelt. Entwurf: Wann? Entwurf vs.

Definition: Software-Entwurf (SW Design) Vorlesung Softwaretechnik Software-Entwurf Dr. Lutz Prechelt. Entwurf: Wann? Entwurf vs. Definition: Software-Entwurf (SW Design) Ziele Entwurf vs. Architektur Vorlesung Softwaretechnik Software-Entwurf Dr. Lutz Prechelt Vorgehen Festlegung der Struktur eines Softwaresystems Welche Teile gibt

Mehr

OGC-konforme Services für 3D-Stadtmodelle

OGC-konforme Services für 3D-Stadtmodelle OGC-konforme Services für 3D-Stadtmodelle Jürgen DÖLLNER Hasso-Plattner-Institut Universität Potsdam www.hpi3d.de Einführung Zum Begriff Service-Oriented Architectures Service-Oriented Architecture - A

Mehr

eclipse - Entwicklungsumgebung und mehr ETIS SS05

eclipse - Entwicklungsumgebung und mehr ETIS SS05 eclipse - Entwicklungsumgebung und mehr ETIS SS05 Gliederung Motivation Geschichte Architektur Platform Runtime Eclipse Platform Java Development Tools (JDE) Plugin Development Environment (PDE) Zusammenfassung

Mehr

Projekt:

Projekt: <Hier den Namen des Projektes eingeben!> <Adresse> <Telefon / Fax> <Ansprechpartner> Pflichtenheft Die Aufgabe des Pflichtenheftes ist es zu beschreiben, was die zu entwickelnde Software für den Anwender leisten soll. Diese Vorlage basiert auf der aus TSE I bekannten Vorlage. Projekt:

Mehr

Implementierung von Geschäftsprozessen in der Verwaltung mit Hilfe von SOA

Implementierung von Geschäftsprozessen in der Verwaltung mit Hilfe von SOA E-Gov Fokus Geschäftsprozesse und SOA 31. August 2007 Implementierung von Geschäftsprozessen in der Verwaltung mit Hilfe von SOA Im Vortrag werden die Vor- und Nachteile von Geschäftsprozessen in der öffentlichen

Mehr

Software-Qualität im Rahmen modellgetriebener Softwareentwicklung

Software-Qualität im Rahmen modellgetriebener Softwareentwicklung Software-Qualität im Rahmen modellgetriebener Softwareentwicklung OFFIS Technologiecluster Enterprise Application Integration niels.streekmann@offis.de 09.07.2008 Seite 1 / 13 Software-Qualität: Unterschiedliche

Mehr

Praxisberichte. Plan des Vortrags. Das Rational Unified Process für die Anforderungsspezifikation

Praxisberichte. Plan des Vortrags. Das Rational Unified Process für die Anforderungsspezifikation Praxisberichte Das Rational Unified Process für die Anforderungsspezifikation Seminar in Software Engineering Spezifikationsverfahren Prof. Dr. Martin Glinz Nancy Schett Laurent Bagnoud Plan des Vortrags

Mehr

Entwurfsmuster (Design Pattern) ETIS SS05

Entwurfsmuster (Design Pattern) ETIS SS05 Entwurfsmuster (Design Pattern) ETIS SS05 Gliederung Motivation Pattern allgemein Proxy-Pattern Zusammenfassung 2 Motivation I Wie gut sind eure Programme strukturiert? Wartbarkeit? - Verständlichkeit

Mehr

Funktionale Sicherheit ISO 26262 Schwerpunkt Requirements Engineering,

Funktionale Sicherheit ISO 26262 Schwerpunkt Requirements Engineering, Funktionale Sicherheit ISO 26262 Schwerpunkt Requirements Engineering, Manfred Broy Lehrstuhl für Software & Systems Engineering Technische Universität München Institut für Informatik ISO 26262 Functional

Mehr

PIWIN I. Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler I. Vorlesung 3 SWS WS 2008/2009

PIWIN I. Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler I. Vorlesung 3 SWS WS 2008/2009 PIWIN I Kap. 8 Objektorientierte Programmierung - Vererbung 1 PIWIN I Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler I Vorlesung 3 SWS WS 2008/2009 FB Informatik

Mehr

Hochleistungsrechnen in Grids

Hochleistungsrechnen in Grids Hochleistungsrechnen in Grids ProActive Markus Matz 11.12.2006 Übersicht Grids Merkmale Probleme ProActive Aktive Objekte Knoten Virtuelle Knoten Grid Komponenten Kompatibilität & Anwendungen Markus Matz

Mehr

- Antipatterns - der Softwareentwicklung. Tanja Brockmeier

- Antipatterns - der Softwareentwicklung. Tanja Brockmeier - Antipatterns - der Softwareentwicklung Tanja Brockmeier Antipatterns Definition Antipatterns: sind eine häufige wiederkehrende Lösungen, die fehlerhaft sind und Merkmale mit sich bringen, die unerwünscht

Mehr

Oberseminar Softwareentwicklung

Oberseminar Softwareentwicklung Oberseminar Softwareentwicklung Data structures programs / Daten strukturieren Programme Pieter Hauffe Data structures programs Die Wahl der Datenrepräsentation in Software beeinflusst die gesamte Entwicklung

Mehr

3. Konzepte der objektorientierten Programmierung

3. Konzepte der objektorientierten Programmierung 3. Konzepte der objektorientierten Programmierung 3.1 Basiskonzepte 3.2 Generalisierung / Spezialisierung 3.3 Aggregation 3.4 Assoziation 3.5 Nachrichten 3.6 Polymorphismus 3. Konzepte der Objektorientierung

Mehr

1. Motivation 2. Begriffsklärung 3. Komponententests 4. Integrationstests 5. Integrationsstrategien 6. Zusammenfassung

1. Motivation 2. Begriffsklärung 3. Komponententests 4. Integrationstests 5. Integrationsstrategien 6. Zusammenfassung Übersicht s s Gregoire Kemgne 1 Motivation Problem: Software wird immer größer und komplexer, dadurch ist diese immer schwerer zu überschauen Ein Projekt benötigt mehr Zeit und/oder Entwickler. Lösung:

Mehr

Do 8.3. Schwarzweiss. Peter Hruschka. January 21-25, 2008, Munich, Germany ICM - International Congress Centre Munich

Do 8.3. Schwarzweiss. Peter Hruschka. January 21-25, 2008, Munich, Germany ICM - International Congress Centre Munich Do 8.3 January 21-25, 2008, Munich, Germany ICM - International Congress Centre Munich Schwarzweiss Peter Hruschka schwarzweiß Peter Hruschka Principal of the Atlantic Systems Guild Aachen - London - New

Mehr

Komponentenbasierte Softwareentwicklung

Komponentenbasierte Softwareentwicklung Seminar WS04 Komponentenbasierte Softwareentwicklung Karl Pauls Software-Komponente A software component is a unit of composition with contractually specified interfaces and explicit context dependencies

Mehr

Teil I Grundlagen und Organisation

Teil I Grundlagen und Organisation Teil I Grundlagen und Organisation 1 2 3 1 Grundlagen Wir sind alle stolz auf die Werkzeugmaschinen, die in den entlegensten Gebieten der Welt hohes Ansehen genießen. Deutsche Automobile zählen zu den

Mehr

Erste Erfahrungen mit NSASJ anhand der OmnivoBase Portierung. September 2013

Erste Erfahrungen mit NSASJ anhand der OmnivoBase Portierung. September 2013 GTUG Java Arbeitskreis Erste Erfahrungen mit NSASJ anhand der OmnivoBase Portierung September 2013 Jürgen Depping CommitWork GmbH Seite 1 Info@CommitWork.de www.commitwork.de Agenda Was ist OmnivoBase?

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

Java lernen mit BlueJ

Java lernen mit BlueJ Java lernen mit BlueJ Eine Einführung in die objektorientierte Programmierung David J. Barnes Michael Kölling 4.0 Lernen in Eigenregiegi Vorlesungen Seminare Übungen Bücher Webseiten Diskussionslisten

Mehr

BESSER SPÄT ALS FRÜH ARCHITEKTURENTSCHEIDUNGEN AUF DEM PRÜFSTAND. AIT GmbH & Co. KG Ihr Software effizienter entwickelt.

BESSER SPÄT ALS FRÜH ARCHITEKTURENTSCHEIDUNGEN AUF DEM PRÜFSTAND. AIT GmbH & Co. KG Ihr Software effizienter entwickelt. BESSER SPÄT ALS FRÜH ARCHITEKTURENTSCHEIDUNGEN AUF DEM PRÜFSTAND AIT GmbH & Co. KG Ihr Software effizienter entwickelt. AGENDA Problemstellung Architekturmuster vs. Designmuster MVVM Das Wesentliche Fazit

Mehr

Drei-Schichten-Architektur. Informatik B - Objektorientierte Programmierung in Java. Vorlesung 16: 3-Schichten-Architektur 1 Fachkonzept - GUI

Drei-Schichten-Architektur. Informatik B - Objektorientierte Programmierung in Java. Vorlesung 16: 3-Schichten-Architektur 1 Fachkonzept - GUI Universität Osnabrück Drei-Schichten-Architektur 3 - Objektorientierte Programmierung in Java Vorlesung 6: 3-Schichten-Architektur Fachkonzept - GUI SS 2005 Prof. Dr. F.M. Thiesing, FH Dortmund Ein großer

Mehr

Software- und Systementwurf - Softwarearchitektur -

Software- und Systementwurf - Softwarearchitektur - Software- und Systementwurf - Softwarearchitektur - Software Engineering 1 WS 2011/2011 Dr. Ina Schaefer Software Systems Engineering Technische Universität Braunschweig (Folien von Prof. B. Rumpe) Überblick

Mehr

Design im Softwareentwicklungsprozess. Stand der Dinge & Designziel. fachliche & technische Architektur. generelles Vorgehen bei Grob-Design

Design im Softwareentwicklungsprozess. Stand der Dinge & Designziel. fachliche & technische Architektur. generelles Vorgehen bei Grob-Design Design im Softwareentwicklungsprozess traditionell Geschäftsprozessmodellierung Requirements Engineering Analyse Design Implementierung Tests Design 1 test-getrieben: nur 1. Design top-down hier testgetrieben

Mehr

Softwaretechnik WS 2004/05

Softwaretechnik WS 2004/05 Softwaretechnik WS 2004/05 1 Softwaretechnik WS 2004/05 Basisveranstaltung im Studiengebiet SSG (Softwaretechnik und Systemgestaltung) Stephan Herrmann Susanne Jucknath-John Matthias Vösgen Softwaretechnik

Mehr

Das Lehren von objektorientierter Programmierung in Java mit

Das Lehren von objektorientierter Programmierung in Java mit Das Lehren von objektorientierter Programmierung in Java mit Dr. Axel Schmolitzky Arbeitsbereich Softwaretechnik Fachbereich Informatik Universität Hamburg Überblick Kurz zu meiner Person Objektorientierung

Mehr

Software-Lebenszyklus

Software-Lebenszyklus Software-Lebenszyklus Inhalt Vorgehensmodell/Phasenplan Wasserfallmodell WAS-Beschreibung WIE-Beschreibung Weitere Phasenmodelle: Spiral-Modell, V-Modell, RUP Extreme Programming SW-Qualitätssicherung

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

Das Rollenmuster. Rollenmuster

Das Rollenmuster. Rollenmuster Rollenmuster Zweck Modelliere die verschiedenen Blickwinkel eines fachlichen Gegenstands in eigenen Objekten, den sog. Rollenobjekten. Diese Rollenobjekte können dynamisch zu Kernobjekten hinzugefügt und

Mehr

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Andreas Ditze MID GmbH Kressengartenstraße 10 90402 Nürnberg a.ditze@mid.de Abstract: Data Lineage

Mehr

Datenbankmodelle 1. Das Entity-Relationship-Modell. Prof. Dr. Bernhard Schiefer 2-1

Datenbankmodelle 1. Das Entity-Relationship-Modell. Prof. Dr. Bernhard Schiefer 2-1 Datenbankmodelle 1 Das Entity-Relationship-Modell Prof. Dr. Bernhard Schiefer 2-1 Datenbankmodelle ER-Modell hierarchisches Modell Netzwerkmodell relationales Modell objektorientierte Modelle Prof. Dr.

Mehr

Softwareentwicklungsprozesse. 18. Oktober 2012

Softwareentwicklungsprozesse. 18. Oktober 2012 Softwareentwicklungsprozesse 18. Oktober 2012 Überblick Was soll ein Softwareentwicklungsprozess leisten? Überblick über Softwareentwicklungsprozesse Welche gibt es? Warum gibt es mehrere? Diskussion:

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

Aspektorientierte Modellierung

Aspektorientierte Modellierung Aspektorientierte Modellierung Softwaretechnik-Seminar 2002 Thema: Evolutionäre Software Referent: Alexander Winter Gliederung Einführung und Motivation Was ist Aspektorientierte Modellierung? Vorstellung

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

Wieviel Usability Engineering braucht das Software Engineering?

Wieviel Usability Engineering braucht das Software Engineering? Wieviel Usability Engineering braucht das Software Engineering? Prof. Dr. Institut für Informatik Neuenheimer Feld 348 69120 Heidelberg http://www-swe.uni-heidelberg.de paech@informatik.uni-heidelberg.de

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

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

arlanis Software AG SOA Architektonische und technische Grundlagen Andreas Holubek

arlanis Software AG SOA Architektonische und technische Grundlagen Andreas Holubek arlanis Software AG SOA Architektonische und technische Grundlagen Andreas Holubek Speaker Andreas Holubek VP Engineering andreas.holubek@arlanis.com arlanis Software AG, D-14467 Potsdam 2009, arlanis

Mehr

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA Liste der Handbücher Liste der Benutzerhandbücher von MEGA MEGA 2009 SP4 1. Ausgabe (Juni 2010) Die in diesem Dokument enthaltenen Informationen können jederzeit ohne vorherige Ankündigung geändert werden

Mehr

Von 0 auf SOA in 10 Schritten. Stefan Tilkov innoq stefan.tilkov@innoq.com

Von 0 auf SOA in 10 Schritten. Stefan Tilkov innoq stefan.tilkov@innoq.com Von 0 auf SOA in 10 Schritten Stefan Tilkov innoq stefan.tilkov@innoq.com 1 Stefan Tilkov Geschäftsführer und Principal Consultant, innoq Deutschland GmbH Fokus auf SOA, Web-Services, REST SOA-Editor InfoQ.com

Mehr

Software Engineering Übung 4 Architektur, Modulentwurf

Software Engineering Übung 4 Architektur, Modulentwurf software evolution & architecture lab Software Engineering Übung 4 Architektur, Modulentwurf 1 Informationen 1.1 Daten Ausgabe Di 27.10.2009 Abgabe So 08.11.2009 bis 23:59 Uhr Besprechung am Di 17.11.2009

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