SOFTWARE ENGINEERING 2

Transkript

1 Fakultät Informatik/Mathematik Lehrstuhl für Softwaretechnologie Vorlesungsmitschrift SOFTWARE ENGINEERING 2 Mitschrift von Falk-Jonatan Strube Vorlesung von Prof. Dr. Anna Sabine Hauptmann 27. März 2018

2 INHALTSVERZEICHNIS I. Vorlesung 4 1. Entwurf, Architektur, Risiken Rückblick Prozess und Produkt Struktur Grob- und Feinentwurf System vs Software-System Komplexität Risiko beim Software-Entwurf Fragen bei der Softwarentwicklung Zusammenfassung Module, Schnittstellen, Entwurf, Architektur Komponenten und Module Schnittstellen Entwurf: Prinzipien und Perspektiven Architektur Drei-Schichten-Architektur versus physische Verteilung Model-View-Control Paradigma Entwurfsprinzipien Systemstruktur Struktur im Inneren des Systems Unterstützung von loser Kopplung / innere Bindung Kopplung und Kohäsion Kopplung Kohäsion Beschreibung einer Programmierschnittstelle Langlebige Struktur im inneren System Grundlegende Entwurfsprinzipien Muster Grundlegende Architekturen Schichten / Layer Datenfluss und Filter / Pipes-and-Filters Depot-Architektur Client-Server-Architektur Peer-to-Peer-Architektur Proxy-Pattern (Vermittler/Broker) Säulenarchitektur Säulen-Architektur Säulen-Architektur Reflection Quasar

3 5. Entwurfsmuster Objektorientierte Programmierung Objekt Vererbung Substitutionsprinzip Chancen und Gefahren der Vererbung Entwurfsmuster Erzeugermuster Singleton Prototyp Fabrikmethode II. Praktikum Einführung MVC Notenverwaltung 21 3

4 Fakultät Informatik/Mathematik Lehrstuhl für Softwaretechnologie TEIL I. VORLESUNG 4

5 EINFÜHRUNG BELEGARBEIT Folie 3 Im Protokoll (bei Bedarf) nicht vergessen: Teilnehmende (entschuldigt/unentschuldigt) Festsetzungsprotokoll (wer macht was bis wann?) 5

6 1. ENTWURF, ARCHITEKTUR, RISIKEN 1.1. RÜCKBLICK Vorlesung Folie 7 Folie PROZESS UND PRODUKT Folie STRUKTUR Folie GROB- UND FEINENTWURF Folie SYSTEM VS SOFTWARE-SYSTEM Folie 13 Folie KOMPLEXITÄT Folie 14 6

7 1.7. RISIKO BEIM SOFTWARE-ENTWURF Folie FRAGEN BEI DER SOFTWARENTWICKLUNG Folie ZUSAMMENFASSUNG Folie 23 7

8 2. MODULE, SCHNITTSTELLEN, ENTWURF, ARCHITEKTUR Folie 3 Vorlesung KOMPONENTEN UND MODULE Folie 4 Folie SCHNITTSTELLEN Folie 8 Folie ENTWURF: PRINZIPIEN UND PERSPEKTIVEN Folie 10 Folie ARCHITEKTUR Folie 11 8

9 DREI-SCHICHTEN-ARCHITEKTUR VERSUS PHYSISCHE VERTEILUNG Folie 12 Folie 13 Die Drei-Schichten-Architektur sagt nichts über die physische Verteilung der Schichten aus MODEL-VIEW-CONTROL PARADIGMA Folie 14 ENTKOPPLUNG VON VIEW UND MODEL Folie 16 9

10 3. ENTWURFSPRINZIPIEN 3.1. SYSTEMSTRUKTUR Vorlesung /1 VO03.pdf Folie STRUKTUR IM INNEREN DES SYSTEMS VO03.pdf Folie 3 Kopplung: Einfluss von Außen Kohäsion: Einfluss von Innen (untereinander) VO03.pdf Folie UNTERSTÜTZUNG VON LOSER KOPPLUNG / INNERE BINDUNG Vergleich: Aufteilung in Klassen. VO03.pdf Folie 6 VO03.pdf Folie KOPPLUNG UND KOHÄSION KOPPLUNG VO03.pdf Folie KOHÄSION VO03.pdf Folie 9 10

