Softwarequalität - Architektur

Embed Size (px)

DESCRIPTION

Vorlesung Softwarequalität:Die Folien zum Thema Software-Architektur.Inkl. Schnellüberblick zu Kommunikationsprotokollen aus Architektur-Sicht.

Text of Softwarequalität - Architektur

  • 1. Softwarequalitt Architektur & QualittProf. Dr. Wolfgang GolubskiGerrit Beine, M.Sc.golubski@fh-zwickau.demail@gerritbeine.com 1

2. Aufgaben von Software-Architektur2 3. Aufgaben der Software-Architektur Software-Architektur:Beschreibt die Komponenten einer Software sowie deren funktionales Zusammenspiel. SWEBOK (Software Engineering Body of Knowledge, IEEE) ordnet Software-Architektur zurder Entwurfsphase zu Software-Architektur ist die Summe von Design-Entscheidung vor der Implementierung Praktisch ist die Software-Architektur der IT-Architektur und derUnternehmensarchitektur untergeordnet IT-Architektur: Infrastruktur (Hard- und Software) im Unternehmen Unternehmensarchitektur: Zusammenspiel der IT-Elemente im Sinne des geschftlichen Zwecks Software-Architektur verantwortet im Wesentlich Nicht-Funktionale Anforderung FURPS (Functionality, Usability, Reliability, Performance, Supportability) siehe auch ISO 9126 3 4. Kollaborative Aufgaben des Software-Architekten Requirements Engineering Festlegen von Nicht-Funktionalen Anforderungen Bewerten von funktionalen Anforderungen hinsichtlich ihrer Bedeutung fr die Architektur Betriebsfhrung Definition der Laufzeitumgebung, Hardware, Betriebssystem, Datenbank Festlegung des Deployments, Verteilung von Client-Anwendungen Test Design for Testability whrend Design und Implementierung Untersttzung des Testmanagements in allen Phasen Projektmanagement Tracking der Nicht-Funktionalen Anforderungen Auswahl und Definition einer Architektur mit Blick auf Zeit und Kosten4 5. Software-Architekten & Software-Entwickler Software-Architekten machen Vorgaben fr Projekte berblick des Gesamtprojektes, Kontext-bezogenes Wissen Software-Entwickler realisieren konkrete Lsungen fr Teilaspekte des Projektes Tiefes Detailwissen bezglich Frameworks und Problemstellungen Software-Architekten sollten: Erklren, WARUM sie welche Vorgabe machen Kontext-Wissen transparent machen, berblick ermglichen Programmieren knnen; Code-Beispiele sind gute Eisbrecher Zuhren Software-Entwickler sollten: Fragen, warum etwas vorgegeben wurde Begrnden, warum abgewichen werden sollte5 6. Architektur, Conways Law und das Problem derKomponententeams6 7. Conways Law organizations which design systems are constrained to produce designs which are copiesof the communication structures of these organizationsMelvin Conway, 1968 Bedeutung fr die Software-Architektur Die fachliche Architektur einer Anwendung sollte immer der Struktur des Fachbereichs folgen, der die Anwendung nutzen wird. Die technische Architektur sollte immer die fachlichen Architektur widerspiegeln und sie erweitern. Build-Strukturen sollten immer der technischen Architektur folgen. Bei der Planung von Software und dem Team-Setup eines Projektes sollte Conways Lawbercksichtigt werden.7 8. Conways Law und ModellebenenSicht ArtefakteBeziehungenGeschftsobjektsicht Business Objects, reprsentiert Ausschlielich zwischen durch Klassen, sehr hohes Business Objects AbstraktionsniveauAnforderungssichtRequirements, Functional &Verbindung zwischen Functional Non-Functional& Non-Functional Requirements, Abhngigkeiten zu Business ObjectsAnwendungsfallsichtUse Cases, Actors Use Cases realisieren Manchmal hier sinnvoll: Requirements FachklassenmodelleUse Cases bentigen Business Objects (oder Fachklassen)Fachliche ArchitekturComponents, Dependencies, Component realisiert Use Case Fachlich orientiert, Keine technologische AspekteTechnische Architektur Components, Dependencies, Component realisiert Technische Aspekte sichtbar,Component aus Fachlicher Grundlage fr Build Process Architektur 8 9. Komponenten und Subsysteme Komponente: "A software component is a unit of composition with contractually specifiedinterfaces and explicit context dependencies only. A software component can bedeployed independently and is subject to composition by third parties."(Clemens Szyperski, Component Software, ACM Press/Addison-Wesley, England, 1998) "Eine Software-Komponente ist ein Software-Element, das konform zu einemKomponentenmodell ist und gem einem Composition-Standard ohne nderungenmit anderen Komponenten verknpft und ausgefhrt werden kann."(William T. Councill, George T. Heineman: Component-Based Software Engineering. Addison-Wesley, 2001, ISBN 0-201-70485-4) Subsystem: Ein Subsystem (Teilsystem) ist eine Komponente, die sehr gro ist oder sich ausmehreren Komponenten zusammensetzt. Agiles Identifizieren von Subsystem: Ein Subsystem besteht aus einer oder mehrerenKomponenten, die fr sich stehend einen Geschftswert erzeugen.9 10. Komponententeams und Featureteams Komponententeams haben in der Regel eine hohe Domnenkompetenz tendieren aberzur Wasserfall-Entwicklung. Feature-Teams sind in der Regel Cross-Funktional, haben kaum bergabepunkte undtendieren eher zu agilen und emergenten Entwicklungen. Wann lohnen sich Komponententeams? In groen Wartungsprojekten, wenn nderungen kontinuierlich erfolgen. Wann lohnen sich Featureteams? In Greenfield-Projekten In Brownfield-Projekten, wenn ein schlechter Komponentenschnitt vorliegt oder nicht kontinuierlich an einzelnen Komponenten weiterentwickelt wird. Das Problem mit dem Collaborative-Code-Ownership: Idealerweise sollte nur ein Feature-Team zu einem Zeitpunkt ein Teilsystem bearbeiten, klappt das nicht, sollte pro Komponente nur ein Team arbeiten. In groen Projekten sollte ein Feature-Team fr die betroffenen Komponenten verantwortlich sein, bis das Feature implementiert ist.10 11. Architektur-Dokumentation11 12. Die vier Sichten von Architekturdokumentation KontextabgrenzungEinbettung in der Umgebung, KontextabgrenzungSchnittstellen zu Nachbarsystemen,System ist Blackbox BausteinsichtInterne Sicht des Systems, statische LaufzeitsichtenStrukturen, Abhngigkeiten zwischenKomponenten LaufzeitsichtInterne Sicht, Verhaltensbeschreibungen,Interaktion der Bausteine zur Laufzeit, BausteinsichtenBeschreibung des dynamischenStrukturen VerteilungssichtExterne Sicht, Topologie des Systems,VerteilungssichtenInfrastruktur, Hardware, Deployment Vier Arten von Sichten (Nach Effektive Software-Architekturen, Gernot Starke, 4. Auflage, 2009, Carl Hanser Verlag Mnchen)12 13. Schnittstellendokumentation Schnittstellen zu externen Systemen mssen dokumentiert sein Formal mit Beschreibungssprachen wie WSDL, WADL, Corba-IDL oder API-Dokumentation Elemente der Schnittstellendokumentation Versionsinformationen der Schnittstelle Bereitgestellte Ressourcen (API-Dokumentation) Semantik der Ressourcen (Events, Daten, Zustnde) sowie potentieller nderungen Restriktionen hinsichtlich der Benutzung der Schnittstelle Fehlerszenarien, Konfigurationsparameter Erklrung der Entwurfsentscheidungen Verfgbarkeit der Schnittstellen (sowohl operativ als auch strategisch) Reaktionszeiten bei Problemen Ansprechpartner beider beteiligten Systeme Beispiele zur Verwendung 13 14. Architektur-Dokumentation Inhalte Strukturen des Systems (Vier Sichten) Schnittstellen, idealerweise als Kontrakte mit Ansprechpartnern Architektur-Entscheidungen mit ihren Begrndungen Umfang von Architektur-Dokumentation So wenig wie mglich, so viel wie ntig Weniger ist oft mehr, lange Prosa-Dokumente schrecken oft ab Bilder sagen mehr als Worte, Zusammenhnge lassen sich visuell gut transportieren Verstndlichkeit ist zwingend, Sprachen wie UML sind optional Gut geeignet ist Architekturtapete Einzelne Aspekte der Architektur werden auf Packpapier an der Wand verewigt Erklrungen und Diskussionen lassen sich wie an einem Scrum-Board fhren 14 15. Kommunikationsprotokolle aus Architektursicht15 16. Kommunikationsprotokolle Notwendig, um Informationen zwischen Anwendungen auszutauschen In der Regel ab OSI-Layer 5 (Session Layer) implementiert, oft noch aufAnwendungsprotokollen aufbauend (z.B. HTTP) Architekturentscheidungen berhren folgende Punkte: Sicherheit Ist das Protokoll zulssig? Erfllt es die notwendigen Sicherheitskriterien? Performance Kann der Informationsaustausch schnell genug durchgefhrt werden? Beschrnkungen Kann der Umfang der Informationen durch das Protokoll bertragen werden?16 17. Common Object Request Broker Architecture (CORBA) Objektorientierte Middleware und plattformbergreifender Protokollstack Definiert durch die Object Management Group Basiert auf TCP/IP, kann Secure Socket Layer verwenden CORBA IIOP Standard-Port 683 (Port 684 fr CORBA IIOP over SSL) Schnittstellenspezifikation durch Interface Definition Language IDL wird mit Compiler in jeweilige Programmiersprache bersetzt Stubs und Skeletons entsprechen dem Mediator-Pattern Service-basierte Architektur (u.a. Naming Service, Trading Service, Event Service, Life CycleService, Relationship Service) Datenbeschreibung als struct, union und sequence, bestehend aus primitiven Typen wielong, double, string, boolean, enum Wurde groteils durch Java und .NET Remoting verdrngt Relevante Implementierungen in IBM WebSphere (Basis fr Java-Remoting) und ORBit(verwendet von Mozilla und LibreOffice)17 18. Remote Procedure Call Protokoll zur Interprozesskommunikation, erstmals 1976 beschrieben (RFC 707) Aktuelle Version in RFC 1057 und 5531 beschrieben Basiert in der Regel auf UDP, prinzipiell aber auch TCP mglich Standard-Port fr Sun-RPC ist 111, DCE RPC Port ist 135 Verschiedene Implementierungen, die inkompatibel sind Open Network Computing (ONC) RPC (Sun-RPC) Distributed Computing Environment (DCE) RPC Microsoft RPC (MSRPC), abgeleitet von DCE RPC, Grundlage fr DCOM Client-Server-Modell, Verzeichnisdienst oder Broadcast notwendig Koordination der vom Client initiierten Aufrufe bernimmt ein Portmapper Basis von NFS und NIS Fr die Entwicklung moderner Anwendung kaum von Bedeutung 18 19. Extensible Markup Language Remote Procedure Call (XML-RPC) Protokoll auf Basis von HTTP(S) und XML Hauptschlich von Microsoft entwickelt Plattformbergreifend und unabhngig von Programmiersprachen durch XML-Format Sehr leichtgewichtig, einfach z