Service-Orientierte Architekturen

Transkript

1 Hochschule Bonn-Rhein-Sieg Service-Orientierte Architekturen Kapitel 1: Einführung Vorlesung im Masterstudiengang Informatik Sommersemester 2010 Prof. Dr. Sascha Alda

2 Vorstellung Prof. Dr. Sascha Alda Professor für Software-Architektur an der Hochschule Bonn-Rhein-Sieg Raum: C 218, Campus Sankt Augustin Telefon: sascha.alda@h-brs.de Web: Sprechstunde (allgemein): Nach Vereinbarung Offene Sprechstunde (Lehre): Do., ab Uhr Folie 2

3 Ziele der Vorlesung Kennenlernen und Bewertung von grundlegenden Entwurfsprinzipien für Service-Orientierte Architekturen Vermittlung von State-Of-The-Art Technologien zur Entwicklung von Service- Orientierten Architekturen Anwendung der erlernten Entwurfsprinzipien und Technologien anhand einer komplexen Aufgabenstellung ( Purchase-To-Pay Prozess) Vertiefung von Soft Skills im Bereich Team-Building, Team-Work sowie Präsentation von Projektergebnissen Folie 3

4 (Vorläufiger) Aufbau der Vorlesung Kapitel Thema 1 Organisation, Einführung in Software-Architekturen 2 Einführung in Service-Orientierte Architekturen 3 Design Prinzipien von Service-Orientierten Architekturen 4 Web Services I (SOAP, WSDL) 5 Web Services II (UDDI, WS-Policies, Axis2) 6 Modellierung von Geschäftsprozessen (BPEL, BPMN) 7 Vertiefung Web Services (BAM, BPEL4People,...) 8 OSGi Service Plattform 9 Einführung in Swordfish 10 REST Architekturen 11 (22.6.) Exception Handling in SOA (Gastvortrag) 12 (29.6.) SOA Point of View von Accenture (Gastvortrag) Folie 4

5 Organisation der Übungen Termin der Übungen: Dienstag, 10:00 11:30 (C 118) Für jede Übung müssen die einzelnen Teams Übungsaufgaben abgeben: Ausgabe der Übungsaufgaben: Mittwoch, ab 12 Uhr unter: Abgabe der Übungsaufgaben: den darauffolgenden Mittwoch, 12 Uhr (per oder Postkasten) Voraussetzungen für den Erwerb der ECTS-Punkte: Aktive Mitarbeit in der Vorlesung und in den Übungen von allen Studierenden erwartet (Vorstellung Lösungen zu Übungen) Mindestens 50% der Punkte aus den Übungsaufgaben müssen durch die Teams erreicht werden Jedes Team hat ein Verkaufsgespräch erfolgreich zu absolvieren (ab Juni 2010) Jeder Student hat eine mündliche Prüfung nach der Vorlesung zu bestehen (erster oder zweiter Prüfungszeitraum) Folie 5

6 Software-Projekt Jedes Team muss ein Software-Projekt während der Gesamtlaufzeit der Vorlesung bearbeiten: Entwicklung und Beschreibung einer Gesamt-Architektur Fokus auf ein selektiertes Thema Entwicklung eines Prototyps basierend auf den Technologien der Vorlesung (bis Kapitel 8) Für später eingeführte Technologien wird u.u. eine Neubewertung erfolgen ( Übungen) Status muss jede Woche abgegeben werden können Vorstellung der Anforderungen an das Software-Projekt erfolgt in der Übung am 6. April Folie 6

7 Verkaufsgespräche Jedes Team muss ein Verkaufsgespräch erfolgreich absolvieren. Inhalt: Darstellung von Zwischenständen oder Endständen des Projekts Was sind Probleme und Risiken? Das Ziel: Überzeugung des Kunden, dass Ihr Projekt für die nächste Phase verlängert wird oder final abgenommen wird 45 Minuten pro Team Beteiligte Rollen im Verkaufsgespräch: Software-Entwicklungsteam (Ihr Team) Kunde (Prof. Dr. Sascha Alda) Beirat des Kunden (restliches Auditorium) Zusätzlicher externer Experte (N.N.) Folie 7

