SlideShare ist ein Scribd-Unternehmen logo
Impulsvortrag: Steht alles im Wiki? Das kleine 1x1 der Architekturdokumentation Stefan Zörner, oose Innovative Informatik GmbH, Hamburg Gesellschaft für Informatik e.V.,  Regionalgruppe Dortmund, 04.10.2010
Zusammenfassung Steht alles im Wiki?  Das kleine 1x1 der Architekturdokumentation Architekturdokumentation wird oft als lästige Pflicht angesehen. Dabei ermöglicht das angemessene Festhalten die Kommunikation Ihrer Konzepte im Team und dem Auftraggeber gegenüber überhaupt erst. Der Vortrag stellt anhand konkreter Beispiele bewährte Arbeitsergebnisse und mögliche Strukturierungen vor. Häufige Herausforderungen werden ebenso diskutiert wie typische Werkzeugketten. Wiki oder UML-Tool? Oder was dazwischen? Welche Notationen haben sich in der Praxis bewähren? Und wie kommt man falls verlangt jederzeit zu einer druckbaren Dokumentation?
Stefan Zörner, Stationen 1991-94 Ausbildung  Math.-techn . Assistent bei der  Bayer AG Studium  Mathematik (Diplom 1998), Schwerpunkt Informatik 1998-2001  Mummert + Partner  AG, Berater, u.a. Sun-Trainer 2001-2006  IBM  e-business Innovation Center , IT-Architekt Seit Juli 2006: Berater und Trainer bei  oose  in Hamburg Schwerpunkt: Softwareentwurf und Java-Technologien [email_address] Veröffentlichungen, Vorträge Bücher „Portlets“, 2006  „ LDAP für Java-Entwickler“, 3. Auflage 2007 Artikel u.a. in Java Magazin und bei IBM  developerWorks Vorträge bei JAX und W-JAX seit 2002,  Advisory  Board Dies und das Seit 2005 Mitarbeit im  Apache  Directory Project,  [email_address] iSAQB  Certified Professional for Software Architecture OMG  Certified UML Professional (Intermediate) SpringSource  Certified Spring Professional
Agenda 1   Montag Morgen 2 Entscheidungen 3   Sichten 4   Bewerten 5 Strukturieren 6   Schluss und Aus(-blick)
Agenda 1   Montag Morgen 2 Entscheidungen 3   Sichten 4   Bewerten 5 Strukturieren 6  Schluss und Aus(-blick)
Montag Morgen …
Fragen, die neue Mitarbeiter so stellen … ? Wie checke ich die Sourcen aus, und wie baue ich  die  Software?  Warum sind bei mir Tests rot? Was brauche ich für Tools?    Wenn ich neue Funktionalität hinzufügen soll – wie  stelle ich das an?  Hier ist doch schon was Ähnliches,  kann ich das wiederverwenden?  Was leistet das System überhaupt?  Aus welchen Bestandteilen besteht die Software?  Wie arbeiten diese zusammen?  Ist das irgendwo beschrieben? Warum benutzt ihr noch JDK 1.3? Wieso habt Ihr das denn so gemacht? …
Antworten, die neue Mitarbeiter daraufhin erhalten  ! Steht alles im Wiki. Das haben wir nicht dokumentiert – wir gehen agil vor. Das war schon so, als ich neu war. Das ist historisch gewachsen.
Definitionen zu Softwarearchitektur Es gibt nicht die eine allgemein akzeptierte Definition für Softwarearchitektur Das  Software Engineering Institute  (SEI) sammelt sogar Definitionen:    http://www.sei.cmu.edu/architecture/definitions.html
Eine konkrete Definition Architektur :=    wichtige Entscheidungen Softwarearchitektur umfasst die Summe verschiedener wichtiger Entscheidungen über die Auswahl von Strukturelementen und deren Schnittstellen,  aus denen das System zusammengesetzt ist das Verhalten und Zusammenspiel dieser Elemente  den hierarchischen Aufbau von Subsystemen den zugrunde liegenden Architekturstil … G. Booch, P. Krutchen, K. Bittner and R. Reitman. The Rational Unified Process — AnIntroduction. 1999.
Agenda 1   Montag Morgen 2 Entscheidungen 3   Sichten 4   Bewerten 5 Strukturieren 6  Schluss und Aus(-blick)
Architekturentscheidungen … Zitat zu Architekturentscheidung (Woods) : Die, die wenn falsch  Architekturentscheidungen sind diejenigen, die sich im weiteren Verlauf nur  sehr schwer revidieren lassen. Konsequenzen: höhere Kosten, Zeitverlust, ggf. scheitert das Vorhaben “ Software architecture is the set of design decisions which, if made incorrectly, may cause your project to be cancelled.” ( Eoin  Woods )
Entscheidungen treffen und festhalten. Ein Werkzeug
Fragestellung, Rahmenbedingungen Fragestellung – Leitfragen  Was genau ist das Problem? Warum ist es für die Architektur relevant? Welche Auswirkung hat die Entscheidung? Rahmenbedingungen – Leitfragen  Welche festen Randbedingungen haben wir einzuhalten? Welche Einflussfaktoren sind zu beachten?
Annahmen Annahmen – Leitfragen  Welche Annahmen haben wir getroffen? Welche Annahmen können wie vorab überprüft werden? Mit welchen Risiken müssen wir rechnen? “ The life of a software architect is a long and rapid succession of suboptimal design decisions taken partly in the dark.” ( Philippe Kruchten )
Betrachtete Alternativen, Entscheidung Betrachtete Alternativen – Leitfragen  Welche Lösungsoptionen ziehen wir in die nähere Auswahl? Wie bewerten wir jede einzelne? Welche Optionen schließen wir bewusst aus? Entscheidung – Leitfragen  Wer hat die Entscheidung getroffen? Wie ist sie begründet? Wann wurde entschieden?
Gesamtbild.
Agenda 1   Montag Morgen 2 Entscheidungen 3   Sichten 4   Bewerten 5 Strukturieren 6  Schluss und Aus(-blick)
Schwanensee (1877)
Beispiel Tanznotation
Analogie zur Softwarearchitektur:  Views  (Sichten) Es ist sinnvoll, bestimmte Aspekte einer Software mit Bilder statt  textuell  zu beschreiben Ein einzelnes Bild reicht in der Regel nicht aus Unterschiedliche Sichten für unterschiedliche Aspekte Beispiel:  Rational Unified Process  ( P. Kruchten ) 4 + 1 Views: Logical View Development View Process View Physical View Scenarios
Literaturtipp zu dem Thema:  Dort beschriebene Sichten (u.a.) Kontextsicht Bausteinsicht (= Struktur) Laufzeitsicht (= Verhalten, Dynamik) Verteilungssicht Effektive Software-Architekturen Ein praktischer Leitfaden von Gernot Starke 449 Seiten,  Hanser  Fachbuch; 4. Auflage (2009) ISBN  978-3446420083
Die Kontextsicht – Software agiert nicht allein … Systemkontextdiagramm: Visualisierung des Umfelds das zu beschreibende System im Mittelpunkt als Blackbox drum herum die direkt beteiligten Benutzer und Fremdsysteme Verbindung zwischen einem solchen Akteur und dem System  drückt Interaktion aus. Der  Kontextsicht  zeigt das Umfeld, d.h. alle außerhalb des eigenen Systems liegenden Akteure, mit denen direkt kommuniziert wird. Stets gibt es Beteiligte außerhalb des Systems: Anwendergruppen, die Funktionalität nutzen und erwarten Fremdsysteme, die zur Ausführung erforderlich sind
Fallbeispiel: Apache Tomcat Apache Tomcat ist ein in Java geschriebener Webapplikationsserver zum Betreiben Java EE-konformer Webapplikationen.    http://tomcat.apache.org
Eine Kontextsicht für Apache Tomcat in UML.
Warum ist das so wichtig? Potenzielle Schnittstellen zum Zielsystem finden! Sie Anbindung eines Fremdsystems ist regelmäßig ein  technisches Risiko. Solche frühzeitig zu erkennen kann entscheidend sein für den  Erfolg Ihres Projektes. Architekturentscheidungen ableiten. Startpunkt, um Verantwortlichkeiten zu klären Welche Fremdsysteme müssen wir integrieren? Was leistet unser System, und vor allem: was leistet es  nicht? Wo ist die Systemgrenze?
Was ist was?
Die Bausteinsicht „ Die Bausteinsicht bildet die Funktionalität des Systems auf Software- oder Implementierungsbausteine ab. Die Sicht macht Struktur und Zusammenhänge zwischen den Bausteinen der Struktur explizit “ (G. Starke) Beispiel (UML, Kompositionsstrukturdiagramm)
Apache Tomcat: Komponentendiagramm
Apache Tomcat: Kompositionsstrukturdiagramm
Zusammenspiel Kontextsicht / Bausteinsicht Blackbox Whitebox
Nächste Ebene.
Nächste Ebene ...
Die Laufzeitsicht – In Bewegung Die Bausteinsicht bietet lediglich eine statische Sicht Oft bringt erst die Zusammenschau mit dynamischen Aspekten  Einsichten, wie das System eigentlich funktioniert, bzw. zu  verwenden oder zu erweitern ist. Die  Laufzeitsicht  (alternativ: Verhaltenssicht) beschreibt, wie Softwareelemente zur Laufzeit interagieren, bzw. wie ein Element selbst sich verhält. Laufzeitsicht und UML Die UML bietet verschiedene Modellelemente und  Diagrammtypen für die Laufzeitsicht an, z.B. Aktivitätsdiagramm Sequenzdiagramm Zustandsdiagramm
Beispiel: Apache Tomcat Implementierung einer eigenen  Tomcat -Komponente Tomcat kennt verschiedene Abstraktionen, die gewollte Erweiterungspunkte  darstellen (z.B.  Connector, Realm ) Frage: Wie dokumentiert man die Implementierung von Erweiterungen? „ Ein Design sollte  offen  für Erweiterungen, aber  geschlossen  für Änderungen sein.“ ( Open Closed Principle ) Bertrand Meyer 1988 Beispiel:  Valve Ein  Valve  (dt. "Ventil") ist eine Anfragen verarbeitende  Komponente, die mit einem Container assoziiert ist.  Üblicherweise bilden eine Kette von  Valves  eine Pipeline (d.h.  ein  Valve  kennt seinen Nachfolger).
Statische Sicht.
Dynamische Sicht.
Die Verteilungssicht – Ja wo laufen sie denn? Die bisherigen Sichten blenden Betriebsaspekte völlig aus. Wie verteilt sich die Lösung auf z.B. auf unterschiedliche  Rechner? Die  Verteilungssicht  beschreibt, welche physikalischen Informationseinheiten (Jar-Files, DLLs, ...) im Rahmen des Entwicklungsprozesses erstellt bzw. benötigt werden, welche Komponenten sie manifestieren, und wie sie für den Betrieb zu verteilen sind. Verteilungssicht und UML Die UML bietet eigene Modellelemente und ein Diagramm für die  Verteilungssicht an Verteilungsdiagramm Knoten, Artefakte
Beispiel: Apache Tomcat Konkret bei Tomcat: Tomcat wird in reichlich JAR-Files ( J ava  Ar chive)  ausgeliefert Wenn ich nur Teile von Tomcat verwenden möchte  (z.B.  nur den JSP Compiler), welche JAR-Files  werden  benötigt? Wenn neue Komponenten realisiert werden (z.B. eine  Valve ), wogegen muss kompiliert werden? Allgemeine Fragen:  Welche  Deployment Units   (JARs, DLLs, SOs, …)   manifestieren welche Bausteine? Welche  Deployment Units  müssen wo installiert  werden (z.B. bei Client Server) Beispiel 1: Welche  Deployment Units  brauche ich für was?
UML Deployment Diagram
UML Deployment Diagram Beispiel 2: Szenario: Tomcat + Apache HTTP Server
Agenda 1   Montag Morgen 2 Entscheidungen 3   Sichten 4   Bewerten 5 Strukturieren 6  Schluss und Aus(-blick)
Architekturbewertung: Reflektieren bevor man dokumentiert… Meeting Feedback Review Workshop Kommunikation Planung Priorisierung Zusammenarbeit Kundenorientierung Präsentation Risikominderung Transparenz Qualitätssicherung Flexibilität Zentrale Frage:  Erreicht man die geforderte Qualitätsmerkmale mit den getroffenen Entscheidungen?
Der Architekturbewertungsprozess
Entscheidungen vor / im / nach dem Workshop festhalten
Qualitätsanforderungen dokumentieren © by oose innovative Informatik GmbH Performanz ist  superwichtig! Qualitätsmerkmale  für die Umsetzung  spezifischer   zu   formulieren   hilft:  beim Treffen von Design-Entscheidungen bei der Priorisierung der Qualitätsmerkmale bei der Bewertung von Entscheidungen
Möglichkeiten Qualitätsanforderungen zu beschreiben © by oose innovative Informatik GmbH
Szenarien © by oose innovative Informatik GmbH Szenarien Ein entfernter Benutzer sendet bei Hochauslastung  eine Anfrage für einen Datenbank-Report über das Internet und erhält den Report innerhalb von 5 Sekunden. Ein Szenario ist ein Beispiel für die Verwendung des Systems Ein Szenario ist eine „Manifestation“ eines Qualitätsmerkmals Ein Szenario ist überprüfbar (zumindest theoretisch) Ein Szenario gibt dem „Umsetzer“ Anforderungen auf richtigem Niveau
© by oose innovative Informatik GmbH Ein entfernter Benutzer sendet bei Hochauslastung  eine Anfrage für einen Datenbank-Report über das Internet und erhält den Report innerhalb von 5 Sekunden. Mögliche Teile eines Szenarios
Entscheidungen im Kontext Die Verbindung zwischen Rahmenbedingungen, Anforderungen und Architekturentscheidungen ist essenziell! Durch die Verbindung können Änderungen  in ihren Auswirkungen abgeschätzt werden weniger aufwändig durchgeführt werden (und konsistent erfolgen)
Architekturbewertung – keine Noten aber mehr Durchblick http://it-republik.de/business-technology/
Agenda 1   Montag Morgen 2 Entscheidungen 3   Sichten 4   Bewerten 5 Strukturieren 6  Schluss und Aus(-blick)
arc42 – Vorschlag für ein  Template http://arc42.de/ (Gernot Starke, Peter Hruschka)
Struktur des  Templates
Es muss nicht immer ein digitales Tool sein ...
Übungsergebnisse aus einem oose-Seminar zu Softwarearchitektur
UML =  Unified Modeling Language etablierte, standardisierte Notation im Bereich  Software-Engineering    http://www.uml.org/ Primäre Disziplinen:  Analyse Entwurf / Architektur umfangreich, 14 Diagrammtypen
Diagramme == Sichten auf ein Modell
Und im Wiki? Nachvollziehbarkeit von Ergänzungen und Änderungen Autor, Historie, … Benachrichtigungen  Freies Verknüpfen von Inhalten (Links, Tags Leicht zugänglich für das ganze Team (kein spezieller Client) Lädt zum Kommentieren ein „ Wikis ermöglichen das gemeinschaftliche Arbeiten an Texten. Ziel eines Wikis ist es im Allgemeinen, die Erfahrung und den Wissensschatz der Autoren  kollaborativ  auszudrücken.“ wikipedia.de Generell ein tolles Medium für Entwicklungsprojekte, um untereinander zu kommunizieren.
arc42 in einem Wiki?
Herausforderungen Versionierung Wikis führen Versionen für einzelne Seiten Wie  versioniert  man die Dokumentation vollständig, z.B. für ein  Release? Diagramme Wie erstellt man Abbildungen im bzw. für das Wiki Wie hält man Abbildungen  und Textinhalte konsistent? Drucken Wie gibt man die Dokumentation aus dem Wiki als  Dokument  (z.B. PDF) heraus? Wie befüllt man eine vorgegebene Struktur?
Entscheidungsfaktoren
Agenda 1   Montag Morgen 2 Entscheidungen 3   Sichten 4   Bewerten 5 Strukturieren 6   Schluss und Aus(-blick)
Früher kaufte man Software im Laden in einem Karton …
Homepage ActiveMQ
Projektteams brauchen ein gemeinsames Ziel, eine Vision Was entwickeln wir eigentlich?  Was ist die Idee des Systems?  Wem nützt es?  Wie unterscheidet es sich von Produkten der Mitbewerber?  Es ist eine Ihrer Aufgaben als Softwarearchitekt, die Idee des Systems im Entwicklungsteamteam zu verankern.
Mission Statement
Machen Sie die Systemidee explizit! Machen Sie die Systemidee explizit!
Systemidee auf der Startseite des Projekt- Wikis  …
Virtuellen Produktkarton erstellen z.B.    http://www.wikihow.com/Create-a-Product-Box-in-Photoshop
Systemkontext und Systemidee Was steckt drin? Was ist drum herum?
Kolumne „Architekturen dokumentieren“ Java Magazin, 10.2008 – 09.2009 http://javamagazin.de/
Auch im Web http://it-republik.de/jaxenter/
Vielen Dank! Ich freue mich auf Ihre Fragen … ? ? ? Stefan Zörner :: Stefan.Zoerner@oose.de

Weitere ähnliche Inhalte

Was ist angesagt?

Lightning Web Components
Lightning Web ComponentsLightning Web Components
Lightning Web Components
AbdulGafoor100
 
Resume_Sanket_S_Manjrekar - Software Developer
Resume_Sanket_S_Manjrekar - Software DeveloperResume_Sanket_S_Manjrekar - Software Developer
Resume_Sanket_S_Manjrekar - Software Developer
Sanket S. Manjrekar
 
Transform Your Data Integration Platform From Informatica To ODI
Transform Your Data Integration Platform From Informatica To ODI Transform Your Data Integration Platform From Informatica To ODI
Transform Your Data Integration Platform From Informatica To ODI
Jade Global
 
MongoDB
MongoDBMongoDB
Presentation- on OIM
Presentation- on OIMPresentation- on OIM
Presentation- on OIM
Tamim Khan
 
Java applications developer responsibilities and duties
Java applications developer responsibilities and dutiesJava applications developer responsibilities and duties
Java applications developer responsibilities and duties
Suri P
 
ClustrixDB at Samsung Cloud
ClustrixDB at Samsung CloudClustrixDB at Samsung Cloud
ClustrixDB at Samsung Cloud
MariaDB plc
 
Java Technical Design Document
Java Technical Design DocumentJava Technical Design Document
Java Technical Design Document
Deborah Obasogie
 
0228 2 sample_distribution
0228 2 sample_distribution0228 2 sample_distribution
0228 2 sample_distribution
Jeonghun Yoon
 
Wakanda: NoSQL for Model-Driven Web applications - NoSQL matters 2012
Wakanda: NoSQL for Model-Driven Web applications - NoSQL matters 2012Wakanda: NoSQL for Model-Driven Web applications - NoSQL matters 2012
Wakanda: NoSQL for Model-Driven Web applications - NoSQL matters 2012
Alexandre Morgaut
 
Packer, Terraform, Vault를 이용해 만드는 
재현 가능한 게임 인프라
Packer, Terraform, Vault를 이용해 만드는 
재현 가능한 게임 인프라Packer, Terraform, Vault를 이용해 만드는 
재현 가능한 게임 인프라
Packer, Terraform, Vault를 이용해 만드는 
재현 가능한 게임 인프라
MinKyu Kim
 
Domain Driven Design & Hexagonal Architecture
Domain Driven Design & Hexagonal ArchitectureDomain Driven Design & Hexagonal Architecture
Domain Driven Design & Hexagonal Architecture
Can Pekdemir
 
Maximizing MongoDB Performance on AWS
Maximizing MongoDB Performance on AWSMaximizing MongoDB Performance on AWS
Maximizing MongoDB Performance on AWS
MongoDB
 
Real-time Data Processing with Amazon DynamoDB Streams and AWS Lambda
Real-time Data Processing with Amazon DynamoDB Streams and AWS LambdaReal-time Data Processing with Amazon DynamoDB Streams and AWS Lambda
Real-time Data Processing with Amazon DynamoDB Streams and AWS Lambda
Amazon Web Services
 
What is performance_engineering_v0.2
What is performance_engineering_v0.2What is performance_engineering_v0.2
What is performance_engineering_v0.2
Trevor Warren
 
Apresentação Banco de Dados - Caché
Apresentação Banco de Dados - CachéApresentação Banco de Dados - Caché
Apresentação Banco de Dados - Caché
Renzo Petri
 
AWS Batch를 통한 손쉬운 일괄 처리 작업 관리하기 - 윤석찬 (AWS 테크에반젤리스트)
AWS Batch를 통한 손쉬운 일괄 처리 작업 관리하기 - 윤석찬 (AWS 테크에반젤리스트)AWS Batch를 통한 손쉬운 일괄 처리 작업 관리하기 - 윤석찬 (AWS 테크에반젤리스트)
AWS Batch를 통한 손쉬운 일괄 처리 작업 관리하기 - 윤석찬 (AWS 테크에반젤리스트)
Amazon Web Services Korea
 
Alfresco ECM e Gestão Eletrônica de Documentos Open Source
Alfresco ECM e Gestão Eletrônica de Documentos Open SourceAlfresco ECM e Gestão Eletrônica de Documentos Open Source
Alfresco ECM e Gestão Eletrônica de Documentos Open Source
Ambiente Livre
 
Abhilash resume
Abhilash resumeAbhilash resume
Abhilash resume
Abhilash Ramadugu
 
Anil purswani Resume
Anil purswani ResumeAnil purswani Resume
Anil purswani Resume
Anil Purswani
 

Was ist angesagt? (20)

Lightning Web Components
Lightning Web ComponentsLightning Web Components
Lightning Web Components
 
Resume_Sanket_S_Manjrekar - Software Developer
Resume_Sanket_S_Manjrekar - Software DeveloperResume_Sanket_S_Manjrekar - Software Developer
Resume_Sanket_S_Manjrekar - Software Developer
 
Transform Your Data Integration Platform From Informatica To ODI
Transform Your Data Integration Platform From Informatica To ODI Transform Your Data Integration Platform From Informatica To ODI
Transform Your Data Integration Platform From Informatica To ODI
 
MongoDB
MongoDBMongoDB
MongoDB
 
Presentation- on OIM
Presentation- on OIMPresentation- on OIM
Presentation- on OIM
 
Java applications developer responsibilities and duties
Java applications developer responsibilities and dutiesJava applications developer responsibilities and duties
Java applications developer responsibilities and duties
 
ClustrixDB at Samsung Cloud
ClustrixDB at Samsung CloudClustrixDB at Samsung Cloud
ClustrixDB at Samsung Cloud
 
Java Technical Design Document
Java Technical Design DocumentJava Technical Design Document
Java Technical Design Document
 
0228 2 sample_distribution
0228 2 sample_distribution0228 2 sample_distribution
0228 2 sample_distribution
 
Wakanda: NoSQL for Model-Driven Web applications - NoSQL matters 2012
Wakanda: NoSQL for Model-Driven Web applications - NoSQL matters 2012Wakanda: NoSQL for Model-Driven Web applications - NoSQL matters 2012
Wakanda: NoSQL for Model-Driven Web applications - NoSQL matters 2012
 
Packer, Terraform, Vault를 이용해 만드는 
재현 가능한 게임 인프라
Packer, Terraform, Vault를 이용해 만드는 
재현 가능한 게임 인프라Packer, Terraform, Vault를 이용해 만드는 
재현 가능한 게임 인프라
Packer, Terraform, Vault를 이용해 만드는 
재현 가능한 게임 인프라
 
Domain Driven Design & Hexagonal Architecture
Domain Driven Design & Hexagonal ArchitectureDomain Driven Design & Hexagonal Architecture
Domain Driven Design & Hexagonal Architecture
 
Maximizing MongoDB Performance on AWS
Maximizing MongoDB Performance on AWSMaximizing MongoDB Performance on AWS
Maximizing MongoDB Performance on AWS
 
Real-time Data Processing with Amazon DynamoDB Streams and AWS Lambda
Real-time Data Processing with Amazon DynamoDB Streams and AWS LambdaReal-time Data Processing with Amazon DynamoDB Streams and AWS Lambda
Real-time Data Processing with Amazon DynamoDB Streams and AWS Lambda
 
What is performance_engineering_v0.2
What is performance_engineering_v0.2What is performance_engineering_v0.2
What is performance_engineering_v0.2
 
Apresentação Banco de Dados - Caché
Apresentação Banco de Dados - CachéApresentação Banco de Dados - Caché
Apresentação Banco de Dados - Caché
 
AWS Batch를 통한 손쉬운 일괄 처리 작업 관리하기 - 윤석찬 (AWS 테크에반젤리스트)
AWS Batch를 통한 손쉬운 일괄 처리 작업 관리하기 - 윤석찬 (AWS 테크에반젤리스트)AWS Batch를 통한 손쉬운 일괄 처리 작업 관리하기 - 윤석찬 (AWS 테크에반젤리스트)
AWS Batch를 통한 손쉬운 일괄 처리 작업 관리하기 - 윤석찬 (AWS 테크에반젤리스트)
 
Alfresco ECM e Gestão Eletrônica de Documentos Open Source
Alfresco ECM e Gestão Eletrônica de Documentos Open SourceAlfresco ECM e Gestão Eletrônica de Documentos Open Source
Alfresco ECM e Gestão Eletrônica de Documentos Open Source
 
Abhilash resume
Abhilash resumeAbhilash resume
Abhilash resume
 
Anil purswani Resume
Anil purswani ResumeAnil purswani Resume
Anil purswani Resume
 

Ähnlich wie Steht alles im Wiki? Das kleine 1x1 der Architekturdokumentation

Verunfallte Softwarearchitektur. Erfolgreiche Lösungen höchstens per Zufall?
Verunfallte Softwarearchitektur. Erfolgreiche Lösungen höchstens per Zufall?Verunfallte Softwarearchitektur. Erfolgreiche Lösungen höchstens per Zufall?
Verunfallte Softwarearchitektur. Erfolgreiche Lösungen höchstens per Zufall?
embarc Software Consulting GmbH
 
Architekturbewertung
ArchitekturbewertungArchitekturbewertung
Architekturbewertung
Brockhaus Consulting GmbH
 
Softwarequalität - Architektur
Softwarequalität - ArchitekturSoftwarequalität - Architektur
Softwarequalität - Architektur
Gerrit Beine
 
Mehr Softwarequalität: Team-Cleancoding
Mehr Softwarequalität: Team-CleancodingMehr Softwarequalität: Team-Cleancoding
TAG2015: ArchiteKultur – wie bekommen wir Architekturarbeit in den Alltag rei...
TAG2015: ArchiteKultur – wie bekommen wir Architekturarbeit in den Alltag rei...TAG2015: ArchiteKultur – wie bekommen wir Architekturarbeit in den Alltag rei...
TAG2015: ArchiteKultur – wie bekommen wir Architekturarbeit in den Alltag rei...
Matthias Bohlen
 
Vorgehensmodelle - Methoden der Wirtschaftsinformatik
Vorgehensmodelle - Methoden der WirtschaftsinformatikVorgehensmodelle - Methoden der Wirtschaftsinformatik
Vorgehensmodelle - Methoden der Wirtschaftsinformatik
Claus Brell
 
Everything's connected
Everything's connectedEverything's connected
Everything's connected
Philipp Schneider
 
Analyse-Methodik
Analyse-MethodikAnalyse-Methodik
Analyse-Methodik
Christoph Santschi
 
Mehr Softwarequalität: Team Clean Coding
Mehr Softwarequalität: Team Clean CodingMehr Softwarequalität: Team Clean Coding
Illik verteilte systeme
Illik verteilte systemeIllik verteilte systeme
Templates, Code & Tools
Templates, Code & ToolsTemplates, Code & Tools
Templates, Code & Tools
Ulrich Krause
 
Sdv 0405 design-pattern_thc_jps_skript
Sdv 0405 design-pattern_thc_jps_skriptSdv 0405 design-pattern_thc_jps_skript
Sdv 0405 design-pattern_thc_jps_skript
Tomasz Waszczyk
 
Sdv 0405 design-pattern_thc_jps_skript
Sdv 0405 design-pattern_thc_jps_skriptSdv 0405 design-pattern_thc_jps_skript
Sdv 0405 design-pattern_thc_jps_skript
Tomasz Waszczyk
 
Top 10 Internet Trends 2001
Top 10 Internet Trends 2001Top 10 Internet Trends 2001
Top 10 Internet Trends 2001
Jürg Stuker
 
Agile UX, Ideation and Scrum Workshop, ditact Nov 2013 (German)
Agile UX, Ideation and Scrum Workshop, ditact Nov 2013 (German)Agile UX, Ideation and Scrum Workshop, ditact Nov 2013 (German)
Agile UX, Ideation and Scrum Workshop, ditact Nov 2013 (German)
Renate Pinggera
 
Der Enterprise-Java-Architekt – eine aussterbende Gattung!?
Der Enterprise-Java-Architekt – eine aussterbende Gattung!?Der Enterprise-Java-Architekt – eine aussterbende Gattung!?
Der Enterprise-Java-Architekt – eine aussterbende Gattung!?
OPEN KNOWLEDGE GmbH
 
system worx: Wie Open Source Software zur Optimierung von Geschäftsprozessen ...
system worx: Wie Open Source Software zur Optimierung von Geschäftsprozessen ...system worx: Wie Open Source Software zur Optimierung von Geschäftsprozessen ...
system worx: Wie Open Source Software zur Optimierung von Geschäftsprozessen ...
AKJoom
 

Ähnlich wie Steht alles im Wiki? Das kleine 1x1 der Architekturdokumentation (20)

Verunfallte Softwarearchitektur. Erfolgreiche Lösungen höchstens per Zufall?
Verunfallte Softwarearchitektur. Erfolgreiche Lösungen höchstens per Zufall?Verunfallte Softwarearchitektur. Erfolgreiche Lösungen höchstens per Zufall?
Verunfallte Softwarearchitektur. Erfolgreiche Lösungen höchstens per Zufall?
 
Architekturbewertung
ArchitekturbewertungArchitekturbewertung
Architekturbewertung
 
Softwarequalität - Architektur
Softwarequalität - ArchitekturSoftwarequalität - Architektur
Softwarequalität - Architektur
 
Mehr Softwarequalität: Team-Cleancoding
Mehr Softwarequalität: Team-CleancodingMehr Softwarequalität: Team-Cleancoding
Mehr Softwarequalität: Team-Cleancoding
 
TAG2015: ArchiteKultur – wie bekommen wir Architekturarbeit in den Alltag rei...
TAG2015: ArchiteKultur – wie bekommen wir Architekturarbeit in den Alltag rei...TAG2015: ArchiteKultur – wie bekommen wir Architekturarbeit in den Alltag rei...
TAG2015: ArchiteKultur – wie bekommen wir Architekturarbeit in den Alltag rei...
 
Vorgehensmodelle - Methoden der Wirtschaftsinformatik
Vorgehensmodelle - Methoden der WirtschaftsinformatikVorgehensmodelle - Methoden der Wirtschaftsinformatik
Vorgehensmodelle - Methoden der Wirtschaftsinformatik
 
Everything's connected
Everything's connectedEverything's connected
Everything's connected
 
Analyse-Methodik
Analyse-MethodikAnalyse-Methodik
Analyse-Methodik
 
Mehr Softwarequalität: Team Clean Coding
Mehr Softwarequalität: Team Clean CodingMehr Softwarequalität: Team Clean Coding
Mehr Softwarequalität: Team Clean Coding
 
Illik verteilte systeme
Illik verteilte systemeIllik verteilte systeme
Illik verteilte systeme
 
Zwischenstand
ZwischenstandZwischenstand
Zwischenstand
 
Templates, Code & Tools
Templates, Code & ToolsTemplates, Code & Tools
Templates, Code & Tools
 
Jazz
JazzJazz
Jazz
 
Sdv 0405 design-pattern_thc_jps_skript
Sdv 0405 design-pattern_thc_jps_skriptSdv 0405 design-pattern_thc_jps_skript
Sdv 0405 design-pattern_thc_jps_skript
 
Sdv 0405 design-pattern_thc_jps_skript
Sdv 0405 design-pattern_thc_jps_skriptSdv 0405 design-pattern_thc_jps_skript
Sdv 0405 design-pattern_thc_jps_skript
 
Top 10 Internet Trends 2001
Top 10 Internet Trends 2001Top 10 Internet Trends 2001
Top 10 Internet Trends 2001
 
Agile UX, Ideation and Scrum Workshop, ditact Nov 2013 (German)
Agile UX, Ideation and Scrum Workshop, ditact Nov 2013 (German)Agile UX, Ideation and Scrum Workshop, ditact Nov 2013 (German)
Agile UX, Ideation and Scrum Workshop, ditact Nov 2013 (German)
 
It Projekte
It  ProjekteIt  Projekte
It Projekte
 
Der Enterprise-Java-Architekt – eine aussterbende Gattung!?
Der Enterprise-Java-Architekt – eine aussterbende Gattung!?Der Enterprise-Java-Architekt – eine aussterbende Gattung!?
Der Enterprise-Java-Architekt – eine aussterbende Gattung!?
 
system worx: Wie Open Source Software zur Optimierung von Geschäftsprozessen ...
system worx: Wie Open Source Software zur Optimierung von Geschäftsprozessen ...system worx: Wie Open Source Software zur Optimierung von Geschäftsprozessen ...
system worx: Wie Open Source Software zur Optimierung von Geschäftsprozessen ...
 

Mehr von oose

Tiefkühlpizza Softwaretesten und der Mann im Mond
Tiefkühlpizza Softwaretesten und der Mann im Mond Tiefkühlpizza Softwaretesten und der Mann im Mond
Tiefkühlpizza Softwaretesten und der Mann im Mond
oose
 
Management -Das ist sowas von 2019!
Management -Das ist sowas von 2019!Management -Das ist sowas von 2019!
Management -Das ist sowas von 2019!
oose
 
oose. Nein sagen
oose. Nein sagenoose. Nein sagen
oose. Nein sagen
oose
 
Wertstiftender Agile Coach - Auszug aus KompetenzNavigator 1. Halbjahr
Wertstiftender Agile Coach - Auszug aus KompetenzNavigator 1. HalbjahrWertstiftender Agile Coach - Auszug aus KompetenzNavigator 1. Halbjahr
Wertstiftender Agile Coach - Auszug aus KompetenzNavigator 1. Halbjahr
oose
 
Feedback geben und nehmen - Abendvortrag_revised
Feedback geben und nehmen - Abendvortrag_revisedFeedback geben und nehmen - Abendvortrag_revised
Feedback geben und nehmen - Abendvortrag_revised
oose
 
Feedback geben und nehmen | oose-Vortragsfolien
Feedback geben und nehmen | oose-VortragsfolienFeedback geben und nehmen | oose-Vortragsfolien
Feedback geben und nehmen | oose-Vortragsfolien
oose
 
Gehaltsmodell in Selbstorganisation
Gehaltsmodell in SelbstorganisationGehaltsmodell in Selbstorganisation
Gehaltsmodell in Selbstorganisation
oose
 
Haqoona matata - Die Digitalisierung lebenslangen Lernens
Haqoona matata - Die Digitalisierung lebenslangen LernensHaqoona matata - Die Digitalisierung lebenslangen Lernens
Haqoona matata - Die Digitalisierung lebenslangen Lernens
oose
 
Personalarbeit in selbstorganisierten Teams
Personalarbeit in selbstorganisierten TeamsPersonalarbeit in selbstorganisierten Teams
Personalarbeit in selbstorganisierten Teams
oose
 
Psychologisch sichere Teams | oose-Vortragsfolien
Psychologisch sichere Teams | oose-VortragsfolienPsychologisch sichere Teams | oose-Vortragsfolien
Psychologisch sichere Teams | oose-Vortragsfolien
oose
 
Das Prinzip Verantwortung in selbstorganisierten Teams
Das Prinzip Verantwortung in selbstorganisierten TeamsDas Prinzip Verantwortung in selbstorganisierten Teams
Das Prinzip Verantwortung in selbstorganisierten Teams
oose
 
Wertstiftender Agile Coach - Ausbildung
Wertstiftender Agile Coach - AusbildungWertstiftender Agile Coach - Ausbildung
Wertstiftender Agile Coach - Ausbildung
oose
 
Gehalt und Selbstorganisation: Gehalt neu denken
Gehalt und Selbstorganisation: Gehalt neu denkenGehalt und Selbstorganisation: Gehalt neu denken
Gehalt und Selbstorganisation: Gehalt neu denken
oose
 
Das kleine Einmaleins des agilen Produktmanagements
Das kleine Einmaleins des agilen Produktmanagements Das kleine Einmaleins des agilen Produktmanagements
Das kleine Einmaleins des agilen Produktmanagements
oose
 
DMN - Was gibt es da zu Entscheiden?
DMN - Was gibt es da zu Entscheiden?DMN - Was gibt es da zu Entscheiden?
DMN - Was gibt es da zu Entscheiden?
oose
 
Schöner scheitern – Die beliebtesten Missverständnisse im agilen RE
Schöner scheitern – Die beliebtesten Missverständnisse im agilen RESchöner scheitern – Die beliebtesten Missverständnisse im agilen RE
Schöner scheitern – Die beliebtesten Missverständnisse im agilen RE
oose
 
DMN – Was gibt es da zu entscheiden?
 DMN – Was gibt es da zu entscheiden? DMN – Was gibt es da zu entscheiden?
DMN – Was gibt es da zu entscheiden?
oose
 
MARTE – UML für eingebettete Systeme
MARTE – UML für eingebettete SystemeMARTE – UML für eingebettete Systeme
MARTE – UML für eingebettete Systeme
oose
 
A World In Motion
A World In MotionA World In Motion
A World In Motion
oose
 
Produktvarianten mit SysML/UML modellieren
Produktvarianten mit SysML/UML modellierenProduktvarianten mit SysML/UML modellieren
Produktvarianten mit SysML/UML modellieren
oose
 

Mehr von oose (20)

Tiefkühlpizza Softwaretesten und der Mann im Mond
Tiefkühlpizza Softwaretesten und der Mann im Mond Tiefkühlpizza Softwaretesten und der Mann im Mond
Tiefkühlpizza Softwaretesten und der Mann im Mond
 
Management -Das ist sowas von 2019!
Management -Das ist sowas von 2019!Management -Das ist sowas von 2019!
Management -Das ist sowas von 2019!
 
oose. Nein sagen
oose. Nein sagenoose. Nein sagen
oose. Nein sagen
 
Wertstiftender Agile Coach - Auszug aus KompetenzNavigator 1. Halbjahr
Wertstiftender Agile Coach - Auszug aus KompetenzNavigator 1. HalbjahrWertstiftender Agile Coach - Auszug aus KompetenzNavigator 1. Halbjahr
Wertstiftender Agile Coach - Auszug aus KompetenzNavigator 1. Halbjahr
 
Feedback geben und nehmen - Abendvortrag_revised
Feedback geben und nehmen - Abendvortrag_revisedFeedback geben und nehmen - Abendvortrag_revised
Feedback geben und nehmen - Abendvortrag_revised
 
Feedback geben und nehmen | oose-Vortragsfolien
Feedback geben und nehmen | oose-VortragsfolienFeedback geben und nehmen | oose-Vortragsfolien
Feedback geben und nehmen | oose-Vortragsfolien
 
Gehaltsmodell in Selbstorganisation
Gehaltsmodell in SelbstorganisationGehaltsmodell in Selbstorganisation
Gehaltsmodell in Selbstorganisation
 
Haqoona matata - Die Digitalisierung lebenslangen Lernens
Haqoona matata - Die Digitalisierung lebenslangen LernensHaqoona matata - Die Digitalisierung lebenslangen Lernens
Haqoona matata - Die Digitalisierung lebenslangen Lernens
 
Personalarbeit in selbstorganisierten Teams
Personalarbeit in selbstorganisierten TeamsPersonalarbeit in selbstorganisierten Teams
Personalarbeit in selbstorganisierten Teams
 
Psychologisch sichere Teams | oose-Vortragsfolien
Psychologisch sichere Teams | oose-VortragsfolienPsychologisch sichere Teams | oose-Vortragsfolien
Psychologisch sichere Teams | oose-Vortragsfolien
 
Das Prinzip Verantwortung in selbstorganisierten Teams
Das Prinzip Verantwortung in selbstorganisierten TeamsDas Prinzip Verantwortung in selbstorganisierten Teams
Das Prinzip Verantwortung in selbstorganisierten Teams
 
Wertstiftender Agile Coach - Ausbildung
Wertstiftender Agile Coach - AusbildungWertstiftender Agile Coach - Ausbildung
Wertstiftender Agile Coach - Ausbildung
 
Gehalt und Selbstorganisation: Gehalt neu denken
Gehalt und Selbstorganisation: Gehalt neu denkenGehalt und Selbstorganisation: Gehalt neu denken
Gehalt und Selbstorganisation: Gehalt neu denken
 
Das kleine Einmaleins des agilen Produktmanagements
Das kleine Einmaleins des agilen Produktmanagements Das kleine Einmaleins des agilen Produktmanagements
Das kleine Einmaleins des agilen Produktmanagements
 
DMN - Was gibt es da zu Entscheiden?
DMN - Was gibt es da zu Entscheiden?DMN - Was gibt es da zu Entscheiden?
DMN - Was gibt es da zu Entscheiden?
 
Schöner scheitern – Die beliebtesten Missverständnisse im agilen RE
Schöner scheitern – Die beliebtesten Missverständnisse im agilen RESchöner scheitern – Die beliebtesten Missverständnisse im agilen RE
Schöner scheitern – Die beliebtesten Missverständnisse im agilen RE
 
DMN – Was gibt es da zu entscheiden?
 DMN – Was gibt es da zu entscheiden? DMN – Was gibt es da zu entscheiden?
DMN – Was gibt es da zu entscheiden?
 
MARTE – UML für eingebettete Systeme
MARTE – UML für eingebettete SystemeMARTE – UML für eingebettete Systeme
MARTE – UML für eingebettete Systeme
 
A World In Motion
A World In MotionA World In Motion
A World In Motion
 
Produktvarianten mit SysML/UML modellieren
Produktvarianten mit SysML/UML modellierenProduktvarianten mit SysML/UML modellieren
Produktvarianten mit SysML/UML modellieren
 

Steht alles im Wiki? Das kleine 1x1 der Architekturdokumentation

  • 1. Impulsvortrag: Steht alles im Wiki? Das kleine 1x1 der Architekturdokumentation Stefan Zörner, oose Innovative Informatik GmbH, Hamburg Gesellschaft für Informatik e.V., Regionalgruppe Dortmund, 04.10.2010
  • 2. Zusammenfassung Steht alles im Wiki? Das kleine 1x1 der Architekturdokumentation Architekturdokumentation wird oft als lästige Pflicht angesehen. Dabei ermöglicht das angemessene Festhalten die Kommunikation Ihrer Konzepte im Team und dem Auftraggeber gegenüber überhaupt erst. Der Vortrag stellt anhand konkreter Beispiele bewährte Arbeitsergebnisse und mögliche Strukturierungen vor. Häufige Herausforderungen werden ebenso diskutiert wie typische Werkzeugketten. Wiki oder UML-Tool? Oder was dazwischen? Welche Notationen haben sich in der Praxis bewähren? Und wie kommt man falls verlangt jederzeit zu einer druckbaren Dokumentation?
  • 3. Stefan Zörner, Stationen 1991-94 Ausbildung Math.-techn . Assistent bei der Bayer AG Studium Mathematik (Diplom 1998), Schwerpunkt Informatik 1998-2001 Mummert + Partner AG, Berater, u.a. Sun-Trainer 2001-2006 IBM e-business Innovation Center , IT-Architekt Seit Juli 2006: Berater und Trainer bei oose in Hamburg Schwerpunkt: Softwareentwurf und Java-Technologien [email_address] Veröffentlichungen, Vorträge Bücher „Portlets“, 2006 „ LDAP für Java-Entwickler“, 3. Auflage 2007 Artikel u.a. in Java Magazin und bei IBM developerWorks Vorträge bei JAX und W-JAX seit 2002, Advisory Board Dies und das Seit 2005 Mitarbeit im Apache Directory Project, [email_address] iSAQB Certified Professional for Software Architecture OMG Certified UML Professional (Intermediate) SpringSource Certified Spring Professional
  • 4. Agenda 1 Montag Morgen 2 Entscheidungen 3 Sichten 4 Bewerten 5 Strukturieren 6 Schluss und Aus(-blick)
  • 5. Agenda 1 Montag Morgen 2 Entscheidungen 3 Sichten 4 Bewerten 5 Strukturieren 6 Schluss und Aus(-blick)
  • 7. Fragen, die neue Mitarbeiter so stellen … ? Wie checke ich die Sourcen aus, und wie baue ich die Software? Warum sind bei mir Tests rot? Was brauche ich für Tools? Wenn ich neue Funktionalität hinzufügen soll – wie stelle ich das an? Hier ist doch schon was Ähnliches, kann ich das wiederverwenden? Was leistet das System überhaupt? Aus welchen Bestandteilen besteht die Software? Wie arbeiten diese zusammen? Ist das irgendwo beschrieben? Warum benutzt ihr noch JDK 1.3? Wieso habt Ihr das denn so gemacht? …
  • 8. Antworten, die neue Mitarbeiter daraufhin erhalten ! Steht alles im Wiki. Das haben wir nicht dokumentiert – wir gehen agil vor. Das war schon so, als ich neu war. Das ist historisch gewachsen.
  • 9. Definitionen zu Softwarearchitektur Es gibt nicht die eine allgemein akzeptierte Definition für Softwarearchitektur Das Software Engineering Institute (SEI) sammelt sogar Definitionen:  http://www.sei.cmu.edu/architecture/definitions.html
  • 10. Eine konkrete Definition Architektur :=  wichtige Entscheidungen Softwarearchitektur umfasst die Summe verschiedener wichtiger Entscheidungen über die Auswahl von Strukturelementen und deren Schnittstellen, aus denen das System zusammengesetzt ist das Verhalten und Zusammenspiel dieser Elemente den hierarchischen Aufbau von Subsystemen den zugrunde liegenden Architekturstil … G. Booch, P. Krutchen, K. Bittner and R. Reitman. The Rational Unified Process — AnIntroduction. 1999.
  • 11. Agenda 1 Montag Morgen 2 Entscheidungen 3 Sichten 4 Bewerten 5 Strukturieren 6 Schluss und Aus(-blick)
  • 12. Architekturentscheidungen … Zitat zu Architekturentscheidung (Woods) : Die, die wenn falsch Architekturentscheidungen sind diejenigen, die sich im weiteren Verlauf nur sehr schwer revidieren lassen. Konsequenzen: höhere Kosten, Zeitverlust, ggf. scheitert das Vorhaben “ Software architecture is the set of design decisions which, if made incorrectly, may cause your project to be cancelled.” ( Eoin Woods )
  • 13. Entscheidungen treffen und festhalten. Ein Werkzeug
  • 14. Fragestellung, Rahmenbedingungen Fragestellung – Leitfragen Was genau ist das Problem? Warum ist es für die Architektur relevant? Welche Auswirkung hat die Entscheidung? Rahmenbedingungen – Leitfragen Welche festen Randbedingungen haben wir einzuhalten? Welche Einflussfaktoren sind zu beachten?
  • 15. Annahmen Annahmen – Leitfragen Welche Annahmen haben wir getroffen? Welche Annahmen können wie vorab überprüft werden? Mit welchen Risiken müssen wir rechnen? “ The life of a software architect is a long and rapid succession of suboptimal design decisions taken partly in the dark.” ( Philippe Kruchten )
  • 16. Betrachtete Alternativen, Entscheidung Betrachtete Alternativen – Leitfragen Welche Lösungsoptionen ziehen wir in die nähere Auswahl? Wie bewerten wir jede einzelne? Welche Optionen schließen wir bewusst aus? Entscheidung – Leitfragen Wer hat die Entscheidung getroffen? Wie ist sie begründet? Wann wurde entschieden?
  • 18. Agenda 1 Montag Morgen 2 Entscheidungen 3 Sichten 4 Bewerten 5 Strukturieren 6 Schluss und Aus(-blick)
  • 21. Analogie zur Softwarearchitektur: Views (Sichten) Es ist sinnvoll, bestimmte Aspekte einer Software mit Bilder statt textuell zu beschreiben Ein einzelnes Bild reicht in der Regel nicht aus Unterschiedliche Sichten für unterschiedliche Aspekte Beispiel: Rational Unified Process ( P. Kruchten ) 4 + 1 Views: Logical View Development View Process View Physical View Scenarios
  • 22. Literaturtipp zu dem Thema: Dort beschriebene Sichten (u.a.) Kontextsicht Bausteinsicht (= Struktur) Laufzeitsicht (= Verhalten, Dynamik) Verteilungssicht Effektive Software-Architekturen Ein praktischer Leitfaden von Gernot Starke 449 Seiten, Hanser Fachbuch; 4. Auflage (2009) ISBN 978-3446420083
  • 23. Die Kontextsicht – Software agiert nicht allein … Systemkontextdiagramm: Visualisierung des Umfelds das zu beschreibende System im Mittelpunkt als Blackbox drum herum die direkt beteiligten Benutzer und Fremdsysteme Verbindung zwischen einem solchen Akteur und dem System drückt Interaktion aus. Der Kontextsicht zeigt das Umfeld, d.h. alle außerhalb des eigenen Systems liegenden Akteure, mit denen direkt kommuniziert wird. Stets gibt es Beteiligte außerhalb des Systems: Anwendergruppen, die Funktionalität nutzen und erwarten Fremdsysteme, die zur Ausführung erforderlich sind
  • 24. Fallbeispiel: Apache Tomcat Apache Tomcat ist ein in Java geschriebener Webapplikationsserver zum Betreiben Java EE-konformer Webapplikationen.  http://tomcat.apache.org
  • 25. Eine Kontextsicht für Apache Tomcat in UML.
  • 26. Warum ist das so wichtig? Potenzielle Schnittstellen zum Zielsystem finden! Sie Anbindung eines Fremdsystems ist regelmäßig ein technisches Risiko. Solche frühzeitig zu erkennen kann entscheidend sein für den Erfolg Ihres Projektes. Architekturentscheidungen ableiten. Startpunkt, um Verantwortlichkeiten zu klären Welche Fremdsysteme müssen wir integrieren? Was leistet unser System, und vor allem: was leistet es nicht? Wo ist die Systemgrenze?
  • 28. Die Bausteinsicht „ Die Bausteinsicht bildet die Funktionalität des Systems auf Software- oder Implementierungsbausteine ab. Die Sicht macht Struktur und Zusammenhänge zwischen den Bausteinen der Struktur explizit “ (G. Starke) Beispiel (UML, Kompositionsstrukturdiagramm)
  • 31. Zusammenspiel Kontextsicht / Bausteinsicht Blackbox Whitebox
  • 34. Die Laufzeitsicht – In Bewegung Die Bausteinsicht bietet lediglich eine statische Sicht Oft bringt erst die Zusammenschau mit dynamischen Aspekten Einsichten, wie das System eigentlich funktioniert, bzw. zu verwenden oder zu erweitern ist. Die Laufzeitsicht (alternativ: Verhaltenssicht) beschreibt, wie Softwareelemente zur Laufzeit interagieren, bzw. wie ein Element selbst sich verhält. Laufzeitsicht und UML Die UML bietet verschiedene Modellelemente und Diagrammtypen für die Laufzeitsicht an, z.B. Aktivitätsdiagramm Sequenzdiagramm Zustandsdiagramm
  • 35. Beispiel: Apache Tomcat Implementierung einer eigenen Tomcat -Komponente Tomcat kennt verschiedene Abstraktionen, die gewollte Erweiterungspunkte darstellen (z.B. Connector, Realm ) Frage: Wie dokumentiert man die Implementierung von Erweiterungen? „ Ein Design sollte offen für Erweiterungen, aber geschlossen für Änderungen sein.“ ( Open Closed Principle ) Bertrand Meyer 1988 Beispiel: Valve Ein Valve (dt. "Ventil") ist eine Anfragen verarbeitende Komponente, die mit einem Container assoziiert ist. Üblicherweise bilden eine Kette von Valves eine Pipeline (d.h. ein Valve kennt seinen Nachfolger).
  • 38. Die Verteilungssicht – Ja wo laufen sie denn? Die bisherigen Sichten blenden Betriebsaspekte völlig aus. Wie verteilt sich die Lösung auf z.B. auf unterschiedliche Rechner? Die Verteilungssicht beschreibt, welche physikalischen Informationseinheiten (Jar-Files, DLLs, ...) im Rahmen des Entwicklungsprozesses erstellt bzw. benötigt werden, welche Komponenten sie manifestieren, und wie sie für den Betrieb zu verteilen sind. Verteilungssicht und UML Die UML bietet eigene Modellelemente und ein Diagramm für die Verteilungssicht an Verteilungsdiagramm Knoten, Artefakte
  • 39. Beispiel: Apache Tomcat Konkret bei Tomcat: Tomcat wird in reichlich JAR-Files ( J ava Ar chive) ausgeliefert Wenn ich nur Teile von Tomcat verwenden möchte (z.B. nur den JSP Compiler), welche JAR-Files werden benötigt? Wenn neue Komponenten realisiert werden (z.B. eine Valve ), wogegen muss kompiliert werden? Allgemeine Fragen: Welche Deployment Units (JARs, DLLs, SOs, …) manifestieren welche Bausteine? Welche Deployment Units müssen wo installiert werden (z.B. bei Client Server) Beispiel 1: Welche Deployment Units brauche ich für was?
  • 41. UML Deployment Diagram Beispiel 2: Szenario: Tomcat + Apache HTTP Server
  • 42. Agenda 1 Montag Morgen 2 Entscheidungen 3 Sichten 4 Bewerten 5 Strukturieren 6 Schluss und Aus(-blick)
  • 43. Architekturbewertung: Reflektieren bevor man dokumentiert… Meeting Feedback Review Workshop Kommunikation Planung Priorisierung Zusammenarbeit Kundenorientierung Präsentation Risikominderung Transparenz Qualitätssicherung Flexibilität Zentrale Frage: Erreicht man die geforderte Qualitätsmerkmale mit den getroffenen Entscheidungen?
  • 45. Entscheidungen vor / im / nach dem Workshop festhalten
  • 46. Qualitätsanforderungen dokumentieren © by oose innovative Informatik GmbH Performanz ist superwichtig! Qualitätsmerkmale für die Umsetzung spezifischer zu formulieren hilft: beim Treffen von Design-Entscheidungen bei der Priorisierung der Qualitätsmerkmale bei der Bewertung von Entscheidungen
  • 47. Möglichkeiten Qualitätsanforderungen zu beschreiben © by oose innovative Informatik GmbH
  • 48. Szenarien © by oose innovative Informatik GmbH Szenarien Ein entfernter Benutzer sendet bei Hochauslastung eine Anfrage für einen Datenbank-Report über das Internet und erhält den Report innerhalb von 5 Sekunden. Ein Szenario ist ein Beispiel für die Verwendung des Systems Ein Szenario ist eine „Manifestation“ eines Qualitätsmerkmals Ein Szenario ist überprüfbar (zumindest theoretisch) Ein Szenario gibt dem „Umsetzer“ Anforderungen auf richtigem Niveau
  • 49. © by oose innovative Informatik GmbH Ein entfernter Benutzer sendet bei Hochauslastung eine Anfrage für einen Datenbank-Report über das Internet und erhält den Report innerhalb von 5 Sekunden. Mögliche Teile eines Szenarios
  • 50. Entscheidungen im Kontext Die Verbindung zwischen Rahmenbedingungen, Anforderungen und Architekturentscheidungen ist essenziell! Durch die Verbindung können Änderungen in ihren Auswirkungen abgeschätzt werden weniger aufwändig durchgeführt werden (und konsistent erfolgen)
  • 51. Architekturbewertung – keine Noten aber mehr Durchblick http://it-republik.de/business-technology/
  • 52. Agenda 1 Montag Morgen 2 Entscheidungen 3 Sichten 4 Bewerten 5 Strukturieren 6 Schluss und Aus(-blick)
  • 53. arc42 – Vorschlag für ein Template http://arc42.de/ (Gernot Starke, Peter Hruschka)
  • 54. Struktur des Templates
  • 55. Es muss nicht immer ein digitales Tool sein ...
  • 56. Übungsergebnisse aus einem oose-Seminar zu Softwarearchitektur
  • 57. UML = Unified Modeling Language etablierte, standardisierte Notation im Bereich Software-Engineering  http://www.uml.org/ Primäre Disziplinen: Analyse Entwurf / Architektur umfangreich, 14 Diagrammtypen
  • 58. Diagramme == Sichten auf ein Modell
  • 59. Und im Wiki? Nachvollziehbarkeit von Ergänzungen und Änderungen Autor, Historie, … Benachrichtigungen Freies Verknüpfen von Inhalten (Links, Tags Leicht zugänglich für das ganze Team (kein spezieller Client) Lädt zum Kommentieren ein „ Wikis ermöglichen das gemeinschaftliche Arbeiten an Texten. Ziel eines Wikis ist es im Allgemeinen, die Erfahrung und den Wissensschatz der Autoren kollaborativ auszudrücken.“ wikipedia.de Generell ein tolles Medium für Entwicklungsprojekte, um untereinander zu kommunizieren.
  • 60. arc42 in einem Wiki?
  • 61. Herausforderungen Versionierung Wikis führen Versionen für einzelne Seiten Wie versioniert man die Dokumentation vollständig, z.B. für ein Release? Diagramme Wie erstellt man Abbildungen im bzw. für das Wiki Wie hält man Abbildungen und Textinhalte konsistent? Drucken Wie gibt man die Dokumentation aus dem Wiki als Dokument (z.B. PDF) heraus? Wie befüllt man eine vorgegebene Struktur?
  • 63. Agenda 1 Montag Morgen 2 Entscheidungen 3 Sichten 4 Bewerten 5 Strukturieren 6 Schluss und Aus(-blick)
  • 64. Früher kaufte man Software im Laden in einem Karton …
  • 66. Projektteams brauchen ein gemeinsames Ziel, eine Vision Was entwickeln wir eigentlich? Was ist die Idee des Systems? Wem nützt es? Wie unterscheidet es sich von Produkten der Mitbewerber? Es ist eine Ihrer Aufgaben als Softwarearchitekt, die Idee des Systems im Entwicklungsteamteam zu verankern.
  • 68. Machen Sie die Systemidee explizit! Machen Sie die Systemidee explizit!
  • 69. Systemidee auf der Startseite des Projekt- Wikis …
  • 70. Virtuellen Produktkarton erstellen z.B.  http://www.wikihow.com/Create-a-Product-Box-in-Photoshop
  • 71. Systemkontext und Systemidee Was steckt drin? Was ist drum herum?
  • 72. Kolumne „Architekturen dokumentieren“ Java Magazin, 10.2008 – 09.2009 http://javamagazin.de/
  • 73. Auch im Web http://it-republik.de/jaxenter/
  • 74. Vielen Dank! Ich freue mich auf Ihre Fragen … ? ? ? Stefan Zörner :: Stefan.Zoerner@oose.de

Hinweis der Redaktion

  1. Eine Tanznotation ist die symbolische Repräsentation von Tanzbewegungen.
  2. Statische Sicht. Das Dillema: In welcher Reihenfolge werden die Lifecycle-Methoden von Lifecycle und Valve aufgerufen?
  3. Spring-/Hibernate-Benutzer kennen das Problem vielleicht auch: Bergeweise jar-Files, und man hat keine Ahnung, wofür das alles gut ist, und ob man das braucht (OSGi und Maven gibt es ja nicht von ungefähr)
  4. Solche Diagramme können erhellen. Ein Artefakt repräsentiert eine physikalische Informationseinheit, die während der Softwareentwicklung benötigt bzw. erstellt wird. Eine Manifestation verbindet ein Modellelement mit einem Artefakt. Das Artefakt ist die physikalische Manifestation des Modellelementes.
  5. Man sieht, es sind teilweise ähnliche Ziele wie bei Dokumentation auch: Kommunikation, Transparenz. Architekturbewertung fördert Dokumentation im Vorfeld (Man braucht Artefakte um Entscheidungen und Anforderungen zu vermitteln) Architekturbewertung sorgt dafür dass wichtige, dokumentierte Dinge auch reflektiert wurden bevor sie dokumentiert werden und damit in Stein gemeißelt sind (ansonsten: Buße tun, abschließen) Architekturbewertung nimmt Dokumentation die alleinige Last der Kommunikation von Entscheidungen
  6. Szenarien: gute Anforderungen wo sie oft nicht sind: bei Qualitätsmerkmalen Bewertungs-Workshop: Erfahrung und Know-How teilen und multiplizieren, Anforderungen nochmals schärfen und sofortiges Feedback von ALLEN Stakeholdern Feedback von Ergebnissen: nicht nur in Software-Architektur, sondern auch in Anforderungs- und Kundenprozess Outputs müssen natürlich auch wieder dokumentiert werden und vervollständigen meist die Dokumentation von Entscheidungen…
  7. Zweierlei Werkzeug: Methodik zum Treffen von Entscheidungen Struktur zum Festhalten von Entscheidungen – Formatvorlage für Word, Wiki etc.
  8. Auf einer Vielzahl von Webseiten finden sich virtuelle Produktkartons. Beispiel : Homepage von Apache ActiveMQ Als Open Source Middleware ist es ein besonders interessanter Vertreter, da man diese Software gar nicht käuflich erwerben kann, und sie als Software-Infrastruktur-Komponente für Außenstehende auch schwer zu begreifen ist (es gibt nichts zu klicken). Durch den Karton bekommt die Lösung trotzdem etwas Gegenständliches, sie erscheint fassbarer.