Upload
others
View
0
Download
0
Embed Size (px)
Citation preview
Entwickeln und Dokumentieren vonSoftwarearchitektur
„Best Practices“ in Entwurf und Kommunikation
Burkhardt Renz
Fachbereich MNITechnische Hochschule Mittelhessen
Wintersemester 2020/21
Übersicht
Entwurf einer SoftwarearchitekturEntwicklungsprozess und Architektur„Best Practices“Voraussetzungen
Vorgehen
Dokumentation von Softwarearchitektur
Entwicklungsprozess und Softwarearchitektur
Architektur ist nicht Phase des Entwicklungsprozesses,sondern DaueraufgabeArchitektur als initialer BauplanIterative Entwicklung fl Architekturverfeinerung undArchitekturrefactoringÜberprüfung architektonischer Richtlinien fl Erosion derArchitektur verhindernArchitektur und agiles Vorgehen – Diskussion, siehe zumBeispiel das Paper von Wils und Van Baelen
Entwurf einer Softwarearchitektur
Kein „Königsweg“ oder RezeptDenn: Softwareentwicklung oft auf NeulandLeitlinie: „Best Practices“Erfahrungsschatz nutzenArchitekturstile und -muster kennenMechanismen für Qualitätsmerkmale kennen
Voraussetzungen
GeschäftszieleFunktionale Anforderungen (einigermaßen) vollständigdefiniert; möglichst samt Anwendungsfälle/User StoriesGegebenheiten des AnwendungsgebietsEinschränkungen/Festlegungen bezüglich der InfrastrukturGegebenheiten des Softwareproduktionsprozesses definiert
Übersicht
Entwurf einer Softwarearchitektur
VorgehenKomponenten für die FunktionalitätQualitätsmerkmale und MechanismenDetaillierung und „Refactoring“
Dokumentation von Softwarearchitektur
Initialen Achitekturentwurf finden
Systemkontext definieren.Grundlage: Funktionale Anforderungen, InfrastrukturDomänenmodell erstellen .Grundlage: Funktionale Anforderungen, AnwendungsgebietTechniken: Objektorientierte Modellierung,Informationsmodellierung, Geschäftsprozessmodellierung, . . .Typ der Problemstellung ò Architekturstilauch: Kombination von Stilen für SubsystemeDekomposition in Komponenten und Konnektorenauf Basis der funktionalen Eigenschaften
+ Initiale Architektur
Qualitätsmerkmale und Mechanismen
Gewünschte Qualitätsmerkmale ermittelnQualität für den Benutzer; Qualität der EntwicklungQualitätsszenarien ermittelnSzenarien gegeneinander abschätzen:Trade-offs? Prioritäten?Mechanismen für Kernszenarien entwickeln und in dieArchitektur einbringen.
Detaillierung und „Refactoring“
Anwendung von Mechanismenñ Transformation von Qualitätsanforderungen in funktionaleKomponentenñ neue Komponenten, neue KonnektorenAnwendung von Entwurfsmusternñ Einfluss auf Designzentren?Festlegung der Codestruktur: Abhängigkeiten vonCode-Komponentenñ Planung und Überwachung von Struktur im Codeñ Gleichzeitig Überprüfung der Architektur
Risiko im Vordergrund
Architekturentwurf und agiles Vorgehen – LangeArchitekturphase „up front“ nicht notwendigStattdessen: Risiko im FokusIdentifizieren von Risiken, PriorisierungMechanismus überlegen, der das Risiko vermindertNoch ein wichtiges Risiko?
Methode: Attribute-Driven Design
ADD ist eine systematische und iterative Methode für dieEntwicklung einer SoftwarearchitekturPro Iterationsschritt:
Wähle zu betrachtende Komponenten und definiere ZielIdentifiziere relevante Geschäftsziele, Qualitätsattribute undConstraintsFinde geeignete Mechanismen dafür und verfeinere dieArchitektur entsprechend
Resultat jeweils: Skizzen der KonzepteDer iterative Ansatz eignet sich zu Verwendung der Methodein agilen Prozessen
Literatur und Links zu ADD
Humberto Cervantes, Rick KazmanDesigning Software ArchitecturesHarlow, UK: Addison-Wesley, 2016.
Humberto Cervantes et al.Smart Decisions: A game about architecting modern softwaresystemshttps://smartdecisionsgame.com
Literatur
Jan BoschDesign and Use of Software ArchitecturesHarlow, UK: Addison-Wesley, 2000.
Rick Kazman, Paul Clements, Len BassSoftware Architecture in Practice Part TwoBoston: Addison-Wesley, Third Edition 2012.
George FairbanksJust Enough Software Architecture: A Risk-Driven ApproachBoulder, CO: Marshall & Brainard, 2012.Michael Stal, Stefan Tilkov, Markus Völter, Christian WeyerSoftwareArchitekTOUR - Podcast für den professionellenSoftwarearchitekten – Episode über Architektur-Refactoringwww.heise.de/developer/podcast/
Übersicht
Entwurf einer Softwarearchitektur
Vorgehen
Dokumentation von SoftwarearchitekturPerspektiven und SichtenNotationenBeispiele
Sichten der Softwarearchitektur
Das Wesentliche der Architektur lässt sich in der Regel nicht ineiner Sicht allein darstellen. Man unterscheidet deshalbverschiedene Sichten.
Im konkreten Fall wählt man die „passenden“ Sichten, um dieArchitektur darzustellen.Es gibt verschiedene Methoden, Softwarearchitektur darzustellen:
Das 4+1-Sichten-Modell von Phillipe Kruchten, verwendet im(Rational) Unified Process4 Sichten von Hofmeister, Nord und SoniViewtypes und Styles des SEICanonical Model Structure von George FairbanksFMC Fundamental Modeling Concepts, gelehrt amHasso-Plattner-Institut
Kruchten & UML
2
Logical View Implementation View
Process View Deployment View
Use-Case View
Programmers Software management
End User Functionality
The “4+1” view model (Phillipe Kruchten 1995)
System Integrators Performance ScalabilityThroughput
Analysts/TesterBehavior
System EngineersSystem Topology
Delivery, InstallationCommunication
Charakteristik der 4+1-Sichten
Für jede Sicht wird angegeben:I Inhalt, K Komponenten, B Beziehungen und S Stakeholder.
Use Case SichtI: Verhalten des SystemsK: Akteure, AnwendungsfälleB: Interaktion, Verwendung, VererbungS: Anwender, Analytiker, Tester
Logische SichtI: Vokabular des Gebietes, FunktionalitätK: Klassen, Verantwortlichkeiten, KollaborationenB: Assoziation, Vererbung, Abhängigkeit, SteuerungS: Anwender, Analytiker, Designer, Bereichsexperte
Charakteristik der 4+1-Sichten
Prozess-SichtI: Performanz, Skalierbarkeit, VerfügbarkeitK: Prozesse, ThreadsB: Aktivierungssteuerung, (gemeinsame) ResourcenS: Designer, Deployer
Implementierungs-SichtI: Systembestandteile, KonfigurationsmanagementK: Dateien, RepositoriesB: Enthaltensein, AbhängigkeitS: Designer, Entwickler, Konfigurationsmanager
Physische SichtI: HardwaretopologieK: HardwareresourcenB: Kommunikationskanäle, AbhängigkeitS: Hardwareingenieur, Deployer.
Hofmeister, Nord und Soni
Konzeptionelle Sicht beschreibt Komponenten und Konnektorenund wie sie zusammenarbeiten
Modulsicht beschreibt Subsysteme, bestehend aus Modulen mitihren Schnittstellen, eventuell angeordnet inSchichten
Ausführungssicht beschreibt Ausführungseinheiten (z.B. Prozesse),die auf einer bestimmten Plattform laufen undkommunizieren
Codesicht beschreibt Quelldateien, binäre Komponenten,Bibliotheken, ausführbare Programme und weitereDateien
UML Composite Structure Diagram
(c) Warren Tang
Elemente des Composite Structure Diagrams
Structured ClassKlasse, die eine interne Struktur hat, bestehend ausEigenschaften (properties), Teilen (parts) mit bestimmtenRollen (roles) und Konnektoren (connectors), sowie Ports.Property, Part, RoleProperties sind Instanzen, die Teil der Structured Class sind,Parts speziell Aggregationen von Properties, sie könnenbestimmte Rollen spielenConnectorssind Assoziationen innerhalb der Komponente, die einenKommunikationskanal repräsentierenPortssind Interaktionspunkte einer strukturierten Klasse(1) nach außen (service port), oder(2) zu inneren Teilen (behavior port).
Viewtypes des SEI
Viewtype = Perspektive auf das SystemA viewtype defines the element types and relationship types usedto describe the architecture of a software system from a particularperspective
Drei Viewtypes1 Module viewtype2 Component-and-connector viewtype3 Allocation viewtype
Styles
Style = Spezielle Ausprägung/Muster der PerspektiveA style guide is the description of an architectural style thatspecifies the vocabulary of design (set of element and relationshiptypes) and the rules (sets of topological and semantic constraints)for how that vocabulary can be used.
BeispielPipes & Filters ist ein Style des Component-and-ConnectorViewtypes.
Canonical Model Structure (George Fairbanks)
George Fairbanks: Just Enough Software Architecture, S.116
Sichten auf das Domain Model
Model
RelationshipDomainModel
Concepts
Snapshots
Scenarios
«view»
«view»
«view»
…
George Fairbanks: Just Enough Software Architecture, S.119
Sichten auf das Design Model
George Fairbanks: Just Enough Software Architecture
Use Cases
System Context
«view»
«view» …
ModuleViews
RuntimeViews
AllocationViews
SpanningViews
«view»
«view»
«view»
«view»
• Module diagram• Component, connector, port types• Use case diagram• Responsibilities
• System context diagram• Components, connectors, ports• Functionality scenarios• Component assembly
• Allocation diagram• Environmental elements
• Quality attribute scenarios• Tradeoffs
Fundamental Modeling Concepts
Ausgehend von einer Klassifikation dynamischer Systeme schlägtSiegfried Wendt eine Darstellung der fundamentalen Struktureneines Softwaresystems vor, die die grundlegende konzeptionelleArchitektur des Systems verständlich machen
Drei fundamentale Strukturen in informationellen dynamischenSystemen:
AufbaustrukturenWertebereichsstrukturenAblaufstrukturen
Notation von FMC
Bipartite GraphenAufbaustrukturen bestehen aus
aktiven, verarbeitenden Komponenten (Agenten)passiven, datenhaltenden Komponenten (Kanälen undSpeichern)Struktur: Agenten verarbeiten Daten, Ergebnisse werden anKanälen oder in Speichern beobachtbar
Darstellung der Wertebereichsstukturen durch Mengen undRelationen, optisch ähnlich den Venn-Diagrammen, inhaltlichEntity-Relationship-ModelleAblaufstrukturen durch Petri-Netze, genauerStellen-Transitions-Netze
Beispiel Aufbaustruktur in FMC
© FMC Research Staff – http://fmc.hpi.uni-potsdam.de
Travel agency
place order,get ticket
Reservationsystem
R R
Reser-vations
Customerdata
Travelinformation
Informationhelp desk
Travel organization
Customers Interested persons
advertising,consulting
Beispiel Architektur von AutiSta
Beispiel Architektur von Apache Lucene
Original-Dokument
DocumentConverter
Document
IndexWriter Analyzer
IndexReader
IndexSearcher
Document
Query
Anfrage
QueryParser
R
R
R
Lucene Index Apache LuceneArchitektur -- Überblick
Literatur
Philippe KruchtenArchitectural Blueprints – The „4+1“ View Model of SoftwareArchitectureIEEE Software 12(6), November 1995
Christine Hofmeister, Robert Nord, Dili SoniApplied Software ArchitectureReading, MA: Addison-Wesley, 2000.
Paul Clements et al.Documenting Software Architectures: Views and BeyondBoston: Addison-Wesley, 2003.
Literatur
George FairbanksJust Enough Software ArchitectureBoulder, CO: Marshall & Brainerd, 2012.Andreas Knöpfel, Bernhard Gröne, Peter TabelingFundamental Modeling ConceptsJohn Wiley & Sons, 2005.http://www.fmc-modeling.org/