System Architekturen erstellen (Part 2)

Um was geht es hier?

Jeder der in einer Situation war, eine Systemarchitektur definieren zu müssen, ist auf folgende Herausforderungen gestoßen.

  • Wie komme ich zu einer System Architektur.
  • Wie kann ich meine System-Architektur dokumentieren?

Auf die erste Frage, bin ich in meinem vorherigen Eintrag eingegangen. In diesem Beitrag möchte ich auf die zweite Frage eingehen.

Wie finde ich einen ersten Entwurf einer System-Architektur

Hierfür bieten sich folgende Ansätze an:

Ausgangspunkt Vorgehen
Ein ähnliches System wurde in der Vergangenheit bereits erstellt Man startet mit der bereits verwendeten System-Architektur und passt diese an das Projekt an
Referenz-Architektur Man startet mit einer Referenzarchitektu,r für die zu unterstützende Platform. Zum Beispiel JAVA2EE
Architektur Pattern Man startet mit einem Architektur-Pattern. Ggf werden mehrere Pattern angewendet, die sich ergänzen.

Wie kann ich die System-Architektur beschreiben

Fachliche Anforderungen sind im Allgemeinen stabiler als technische Anforderungen. Stabil bedeutet, dass diese weniger volatil sind bzw. sich ändern.

Oder mit anderen Worten:
„Technologien ändern sich schneller als die fachlichen Anforderungen“

Für die System-Architektur bedeutet dies, das wir uns auf das High-Level Design beschränken.

Intermediate und Low-Level Design ersparen wir uns bei der Dokumentation.

Für die Definition und Beschreibung der wichtigsten Informationen im High-Level Design haben sich in der Praxis folgende Notation/Visualisierungen bewährt.

Die Fokus-Frage Notation
Was gehört zum System? Kontext-Diagramm
Wie trenne ich fachliche und technische Dienste? DDD Hexagon Diagramm
Wie beschreibe ich, wie die Daten verarbeitet werden? Datenfluss-Diagramm
Wie beschreibe ich, aus welchen Teilen/Komponenten mein System besteht? Struktur / Blockdiagramme
Welche Daten werden gespeicherte Datenmodelle

Für die weitere Vertiefung zur Erstellung von System-Modellen empfehle ich die Seite:
Blockdiagramme

Katgeorie:VisualPedia | Kommentare deaktiviert für System Architekturen erstellen (Part 2)

System-Architekturen erstellen (Part 1)

Um was geht es hier?

Jeder, der schon einmal in einer Situation war, eine Systemarchitektur definieren zu müssen, ist auf folgende Herausforderungen gestoßen.

  • Wie komme ich zu einer System Architektur?
  • Wie kann ich meine System-Architektur dokumentieren?

Auf die erste Frage möchte ich in diesem Beitrag eingehen und einen Leitfaden vorstellen, der den Einstieg in die Welt der System-Architekturen erleichtern soll. Auf die zweite Fragen werde ich in einem nachfolgenden Beitrag eingehen.

Big Architecture – Front up

Dies ist der  klassische Ansatz.

  • Sammeln aller Anforderungen
  • Definiere anschliessend eine System Architektur, die alle Anforderungen erfüllt.

Big-Bag Vorgehen
Abb.: Big Architecture Front – Up

In der Praxis stellen sich hierbei folgende Nachteile heraus:

  • Das Sammeln der Anforderungen erfordert zum Teil viel Zeitaufwand
  • Feedback und Beurteilung der gewählten System-Architektur erst möglich, nachdem alles umgesetzt ist.

Bessere und schnellere Erfolge erziehlt man daher mit einem agilen Ansatz.

Der agile Ansatz

Beim agilen Ansatz lautet das Prinzip:

YAGNI -> You aren’t gonna need it

Vergleiche: Dzone yagni-a-quick-introduction

Dies bedeutet, dass in der Architektur nur dann Komponenten und Subsystem eingeführt werden, wenn diese auch wirklich benötigt werden.