11 3.5. BESCHREIBUNG EINER PROGRAMMIERSCHNITTSTELLE (bspw. Klassenebene) Jede öffentliche Operation/Funktion braucht: Signatur: Syntax name (...) Wesen: Semantik Was die Operation tut. Vorbedingungen Nachbedingungen Invariante (nicht veränderlich) Protokoll (synchron/asynchron) Kosten (Zeit, Rechenleistung, Dienste[ Geld],... ) Anforderungen (funktional [ Signatur / Wesen], Qualitätsanforderungen [ Vor-/Nachbed. / Invariant / Protokoll], Rahmenbedingungen [ Kosten]) 3.6. LANGLEBIGE STRUKTUR IM INNEREN SYSTEM VO03.pdf Folie 11 Open/Closed Prinzip 3.7. GRUNDLEGENDE ENTWURFSPRINZIPIEN VO03.pdf Folie 12 11

12 4. MUSTER VO04.pdf Folie 9 Vorlesung /2 VO04.pdf Folie 5 VO04.pdf Folie 6 Kategorien von Mustern: Architektur-Unabhängig: Architektur-Muster (im Grobentwurf) Entwurfs-Muster (im Feinentwurf, näher an der Implementierung) Für bestimmte Implementierungen (abhängig von der Sprache): Idiom 4.1. GRUNDLEGENDE ARCHITEKTUREN SCHICHTEN / LAYER VO04.pdf Folie DATENFLUSS UND FILTER / PIPES-AND-FILTERS Daten fließen durch Filter-Komponenten (Beispiele: Compiler, Converter,... ) DEPOT-ARCHITEKTUR In einem Depot sind Informationen, in Anwendungen/Teilsystemen werden diese dargestellt oder verarbeitet (Vergleich: objectif/case Klassendiagramm und Sequenzdiagramm greifen auf Objekte zurück [beim Löschen ist bspw. dann die Frage: Soll die Representation oder das Objekt im Depot gelöscht werden]) CLIENT-SERVER-ARCHITEKTUR Weiterentwicklung der Depot-Architektur: Das Depot verarbeitet nun auch Informationen (bekommt Funktionalität). 12

13 PEER-TO-PEER-ARCHITEKTUR Spezielle Client-Server-Architektur, wo der Client und Server eine Komponente sind PROXY-PATTERN (VERMITTLER/BROKER) Kontext, Problem Netzwerk von Clients und Servern, die Informationen austauschen sollen. Vorlesung Lösungsstrategie und Server(n) Eine spezielle Komponente übernimmt die VERMITTLUNG zwischen Clients Konsequenzen Effizienz sinkt Fehleranfälligkeit steigt Fehlertoleranzmaßnahmen (redundant, Prüf-Funktionalitäten) Kommunikationsaufwand steigt Client Proxy Broker Server Proxy Client Server SÄULENARCHITEKTUR Client (Benutzerschnittstelle) Anwendungslogik Server (Datenbank-Server) SÄULEN-ARCHITEKTUR Client Applikationsserver (Anwendungsserver) DB-Server SÄULEN-ARCHITEKTUR Client Formularerstellung Applikationsserver (Anwendungsserver) DB-Server Client DB-Server Anwendungslogik Client Benutzerschnittstelle Server Datenbank-Server (zentrale Datenhaltung) Applikationsserver (Anwendungsserver) REFLECTION REFLEXIVES SYSTEM, d.h. dynamische Veränderung von Struktur + Verhal- Kontext, Problem ten 13

14 Lösungsstrategie Metaebene Informationen über spezielle Systemeigenschaften Basisebene Anwendungslogik Veränderung in der Metaebene beeinflussen die Basisebene QUASAR Referenzarchitektur Wurde entwickelt bei der Firma sd&m ( , seit 2001 bei Capgemini ). Vorlesung Ziel Trennung von Zuständigkeiten realisieren Programmierung gegen Schnittstellen realisieren Denken in Komponenten fördern Trennung von Zuständigkeiten Definition von SW-KATEGORIEN Ansatz bei Quasar: SW-Komponenten klassifizieren durch SW-Kategorien Trennung von ANWENDUNG und TECHNIK Kategorie A-Software von fachlicher Anwendung bestimmt Kategorie T-Software technische Komponenten, von mindestens einer API bestimmt (DB-anschluss, Technologie der Oberflächenprogrammierung,... ) weitere: Kategorie AT-Software (möglichst vermeiden!) Mischung aus A- und T-Komponenten Kategorie R-Softwaree reserviert für Bausteine, die als Transformator zwischen A- und T-Software liegen Einfache Darstellung: 14

