Vorlesung Software Engineering I

Vorlesung Software Engineering I
Statische Basiskonzepte 2 (Architektur) Software Engineering I VE 09: Statische Basiskonzepte 2 Version

Systemsichten und Modellierung
Statik Funktionen Daten Datenstrukturen Architektur Dynamik Kontrollstrukturen Zustände Prozesse Zeitliches Verhalten Logik Abhängigkeiten Entscheidungstabellen Mathematik Regeln Beschreiben die feste Struktur des Systems, die sich während der Laufzeit nicht ändert. Beschreiben das Verhalten und die Veränderungen während der Laufzeit. Beschreiben die Programmfunktion logisch und mathematisch Software Engineering I VE 09: Statische Basiskonzepte 2 Version

Definiton: Software-Architektur
Was ist Software-Architektur? • J.Siedersleben: “Es geht um die Frage, wie man Millionen Programmzeilen großer Systeme so strukturiert, dass im Ergebnis die gewünschte Qualität erreicht wird: Wartbarkeit, Flexibitlität, Performance und andere Eigenschaften.„ • H.Balzert: “eine strukturierte oder hierarchische Anordnung der Systemkomponenten sowie Beschreibung ihrer Beziehungen“ • T.Posch: „Softwarearchitektur entstand aus der Notwendigkeit heraus, immer größer und komplexer werdende Software zu beherrschen." Software Engineering I VE 09: Statische Basiskonzepte 2 Version

Definition: Software Architektur
Software-Architektur beschreibt die Beziehungen der Fachkomponenten untereinander, mit weiteren Systemkomponenten, sowie der Systemumgebung. Auswahlkriterien: Art der Aufgabenstellung Realisierungsvorgaben nicht-funktionale Systemanforderungen Ziel: klare Struktur eindeutige "Rollen" der Komponenten wenige, klar umrissene Kommunikationsschnittstellen Verkürzt kann man sagen, dass eine Architektur regelt, welche Komponente mit welcher kommuniziert. Software Engineering I VE 09: Statische Basiskonzepte 2 Version

Keinerlei Architektur
Software Engineering I VE 09: Statische Basiskonzepte 2 Version

Prinzip Strukturierung
Strukturierung = (separation of concerns / Unterteilung in Aspekte) Arten der Unterteilung zeitliche Unterteilung: Anforderungsanalyse / Entwurf / Programmierung / Test qualitative Unterteilung: Effizienz / Robustheit / Korrektheit perspektivische Unterteilung: Statik /Dynamik / Logik (Datenstrukturen / Datenfluss / Kontrollfluss) Dekomposition (Unterteilung in Bestandteile): Komponente 1, Komponente 2 (-> diese Unterteilung ist so wesentlich, dass sie unter dem Prinzip Modularität gesondert betrachtet wird!) Software Engineering I VE 09: Statische Basiskonzepte 2 Version

Prinzip: Strukturierung
Dekomposition Komposition Legende Komponente / Modul A A ruft B auf B Software Engineering I VE 09: Statische Basiskonzepte 2 Version

Unterteilung eines komplexen Systems in Komponenten / Module
Prinzip: Modularität Unterteilung eines komplexen Systems in Komponenten / Module Anwendungsbeispiele Schreiben eines Berichts (Gliederung) Bau eines Autos (Arbeitsteilung) Modularität als Ergebnis der Dekomposition Modularität als Grundlage der Komponierbarkeit Modularität als Voraussetzung für Wiederverwendung Modularität als Voraussetzung für lokale Änderungen Bestandteile eines Moduls Operationen Objekttypen Beziehungen zwischen Objekttypen DEFINITION 6.7. Geheimnisprinzip (information hiding). Kriterium zur Gliederung eines Gebildes in Komponenten, so dass jede Komponente eine Leistung (oder eine Gruppe logisch eng zusammenhängender Leistungen) vollständig erbringt und zwar so, dass außerhalb der Komponente nur bekannt ist, was die Komponente leistet. Wie sie ihre Leistungen erbringt, wird nach außen verborgen. Parnas hat das Geheimnisprinzip ursprünglich definiert als das Einkapseln von Entwurfsentscheidungen beim Modularisieren von Software mit dem Ziel, die Realisierung der Entwurfsentscheidungen vor den Modulverwendern zu verbergen und die Entwürfe dadurch leichter änderbar zu machen. Die Definition 6.7 wurde bewusst allgemeiner gefasst, um deutlich zu machen, dass es sich hier um ein weit über den Software-Entwurf und die Informatik hinausreichendes, allgemeines und fundamentales Abstraktionsprinzip zur Beherrschung komplexer Systeme handelt. Wir benutzen das Geheimnisprinzip tagtäglich zur Beherrschung der Komplexität unserer Umwelt; etwa indem wir Auto fahren, ohne wissen zu müssen, wie ein Verbrennungsmotor funktioniert oder ein elektrisches Gerät in Betrieb nehmen, ohne wissen zu müssen, wie der Strom in die Steckdose kommt. Im Software-Entwurf sind die Komponenten Module, die Leistungen Teillösungen. Das WAS ist in der Modulschnittstelle beschrieben, das WIE sind die Entwurfsentscheidungen und ihre Realisierung durch Programme. Software Engineering I VE 09: Statische Basiskonzepte 2 Version

