Wirtschaftsinformatik IV - Informationswirtschaft. Softwarearchitektur Client-Server-Modell SOA

Transkript

1 Wirtschaftsinformatik IV - Informationswirtschaft Softwarearchitektur Client-Server-Modell SOA 18. Mai 2011

2 Einordnung Software Engineering Entwicklung, Betrieb und Wartung von Anwendungen Organisation und Modellierung der zugehörigen Datenstrukturen Softwareentwicklung Planung Analyse Entwurf Implementierung Validierung und Verifizierung Softwareentwurf Architektur Design Modellierung 2

3 Softwareentwicklung (1) Fragen der technischen Gestaltung einer Software des Managements der Entwicklung Gesamtheit von Brainware (Prinzipien, Methoden, Verfahren, Techniken) Toolware (Entwicklungssystem, Werkzeuge, Hilfsmittel) Zielsetzung Produktion fehlerfreier Software Produktion von Software, welche die Anforderungen der Benutzer erfüllt Einhaltung des geplanten Zeitrahmens Einhaltung der geplanten Kosten 3

4 Softwareentwicklung (2) Software-Lebenszyklus Analyse Was soll die Software tun? Entwurf Wie kann sie das am besten? Implementierung Umsetzung in Programmiersprache Wartung Fehlerbeseitigung, Funktionsergänzung/- änderung Inbetriebnahme Installation, Schulung Test Modultest, Integration, Systemtest 4

5 Softwareentwicklung (3) Grundmodell aus den Anfängen der Softwareentwicklung: Code & Fix Nachteile Schreibe ein Programm Finde und behebe die Fehler im Programm Fehlerbehebung strukturiert Programm so um, dass weitere Fehlerbehebungen und die Weiterentwicklung immer teurer werden. Entwurfsphase wird nötig. Selbst gut entworfene Software wird von den Benutzern oft nicht akzeptiert Definitionsphase vor dem Entwurf wird nötig. Fehler sind schwer zu finden, da Tests schlecht vorbereitet und Änderungen unzureichend durchgeführt wurden. Separate Testphase wird nötig. Folge: Entwicklung einer Reihe von besseren Modellen. 5

6 Softwareentwicklung Wasserfallmodell (1) 6

7 Softwareentwicklung Wasserfallmodell (2) Charakteristika Aktivitäten sind in der richtigen Reihenfolge und vollen Breite durchzuführen Am Ende jeder Aktivität steht ein Dokument (dokumentgetriebenes Modell) Entwicklungsablauf ist sequentiell, vorhergehende Aktivität muss beendet werden, bevor die nächste beginnt Orientiert am Top-down-Vorgehen Einfach, verständlich, wenig Managementaufwand Benutzerbeteiligung nur in der Definitionsphase Nachteile Notwendige Kurskorrekturen nicht frühzeitig erkennbar Sequentialität nicht immer nötig Gefahr, dass Dokumente wichtiger als das System werden Risikofaktoren werden u.u. zu wenig berücksichtigt 7

8 Softwareentwicklung V-Modell (1) Erweiterung des Wasserfall-Modells (nur Qualitätssicherung) um Submodelle für Systemerstellung (SE), Qualitätssicherung (QS), Konfigurationsmanagement (KM) und Projektmanagement (PM) 8

9 Softwareentwicklung V-Modell (2) Verifikation und Validation werden Bestandteile des Modells Verifikation: Überprüfung der Übereinstimmung zwischen Software-Produkt und seiner Spezifikation Are we building the product right? Validation: Eignung bzw. Wert eines Produkts bezogen auf seine Einsatzzweck Vorteile Are we building the right product? Integrierte, detaillierte Beschreibung von SE, QS, KM, PM Generisches Vorgehensmodell Gut geeignet für große Projekte Nachteile Unkritische Übernahme der Konzepte, die für eingebettete Systeme entwickelt wurden, für andere Anwendungstypen Software-Bürokratie bei kleinen und mittleren Projekten 9

