5. Design: Architektur-Grundlagen Softwaretechnik (CNAM) Wintersemester 2011 / 2012 Prof. Dr. Bernhard Humm Hochschule Darmstadt, FB Informatik

Transkript

1 5. Design: Architektur-Grundlagen Softwaretechnik (CNAM) Wintersemester 2011 / 2012 Prof. Dr. Bernhard Humm Hochschule Darmstadt, FB Informatik 1 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

2 Einordnung in den gesamten Kurs 1. Einführung 2. Analyse: Anforderungen und Anwendungsfälle 3. Analyse: Datenmodell 4. Analyse: Dialoge 5. Design: Architektur-Grundlagen 6. Design: Referenzarchitektur betriebliche Informationssysteme 7. Design: Querschnittsthemen und Muster 8. Programmierung 9. Test, Einführung, Qualitätsmanagement 10. Projektmanagement 11. Vorgehensmodelle 2 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

3 Agenda Motivation Architektur-Sichten Software-Kategorien Komponenten & Schnittstellen Regeln für den Komponentenschnitt Spezifikation von Schnittstellen Literatur, Kontrollfragen Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

4 Design: Die Königsdisziplin des Software Engineering Analyse WAS? Design WIE? 4 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

5 Architektur: Verteidigen Quelle: 5 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

6 Architektur: Beeindrucken Quelle: 6 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

7 Architektur: Verkehrsfluss Quelle: 7 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

8 Architektur: Erweitern Quelle: 8 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

9 Architektur: Mobilität Quelle: 9 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

10 Architektur: Grundriss 10 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

11 Architektur: Aufriss 11 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

12 Architektur: Elektriker-Sicht 12 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

13 Architektur: Sanitär-Installateur-Sicht 13 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

14 Softwaresysteme gehören zu den komplexesten Dingen, die Menschen je gemacht haben 14 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

15 und brauchen daher eine gute Architektur Wo ist hier die Architektur? Übersicht Quelle: Erich Gamma, "100 OO Frameworks, Pitfalls and Lessons Learned", Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

16 Übersicht Wichtigste Aufgaben der Design-Phase Fachliches (Anwendungs-)Design Zerlegung (Dekomposition) des Systems in Komponenten (z.b. in Vertragsverwaltung, Kundenverwaltung ) Festlegung der Schnittstellen (Operationen) Technisches Design (parallel zur Analysephase durchführbar) Festlegung der technischen Infrastruktur (GUI-Toolkit, Datenbanksystem, App. Server, Frameworks, Hardware, ) Festlegung der Entwicklungsumgebung (SEU) (Programmiersprache, Umgebung, Build-Tool, Bugtracker, ) Festlegung der Grobstruktur des Systems (Schichten, Tiers, Standard-Architektur, ) Festlegung der (Programmier-)richtlinien (Coding Conventions, Verzeichnisstruktur, Nutzungskonzepte für Tools, ) 16 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

17 Agenda Motivation Architektur-Sichten Software-Kategorien Komponenten & Schnittstellen Regeln für den Komponentenschnitt Spezifikation von Schnittstellen Literatur, Kontrollfragen Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

18 Architektur- Sichten A-Architektur (fachliche Anwendungsarchitektur) frei von technischen, produktbezogenen Sachzwängen wird für jedes Projekt neu entwickelt strukturiert die Software aus der Sicht der Anwendung enthält fachliche Klassen wie Mitarbeiter oder Konto. T-Architektur (Technikarchitektur) verbindet A- und TI- Architektur; beschreibt die virtuelle Maschine, auf der die mit der A-Architektur entworfene Software läuft. TI-Architektur (Architektur der technischen Infrastruktur) beschreibt die physischen Geräte (Rechner, Netzleitung, etc.), die darauf installierte Systemsoftware (Betriebssystem, Application-Server, etc.), das Zusammenspiel von Hardware und Systemsoftware sowie die verwendeten Programmiersprachen. 18 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

19 Beispiel-Projekt für Logistik-Dienstleister Kunde: großer Logistik-Dienstleister Projekt: Auftragsmanagement Volumen Stufe 1: > 30 BJ Zeit: April 2003 Januar Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