15 UI1... ) Nachbarsysteme Adapter ) ) Anwendungskern A-Software R-Software ( ( Authorisierung Regelinterpreter ) Persistenzframework T-Software DB Detaillierte Darstellung: VO06Quasar.pdf Folie 1 15

16 5. ENTWURFSMUSTER 5.1. OBJEKTORIENTIERTE PROGRAMMIERUNG Vorlesung Instanz (in der Realität) einer abstrakten Bauanleitung Kapselung Vererbung Schnittstelle wird benutzt ( Kapselung) Zusammenführung von Daten und Methoden. Folie OBJEKT Folie 5 Folie 6 Folie VERERBUNG Folie 8 Polymorphie (mit früher/später Bindung) Folie SUBSTITUTIONSPRINZIP Folie 10 16

17 CHANCEN UND GEFAHREN DER VERERBUNG Folie ENTWURFSMUSTER Folie 12 Folie 14 Folie ERZEUGERMUSTER Folie 16 Problem Komplexe Objekte erstellen. Vorlesung Kontext Erzeugung und Darstellung eines Objektes getrennt (Methode der Erzeugung interessiert Client nicht): Konvertierung von Zeichenketten, Erzeugung von Fensteranordnungen [bspw. in Eclipse]. Lösungsstrategie Ein Direktor delegiert das Erbauen an einen Erbauer, der das Produkt dann ausgibt. einfache Erweiterung und gute Kapselung SINGLETON Problem absichern, dass nur ein Objekt instanziiert wird Kontext Zugriff auf zentrale HW-Ressourcen (z.b. eine Instanz einer Drucker-Warteschlange) Lösungsstrategie Anzahl von Instanzen zählen ( wenn 0, dann instanziieren sonst nicht). Variable, die den Wert aufnimmt Kontrollierte Instanziierung im Standardkonstruktor prüfen 17

18 1 Standardkonstruktor privat 2 GibInstanz (){ 3 // prüfen 4 // Aufruf des Standardkonstruktors, abh ä ngig vom Pr ü fergebnis 5 } Singleton - instanz: singleton - singleton(); + GibInstanz(): singleton; PROTOTYP Problem Ein Sachverhalt viele Ausprägungen. Kontext Erzeugung eines neuen Dokuments in Word Dokument wird nach Prototyp (Vorlage) erzeugt Vorlage zur Serienfertigung. Lösung Nur eine Klasse eine Instanz gespeichert beliebig viele Kopien davon können Prototyp erstellt werden. + clone(); FABRIKMETHODE Problem verschieden Produkte mit ähnlichem Aufbau Lösung (abstrakte) Klasse, die einen Grundaufbau für alle Produkte enthält. 18

19 Fakultät Informatik/Mathematik Lehrstuhl für Softwaretechnologie TEIL II. PRAKTIKUM 19

20 1. EINFÜHRUNG MVC INHALTE Wiederholung objectif Persektive: Entwurf technische Sicht Klassendiagramm statische Struktur Darstellung des VERHALTENS (Dynamik, Progress) Sequenzdiagramm Konkretes Beispiel: MVC NOTIZEN Controller und View hängen immer zusammen, da die Art, wie ich kontrolliere abhängig ist von der Art, wie mir zu Kontrollierendes angezeigt wird. Das Klassendiagramm(KD) zeigt mögliche Botschaftswege. Das Sequenzdiagramm(SD) zeigt die zeitliche Reihenfolge konkreter Botschaften (d.h. Methodenaufrufe). Modellelemente: Instanz (Objekt) als Lebenslinie rot: zugeordnete Klasse), schwarz: ohne zugeordnete Klasse verdickt: wenn Instanz an Botschaft beteiligt ist Botschaft Systemgrenze 20

21 2. NOTENVERWALTUNG 1. Methodik: Modell (objectif) Roundtrip-Verfahren Forward Engineering Reverse Engineering Implementation (MS VisualStudio.NET) 2. Architektur: 3-Schichten-Architektur Präsentation Logik Datenhaltung Im objectif: Schichten sind Pakete Paketdiagramm Im VisualStudio: Schichten sind Projekte Projektmappe Vereinbarung: Verbindung der Schichten zwischen objectif und VisualStudio außer bei der Präsentation Dialog bauen MS Visual Studie.NET KD: DBService objectif Paket Typen (Student, Fachnote) objectif Synchronisation: Modell Implementation objectif MS Visual Studio Vorlesung