Prinzip: Modularität ff.
Kohäsion (cohesion). Ein Maß für die Stärke des inneren Zusammenhangs eines Moduls. Je höher die Kohäsion ist, desto besser. Kopplung (coupling). Ein Maß für die Abhängigkeit zwischen zwei Modulen. Die Modularisierung ist umso besser, je geringer die wechselseitige Kopplung zwischen den Modulen ist. Software Engineering I VE 09: Statische Basiskonzepte 2 Version

Ziel von Modularität: hohe Kohäsion geringe Kopplung Geheimnisprinzip („Information Hiding“) d.h. enger interner Zusammenhalt innerhalb eines Moduls wenig Wechselwirkungen mit anderen Modulen außerhalb des Moduls nur bekannt, was die Komponente leistet. Wie sie ihre Leistungen erbringt, wird nach außen verborgen. Nur dann Wiederverwendung in kleinen Teilen lokale Änderbarkeit Software Engineering I VE 09: Statische Basiskonzepte 2 Version

hohe Kohäsion / geringe Kopplung geringe Kohäsion / geringe Kohäsion / hohe Kopplung hohe Kopplung Software Engineering I VE 09: Statische Basiskonzepte 2 Version

Trennung von wichtigen und unwichtigen Merkmalen
Prinzip: Abstraktion Trennung von wichtigen und unwichtigen Merkmalen „Unterschlagung“ / „Wegabstraktion“ der unwichtigen und Betonung der wichtigen zum Zweck der Konzentration auf das Wesentliche Gängige Abstraktionen die Signatur einer Operation abstrahiert von der Realisierung der Operation die Konstrukte einer Programmiersprache abstrahieren von Prozessorendetails ein Datenflussdiagramm abstrahiert von den Aufrufstrukturen zwischen Komponenten Software Engineering I VE 09: Statische Basiskonzepte 2 Version

Prinzip: Abstraktion ff.
wichtig unwichtig für mit dem Auto Reisende für mit dem Zug Reisende Straßen Gleise, Hauptbahnhöfe Radwege Straßen, Radwege Abstraktion Straßenkarte: wichtig unwichtig für den Anwender für den Vorstand für den Entwickler Oberflächen, Funktionalität Rentabilität Schnittstellen zwischen Komponenten Interne Struktur Plattform Schulungsaufwand für neue Software Abstraktion Software: Software Engineering I VE 09: Statische Basiskonzepte 2 Version

Prinzip: Änderungsnotwendigkeit
Software ist Gegenstand von Änderungen. Ursachen für Änderungen: (Geplante) Inkrementelle Entwicklung Beseitigung von Fehlern (korrektive Wartung) Verbesserung nichtfunktionaler Eigenschaften (perfektive Wartung) Erweiterung der Funktionalität wegen sich ändernder Rahmenbedingungen (adaptive Wartung) (Ungeplante) Erweiterung der Funktionalität wegen Erkenntnisgewinn während der Entwicklung Software Engineering I VE 09: Statische Basiskonzepte 2 Version

Prinzip: Objektorientierung
Die Programmstruktur besteht nicht direkt aus Abläufen, sondern aus Objekten mit Eigenschaften und Methoden (Daten und darauf operierenden Funktionen) Das Programm besteht aus Interaktionen zwischen den Objekten Die Objekte werden stets nur von außen betrachtet und verbergen ihren inneren Aufbau.  Modularität und Abstraktion Software Engineering I VE 09: Statische Basiskonzepte 2 Version

Notationen für Architektur
Blockdiagramme UML: Implementierungsdiagramme, auch Klassendiagramm als kleinste modulare Einheit aus Architektursicht. Konfigurationsdiagramm UML: Verteilungsdiagramm Software Engineering I VE 09: Statische Basiskonzepte 2 Version