20 Beispiel für A-Architektur Master Applikation Informationsanforderung Benutzerverwaltung Frontend Internes Informationsservice und Clearing Portal Informationsservice und Clearing Benutzerverwaltung Stammdatenverwaltung Clients ESI-Frontend Benutzerverwaltung Stammdatenverwaltung SA- Frontend SA- Batch- Scanner SA- Online- Scanner NVE- Drucker NVE- Drucker NVE- Drucker Backend Auftragsverwaltung Produktionsauftragsverwaltung Annahme/Importer Auftragsüberwachung ESi-Backend SA-Backend Konvertierung Disposition Auftragsüberwachung T&T-Verwaltung Auftragsverwalter Auftragsabrechnung Disposition Nummerverwaltung Inform.service u. Clearing Auftragsverwalter Stammdatenverwaltung Informationsservice und Clearing Nummernverwaltung Stammdatenverwaltung Auftragsverwaltung Produktion Entgeltsicherung Tracking & Tracing Querschnitt Benutzerverwaltung 20 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

21 Beispiel für T-Architektur Clients nutzen Services zur Kommunikation mit den Applikationen Die publizierten und genutzten Services werden mit Hilfe von Adaptern und Proxies von den Use-Cases entkoppelt Strikte Trennung von fachlichen und technischen Programmteilen Anwendungskern kann wiederverwendet werden (z.b. im Offline-Client) 21 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

22 Beispiel für TI-Architektur PC Web-Browser Java-Applet IDMS Nachbarsysteme z/os USS CICS/TSO http IBM-Webserver Bridge (GWAPI) EXCI Anwendungskern AKS-Shell CICS Nachbarsysteme CICS-DPL CICS/UNIX Nachbarsysteme TCP/IP MQSeries Nachbarsysteme DB2 22 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

23 Entwicklung der Architektur-Sichten im Projekt-Ablauf A-Architektur T-Architektur TI-Architektur Referenzarchitektur A-Architektur grob Anforderungen Teilsysteme Nachbarsysteme Spezifikation Anwendungsfälle Entitätenmodell Dialogspezifikation etc. Schichten Komponenten Klassen/Module Auswahl einer geeigneten Technologie logische Rechner, Netze, Trägersysteme technische Produkte Teilsysteme, Komponenten, Schnittstellen, Klassen/Module Pakete, DLLs, Programmiersprachendateien Pakete, DLLs, Programmiersprachendateien Programmierung von Basiskomponenten (0/T-Software) Zeit Programmierung der Anwendung 23 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

24 Agenda Motivation Architektur-Sichten Software-Kategorien Komponenten & Schnittstellen Regeln für den Komponentenschnitt Spezifikation von Schnittstellen Literatur, Kontrollfragen Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

25 Idee der Softwarekategorien Software, die sich unterschiedlich schnell ändert, wird in unterschiedliche Module aufgeteilt. David Parnas, Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

26 Beispiel Gehaltssoftware IBM AS/400 Fachliche Änderungen Neues Entwicklungspfadeund Entlohnungsmodell technische Änderungen Neue CORBA-Version Neue Beitragssätze zur Sozialvericherung 26 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

27 Softwarekategorien: Trenne Zuständigkeiten Kategorien A-Software T-Software 0-Software AT-Software R-Software C-Software Kombinationen A + 0 = A T + 0 = T A + T = AT Das heißt bestimmt durch die fachliche Anwendung; unabhängig von Technik; Meist der größte Teil des Systems; Beispiel: Mitarbeiter, Buchung unabhängig von der fachlichen Anwendung; wiederverwendbar bei Einsatz derselben technischen Komponente; Beispiel: Zugriffsschicht auf Datenbank unabhängig von Anwendung und Technik; ideal wiederverwendbar; Beispiel: Klassenbibliothek für Strings und Behälter befasst sich mit Technik und Anwendung; schwer zu warten; widersetzt sich Änderungen; Wiederverwendung = 6er im Lotto! reine Transformation; Beispiel: Bildschirmformat in XML Konfiguration: Bringt die verschiedenen Kategorien zusammen (main) Quelle: J. Siedersleben: Moderne Softwarearchitektur 27 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

28 Software-Kategorien als Maß für Softwarequalität Anteil von AT-Software Wiederverwendbarkeit der technischen Komponenten Wartbarkeit Fehlerfreiheit Stabile Komponenten... Der Anteil an AT-Software ist antiproportional zu der Qualität eines Software- Systems! 28 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

29 Agenda Motivation Architektur-Sichten Software-Kategorien Komponenten & & Schnittstellen Regeln für den Komponentenschnitt Spezifikation von Schnittstellen Literatur, Kontrollfragen Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

30 Komponenten-Orientierung am Beispiel Auto Außensicht (Schnittstelle) des Fahrers: möglichst einfach Innensicht: komplex Außensicht (Schnittstelle) der Werkstatt: möglichst einfach 30 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

