Entwickeln und Dokumentieren von Softwarearchitektur - Best ...Literatur JanBosch...

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/