8 Literatur Nicolai Josuttis: SOA in der Praxis System-Design für verteilte Geschäftsprozesse. Dpunkt.verlag, Heuser, O., und Holubek, A.: Java Web Services in der Praxis: Realisierung einer SOA mit WSIT, Metro und Policies. dpunkt Verlag Hess, A.; Humm, B.; Voß, M.: Regeln für serviceorientierte Architekturen hoher Qualität, in: Informatik Spektrum Juni Springer Verlag (Artikel in Zeitschrift) Melzer, Ingo: Service-Orientierte Architekturen mit Web Services. 2 Auflage. Elsevier Verlag, Frotscher, T. et al.: Java Web Services mit Apache Axis2. entwickler.press Brass, L. et al.: Software Architecture in Practice. Second Edition Taylor, R. et al.: Software Architecture Foundations, Theory, and Practice. Addison-Wesley, 2009 Bruegge, B.; Dutoit, A.H.: Object-Oriented Software Engineering. 2 Auflage, Prentice-Hall, Folie 8

9 SOA BuzzWords Wie findet man Ordnung in dem BuzzWord-Chaos? Wann werden Architekturen eigentlich definiert? Hergestellt mit: Folie 9

10 Gliederung dieser Veranstaltung Kapitel 1: Einführung in Software-Architekturen 0 Organisation, kurze Motivation 1 Software-Architekturen im Kontext des Software-Lifecycle 2 Definition und Eigenschaften einer Software-Architektur 3 Dokumentation einer Software-Architektur 4 Zusammenfassung und Ausblick Folie 10

11 Software-Entwicklungsmodelle Das Software Engineering stellt ausgeprägte Software-Entwicklungsmodelle (Software-Lifecycle, Lebenszyklus) zur Verfügung. Generisches Schema: Business Development Business Case, Project Statement Iterationen... Software-Lifecycle Anforderungs- Entwicklung System-Design Objekt-Design / Implementation Testing & Deployment Use Cases, Geschäfts- & Anwendungsanforderungen, Geschäftsprozesse, Geschäftsobjekte, Testfälle Daten-Anforderungen Software-Architektur: Subsysteme, Verbindungen, Constraints Objekt-Design einzelner Subsyteme, Source and Binary Code Final abgenommenes und integriertes System New Business, Ramp-down... Application Management (AM) Folie 11

12 Aufgabe des System Design Die Aufgabe der Phase System Design ist die Entwicklung einer Software- Architektur basierend auf den ermittelten Anforderungen des Ziel-Systems die Einteilung (Dekomposition) des Ziel-Systems in einzelne, kohärente Subsysteme (Module, Komponenten, Services, Objekte, Funktionsbausteine,..) Die Identifikation der Beziehungen zwischen den Subsystemen Geschäftsprozesse System Data Geschäftsobjekte Domänen-Objekte Use Cases GUI Software-Architektur Use Cases Folie 12

13 Abbildung von Anforderungen auf eine Architektur Keine etablierte Methodik vorhanden, kaum in der Literatur beschrieben Abbildung basiert zu meist auf Heuristiken und Erfahrungswerten ( siehe auch Übungsblatt Nr. 1) Viele Applikationsszenarien implizieren die Verwendung von etablierten Typen von Architekturen, sog. Architekturstilen (in Kürze mehr dazu...) Folie 13

15 Definition Software-Architektur (aus Standardliteratur) The software architecture of a program or computing system is the structure or structures of the system, which comprises: software elements the externally visible properties of those elements, and the relationships among them [Bass et al., 2003] Software architectures are concerned with... structural issues including: Gross organization global control structure protocols for communication Synchronization, data access, assignment of functionality to design elements physical distribution composition of design elements scaling and performance [Garlan and Shaw, 1993] Folie 15

16 Software-Architekturstile Eine Software-Architektur beschreibt die Dekomposition eines einzelnen Systems. Notwendig: eine Menge von Richtlinien und Vorgaben für einzelne Typen oder Stile von Architekturen Definition Software Architectural Style: An architectural style encapsulates important decisions about architectural elements and emphasizes important constraints on the elements and their relationships. [Perry und Wolf, 1992] Architekturstile geben Vorgaben für eine Familie von Software-Architekturen Konkrete Realisierung einer Architektur z.b. für ein Projekt = Instanz eines Architekturstils Bekannte Stile: Client-Server, Peer-to-Peer, 3-Tier, SOA, REST, Pipes-and-Filters Folie 16