31 Komponenten-Orientierung in der Software Beispiel: Berechtigungskomponente Außensicht (Nutzungssicht): operative Schnittstelle des Anwendungsprogrammierers (möglichst einfach) operative Schnittstelle B Berechtigungskomponente Berechtigungskern Admin- Schnittstelle A Berechtigung GUI Außensicht (Nutzungssicht): Schnittstelle des Administrators (möglichst einfach) R S RACF- Adapter DB-Zugriff R JDBC RACF Oracle Innensicht: komplex 31 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

32 UML-Notation Schnittstelle ist Stereotyp von Klasse. Enthält nur Operationen, keine Attribute Alternative Darstellung der Schnittstelle als Ball ( Lollypop ) Angebotene Schnittstellen Komponente als Stereotyp von Klasse mit Komponentensymbol cmp Komponenten & Schnittstellen «interface» Interface Interface ProvidedInterface1 ProvidedInterface2 Angeforderte Schnittstelle (Socket- Symbol, neu in UML 2) Class Class Component RequiredInterface 32 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

33 Was ist eine Komponente Definition Komponente: 6 Merkmale Eine Komponente Johannes Siedersleben definiert ihre angebotenen Dienste. Dazu gehört insbesondere die genaue Semantik der Schnittstellen. definiert die Abhängigkeiten von angeforderten Diensten anderer Komponenten. versteckt die Implementierung und kann daher durch eine andere Komponente ersetzt werden, die dieselbe Schnittstelle exportiert. ist geeignet als Einheit der Wiederverwendung. kann andere Komponenten enthalten. ist neben der Schnittstelle die wesentliche Einheit des Entwurfs, der Implementierung und der Planung. Komponente k t1 t2 k exportiert (implementiert) t1 und t2 Austauschbare Implementierung von k K Impl s1 k importiert (benutzt) s1 und s2 s2 33 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

34 Sichten auf eine Komponente Nutzer (Anwendungsentwickler Client oder Nachbarkomponente): operative Außensicht Komponente Entwickler (Anwendungsentwickler Komponente): Innensicht Integrator: Integrationssicht (technische Konfiguration) Administrator: Administrationssicht (fachliche Konfiguration) Betreiber (Rechenzentrum): Außensicht Betrieb 34 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

35 Application components Außensicht (Anwendungsentwickler Client oder Nachbarkomponente) gets reference to OrderingFactory OrderingFactory Ordering Client Komponente: GUI, Nachbar-Komponente, Test-Treiber <<uses>> <<uses>> Ordering interface OrderingFactory { Ordering getorderingusecase(); } interface Ordering { OrderRecord placeorder( String customerid, String articleid); } Außensicht: So einfach und stabil wie möglich 35 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

36 Application components Innensicht (Anwendungsentwickler der Komponente) Innensicht: die Komponente implementieren Ordering OrderManager public interface OrderManager { Order neworder (Customer customer Article article); } OrderingFactory Ordering FactoryImpl Order public interface Order { String getid(); } Ordering OrderingImpl <<creates>> CustomerManager Customer public interface CustomerManager { Customer newcustomer (String name, String address); Customer findcustomerbyid (String id); } public interface Customer { String getname(); } 36 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

37 Application components Integrationssicht OrderingFactory orderingfactory = getorderingfactory(); Ordering orderingusecase = orderingfactory.getorderingusecase(): ClientComponent c = new ClientComponent(orderingUseCase); Entscheidung für eine konkrete Implementierung und Zusammenbringen von Schnittstelle und Implementierung <<creates>> <<creates>> OrderingFactory OrderingFactory Client- Komponente Ordering Komponente SAP Adapter Ordering Ordering 37 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

38 Administrationssicht settaxvalues, configureprices, configurereductions, OrderingFactory Ordering Komponente Administration Ordering 38 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

39 Betriebssicht Komponente hoch- und herunterfahren, Gesundheitszustand abfragen OrderingFactory Ordering Komponente SystemsManagement Systems Management (z.b. Tivoli) Ordering 39 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

40 Rückblick Grundlagen der Programmierung I Schnittstellen (Interfaces) beschreiben Eigenschaften von Komponenten aus Sicht der Benutzer Patient Katze Haustier class Katze implements Patient, Haustier { } Quelle: Roger King 40 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

41 Analogie Mensch Jeder Mensch hat viele Eigenschaften. Aber für bestimmte Personengruppen sind nur bestimmte Eigenschaften wichtig: Verkehrspolizist: Führerschein Arbeitgeber: Lebenslauf, Aufgaben, Einkommen Bibliothek: Leihausweis Familie: jede Menge anderer Eigenschaften Eine Klasse, zum Beispiel Customer, kann viele Eigenschaften haben. Aber für bestimmte Collaborations sind nur bestimmte Eigenschaften wichtig: Kundenverwaltung: fachliche Attribute und Funktionen SortedSet: Comparable Client-Server Kommunikation: Serializable 41 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

