Softwarearchitektur - ein kurzer Überblick

Transkript

1 - ein kurzer Überblick Maik G. Seewald

2 Ein kurzer Überblick Agenda 1. Begriffsdefinition 2. Stellenwert in Unternehmen und Projekten 3. Rolle der 4. Notation und Darstellung 5. Architekturdefinition und Konzepte 6. Die 3-Schichten-Architektur als Beispiel 7. Zusammenfassung 2

3 1. Ziel der Präsentation und Begriffsdefinition Ziel: Ein kurzer Überblick zur Thematik (SWA), einem kritischen Erfolgsfaktor für Softwareprojekte Herausforderung: Umfassende, sich ständig weiter entwickelnde Thematik Keine allgemeingültige Definition existent Viele Definitionen aus unterschiedlichen Quellen (UML, IEEE, ) The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the external properties of those components, and the relationship among them. [Bass, Clements, Kazman 1998] UML 1.3: Architecture is the organizational structure of a system. An architecture can be recursively decomposed into parts that interact through interfaces, relationships that connect parts, and constraints for assembling parts. Parts that interact through interfaces include classes, components and subsystems. 3 Die ist das Bindeglied zwischen den Anforderungen der Fachdomäne und der technischen Realisierung eines Systems. Aus dem Anforderungsmanagement heraus kann eine abgeleitet und erarbeitet werden. Hierbei wird die Struktur des Softwaresystems definiert und erste technologische Entscheidungen getroffen.

4 2. Stellenwert in Unternehmen und Projekten 1. Motivation - Organisatorische Vorteile: SWA bündelt unternehmensweites Know-How (Modelle, Dokumentationen, etc.) SWA ermöglicht Wiederverwertbarkeit, Reduziert Kosten für Weiterentwicklung und Wartung (ROI) SWA dokumentiert Systeme und erzeugt Transparenz SWA ist Grundlage für die Definition von Arbeitspaketen und unterstützt damit die Projektplanung 2. Motivation - Technische Vorteile: 3. Externe Einflüsse: Beherrschbarkeit von Komplexität SWA ist Basis für Wiederverwertbarkeit, Flexibilität und Erweiterbarkeit Projektbeteiligte (Alle Stakeholder) Unternehmensstrategie, Bestehende Projekte, Standards und Frameworks Maximierung des Kundennutzens Organisatorische Faktoren (Budget, Zeitrahmen) Bestehendes Know-How, Lernkurve 4

5 3. Rolle der Die hat Schnittstellen zu folgenden Prozessen innerhalb von Softwareprojekten: Anforderungsmanagement, Design, Implementierung, Projektplanung, Qualitätssicherung und Hardwarearchitektur. Schlüsselschnittstelle zur Anforderungsanalyse: Fachliche und technische Anforderungen als Resultat der Anforderungsanalyse Berücksichtigung funktionaler und nicht-funktionaler Anforderungen (Qualität, FURPS) Rückkopplung hinsichtlich Machbarkeit und Kosten Allgemeines Vorgehen: Kommunikation und Abstimmung mit oben genannten Stakeholdern SWA ist ein zentrales Bestandteil des Entwicklungsprozesses mit z.t. fest definierten Rollen und Artefakten (RUP, Agile Dev./XP, V-Modell) Typische Schritte innerhalb eines iterativen, inkrementellen Vorgehens der Architekturerstellung: Machbarkeitsstudie, Risikoanalyse, Priorisierung der Anforderungen, Architekturkonzept, Architekturbewertung Grundlagen: Modelle, Heuristiken, Muster (Pattern, Idiome, Best Practices ) 5

6 4. Notation und Darstellung Motivation: Notationsform, mit höherem Abstraktionsgrad als Sourcecode um effektive Kommunikationsstrukturen im Team zu gewährleisten (Artefakte: Graphische Darstellungen, Dokumente) Allgemeine Sichtweisen: Structural View Logisch [detailliert] Konzeptionell [abstrakt] Software System Behavioral View Konzeptionell [abstrakt] Logisch [detailliert] UML als standardisierte Notationsform für Software mit dem Ziel der Bereitstellung von unterschiedlichen Sichten auf das System (Anforderungen, Systemkontext, Systemdesign, Infrastruktur, Verteilung, Informationsfluss, ) UML beschreibt statische und dynamische Elemente mit Hilfe von Klassen, Komponenten, Pakete, Aktionen, Interaktionen, Use Cases und Statischen Diagrammen (Klassen-, Komponenten-, Verteilungs-, Strukturdiagramme,...) zur Beschreibung der Struktur Dynamischen Diagrammen (Aktivitäts-, Sequenz-, Kommunikations-, Use-Case-Diagrammen, ) zur Beschreibung des Verhaltens 6