17 Definition Software-Architektur Eine Software-Architektur beschreibt die Dekomposition eines Software- Systems, die den Vorgaben eines zugehörigen Architekturstils genügt. Die Architektur-Beschreibung umfasst folgende Bestandteile: die grundlegenden Architektur-Elemente die Interaktionsbeziehungen zwischen den Architektur-Elementen die strukturellen und operativen Architektur-Direktive der Gesamtarchitektur die charakterisierenden Kennzahlen der Gesamtarchitektur Folie 17

18 Erläuterung des Begriffs Software Architektur Architektur-Elemente - Defintionen Die Architektur-Elemente einer Architektur bestehen im Wesentlichen aus Subsystemen sowie Modulen, Interfaces und InterfaceObjekt. Definitionen (nach [Sommerville, 2006]): Ein Subsystem kapselt seine Funktionalität und / oder Daten und regelt den Zugriff auf diese über explizit definierte Interfaces (Schnittstellen). Subsysteme sind aus einzelnen Modulen zusammengestellt. Subsysteme sind abgeschlossene Systeme, sie sind nicht von Interfaces anderer Subsysteme abhängig ( realistisch?) Ein Module ist ein atomarer Bestandteil eines Subsystems, das über ein Interface mit anderen, internen Modulen interagieren kann. Ein Modul kann wiederum aus anderen Modulen zusammengestellt sein. Ein Interface repräsentiert die Menge an Operationen und Daten, mit der ein externes Subsystem oder ein Module mit einem Subsystem / mit einem Module interagieren. Das Interface kann durch ein InterfaceObjekt implementiert werden. Folie 18

19 Erläuterung des Begriffs Software Architektur Architektur-Elemente Meta-Modell Die Architektur-Elemente einer Architektur bestehen im Wesentlichen aus Subsystemen sowie Modulen, Interfaces und Interface-Objekten. Meta-Modell eines Architekturstil: Subsystem System Design 1 0..n Module System Design 1 0..n 0..n Interface System Design isimplementedby Interface-Objekt System Design Ein Metamodell ist ein Modell, das beschreibt, wie Modelle gebaut werden. Hier: ein Architekturstil! Folie 19

20 Erläuterung des Begriffs Software Architektur Architektur-Elemente Meta-Modell Das Interface eines Subsystems besteht aus mehren Operationen (Methoden) und zugehörigen Eingabe- (Input) und Rückgabe-Werten (Output). Meta-Modell: Interface System Design 1 0..n Operationen System Design 0..n Eingabe-Werte System Design 0..n Rückgabe-Werte System Design Weitere Eigenschaften System Design z.b. Ausnahmen Folie 20