42 Definition Schnittstelle und Operation Eine Schnittstelle (Interface) fasst Operationen zusammen. Sie wird spezifiziert durch: (1) Einen eindeutigen Namen, (2) Die Menge der zugehörigen Operationen (3) Ein Schnittstellen-Protokoll im Sinne von Reihenfolgen und Restriktionen beim Aufruf der Operationen. Operationen (Operations) beschreiben das Verhalten von Komponenten. Sie werden spezifiziert durch: (1) Signatur: Name der Operation, Parameter und Rückgabewerte und deren Typen, Ausnahmen (2) Semantik: Verhalten der Operation (3) Nichtfunktionale Eigenschaften: z.b. Performanz, Verfügbarkeit, Kosten etc. 42 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

43 Komponenten und Schnittstellen Verschiedene Sichten / Schnittstellen für unterschiedliche Nutzer Entwickler Admin-Client des Admin-Clients Entwickler Operational interface B Authorization kernel administration interface A Authorization GUI A-GUI Anwendungsprogrammierer (viele) R' S Administrator RACF-Adapter DB Access RACF-Experte R DB-Experte RACF Datenbank 43 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

44 Wer definiert Schnittstellen? Konvention für diese Vorlesung: Verwendung des Socket-Symbols nur für angeforderte Schnittstellen, die von der Komponente selbst definiert und exportiert werden angebotene Schnittstelle Nutzer z.b. Oracle Call Interface S Anbieter Standard-Schnittstelle z.b. JDBC Nutzer S Anbieter Nutzer Call-back SS, z.b. Observer z.b. SAP Adapter angeforderte Schnittstelle S Anbieter angeforderte Schnittstelle angebotene Schnittstelle Nutzer S Adapter S Anbieter 44 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

45 Beispiel: Observer Muster addobserver, deleteobserver, <<uses>> Nutzer (Observer) <<implements>> Observable Anbieter (Observable) Observer Update (call-back) Prinzip Inversion of Control (Umkehr der Abhängigkeit) Der Anbieter (Observable) exportiert sowohl die angebotene als auch das angeforderte Schnittstelle Obwohl Aufrufe in beide Richtungen erfolgen, ist die Abhängigkeit unidirektional und damit zyklenfrei (Observer Observable) 45 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

46 Komponenten und Schnittstellen Angeforderte Schnittstellen: Komponenten entkoppeln Konfiguration t1 k s1 a1 s1 h1 und das h1 t2 s2 a2 s2 h2 Das alles gehört k Komponente k definiert die erwarteten Dienste mit Hilfe von Schnittstellen s1 und s2 Diese Schnittstellen, auch angeforderte Schnittstellen genannt, gehören der importierenden Komponente Die Dienstanbieter-Komponenten h1, h2 exportieren die Schnittstellen s1 bzw. s2, welche i.d.r. nicht identisch zu s1 und s2 sind Adapter a1, a2 bilden die angeforderten Schnittstellen auf die konkreten Schnittstellen von h1, h2 ab. Das Komponenten-Binding erfolgt über die Konfiguration und das h2 46 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

47 Agenda Motivation Architektur-Sichten Software-Kategorien Komponenten & Schnittstellen Regeln Regeln für den für den Komponentenschnitt Spezifikation von Schnittstellen Literatur, Kontrollfragen Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

48 Regel 1: Zusammengehörige Fachlichkeit Komponenten sollen zusammengehörige Fachlichkeit zusammenfassen Kriterien: Geschäftslogik für unterschiedliche (Haupt-)Geschäftsprozesse soll getrennt werden Geschäftslogik für unterschiedliche (Haupt-)Geschäftsobjekte soll getrennt werden, insbesondere sollen Stamm- von Bewegungsdaten getrennt werden ( Partitionierung des Datenmodells) Geschäftslogik, die sich unterschiedlich häufig ändert, soll getrennt werden Beispiele: Hauptbuchhaltung, Nebenbuchhaltung Kundenverwaltung, Auftragsverwaltung Vertrieb, Produktion Gegenbeispiele: Host-Anwendungen, Java-Anwendungen 48 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

49 Regel 2: Kategorienreine Komponenten Komponenten sollen eindeutig einer Software-Kategorie zugeordnet werden können: A-Komponenten: implementieren nur Fachlichkeit T-Komponenten: stellen technische Dienste bereit Möglichst keine AT-Software auf Komponentenebene Beispiele A-Komponenten: Kundenverwaltung Buchhaltung Auftragsverwaltung Beispiele T-Komponenten: Datenbank O/R Mapper Middleware 49 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