7 5. Architekturdefinition und Konzepte Kriterien und Dimensionen: Datenorientierte o. Ereignisorientierte Systeme Art der Anwendung (Embedded, Hostbasiert, C/S, Verteilt, ) Technische Rahmenbedingungen (OS, Hardware, Datenhaltung, Infrastruktur, Netzwerk, Security, Transaktionssicherheit, MMI, ) Grundlagen der Entscheidungen: Designmuster u. Architekturstile (Pattern, Best Practices ) z.b.: Layered Application, Façade Pattern, Strukturierung durch Separation of Concerns ), Deployment Patterns Generierungstechniken (MDA), Wiederverwendbarkeit Andere Einflüsse (siehe Folie 2: Know How, Standards) Resultate: Entwurf und Unterteilung in Schichten, Komponenten 7 Deployment; Aufteilung des Systems auf logische/physische Plattformen (C/S- Architektur, Fat-, Thin-Client) Technologieentscheidungen (OS, Tools, RAD, Programmiersprachen, Komponentenmodelle, Application Server, Plattformen [J2EE,.NET]) Make or Buy Entscheidung, 3 rd -Party Software Teamstruktur (Distributed Development)

8 6. Die 3-Schichten-Architektur als Beispiel Three Layered Application Presentation Layer Presentation Components Domain Layer Beispiel: 3 Schichten Architektur einer typischen webbasierten Anwendung (Darstellung in UML) Schichten werden genutzt um die Applikation zu organisieren und die Komponenten anzuordnen Vorteile: Business Logic Components Data Access Layer Data Access Components Skalierbarkeit Verteilbarkeit Wiederverwertbarkeit der Business Logik Robustheit Wartbarkeit Andere Verteilung möglich, siehe Folie 12 8

9 7. Zusammenfassung 1. Die wird durch fachliche und technische Rahmenbedingungen sowie durch politische und organisatorische Einflüsse auf das Projekt bestimmt. 2. Die Entscheidungsfindung hin zur ist ein inkrementeller, iterativer Prozess und basiert auf einer ständigen Rückkopplung mit allen Stakeholdern mit dem Ziel einer Kompromissfindung. 3. Die ist aufgrund der immer größer werdenden Komplexität ein kritischer Erfolgsfaktor in Softwareprojekten. 4. Die Verwendung von Solution Patterns / Best Practices hat sich im Prozess der Definition der als eine effektive Herangehensweise etabliert (siehe Folie 15). 9

10 Backup 01: Die Rolle des Softwarearchitekten RUP: Ein SW Architekt ist die treibende Kraft bei der Systemerstellung. Die wesentliche Aufgabe ist es, eine Folge von suboptimalen Entscheidungen bei unvollständigem Wissen zu treffen. Architekturverantwortung ist Vollzeitbeschäftigung. Der SW Architekt sollte eine starke Persönlichkeit mit breiter technischer Erfahrung und ausgeprägten Soft-Skills wie Abstraktionsvermögen, Entscheidungs-, Durchsetzungs-, Team- und Überzeugungsfähigkeit sein. 10

11 Backup 02: Web Based Computing Layering Architektur web-basierter, mehrschichtiger Anwendungssysteme [konzeptionell / High-Level-Layering] Präsentationsschicht Anwendungsschicht Darstellungslogik Anwendungsschicht Geschäftslogik Persistenzschicht Client-Tier Middle-Tier Middle-Tier Backend Tier Browser (PC, Mobile Client) Skripte Applets ActiveX PlugIns Internet Intranet Webserver HTML / XML ASP,ASP.NET JSP, Servlets CGI PHP CGI Applicationserver EJB DCOM, COM+ MTS.NET Transactions- Processing Monitor (ACID) Database Filesystem 11

12 Backup 03: Java Design Patterns Pattern Name Business Delegate Composite Entity Composite View Data Access Object Fast Lane Reader Front Controller Intercepting Filter Model-View-Controller Service Locator Session Facade Transfer Object Value List Handler View Helper Description Reduce coupling between Web and Enterprise JavaBeans TM tiers Model a network of related business entities Separately manage layout and content of multiple composed views Abstract and encapsulate data access mechanisms Improve read performance of tabular data Centralize application request processing Pre- and post-process application requests Decouple data representation, application behaviour, and presentation Simplify client access to enterprise business services Coordinate operations between multiple business objects in a workflow Transfer business data between tiers Efficiently iterate a virtual list Simplify access to model state and data access logic 12 Anmerkung: Hierbei handelt es sich um Design Pattern, nicht um ein Architektur Pattern (also somit um einen anderen Abstraktionsgrad). Quelle: Sun Microsystems

13 Backup 04: MVC Pattern Model Update data Java / J2EE MS.NET Change get data View M Database Entity Bean Database ADO.NET Controller Change V Servlet JSP ASP.NET C Stateless Session Bean Stateful Session Bean COM, COM+ Event Anmerkung: Hierbei handelt es sich um ein Design Pattern, nicht um ein Architektur Pattern (also somit um einen anderen Abstraktionsgrad). 13

14 Backup 05: Literatur und Links Microsoft: Pattern and Practices /.NET oriented: Java / J2EE Patterns: Excellente Bücher von J. Bloch, E.Gamma, Buschmann und anderen Each Pattern then depends both on the smaller patterns it contains, and on the larger patterns within which it is contained, Christopher Alexander in The Timeless Way of Building 14