System-Modell schrittweise entwerfen

Abb.: Agiler Ansatz

Das Vorgehen ist hierbei wie folgt:

Schritt Tätigkeit
1 Bestimme die minimalste Menge von Features, die im ersten Schritt umgesetzt werden müssen
2 Definiere eine dazugehörige System-Architektur
3 Implementiere die System-Architektur
4 Prüfen, ob die System-Architektur die gewünschten Funktionen und Eigenschaften besitzt (Erfahrung sammeln)
5 ggf. Re-Factoring der System-Architektur
6 Definiere und bestimme die Menge der Features, die im nächsten Schritt unterstützt werden sollen/müssen.
7 Wiederhole Schritt 2 bis Schritt 6 so lange, bis alle Anforderungen/Features umgesetzt sind.

In der Praxis bedeutet dies, dass in Schritt 2 die System-Architektur ggf. erweitert oder geändert werden muss (Re-Factoring) um die jeweiligen Features zu implementieren.

Aus dem Vorgehen wird ersichtlich, dass

  • man sehr schnell zu einem lauffähigen System kommt
  • frühzeitig Erfahrung machen kann um das System-Model  zu verifizieren
  • Das System-Modell wächst mit der Zeit  und deckt genau die Anforderungen ab,  die benötigt werden.
  • Ein Over-Engineering  wird vermieden

Katgeorie:VisualPedia | Kommentare deaktiviert für System-Architekturen erstellen (Part 1)

TDD – Test Driven Development

Die nachfolgende Abbildung habe ich auf  auch Pinterest veröffentlicht. Es zeigt die wichtigsten Aspekte zum Thema Test-Drive-Development.  Es soll motivieren sich mit dem Thema  näher zu beschäftigen oder einfach auch nur als Gedankenstütze für alle, die sich schon mit dem TDD beschäftigt haben.

TDD im Überblick
TDD im Überblick

Katgeorie:VisualPedia | Kommentare deaktiviert für TDD – Test Driven Development

Scrum Pizza – Alternative

In der nachfolgenden Abbildung habe dich das wichtigste zum Scrum diesmal als „“Saum-Pizza-Menu-Card“ dargestellt.

Ich denke diese Darstellung ist etwas übersichtlicher. Auf der linken Seite sind die Aspekte gelistet, die sich mehr an den „Projektablauf“ anlehnen. Während die Aspekte auf der rechten Seite eher an das „Doing“ anlehnen.

Katgeorie:Methodik, VisualPedia | Kommentare deaktiviert für Scrum Pizza – Alternative

Scrum auf einen Blick

In dem nachfolgenden Poster habe ich einmal das wichtigste von Scrum auf einen Blick dargestellt.  Es eignet sich wunderbar zum Ausrucken um es neben seinem Schreibtisch an die Wand zu hängen.  Für Feedback bin ich dankbar und mache gerne eine überarbeitet Version. Email genügt.

 

Scrum Pizza
Scrum Pizza  – Das wichtigste zum Thema SCRUM

 

Katgeorie:Methodik, VisualPedia | Kommentare deaktiviert für Scrum auf einen Blick

Testcase Design != Testcase Design

Tescase Design is not equal Testcase design
Testcase Design ist nicht gleich Testcase Design

In meinem letzen Beitrag habe ich dargestellt, dass die Definition einer Software Architektur auf unterschiedlichen Abstraktions-Ebenen stattfindet und auf jeder Ebene unterschiedliche Ziele, Arbeitsweisen und Fähigkeiten gefordert werden. Ähnlich ist es auch bei der Spezifikation von Testfällen.

Die Abbildung spiegelt die Testfallerstellung anhand der unterschiedlichen Architektur-Ebenen wider. Hierbei sieht man sehr deutlich, dass die Zielsetzung der Testfall-Spezifikation sehr unterschiedlich sein kann.
Auf der Komponenten-Ebene geht es eher um Entwickler-Tests (z.B. mit JUnit) und um entwicklungsbegleitendes Testen.
Auf der Service-Ebene geht es eher um das Testen von Szenarien und Workflow Sequenzen und um Integrationstests.