50 Regel 3: Datenabstraktion Der Zugriff auf Anwendungsdaten soll ausschließlich über Komponentenschnittstellen erfolgen. Schreibende Zugriffe über create- / modify-methoden Lesende Zugriffe über find-methoden Direktzugriff auf Datenbank nur in Ausnahmefällen (Performance) und nur für lesende Zugriffe erlaubt Auftragsverwaltung Kundenverwaltung Kunden-DB 50 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

51 Regel 4: Enger Zusammenhalt, geringe Kopplung Komponenten sollen so geschnitten sein, dass sie intern einen engen Zusammenhang haben und untereinander gering gekoppelt sind. 51 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

52 Regel 5: Azyklische Abhängigkeiten Komponenten sollen so geschnitten sein, dass sie keine zyklischen Abhängigkeiten haben d.h. Abhängigkeitsgraph = DAG (Directed Acyclic Graph) 52 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

53 Regel 6: Handhabbare Komponentengröße Komponenten sollen eine handhabbare Größe haben Weder 100 Klassen noch 1 Klasse, weder noch 10 Zeilen Code 53 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

54 Zuordnung der Regeln zu Qualitätszielen nach ISO/IEC 9126 R1: zusammengehörige Fachlichkeit R2: kategorienrein R3: Datenabstraktion R4: enger Zusammenhalt, geringe Kopplung Angemessenheit (Funktionalität) Benutzbarkeit Änderbarkeit, Austauschbarkeit R5: zyklenfrei R6: handhabbare Größe 54 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

55 Agenda Motivation Architektur-Sichten Software-Kategorien Komponenten & Schnittstellen Regeln für den Komponentenschnitt Spezifikation von von Schnittstellen Literatur, Kontrollfragen Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

56 Spezifikation von Schnittstellen Schnittstelle Name public interface OrderManager { Schnittstellenname Operationen Signatur Semantik } Rückgabetyp Operationsname Eingabeparameter und -typ Order placeorder (Customer customer, Article article) throws NotAvailableException; Prosa, Vorbedingungen, Nachbedingungen, etc. Ausnahme Nicht-funktionale Eigenschaften Prosa Protokoll Prosa, Sequenzdiagramme etc. 56 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

57 Vorbedingungen und Nachbedingungen Vorbedingungen (pre-conditions) Bedingungen, die vor Ausführung der Operation erfüllt sein müssen, z.b. Eigenschaften der Parameter muss der Nutzer der Operation zusichern der Anbieter darf die Arbeit einstellen, wenn die Vorbedingung verletzt ist (Zusätzliche Prüfung erhöht die Sicherheit: bei Verletzung Abbruch mit Ausnahme) Beispiel: Artikel muss verfügbar sein, wenn er bestellt wird Nachbedingungen (post-conditions) Bedingungen, die nach Ausführung der Operation erfüllt sein müssen, z.b. Eigenschaften des Ergebnisses Muss der Anbieter der Operation zusichern Nutzer der Operation kann davon ausgehen (Zusätzliche Prüfung erhöht die Sicherheit: bei Verletzung Abbruch mit Ausnahme) Beispiel: Nach erfolgreicher Bestellung ist Rechnung erzeugt 57 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

58 Agenda Motivation Architektur-Sichten Software-Kategorien Komponenten & Schnittstellen Regeln für den Komponentenschnitt Spezifikation von Schnittstellen Literatur, Kontrollfragen Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

59 Literatur Johannes Siedersleben: Moderne Softwarearchitektur. dpunkt- Verlag 2004 Johannes Siederlseben (Hrsg.): Quasar: Die sd&m Standardarchitektur (Download von meiner Hompage) Martin Haft, Bernhard Humm, Johannes Siedersleben: The Architect s Dilemma Will Reference Architectures Help? (Download von meiner Hompage) 59 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

60 Kontrollfragen Was sind die wichtigsten Aufgaben der Disziplin Design? Welche Architektursichten unterscheiden wir? Was bedeuten die einzelnen Sichten? Wie werden die einzelnen Sichten im Projektablauf entworfen? Erklären Sie die Software-Kategorien Was sind Komponenten? Nennen Sie Beispiele Welche Sichten auf Komponenten existieren? Nennen Sie wichtige Regeln für den Komponentenschnitt Was sind Schnittstellen? Nennen Sie Beispiele Wie werden Schnittstellen spezifiziert? 60 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012