Gewachsene Architektur Das kann nicht funktionieren!

Advanced Developers Conference 10.-11. Oktober 2004 Vorstellung Thomas Schissler Software-Architekt bei Wasserfall & Co Schwerpunkte sind UML V-Modell Architekturkonzepte Blog : http://www.artiso.com/problog Kontakt: Tschissler@artiso.com Thomas Schissler - XML-Serialisierung

Advanced Developers Conference 10.-11. Oktober 2004 Gute Architektur? Thomas Schissler - XML-Serialisierung

Architektur-Probleme bei Agilität

Advanced Developers Conference 10.-11. Oktober 2004 Vorstellung Matthias Rink Scrum Teammitglied artiso AG Schwerpunkte sind WPF Task Parallel Library Neugierde auf alles Neue Blog : http://www.artiso.com/problog Kontakt: MRink@artiso.com Thomas Schissler - XML-Serialisierung

Gewachsene Architektur Wie funktioniert es doch?

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

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

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

Komponentenorientierte Architektur

Contracts Data Contract Component Contract

Implementierung Komponente

Inversion of Control (IoC) Constructor Injection

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

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

Open Closed Principle Closed Interface Open Features

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)

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

Technologien fordern Patterns WCF fordert Trennung Daten und Funktionalität

Technologien fordern Patterns Workflow Foundation: Zustandslose Komponten

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

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

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

Modellgetriebene Entwicklung

Modellgetriebene Entwicklung

Modellgetriebene Entwicklung

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

Danke für ihre Aufmerksamkeit ? Noch Fragen? Gerne auch später unter MRink@artiso.com oder TSchissler@artiso.com