Architekturprinzipien betrieblicher Informationssysteme

Transkript

1 Architekturprinzipien betrieblicher Informationssysteme 1

2 Studium der Wirtschaftsinformatik an der HFU Furtwangen und der Southeastern Louisiana University : bei sd&m als Software-Ingenieur Chefarchitekt Schwerpunkt: Öffentlicher Bereich (Government) Seit 2012 bei der der msg systems ag IT Consultant Branchenschwerpunkt: Telecommunications & Media Aktuell bei der Lufthansa Cargo als Business Analyst und Solution Architekt tätig Zuvor tätig als Architekt und Technischer Projektleiter bei der Finanzinformatik Privates geboren in Furtwangen Reisefan 2

3 AGENDA 1. Motivation Software-Architektur 2. Komponenten und Schnittstellen Bausteine der Architektur 3. Architekturprinzipien 4. Finden von guten Architekturen 5. Quasar-Softwarekategorien 6. Quasar-Architektursichten 7. Literatur 3

4 Beispiele aus der Bauarchitektur Ziel: Verteidigen Quelle: musoft.org 4

5 Beispiele aus der Bauarchitektur Ziel: Mobilität Quelle: musoft.org 5

6 Beispiele aus der Bauarchitektur Sicht: Grundriss Quelle: musoft.org 6

7 Beispiele aus der Bauarchitektur Sicht: Elektriker Quelle: musoft.org 7

8 Bauarchitektur - Zusammenfassung Architektur realisiert bestimmte Ziele durch eine Anordnung der ihr zur Verfügung stehenden Prinzipien Architektur hilft bei der Arbeitsteilung Wenige Architekten entwerfen den Architekturplan Architekturplan ist generisch und kann in vielen Situationen wieder verwendet werden Viele Bauzeichner detaillieren Architekturplan. Sie bringen konkrete Anforderungen der Kunden ein. Noch mehr Bauarbeiter erstellen das Gebäude Architektur hat verschiedene Sichten physikalische Sichten (Grundriss, Aufriss) logische Sichten (Netzwerkplan, Abwasserplan, Statik) Detaillierungsgrad Ein solches Vorgehen ist sinnlos bei einem Vogelhaus. Hammer, Nägel, Bretter und auf geht s. 8

9 Warum Software-Architektur? Typisches Projekt zur Entwicklung eines betrieblichen Informationssystems ca. 15 Entwickler starten gleichzeitig mit der Implementierung Entwickler haben unterschiedliche Erfahrungen Projekt muss trotzdem ein Erfolg werden Wie? 1-2 Architekten entwerfen die Architektur Architektur berücksichtigt die (nichtfunktionalen) Ziele der Anwendung Architektur wird unter Einhaltung grundlegender Prinzipien bestimmt Architektur gibt den Rahmen für die Entwicklung vor 3-4 Spezifikateure entwerfen Detailpläne Detailpläne berücksichtigen die funktionalen Anforderungen des Kunden Gemeinsamkeiten Bauarchitektur Softwarearchitektur: 1) Architektur verfolgt ein Ziel/Zweck. 2) Bewährte Architekturprinzipien zur Erreichung des Ziels einsetzen. 9

10 Definition Software-Architektur The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them. [From the book Software Architecture in Practice (2nd edition), Bass, Clements, Kazman; Addison-Wesley 2003] The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. [IEEE: IEEE Std for Recommended Practice for Architectural Description of Software-Intensive Systems: IEEE Computer Society, 2000] Weitere Definitionen (ca. 123 kb! Text) Wesentliche Bestandteile der Definitionen sind: Software-Architektur beschreibt die Struktur des Systems. Struktur wird mit Komponenten und ihren Beziehungen beschrieben. Komponenten haben sichtbare Eigenschaften. Software-Architektur berücksichtigt Architekturprinzipien. 10