10 Probleme traditioneller Modelle Auftraggeber / Endbenutzer können oft Anforderungen nicht vollständig / explizit formulieren. Dies ist aber in klassischen Definitionsphasen nötig! Kooperation zwischen Anwendern und Entwicklern endet mit der Definitionsphase: Entwicklungsabteilungen ziehen sich nach Definitionsphase zurück und präsentieren erst nach Fertigstellung das Ergebnis; wünschenswerte Koordination zum Lernen von den jeweils anderen unterbleibt Oft existieren unterschiedliche Lösungswege, die besser experimentell erprobt werden und mit dem Auftraggeber diskutiert werden können Manche Anforderungen lassen sich theoretisch nicht garantieren (z.b. Echtzeitanforderungen). Vor dem Abschluss der Definitionsphase muss also ggf. einiges ausprobiert werden Das Überzeugen des Auftraggebers von der prinzipiellen Durchführbarkeit oder Handhabung einer Idee während der Akquisitionsphase wird nicht unterstützt 10

11 Softwareentwicklung Prototypen-Modell (1) Begriffsbestimmung Software-Prototyp (im Gegensatz zum Begriff in anderen Ingenieursdisziplinen): Ein Software-Prototyp ist nicht das erste Muster einer großen Serie (beliebig kopierbar, Massenfertigung)... ist keine Simulation, sondern zeigt ausgewählte Eigenschaften des Zielprodukts im praktischen Einsatz (vgl. z.b. Windkanal oder Architekturmodell)... dient zum Klären von relevanten Anforderungen oder Entwicklungsproblemen.... dient als Diskussionsbasis für Entscheidungen.... dient zu experimentellen Zwecken und Sammeln von praktischen Erfahrungen. 11

12 Softwareentwicklung Prototypen-Modell (2) Arten von Software-Prototypen: Demonstrationsprototyp: Dient zur Auftragsakquisition; verschafft Eindruck, wie das Produkt aussehen kann. Wichtig: Wird später weggeworfen! Prototyp im engeren Sinne: Wird parallel zur Modellierung des Anwendungsbereiches erstellt, um Aspekte der Benutzungsschnittstelle oder Teile der Funktionalität zu veranschaulichen. Dient zur Analyse. (Exploratives Prototyping) Labormuster: Dient zur Beantwortung konstruktionsbezogener Fragen und Alternativen. (Experimentelles Prototyping) Pilotsystem: Dient nicht nur zur experimentelle Erprobung oder Veranschaulichung, sondern ist schon Kern des Produkts. Unterscheidung zwischen Prototyp und Produkt verschwindet später. Die Weiterentwicklung erfolgt in Zyklen unter Beteiligung der Benutzer. Es ist ein wesentlich sorgfältigerer Entwurf nötig, da der Prototyp später weiterbenutzt wird! Benutzerdokumentation wird ebenfalls nötig. (Evolutionäres Prototyping) 12

13 Softwareentwicklung Prototypen-Modell (3) Vorteile: Reduktion des Entwicklungsrisikos durch frühzeitige/stärkere Rückkopplung. Sinnvoll in andere Prozessmodelle integrierbar. Prototypen sind durch geeignete Werkzeuge schnell erstellbar. (Rapid Prototyping) Nachteile Höherer Entwicklungsaufwand. Gefahr, dass ein Wegwerf -Prototyp nicht weggeworfen wird. Prototypen werden oft als Ersatz für Dokumentation angesehen. 13

14 Architekturbegriff Die innere Struktur eines Softwaresystems mit ihren Komponenten und Beziehungen wird als Architektur bezeichnet. Im Rahmen der Softwareentwicklung repräsentiert die Wahl der Architektur eine der frühesten und zentralsten Entscheidungen (Architekturbeschreibung, Architekturentwurf). Eine einmal eingerichtete Architektur ist später nur mit hohem Aufwand abänderbar. Die Entscheidung über ihr Design ist somit eine der kritischsten und wichtigsten Punkte im Entwicklungsprozess einer Software. Ziel des Architekturentwurfs Vollständige und prägnante Architekturbeschreibung erstellen Geforderte funktionale und nicht-funktionale Anforderungen gewährleisten 14

15 Software Architektur entwerfen Warum? Beim Arbeiten im Kleinen nicht oder nur ansatzweise nötig Größere Software braucht einen systematischen Aufbau Arbeit verteilen, Software-Entwicklung ist Teamarbeit einbetten in vorhandene Software, Schnittstellen und Wechselwirkungen beachten verteilen auf Hardware-Komponenten, geographische Verteilung etwas lokal ändern können, Auswirkungen von Erweiterungen und Ergänzungen abschätzen/begrenzen Aufbau im Großen: Software-Architektur, Konzept Aufbau im Detail: Software-Entwurf (und Programme) 15