21 Erläuterung des Begriffs Software Architektur Architektur-Elemente Meta-Modell Die Architektur-Elemente einer Architektur lassen sich auf bestehende Programmiersprache-Konzepte (meist) direkt anwenden. Beispiel Java: Zugriffsberechtigung (access level) Rückgabe-Wert Name der Operation (method) Eingabe-Wert Mögliche Ausnahme (exception) public Address getaddressbyname ( String Name ) throws BadInput { // Some Sample Code } return address; Folie 21

22 Erläuterung des Begriffs Software Architektur Architektur-Elemente Meta-Modell Die Architektur-Elemente einer Architektur lassen sich auf bestehende Programmiersprache-Konzepte (meist) direkt anwenden. Beispiel Java: Package (= Subsystem) package edu.soa.kap1.myprettyaddresssubsystem; public class AddressModule { } public Address getaddressbyname ( String Name ) throws BadInput { // Some Sample Code return address; } protected boolean checkname( String Name ){ return true; } class submodule { // Some Sample Code } Class (= Modul) Public Interface des Subsystems Privates Interface des Subsystems, außerhalb nicht sichtbar! Internal Class (= Sub-Modul), außerhalb nicht sichtbar! Folie 22

23 Erläuterung des Begriffs Software Architektur Architektur-Elemente - Komponenten Software Komponenten sind Spezialfälle von Subsystemen, die folgende zusätzlichen Eigenschaften besitzen (nach [Szyperski, 2002]): Explizite Beschreibung der extern benötigten Interfaces oder Services Einbindung von kontextabhängigen Ressourcen (z.b. Files) Ausweisung zusätzlich benötigter Ressourcen oder Bedingungen (z.b. spezielle Hardware oder Programmiersprache, Treiber usw.) Ein Komponentenmodell gibt Vorgaben für die Implementierung von Komponenten sowie für die Laufzeitumgebung. Bekannte Komponentenmodelle: OSGi Bundles ( nächste Folie) Java Beans Enteprise Java Beans (EJB) Spring CORBA Component Model Vorlesung Komponenten-Architekturen WS 10/11 Folie 23

24 Beispiel eines Komponentenmodells: OSGi package edu.soa.kap1.mypackage; import org.osgi.framework.bundleactivator; import org.osgi.framework.bundlecontext; import edu.soa.kap1.extern.translationservice; import edu.soa.kap1.extern.translationservicefactory; public class Activator extends BundleActivator { public void start( BundleContext context ) throws Exception { } TranslationService service = TranslationFactory.getTranslationService(); // Eingabe eines Strings, der zu übersetzen ist String istring= getstring(); // Aufruf des Service und Übergabe des Input-String String tstring= translatorservice.gettranslation ( istring ); System.out.println( "Text: " tstring); public void stop ( BundleContext context ) throws Exception { } private String getstring(){ // Holt via UserInput einen String } Manifest-Version: 1.0 Bundle-Name: Hello World Import-Package: org.osgi.framework, edu.soa.kap1.extern Manifest-File der Komponente Text Editor Falls Package nicht installiert in der Laufzeitumgebung, kann Komponente (Bundle) nicht gestartet werden Hot Deployment (Nachladen) von Bundles über Tools (z.b. Console) möglich (über Netzwerk) } Source-Code der Komponente Text Editor Folie 24

25 Beispiel eines Komponentenmodells: JavaBean package edu.soa.kap1.mypackage; import java.beans.*; public class AddressBean { String address = null; Eigenschaft der Bean (definiert Zustand) Zugriff mittels setter und getter Methode private PropertyChangeSupport changes = new PropertyChangeSupport( this ); public String getaddress() { return address; } public void setaddress(string address) { String oldaddress = address; this.address = address; changes.firepropertychange( "name", oldaddress, address ); } public void addpropertychangelistener( PropertyChangeListener l ) { changes.addpropertychangelistener( l ); } } Bei Zustandsänderung: Information über Ereignis an Eingeschriebene Empfänger (z.b. andere Beans) Weitere Eigenschaften: Selbstbeobachtung (Inspection) Auslesen einer Bean von außen (z.b. GUI-Editor) Anpassung (Customization) Anpassung der Eigenschaften (visuell durch User) Speicherung (Persistenz) Speichern und Wiederherstellung des Zustands Packaging und Export mit Ressourcen und Libraries als JAR (ggf. mit ANT) Folie 25

26 Erläuterung des Begriffs Software Architektur Interaktionsbeziehungen - Formen Die Interaktionsbeziehungen zwischen den Architektur-Elementen werden durch Konnektoren (Connectors) realisiert. Lokale Formen von Konnektoren (z.b. innerhalb einer Java Virtual Machine) Einfache lokale Methodenaufrufe (point-to-point zwischen zwei Objekten) Shared Data Zugriff Event-basierte Interaktionen (z.b. Publish-Subscribe Pattern) Verteilte Konnektoren (z.b. Remote Procedure Calls, RMI, CORBA, SOAP) Zugriff auf entfernte Interfaces über APIs, welche den notwendigen Netzwerkzugriff kapseln (siehe nächste Folie) Adapter Konnektoren (z.b. Middleware, Enterprise Service Bus (ESB)) Ermöglicht die Interoperabilität zwischen heterogenen Subsystemen Synchronisation von Interaktionen Weitere Aspekte: Transaktionsverarbeitung, Idempotenz, Replication, Steigerung der Effektivität (keine P2P-Verbindungen) Mehr dazu später in der Vorlesung Folie 26

27 Erläuterung des Begriffs Software Architektur Interaktionsbeziehungen Verteilte Konnektoren Typischer Aufbau eines verteilten Konnektors: Provider (Java) <<Interface>> Client (C++) Skeletons Stub Unmarshaling arguments Remote Reference Layer (RMI), Object Request Broker (CORBA) Marshaling arguments Verwendung von Interface Definition Languages (IDL) zur Definition von Interface in einem programmiersprachen-unabhängigen Format Compiler transformiert IDL Beschreibung zu konkreten Modulen (Java, C++) und erzeugt Stubs und Skeletons Folie 27

28 Erläuterung des Begriffs Software Architektur Architektur-Direktive Architektur-Direktive beeinflussen (zur Entwicklungszeit) den strukturellen Aufbau und (zur Laufzeit) die operative Funktionalität einer Software- Architektur Architektur-Direktive sind zusätzliche Eigenschaften, Richtlinien, Einschränkungen (constraints) oder Implikationen an einer Architektur, die sich nicht unmittelbar aus der Dekomposition ergeben. Vorgabe oft durch Anforderungsanalyse ( nicht-funktionale Eigenschaften) oder Architekturstil Strukturelle Direktive implizieren operative Direktive Beispiel: Wahl einer Client-Server Architektur mit Thin-Client: Strukturell: Client beinhaltet nur User-Interface (UI) Module, Verarbeitungslogik wird auf Server realisiert. Funktionell: Eingeschränkte Interaktionsbeziehungen, Server darf auf Client nicht zugreifen; Gefahr von Bottle-Necks, Performance- und Skalierbarkeitsprobleme auf dem Server. Folie 28

29 Erläuterung des Begriffs Software Architektur Architektur-Direktive - Ausprägung 1. Nicht-Funktionale Definition Eigenschaften Trade-Offs 2. Hardware/Software Mapping Special Purpose Buy or Build Trade-Off Allocation Connectivity Architektur- Direktive 3. Data Management Persistent Objects Files Databases Data Structures 6. Boundary Conditions Initialization Termination Failure 5. Software Control Monolithic Event-Driven Threads Conc. Processes 4. Global Resource Handling Access Control Security Nach [Brügge and Dutoit, 2002] Folie 29

30 Erläuterung des Begriffs Software Architektur Charakterisierende Kennzahlen Charakterisierende Kennzahlen einer Architektur definieren messbare Werte zur Bewertung von Architektur-Elemente und Interaktionsbeziehungen an. Aus dieser Kollektion von verschiedenen Werten können übergreifende (akkumulierte Werte) der Gesamtarchitektur abgeleitet werden: Wie performant ist eine Software-Architektur zur Laufzeit? Kann eine Software-Architektur effektiv implementiert werden? Ausprägungen: Service-Level Agreement (SLA) Key Performance Indicators (KPI) Risiko-Parameter Abhängigkeitsparameter Behandlung später in der Vorlesung... Folie 30

32 Dokumentation einer Software-Architektur Modellbasierte Modellierung einer Software-Architektur Basierend auf graph-basierten Modellierungselementen Semi-formal (Semantik oft unpräzise) Dienen zur Kommunikation zwischen Entwicklern und Kunden Aktueller Industrie-Standard: Unified Modeling Language UML 2.0 Architekturbeschreibungssprachen (ADL) Textuelle Spezifikation von Architekturen (insbesondere der Interaktionsbeziehungen Formal (Semantik klar formalisiert) Weniger zur Kommunikation, dient der direkten Umsetzung Meist nur akademische Ansätze (z.b. Darwin, C2, PeerCAT) Textuelle Architektur-Templates Freisprachliche Beschreibung der Architekturelemente und weiteren Eigenschaften Wenige Standards vorhanden Oft unterstützt durch graphische Modellierungssprache Folie 32

33 Dokumentation von Architekturen mit UML Komponentendiagramme Das Komponentendiagramm betrachtet Komponenten, wie sie zur Laufzeit organisiert sind. Beispiel: Architektur eines Systems zur Verwaltung von Studierenden einer Vorlesung (Auszug): <<component>> Teilnehmerverwaltung Wahlfreier Zugriff Benötigte Schnittstelle <<component>> Listengenerator Kompositionskonnektor Delegationskonnektor Komponente Angebotene Schnittstelle Wahlfreier Zugriff Abhängigkeitsbeziehung <<class>> XML-Encoder <<manifest>> <<component>> DBMS Port <<artifact>> <<component>> DataAccess <<component>> XML-Interface MyAPP.jar <<class>> XML-Decoder <<specifiction>> ComponentSpec <<component>> Hardware Access Folie 33

34 Dokumentation von Architekturen mit UML Komponentendiagramme Eine Komponente mit einem Interface-Objekt wird oft mit Hilfe des Facade Pattern [Gamma, 1996] realisiert: Compile-Interface <<component>> Compiler Compile-Interface <<interfaceobject>> Compiler <<component>> Lexer <<component>> CodeGenerator <<component>> Parser <<component>> Optimizer <<interfaceobject>> Compiler Provided Interface ( Compile-Interface ): public Code compilecode( Code ); Required Interface ( CodeGenerator ): Required Interface ( Parser )... Folie 34

35 Dokumentation von Architekturen mit UML Verteilungsdiagramme Das Verteilungsdiagramm betrachtet die Hardware-Topologie sowie die Verteilung der Software des Systems auf die Hardware <<device>> : MyServer <<component>> LDAP Server <<deploy>> <<artifact>> Oracle.exe Komponente Kommunikationspfad HTTP / SOAP 1.1 Artefakt Hardware-Gerät Installiertes Programm (textuelle Spezifikation) <<device>> : ApplicationServer <<execution environment>> : J2EE Server LDAP-Client (Programm) <<deploy>> <<artifact>> Ausführungsumgebung Deployment-Beziehung Deployment-Spezifikation MyAPP.jar <<deployment spec>> Beschreibung.xml Folie 35

36 Dokumentation von Architekturen mit UML Weitere Diagramme Die Modellierung von Architektur-Elementen sowie Interaktionsbeziehungen kann in UML durch weitere Modelle erfolgen: Statische Modelle (z.b. Klassendiagramme) Controller System Design updates Modell System Design Modell System Design 1 n View System Design Usage-Beziehung im Klassendiagramm Assoziationsbeziehung im Klassendiagramm Dynamische Modelle (z.b. Interaktionsdiagramm) :Controller :Modell Message Return Folie 36

37 Das Architektursichten ( Views ) Modell End user Logical view Scenarios Development view Programmers & software managers Process View Physical View Integrator System Engineer Quelle: Kruchten, P.: The 4+1 View Model of Architecture, in: IEEE Software, Vol. 12, Nr Folie 37

38 Das Architektursichten ( Views ) Modell Logical View (Benutzersicht) Beschreibung der objekt-orientierten Struktur des Systems Geeignet für die Modellierung der Endnutzer-Interaktion (z.b. GUI-Komponenten, Interaktionen zwischen Benutzer und System) Basis auch für Abnahmetests Typische UML-Diagramme: Klassendigramm, Sequenzdiagramm Development view (Entwicklungssicht) Modellierung der einzelnen Komponenten des Systems, passend für die jeweilig gewählte Entwicklungsumgebung UML: Komponentendiagramm, Paketdiagramm Process view (Prozesssicht) beschäftig sich mit den dynamischen Aspekten des System. Er verdeutlicht die Prozesse des Systems und wie diese kommunizieren mit Fokus auf dem Laufzeitverhalten. Modellierung von Parallelität, Verteilung, Performanz und Skalierbarkeit UML: Aktivitätsdiagramm Alternativen: BPMN, EPKs Folie 38

39 Das Architektursichten ( Views ) Modell Physical view: Veranschaulichung der Verteilung der Softwarekomponenten auf physikalischer Ebene (also der Zuordnung dieser zu Hardware-Teilen) und der Kommunikation zwischen diesen Komponenten. UML: Verteilungsdiagramm Scenarios: Modellierung von wichtigen Anwendungsfällen oder Anwendungsszenarien. Verdeutlichung von Abläufen zwischen Komponenten bzw. Prozessen Identifikation weiterer Architekturelemente zu identifizieren Basis für spätere Test Cases im Rahmen des Integrationstest UML: Use Case Diagramme Textuelle Szenariobeschreibung Folie 39

40 Templates (Frameworks) für die Beschreibung von Architekturen Zachmann Einbettung einer Architektur in das gesamte Unternehmen (Abläufe, Organisation etc.) Sehr umfangreiches Framework mit 30 verschiedenen Sichten Weit verbreitet in den USA (Großunternehmen) Quelle: TOGAF Fokus auf die Modellierung von großen Unternehmensarchitekturen (Enterprise Architecture) Ebenfalls sehr umfangreich Quelle: Arc42 Leichtgewichtiges Framework zur Beschreibung der wesentlichen Sichten auf eine Architektur (gemäß 4+1 Modell) Berücksichtigung von nicht-funktionalen Eigenschaften und weiteren übergreifenden Angaben (z.b. Risiko) Quelle: Folie 40

42 Zusammenfassung und Ausblick Die Software-Architektur eines Software-Systems wird in der Phase des System-Designs auf Basis der vorher erfassten Anforderungen erstellt Software-Architekturen orientieren sich an (etablierte) Software- Architekturstile, welche Rahmenbedingungen an eine Software-Architektur definieren Service-Orientierung ist ein Architekturstil Folie 42