Darüber hinaus ist auch zu sehen, dass ein Test-Design, Controlling und Test-Automatisierung auf jeder Ebene notwendig ist.

Katgeorie:Methodik, VisualPedia | Kommentare deaktiviert für Testcase Design != Testcase Design

Wie kann ich visuelle Kommunikation einsetzen?

Visuelle Sprache einsetzen
VizTalk richtig einsetzen

In diesem Beitrag habe ich mal in einem „visual“ zusammengefasst, bei welchen Gelegenheiten visuelle Kommunikation  „Standard“ sein sollte.

Ich verwende es immer

  • Wenn ich nachdenke  der persönliche Notizen mach (Sketchnoting)
  • In Gesprächen mit Kollegen
  • In Team-Besprechungen ( am liebsten vor einem Whiteboard)
  • In Besprechungen in denen auch nicht Teammitglieder teilnehmen

 

Und natürlich auch in jeglicher Art von Dokumentation die ich erstelle.

Katgeorie:Methodik, VisualPedia | Kommentare deaktiviert für Wie kann ich visuelle Kommunikation einsetzen?

Entwicklungsumgebung Maven&Eclipse

Maven-Eclipse Senario
Maven-Eclipse Senario

In diesem Beitrag habe ich einmal dargestellt, wie eine Entwicklungsumgebung aussehen könnte, bei der folgende Aspekte im Vordergrund stehen:

  1. Entwickler sollen nur 3rd Party Komponenten verwenden dürfen, die für die Firma/das Projekt freigegeben sind.
  2. Entwickler sollen bei der Eclipse RCP Plugin Entwicklung nur Abhängigkeiten zu freigegebenen/zugelassenen Plugins haben dürfen.  Bestehen Abhängigkeiten zu anderen Plugins, so soll es nicht notwendig sein diese selbst zu erstellen. Ein Entwickler/rin braucht nur sein/ihr eigenes Plugin zu „builden“. Firmen-eigene Plugin sind ebenfalls in einem „Enterprise Eclipse Plugin“ Depot abgelegt.
  3. Eigener Source Code liegt wie üblich in einem Source Code Depot.
  4. Ein „Daily Build“ eines Produktes wird automatisch auf einem „Continious Integration Build Server“ gebaut.
  5. Nach einer „Release QA“ Phase werden  offizielle Produkte in einem firmen-eignen App-Store/Marketplace zu Verfügung gestellt.

Um die Darstellung möglichst übersichtlich zu halten, wurde auf einige Querverweise/Verbindungen verzichtet. Der Focus liegt auf der Verdeutlichung der Idee. Detailfragen können in einer eigenen Detailansicht  geklärt und beschrieben werden.

 

 

Katgeorie:Idee, Methodik, VisualPedia | Kommentare deaktiviert für Entwicklungsumgebung Maven&Eclipse

Technologie-Schwerpunkte 2012-13

In nachfolgender Abbildung sind die Technologie-Schwerpunkte als Inseln dargestellt, die mich in 2012 und 2013 am meisten interessiert haben.

Technology-Cluster 2012/13
Technology-Cluster 2012/13

Katgeorie:Technologie, VisualPedia | Kommentare deaktiviert für Technologie-Schwerpunkte 2012-13

Herausforderung: Internationalisierung

I18N Kontext
I18N Kontext

Internationalisierung & Lokalisierung

Mehrsprachige Anwendungen werden durch die Globalisierung immer wichtiger. In diesem Beitrag habe ich deshalb die wichtigsten Punkte zusammengefasst, die bei der Erstellung von mehrsprachigen Anwendungen zu beachten sind.

Es soll dazudienen einen ersten Einstieg in das Thema „Internationalisierung“ (I18N) zu finden.

Katgeorie:Technologie, VisualPedia | Kommentare deaktiviert für Herausforderung: Internationalisierung