16 Definitionen (1) Software Programme, Verfahren, zugehörige Dokumentation und Daten, die mit dem Betrieb eines Rechnersystems zu tun haben. Software-Entwurf (software design) Der Prozess des Definierens von Architektur, Komponenten, Schnittstellen und anderen Charakteristika eines Software- Systems oder einer Software-Komponente. Software-Architektur (software architecture) Die Organisationsstruktur eines Software-Systems oder einer Software-Komponente. Architekturentwurf (Grobentwurf, architectural design) Der Prozess des Definierens einer Software-Architektur. 16

17 Definitionen (2) Detailentwurf (Feinentwurf, detailed design) Der Prozess der Festlegung der algorithmischen und datenstrukturmäßigen Details einer Software-Architektur (oder eines Teils davon. Implementierung (implementation) Der Prozess des Realisierens einer Software-Lösung. Umfasst in der Regel Detailentwurf, Codierung, Integration und Prüfung. 17

18 Entwurfsprinzipien Systematischer Aufbau: Die Grundlage eines guten Entwurfs Strukturen (Module, Prozesse, Kommunikation...): Gliederung in Komponenten und Interaktion zwischen Komponenten Abstraktionen (Komposition, Benutzung, Generalisierung, Aspekte) Systematische Vergröberung und Verfeinerung nach verschiedenen Kriterien Verständnis großer Zusammenhänge unter Weglassung der Details Verständnis eines Details unter Weglassung/starker Vergröberung des Rests Systematischer Zusammenhang zwischen Übersichten und Detailsichten 18

19 Modularisierung (divide et impera) Gliederung der Gesamtlösung in kleinere, überschaubare Teillösungen Nicht irgendwie gliedern, sondern: Modul = in sich geschlossene Einheit Verwendung erfordert keine Kenntnisse über inneren Aufbau Kommunikation mit Umgebung ausschließlich über Schnittstelle Rückwirkungsfreie Änderbarkeit im Modulinnern Korrektheit ohne Kenntnis der Einbettung prüfbar zwingend bei Entwurf großer Systeme 19

20 Architekturbeschreibung dient dabei als (1) Kommunikations- und Diskussionplattform Abstrakte Beschreibung des Systems Beherrschbarkeit der Komplexität Zuordnen, Priorisieren und Reflektieren von funktionalen und nicht-funktionalen Anforderungen Abgleich mit den Anforderungen an Systemarchitektur und Hardware Erarbeiten, Evaluieren und Bewerten von alternativen Lösungsansätzen 20

21 Architekturbeschreibung dient dabei als (2) Design- und Implementierungsplan Festlegung der Komponenten des Systems sowie deren Schnittstellen und Interaktionsmuster Integration von neuen Technologien und innovativen Lösungsansätzen Erarbeitung, Einführung und Überprüfung von Programmierrichtlinien Erstellung von Prototypen und exemplarischen Teillösungen Wiederverwendung von existierenden (Teil-)Implementierungen Rahmen für die Projektorganisation und -planung 21

22 Architekturmodellierung 22

23 Architekturmodell Modelle sind vereinfachte Abbildungen der Realität, die es erlauben Aussagen im Modell so darzustellen, dass sie von allen Beteiligten gleich interpretiert werden. Architekturmodell besteht aus: Menge von elementaren Bausteinen (z.b. Subsysteme, Module oder Komponenten) Export- und Import-Schnittstellen der Bausteine Komposition der Bausteine zu einer geeigneten Softwarearchitektur Ein Architekturmodell soll präzise und vollständig sein: Interaktion und Kommunikation Verbindungen und Strukturen Zustandsraum und Datenstrukturen Trotzdem innere Struktur der Bausteine verbergen! 23

24 Erfolgsfaktoren des Architekturentwurfs in minimalen Schnittstellen und Komponenten denken Syntax und Verhalten von Schnittstellen und Komponenten beschreiben Komposition der Komponenten zu einer Architektur getrennt beschreiben Modularität Lose Kopplung Abhängigkeiten sichtbar machen zuerst fachliche Sicht, dann technische Sicht 24

25 Strukturierung von Softwaresystemen Ansatz zur Strukturierung ist Zerlegung in Schichten Vergleich: ISO/OSI-Modell als Designgrundlage von Kommunikationsprotokollen in Rechnernetzen Bei Softwaresystem Zerlegung in Systemkomponenten Präsentation (Benutzerinteraktion) Verarbeitung (Anwendungslogik) Datenhaltung (Verwaltung, Speicherung) 25

26 Übung Übung 26

27 Monolithische Systeme fehlende Untergliederung eines Softwaresystems in Teilsysteme führt zu monolithischem System wird als untrennbare Einheit gestaltet ( großes Ganzes ) keine explizite Gliederung in Teilsysteme (Komponenten im weitesten Sinne) steht damit im Gegensatz zu einem verteilten System Host-Rechner (i.d.r. Mainframe) zentral: Datenhaltung, Verarbeitungslogik, Bildschirmmasken Anbindung von Terminals zur Benutzerinteraktion textbasierte Oberfläche Kommunikation über Transaktionen Steuerung der Transaktionen über sog. TP-Monitore (Transaction Processing Monitor) proprietäres Dateisystem geschlossenes System 27

28 Verteilte Systeme wird durch Subsysteme gebildet, die auf mehrere Rechner verteilt sind kooperieren und kommunizieren koordiniert miteinander physischen Dezentralisierung einzelner Schichten möglich Beispiele Client/Server-System Multi-Prozessor-System Grid-Computing Service-orientierte Architektur (SOA) 28

29 Schichtenbasierte Verteilungsformen klassische dreistufige Client-Server-Architektur verteilt die drei grundsätzlichen Funktionen auf dedizierte Systeme, die mehrfach ausgeprägt sein können Beispielsweise umfassen Softwaresysteme im praktischen Einsatz je Benutzer entsprechende Frontends (Präsentation), einen oder mehrere Applikationsserver (Verarbeitung) sowie einen oder mehrere Datenbankserver (Datenhaltung) 29

30 Web-basierte Softwaresysteme (1) 30

31 Web-basierte Softwaresysteme (2) Mehrschichtige Client-Server-Architektur Web-Client realisiert nur die Präsentationsschicht Zugriff über einen Web-Browser, der die Verbindung zum Web- Server herstellt keine Anwendungsinstallation keine permanente Verbindung zum Web-Server Web-Server verteilt HTML-Dokumente, Multimediaobjekte oder Java-Applets auf der Basis des HTTP-Protokolls stellt die Kommunikation mit dem Applikationsserver her Applikations- oder Anwendungsserver Bereitstellung der Funktionalität Datenbankserver Bereitstellung und Speicherung der Daten in der Datenbank 31

32 Web-basierte Softwaresysteme (3) Ablauf Über den Browser des Clients wird ein URL-Request für Webanwendungen (z.b. *.php oder *.aspx) an den Webserver (z.b. Apache, IIS) geschickt. Der Webserver hostet den Applikationsserver und gibt die Anforderung an diesen weiter. Dieser fragt die Datenbank ab. Das Datenbanksystem gibt die angeforderten Daten zurück. Der Applikationsserver stellt die Daten für die Antwort zusammen und liefert diese an den Webserver. Der Webserver sendet die Daten an den Client in Form einer HTML-Seite. 32

33 Präsentationsschicht Über die graphische Benutzeroberfläche (Graphical User Interface, GUI) erfolgt die Mensch-Maschine-Interaktion. Merkmale Strukturierung der Oberfläche Steuerung eines Anwendungssystems Darstellung von Daten und Graphiken Eingabe von Daten Auslösen von Ereignissen und Funktionen Aufbau mit standardisierten Bedienelemente Funktionsbereiche: Menüleiste, Symbolleiste, Statusleiste, Taskleiste, Bildlaufleisten Spezielle Funktionen wie Kontextmenü, Drag-and-Drop Personalisierung 33

34 ThinClient vs. FatClient Bei verteilten Systemen existieren für die Darstellung der Inhalte zwei Alternativen: Man setzt auf den Webbrowser als ThinClient und stellt die Inhalte und Formulare in XHTML, XML, JavaScript und anderen, für das WWW geschaffenen Sprachen dar, nutzt also eine klassische Webanwendung. Man produziert eine eigene grafische Benutzeroberfläche als FatClient. Dieser nutzt die erweiterten Darstellungsmöglichkeiten der dafür verwendeten Programmiersprache bzw. Grafikbibliothek wie Flash, Java Swing oder XAML. 34

35 Grundsätze der Dialoggestaltung (1) Aufgabenangemessenheit Ein Dialog ist aufgabenangemessen, wenn er den Benutzer unterstützt, seine Arbeitsaufgabe effektiv und effizient zu erledigen. Selbstbeschreibungsfähigkeit Ein Dialog ist selbstbeschreibungsfähig, wenn jeder einzelne Dialogschritt durch Rückmeldung des Dialogsystems unmittelbar verständlich ist oder dem Benutzer auf Anfrage erklärt wird. Erwartungskonformität Ein Dialog ist erwartungskonform, wenn er konsistent ist und den Merkmalen des Benutzers entspricht, z.b. den Kenntnissen aus dem Arbeitsgebiet, der Ausbildung und der Erfahrung des Benutzers sowie den allgemein anerkannten Konventionen. 35

36 Grundsätze der Dialoggestaltung (2) Fehlertoleranz Ein Dialog ist fehlertolerant, wenn das beabsichtigte Arbeitsergebnis trotz erkennbar fehlerhafter Eingaben entweder mit keinem oder mit minimalem Korrekturaufwand durch den Benutzer erreicht werden kann. Steuerbarkeit Ein Dialog ist steuerbar, wenn der Benutzer in der Lage ist, den Dialogablauf zu starten sowie seine Richtung und Geschwindigkeit zu beeinflussen, bis das Ziel erreicht ist. Individualisierbarkeit Ein Dialog ist individualisierbar, wenn das Dialogsystem Anpassungen an die Erfordernisse der Arbeitsaufgabe, individuelle Vorlieben des Benutzers und Benutzerfähigkeiten zulässt. Lernförderlichkeit Ein Dialog ist lernförderlich, wenn er den Benutzer beim Erlernen des Dialogsystems unterstützt und anleitet. 36

37 User Interface Guidelines (Styleguides) Richtlinien zur Gestaltung graphischer Oberflächen Aufgaben Konsistentes Look and Feel (Layout, Farben, Fenster, Ikonen, ) einheitliche Interaktionsabläufe (Menü, Dialogboxen, ) Nutzung von radio buttons, check boxes, drop-down-lists, sliders, Tooltips, Wizard Reaktion Sprache Barrierefreiheit 37

38 Verarbeitungsschicht Die Verarbeitungsschicht realisiert das eigentliche Geschäftsmodell, indem die am Geschäftsmodell beteiligten Geschäftsobjekte und Geschäftsprozesse implementiert werden. Merkmale konkrete Implementierung Fachwissen Transaktionsmanagement 38

39 Datenschicht Aufgabe der Datenschicht ist es, große Datenmengen effizient, widerspruchsfrei und dauerhaft zu speichern und benötigte Teilmengen in unterschiedlichen, bedarfsgerechten Darstellungsformen für Benutzer und Anwendungsprogramme bereitzustellen. Merkmale Die Datenschicht wird durch ein Datenbank-Management-System (DBMS) und eine Datenbank (DB) realisiert. Ein Softwaresystem fordert über eine standardisierte Schnittstelle, z.b. ODBC, mittels einer Abfragesprache, z.b. SQL, Daten vom DBMS an oder übergibt Daten zur Speicherung oder Änderung. Hersteller von Softwaresystemen bieten i.d.r. kein eigenes Datenbanksystem an, unterstützen aber Systeme anderer Hersteller (IBM, Informix, Microsoft SQL Server, Oracle) 39

40 Integration Abteilungsübergreifende, durchgängige Unterstützung der Geschäftsprozesse auf der Basis einer zentralen Datenbank Bereiche, auf die sich die Integration bezieht innerhalb des Systems (Modulintegration) Integration von Anwendungssystemen Integration von Altsystemen (legacy system) zwischenbetriebliche Integration Gegenstand der Integration Datenintegration Funktionsintegration Prozess-/Vorgangsintegration Methodenintegration Programmintegration 40

41 Übung Übung 41