Blockdiagramme Blockdiagramme sind kein Bestandteil von UML!
(Gleichwertige Notation in UML: Implementierungsdiagramm) Blockdiagramme sind ein verbreitetes Hilfsmittel zur Skizzierung der logischen Struktur einer Systemarchitektur. Subsystem umfasst Objekte bestimmter Klassen Schnittstelle ist klar definiert (Aufrufschnittstelle, Kommunikationsprotokoll) Software Engineering I VE 09: Statische Basiskonzepte 2 Version

UML:Implementierungsdiagramm

Konfigurationsdiagramme

UML: Verteilungsdiagramm

Architekturmuster und -patterns
Allgemeine Definitionen Muster (Patterns) beschreiben häufig auftretende Entwurfsprobleme und dazu universell verwendbare generische Lösungsschemen. Architekturmuster beziehen sich auf die Architektur von Softwaresystemen. Entwurfsmuster (Design Patterns) sind weniger stark abstrahiert und beziehen sich eher auf die Softwarekodierung. Die bekanntesten Design Patterns sind von GoF beschrieben (Gang of Four: Gamma, Helm, Johnson und Vlissides). Arten von Architekturmustern Struktur (Layer, Pipes and Filters, Blackboard) Verteilte Systeme (Broker, P2P, Client-Server) Interaktive Systeme (MVC / Model-View-Controller, Presentation-Abstraction-Control) Adaptierbare Systeme (Microkernel, Reflection) Ereignisverarbeitung (Proactor, Reactor) Synchronisation (Object Synchronizer) Arten von Entwurfsmustern (Design Patterns) Erzeuger-Muster (Prozess der Objekterzeugung: Abstract Factory, Builder, Factory Method, Prototype, Singleton) Struktur-Muster (Zusammenbau von Klassen und Objekten: Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy) Verhaltens-Muster (Algorithmen sowie Aufgabenteilung zwischen Klassen: Iterator, Mediator, Observer, State, Strategy, Template Method, Visitor) Was ist ein Muster? Muster sind abstrahierte Repräsentationen erfolgreich eingesetzten Problemlösungswissens 􀀀 abstrahiert: Muster beziehen sich auf wiederkehrende Probleme erfolgreich: die Kenntnis von Mustern erspart es einem, das Rad immer wieder selbst erfinden zu müssen eingesetzt: Muster in der Software-Technik sind damit ”das Zunftbuch für Software–Entwickler“ Problemlösungswissen: Muster geben einen Vorschlag f ür effiziente / elegante Lösungen der Problemstellung Muster, die Probleme von Bestandteilen eines Software-Systems adressieren, werden Software-Muster genannt. Software Engineering I VE 09: Statische Basiskonzepte 2 Version

Architekturmuster Allgemeine Strukturierung
– Schichten – Pipes and Filter – Datenhaltung (Blackboard) Strukturierung von Realzeitsystemen – Monitorstruktur Strukturierung verteilter Systeme – Peer-To-Peer – Client-Server – Mehrschichtige Architekturen – Broker Strukturierung Interaktiver Systeme – Model-View-Controller (MVC) – Presentation-Abstraction-Control (PAC) Software Engineering I VE 09: Statische Basiskonzepte 2 Version

Allgemein: Schichtenarchitektur
Verboten! Software Engineering I VE 09: Statische Basiskonzepte 2 Version

Allgemein: Pipe and Filter Architektur

Allgemein: Datenhaltungsarchitektur

Realzeit: Monitor-Architektur

Verteilt: Peer-to-Peer-Architektur

Verteilt: Client-Server-Architektur

Verteilt: Broker-Architektur

Entkopple Client und Server durch eine so genannte Broker–Komponente
Broker - Architektur Entkopple Client und Server durch eine so genannte Broker–Komponente Server registrieren sich beim Broker Server macht seine Dienste durch eine Schnittstelle bekannt Clients greifen auf die Dienste des Servers durch Aufträge über den Broker zu Broker lokalisiert passenden Server, gibt Auftrag weiter und Ergebnisse/Ausnahmen an den Client zurück Hinzufügen, Entfernen, Austausch und Migration von Komponenten zur Laufzeit Für Entwickler und Benutzer sollte es zwischen zentralisierten Systemen und verteilten Systemen keinen Unterschied geben Software Engineering I VE 09: Statische Basiskonzepte 2 Version

