Gewachsene Architektur Das kann nicht funktionieren!

Präsentation zum Thema: "Gewachsene Architektur Das kann nicht funktionieren!"—  Präsentation transkript:

1 Gewachsene Architektur Das kann nicht funktionieren!

2 Advanced Developers Conference
Oktober 2004 Vorstellung Thomas Schissler Software-Architekt bei Wasserfall & Co Schwerpunkte sind UML V-Modell Architekturkonzepte Blog : Kontakt: Thomas Schissler - XML-Serialisierung

3 Advanced Developers Conference
Oktober 2004 Gute Architektur? Thomas Schissler - XML-Serialisierung

4 Architektur-Probleme bei Agilität

5 Advanced Developers Conference
Oktober 2004 Vorstellung Matthias Rink Scrum Teammitglied artiso AG Schwerpunkte sind WPF Task Parallel Library Neugierde auf alles Neue Blog : Kontakt: Thomas Schissler - XML-Serialisierung

6 Gewachsene Architektur Wie funktioniert es doch?

7 Warum ist Architektur wichtig
Fehler vermeiden Wartbarkeit Testbarkeit Verschiedene Ausführungsumgebungen Performance Kosten für Erweiterungen niedrig halten Team-Zusammenarbeit

8 Was ist Architektur eigentlich?
Code-Ebene Modell-Ebene Technologie-Ebene

9 Code-Ebene Architektur auf Code-Ebene sind häufig Design-Patterns die jedoch nicht projektspezifisch sind Das ist das Handwerkszeug jedes Entwicklers, nicht nur des Architekten Wissensvermittlung im Team

10 Komponentenorientierte Architektur

11 Contracts Data Contract Component Contract

12 Implementierung Komponente

13 Inversion of Control (IoC)
Constructor Injection

14 Ohne IoC SavePerson referenziert konkreten DataAccess
Codeänderung an SavePerson nötig wenn statt in die Datenbank in Xml File gespeichert werden soll DataAccessSqlServer DataAccessXmlFile SavePerson

15 Mit IoC SavePerson referenziert Contract von DataAccess
Anpassung der Konfiguration des IoC Keine Änderungen am Code der Komponenten selber IoC Container IDataAccess DataAccessSqlServer SavePerson DataAccessXmlFile

16 Open Closed Principle Closed Interface Open Features

17 Technologie-Ebene Technologieauswahl
Technologie beeinfluss Architektur Technologie birgt auch Architekturrisiken (EF, TFS API, WCF und klassisches OO Customer mit Save-Methode Trennung Daten und Funktion)

18 Technologien ermöglichen Patterns
View View Model Erlaubte Abhängigkeiten Komponenten Data Binding Funktionalität aufrufen

19 Technologien fordern Patterns
WCF fordert Trennung Daten und Funktionalität

20 Technologien fordern Patterns
Workflow Foundation: Zustandslose Komponten

21 Technologien bedeuten Risiken
Risiken durch Verwendung von Technologien: Entity Framework Performance Zugehörigkeit von Tracking Entities zu Kontext über WCF Abhängigkeit von Entity Framework in gesamter Anwendung TFS API Schlechte Testbarkeit Abhängigkeiten bei Verwendung von Workitem Typ in gesamter Anwendung

22 Modell-Ebene Spezifische Architektur sind nur schwer anpassbar, Anpassungen sind aber in jedem Projekt notwendig Wie viel Modellierung, wann, wer und wie lange behalten? Modelle für Diskussion Realisierungsvision im SP2 Modelle gültig im Sprintkontext Fortlaufende Pflege lohnt sich oft nicht Automatisch generierte Modelle verwenden

23 Realisierungsvision Beispiel aus Daily Standup Tool
Abschließen von zugewiesenem Workitem Beachtung von Workflow des Workitems

24 Modellgetriebene Entwicklung

25 Modellgetriebene Entwicklung

26 Modellgetriebene Entwicklung

27 Teamorganisation Weisungsberechtigter Architekt vs. demokratisches Team Kein Code-Ownership, dadurch muss jeder im Team Architektur verstehen und anwenden können Team entwickelt gemeinsam Realisierungsvision, diese wird nicht von einem vorgegeben Neue Technologien und Patterns werden aus dem Team vorgeschlagen und demokratisch deren Nutzung beschlossen

28 Danke für ihre Aufmerksamkeit
? Noch Fragen? Gerne auch später unter oder