11 Eigenschaften betrieblicher Informationssysteme Eigenschaften betrieblicher Informationssysteme Ziele der Architektur zur Berücksichtigung der Eigenschaften groß und komplex lange Lebensdauer Ständiger Wandel Beherrschbare Teilstrukturen finden Entwicklung mit mehreren Teams Entwicklung in Stufen Hohe Verständlichkeit System muss änderbar sein Wartbarkeit Wiedererkennbare Lösungen Einheitliche, konsistente Lösungen Regeln, Konventionen Betreibbarkeit beim Kunden Infrastruktur berücksichtigen Austausch/Upgrade von Teilsystemen möglich (Middleware, Hardware, Datenbank) Quelle: sd&m AG 11 msg systems ag, Oktober

13 Komponenten Verschiedene Definitionen A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties. [Clemens Szyperski: Component Software: Beyond Object-Oriented Programming, 2002] A software component is a coherent package of software implementations that a) has explicit and well-specified interfaces for services it provides; b) has explicit and well-specified interfaces for services it expects; and c) can be composed with other components, perhaps customizing some of their properties, without modifying the components themselves [D'Souza, Wills: Objects, Components, and Frameworks with UML] The component is a modular unit with well defined interfaces that is replaceable within its environment.... It has one or more provided and required interfaces, and its internals are hidden and inaccessible other than as provided by its interfaces. [OMG, UML 2.0, 13

14 Merkmale einer Komponente (Siedersleben, Quasar) 1. Sie exportiert eine oder mehrere Schnittstellen (Export-Schnittstellen) Die Semantik der Schnittstellen ist definiert (Szyperski, D'Souza, UML) 2. Sie importiert andere Schnittstellen (Import-Schnittstellen, D'Souza, UML). Der Import einer Schnittstelle bedeutet, dass die Komponente die Operationen dieser Schnittstelle benutzt. Sie ist erst lauffähig, wenn alle importierten Schnittstellen zur Verfügung stehen, und dies ist Aufgabe der Konfiguration. 3. Sie versteckt die Implementierung und kann daher durch eine andere Komponente ersetzt werden, die dieselbe Schnittstelle exportiert. (UML) 4. Sie eignet sich als Einheit der Wiederverwendung, denn sie kennt nicht die Umgebung, in der sie läuft, sondern macht darüber nur minimale Annahmen. (Szyperski) 5. Komponenten können andere Komponenten enthalten oder anders ausgedrückt. Neue Komponenten können aus vorhandenen über beliebig viele Stufen zusammengesetzt werden. (Szyperski, UML) 6. Die Komponente ist neben der Schnittstelle die wesentliche Einheit des Entwurfs, der Implementierung und damit der Planung. 14

15 Schnittstellen Arten von Schnittstellen: Benutzerschnittstellen Über Benutzerschnittstellen werden Informationen zwischen Anwender und Komponente ausgetaucht. Programmierschnittstellen (Schnittstellen) Verbinden Komponenten untereinander. Eine Schnittstelle (Interface) fasst Operationen zusammen. Eine Schnittstelle besteht aus 1. einen eindeutigen Namen, 2. einer Menge von Operationen 3. Einem Protokoll im Sinne von Reihenfolgen und Restriktionen beim Aufruf. Operationen beschreiben das Verhalten von Komponenten. Sie werden spezifiziert durch: 1. Signatur, Syntax: Name der Operation, Parameter und Rückgabewerte und deren Typen, Ausnahmen 2. Semantik: Verhalten der Operation 3. Nichtfunktionale Eigenschaften: z.b. Performance, Verfügbarkeit, Kosten etc. 15

16 Darstellung von Komponenten und Schnittstellen Komponente Import- Schnittstelle Export- Schnittstelle Verknüpfung über Schnittstelle Schnittstelle detaillierte Sicht Verknüpfung ohne Beschreibung der Schnittstelle 16

17 Schnittstellen definieren Sichten auf eine Komponente Administrator RACF- Experte Anwendungsprogrammierer Datenbankexperte Quelle: sd&m AG 17

19 Qualitätsmerkmale der Architektur Einfachheit Einzelne Elemente der Architektur sollen möglichst einfach sein Das Zusammenspiel der Elemente der Architektur soll einfach sein Klarheit / Verständlichkeit Es soll leicht erkennbar sein, welche Aufgaben einzelne Elemente haben und wie diese miteinander funktionieren Wirtschaftlichkeit Wartbarkeit + Erweiterbarkeit Betreibbarkeit 19

20 Grundlegende Architekturprinzipien Abstraktion Grundlegendes Prinzip, um Informationen auf aktuell wesentliche Informationen zu reduzieren. Modularisierung Gliederung nach Zusammengehörigkeit (High-Cohesion/Low-Coupling) Kapselung Implizite und schwer erkennbare Abhängigkeiten reduzieren Hierarchische Dekomposition Gliederung in Ebenen Seperation of Concerns Gliederung nach Eigenschaften und Aspekten Einheitlichkeit Strukturen, Schemata, Muster, Vorgehensweisen durchgehend beibehalten 20 Prinzipien helfen die Komplexität zu beherrschen Prinzipien sind aus erfolgreichen Strategien für Problemlösungen für komplexe Aufgaben entstanden Prinzipien verdichten Informationen und reduzieren ihre Menge Prinzipien müssen alle gleichzeitig Andy berücksichtigt Scherzinger werden

21 Architekturprinzipien sind Leitlinien für die Gestaltung einer Anwendung, um die Qualitätsmerkmale zu erreichen TOP 5 P1 Trennung von Zuständigkeiten P2 Minimierung von Abhängigkeiten P3 Geheimnisprinzip P4 Homogenität P5 Redundanzfreiheit Weitere wichtige Prinzipien P6 Schichtenbildung P7 Vertragsbasierter Entwurf P8 Datenhoheit Leider gilt bezüglich der Architekturprinzipien: Erst durch die sinnvolle und angemessene Verwendung aller Architekturprinzipien entsteht eine gute Architektur die Verwendung nur eines Prinzips (oder weniger Prinzipien) führt in der Regel zu keiner guten Architektur. 21

22 Architekturprinzipien (1/3) Trennung von Zuständigkeiten Jeder Teil einer Software sollte möglichst nur für eine Aufgabe zuständig sein. Aufgaben muss möglichst genau definiert und klar gegenüber anderen abgegrenzt werden. Minimierung von Abhängigkeiten Minimiere die Abhängigkeiten zwischen den Software-Teilen (z.b. durch Zusammenfassen von Teilen oder durch Entkoppelung). Vermeide zyklische Abhängigkeiten. Geheimnisprinzip Kapsele internes Wissen eines Software-Teiles Nutzer eines Software-Teiles müssen nur das kennen Notwendige kennen Definiere eine spezielle Sicht für die von ihnen verwendete Funktionalität des Software-Teiles. 22

23 Architekturprinzipien (2/3) Homogenität Vergleichbare Problemstellungen ähnlich lösen Bei Lösung gleiche Größen und Einheiten verwenden. Redundanzfreiheit Für gleiche technische oder fachliche Funktionalität in verschiedenen Teilen der Architektur trenne diese Funktionalität heraus, verallgemeinere sie und stelle sie wieder verwendbar zur Verfügung. 23

24 Architekturprinzipien (3/3) Schichtenbildung Unterteile die Software in Schichten. Eine Schicht bündelt Software mit ähnlichem Aufbau bzw. ähnlicher Grundfunktionalität. Eine Schicht darf nur Software innerhalb ihrer eigenen Schicht oder einer darunter liegenden Schicht aufrufen. Vertragsbasierter Entwurf Beschreibe das System vollständig über eine Menge von Schnittstellen. Eine Schnittstelle beschreit Syntax und Semantik. Schnittstelle ist ein Vertrag zwischen Anbieter und Verwender und beschreibt alles, was der Verwender wissen muss um die Funktionalität des Anbieters zu nutzen. Schnittstellen sollten spezifisch wenn nötig und so generell wie möglich beschrieben werden. Eine Schnittstelle ist dann gut, wenn die Implementierung austauschbar wäre. Datenhoheit Dynamisch: Stelle sicher, dass die Verantwortlichkeit über einen Ausschnitt des Datenhaushaltes nur bei einem Teil der Software liegt, der ebenfalls für die Integrität und die Konsistenz dieser Daten sorgt. Statisch: In diesem Teil der Software wird ebenfalls die Struktur / Modellierung dieser fachlichen Daten festgelegt. 24

25 Hoher Zusammenhalt, geringe Kopplung (strong cohesion, loose coupling) Hoher Zusammenhalt (Cohesion) (innerhalb einer Komponente) inhaltlich zusammengehörende Elemente in einer Komponente/Modul/Subsystem klar definierter, präziser Zuständigkeitsbereich Geringe Kopplung (Coupling) (zwischen Komponenten) direkte Kopplung = Abhängigkeit inhaltlich unabhängige Einheiten möglichst stark entkoppelt je weniger Abhängigkeit desto besser (z. B. durch schmale Schnittstellen, wenige Imports, ) 25

26 Kombinieren der Architekturprinzipien ergibt Architektur GENIE Agenten Plattform: Quelle: musoft.org 26

27 Wie findet man jetzt eine gute Architektur? Und wie macht man aus Anforderungen eine Software-Architektur, welche die grundlegenden Architekturprinzipien berücksichtigt? 28

29 Arbeitmittelvorrat des Architekten Man muss nicht immer alles neu erfinden Arbeitsmittelvorrat des Architekturen besteht aus Guidelines, Architekturstilen und Referenzarchitekturen Guidelines Empfehlungen, Erfahrungen und etablierte Methoden Sind oftmals nicht hart festgelegt oder formal definiert Architekturstile Prinzipielle Lösungsstrukturen, die für ein Element einer Architektur durchgängig und mit weitgehendem Verzicht auf Ausnahmen angewandt werden. Können auf allen Verfeinerungsebenen einer Architektur angewandt werden Architekturstile können kombiniert werden Standard-Architekturen Architekturstile auf einer hohen Abstraktionsebene Vorgaben für die Architektur eines ganzen Systems Kapitel Quasar 30

30 Zurück zur Bauarchitektur - Architekturstile Nach Süden gerichteter Außenraum (Pattern 105) aus: Christopher Alexander: A Language of Patterns Ein Freiraum wird nur dann genutzt, wenn er sonnig ist. Ordne ein Gebäude in jedem Fall nördlich des ihm zugehörigen Freiraums an und richte den Freiraum nach Süden aus. Zwischen Haus und sonnigem Außenraum sollte sich nie ein breites, trennendes Schattenbad befinden. Quelle: sd&m AG 31

31 Zurück zur Bauarchitektur - Architekturstile Teilziel 1: Schwächung des Angreifers Aufwärts kämpfen lassen Keine Deckung ermöglichen Stärken verdecken Teilziel 2: Verteidigung vereinfachen Angreifer kontrolliert führen Angreifer von mehreren Stellen beschießen können Bewährte Konstruktionsregeln: Burg auf Berg bauen Versetzte Tore Mauern mit auskragenden Türmen Mehrere konzentrische Bastionen Innere Bastionen überblicken Äußere 32

32 Software-Architekturstile Einige Beispiele Schichtenarchitektur Model View Controller (MVC) Pipes & Filters Regelbasiertes System Blackboard Architektur Service Orientierte Architektur Event driven Reflection Interpreter 33

33 Beispiel Architekturstil: Schichtenarchitektur Schichten sind übereinander angeordnet Elemente einer Schicht besitzen einen ähnlichen Abstraktionsgrad Eine Schicht bietet nach oben Services an (fungiert als Server) Präsentationsschicht Logikschicht Businessregeln Oberfläche (GUI) Dialogkontrolle Interpreter Eine Schicht benutzt nur die Services der darunterliegenden Schicht (fungiert als Client). Ein Durchgreifen auf tiefere Schichten zerstört die Architektur! Vorteil: Änderungen in einer Schicht können maximal eine andere Schicht betreffen Datenhaltungsschicht Produktdaten Kundendaten 34

34 Betriebssystem Hardware Architekturstile können kombiniert werden Präsentationsschicht Oberfläche (GUI) Dialogkontrolle Logikschicht Businessregeln Interpreter Datenhaltungsschicht Produktdaten Kundendaten 35

36 Idee der Software-Kategorien Grundlegendes Idee: "Software, die sich unterschiedlich schnell ändert, wird in unterschiedliche Module aufgeteilt. [Parnas, 1972] Software-Kategorien sind Vorstufen zu Komponenten Richtige Komponenten zu finden ist schwer Software-Kategorien ergeben sich meist einfach Software-Kategorien trennen Zuständigkeiten Software-Kategorien sind Wegweiser für gute Software- Architektur 37

37 Beispiel Gehaltssoftware Fachliche Änderungen Technische Änderungen Art der Änderung Neues Entwicklungspfadeund Entlohnungsmodell Neue Beitragssätze zur Sozialversicherung Bedeutung der Änderung: Komponenten können nicht wiederverwendet werden Komponenten sind unternehmensspezifisch Art der Änderung Neue Corba-Version Neue Java-Version Neue Datenbank Bedeutung der Änderung: Wiederverwendung in anderen Unternehmen möglich Einheitliche Lösung Quelle: sd&m AG 38 Anwendung und Technik möglichst weit voneinander trennen

38 Software-Kategorien trennen Zuständigkeiten Software-Kategorien 0-Software A-Software Unabhängig von Anwendung und Technik; Ideal wiederverwendbar; Beispiel: Klassenbibliothek für Strings und Behälter Bestimmt durch die fachliche Anwendung; Unabhängig von Technik; Meist der größte Teil des Systems; Beispiel: "Mitarbeiter", "Buchung" AT benutzt A R T-Software R-Software Unabhängig von der fachlichen Anwendung; Experte für eine technischen Komponente dafür wiederverwendbar Beispiel: Zugriffsschicht auf Datenbank Reine Transformation (Repräsentation); erträgliche Mischung von A und T Beispiel: Bildschirmdarstellung in XML umsetzen T 0 AT-Software Befasst sich vermischt mit Technik und Anwendung; Grundsätzlich zu vermeiden: schwer zu warten; widersetzt sich Änderungen; Wiederverwendung nahezu ausgeschlossen! 39

39 Anwendung der Softwarekategorien Die Wiederverwendbarkeit der Gruppen nimmt von 0 nach AT hin ab. Technisch orientierte Komponenten sind leichter wiederzuverwenden Anwendungsspezifische schwerer. Problemfall AT-Kategorie: gilt es zu vermeiden Der Aufruf von A-Komponenten aus T-Komponenten heraus ist gefährlich Die azyklische Benutzt-Beziehung von A nach T wird zerstört Es entsteht AT-Software Blutgruppen-Kalkül: A+0 = A T+0 = T A + T = AT AT benutzt A T 0 R Gesetze von Siedersleben: Jede Schnittstelle, Klasse, und Komponente gehört zu genau einer Software-Kategorie Mischen von A und T führt immer zu schlecht wiederverwendbarer Software 40

40 Der Komponentenschnitt soll die Zuständigkeiten definieren und die Abhängigkeiten minimieren Zusammenfassung Komponentenschnitt Ziele Trennung technischer Dienste Leitlinien Trennung von Fachlichkeit (A) und Technik (T) Anwendungskern (A-Software) ist technikunabhängig T-Abhängigkeiten kapseln Eindeutige Verantwortlichkeiten/ Zuständigkeiten Parallele Entwicklung Mehr als eine Zuständigkeit ist schlecht Vermeide verteilte Zuständigkeiten Dokumentiere Zuständigkeiten (Was ist das Geheimnis der Komponente?) Komponenten gehören zu genau einer Softwarekategorie Schneide Komponenten so, dass sie getrennt entwickelt werden können Minimiere die Schnittstellen zwischen den Komponenten Abschottung Nachbarsysteme Kapsle Nachbarsysteme Möglichst keine enge Kopplung 41

42 Quasar-Software-Kategorien liefern eine A/T-Trennung auf Architekturebene Technische Infrastruktur (TI-Architektur) Technische Architektur (T-Architektur) Anwendungsarchitektur (A-Architektur) Beschreibt die physischen Geräte (Rechner, Netzleitung,..) System-Software (BS, DBMS, App-Server,..) Zusammenspiel der Hardware mit darauf installierter System- Software verwendeten Programmiersprachen beschreibt die "virtuelle Maschine", auf der die mit der A-Architektur entworfene Software läuft (Container für A- Komponenten) verbindet A- und TI- Architektur besteht aus T- Komponenten frei von technischen, produkt-bezogenen 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 besteht aus A- Komponenten Architektursichten reduzieren Komplexität durch Beschränkung auf spezifische Aspekte (vgl. auch Architekturprinzipien) Quelle: sd&m AG 43

43 TI-Architektur - Beispiel PC Web-Browser Java-Applet AKS-Shell IDMS Nachbarsysteme http z/os USS IBM-Webserver CICS-DPL CICS Nachbarsysteme Bridge (GWAPI) CICS/TSO EXCI Anwendungskern TCP/IP CICS/UNIX Nachbarsysteme DB2 MQSeries Nachbarsysteme Quelle: sd&m AG 44

44 :Tomcat Appserv er :Tomcat Appserv er TI-Architektur - Beispiel PresentationApp PresentationApp deployment TI-Architektur «http» «http» :Firewall Informations- und Dienstezone :Loadbalancer «http» :Firewall Logik- und Verarbeitungszone «http» :Loadbalancer «http» «http» «http» «http» :Blade Serv er :Blade Serv er :Blade Serv er :Blade Serv er «executionenvironment» :Tomcat Appserv er «executionenvironment» :Tomcat Appserv er «executionenvironment» :Tomcat Appserv er «executionenvironment» :Tomcat Appserv er PresentationApp PresentationApp LogicApp LogicApp «http» :Firewall «http» «JDBC» «JDBC» :Firewall Logik- und Verarbeitungszone «http» :Loadbalancer «JDBC» Datenzone :Oracle RAC «http» :Blade Serv er «http» :Blade Serv er Oracle «executionenvironment» :Tomcat Appserv er «executionenvironment» :Tomcat Appserv er 45 LogicApp LogicApp

45 T-Architektur - Beispiel Präsentation In-Servlet forward Out-JSP Eingabe/Ergebnis Dialog Dialog-Controller Verwaltet und wertet aus Liest Beans aus und stellt sie in den Request ein usebean ruft Präsentationsmodell Kommunikator PM-Ergebnis Java-Bean <<Bean>> Java-Bean Value objects Anwendungskern Anwendungsfall Quelle: sd&m AG 46

46 Standard-T-Architektur für betriebliche Informationssysteme (Siedersleben) für Nachbarsysteme angebotene Schnittstellen Batch Dialog Betriebliches Informationssystem Nachbarsystem A Nachbarsystem B Adapter A Adapter B Anwendungskern Autorisierung Regelinterpreter A T 0 R AT Persistenz Datenbank 47

47 A-Architektur - Beispiel Bestandsführung Ausleihe Kundenverwaltung Titelkatalog Gebühren Quelle: sd&m AG 48

49 Literatur Johannes Siedersleben: Moderne Softwarearchitektur. dpunkt.verlag, 2004, Len Bass, Paul Clements, Rick Kazman: Software Architecture in Practice. Boston: Addison-Wesley, Second Edition, Paul Clements, Felix Bachmann, Len Bass, David Garlan, James Ivers, Reed Little, Paulo Merson, Robert L. Nord: Documenting Software Architectures; Addison- Wesley; Ralf Reussner, Wilhelm Hasselbring: Handbuch der Software-Architektur. dpunkt.verlag, Clemens Szyperski: Component Software: Beyond Object-Oriented Programming. Addison-Wesley Longman, Desmond D'Souza, Alan Cameron Wills: Objects, Components, and Frameworks with UML. Addison-Wesley Longman,

50 Vielen Dank für Ihre Aufmerksamkeit msg systems ag Robert-Bürkle-Straße Ismaning/München Telefon: Fax: info@msg-systems.com 51