Broker - Architektur: CORBA
CORBA – Common Object Request Broker Architecture Standardarchitektur für objekt-orientiertes, verteiltes Rechnen der Object Management Group (OMG) im Rahmen der OMA Interoperabilität zwischen Objekten durch Schnittstellenbeschreibung in Interface Definition Language (IDL) Objektimplementierungen in verschiedenen Implementierungssprachen durch Abbildung des Objekt–Modells auf Elemente der IDL plattformübergreifende Kommunikation durch CORBA–Architektur als Instanz des Broker–Architekturmusters Software Engineering I VE 09: Statische Basiskonzepte 2 Version

Mehrschichten-Architektur
Schichten–Architekturen sind konzeptionell unabh¨angig von objektorientierten Ans¨atzen Software Engineering I VE 09: Statische Basiskonzepte 2 Version

Mehrschichtenarchitektur

Zwei-Schichten-Architektur

Drei-Schichten-Architektur

Schichtenmodelle zur Netzwerkkommunikation
Als das OSI-Modell entwickelt wurde, sollte es zum bereits existierenden DoD-Modell abwärtskompatibel sein. Software Engineering I VE 09: Statische Basiskonzepte 2 Version

OSI Schichtenarchitektur

Architekturmuster: Model-View-Controller
Strukturierung in die drei Einheiten Datenmodell (engl. model), Präsentation (engl. view) und Programmsteuerung (engl. controller). Ziel des Musters ist ein flexibler Programmentwurf, der eine spätere Änderung oder Erweiterung erleichtert und eine Wiederverwendbarkeit der einzelnen Komponenten ermöglicht. Mit Model-View-Controller (kurz MVC) bezeichnet man ein Entwurfsmuster (genauer ein Architekturmuster), das in der Objektorientierten Programmierung Verwendung findet. Es trennt ein Programm auf in seine Teilkomponenten: Daten (Model), Präsentation (View), Programmsteuerung (Controller). Es soll so ein flexibles Programmdesign erzeugt werden, das Erweiterungen vereinfacht und die Wiederverwendbarkeit der einzelnen Komponenten ermöglicht. Durch die einfache, klare Struktur wird die Komplexität gesenkt und Ordnung geschaffen. Weiterer Vorteil: Die Aufgaben der einzelnen Personen können einfach und genau eingeteilt werden. Z.B. kann sich ein Designer auf das Layout des Views konzentrieren. Das Model-View-Controller-Konzept wird in vielen Bereichen moderner Softwareentwicklung eingesetzt und bedeutet die strikte Aufgabenverteilung bei einer Anwendung. So wird als Model die Datenquelle bezeichnet, die Daten unabhängig vom Erscheinungsbild liefert (also beispielsweise aus einer relationalen Datenbank). Die View zeigt diese Daten dann in passender Art und Weise an (z.B. als Tabelle in einer Java-Applikation) - bestimmt durch den »Look«. Wie diese View die Daten anzeigt wird nicht vom Model beeinflusst Model View Controller (MVC, ‚Modell/Präsentation/Steuerung‘) ist ein Architekturmuster zur Strukturierung von Software-Entwicklung in die drei Einheiten Datenmodell (engl. model), Präsentation (engl. view) und Programmsteuerung (engl. controller). Ziel des Musters ist ein flexibler Programmentwurf, der eine spätere Änderung oder Erweiterung erleichtert und eine Wiederverwendbarkeit der einzelnen Komponenten ermöglicht. Es ist dann zum Beispiel möglich, eine Anwendung zu schreiben, die das gleiche Modell benutzt, aber einerseits eine Windows- oder Linux-Oberfläche realisiert, andererseits aber auch eine Weboberfläche beinhaltet. Beides basiert auf dem gleichen Modell, nur Controller und View müssen dabei jeweils neu konzipiert werden. Das MVC-Konzept wurde 1979 zunächst für Benutzeroberflächen in Smalltalk durch Trygve Reenskaug beschrieben (Seeheim-Modell), der damals an Smalltalk im Xerox PARC arbeitete. Es gilt mittlerweile aber als De-facto-Standard für den Grobentwurf vieler komplexer Softwaresysteme, teils mit Differenzierungen und oftmals mehreren jeweils nach dem MVC-Muster aufgeteilten Modulen. Software Engineering I VE 09: Statische Basiskonzepte 2 Version

MVC: Beispiel Software Engineering I VE 09: Statische Basiskonzepte 2
Version

Vorlesung Software Engineering I

Ähnliche Präsentationen

Präsentation zum Thema: "Vorlesung Software Engineering I"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback

Anmelden

Anmeldung über soziales Netzwerk:

Vorlesung Software Engineering I

Ähnliche Präsentationen

Präsentation zum Thema: "Vorlesung Software Engineering I"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback