© Excellent backgrounds/Shutterstock.com
Java Magazin
Kolumne: Requirements4Arc

Kolumne: Requirements4Arc

In der vorigen Folge haben wir Ihnen drei Zutaten vorgestellt, die Sie als Architekt(in) von anderen auf jeden Fall einfordern sollten, bevor Sie mit Designentscheidungen loslegen: klare Ziele, die Kenntnis der Stakeholder und die Festlegung Ihres Scopes. Starten wir mit dem Scope.

Peter Hruschka, Gernot Starke


Der Scope ist der Bereich, in dem Sie freie Entscheidungen treffen dürfen (Abb. 1). Im Kontext liegen die Schnittstellen zu Umsystemen oder Nutzergruppen. Änderungen daran müssen Sie mit den dafür Zuständigen verhandeln. Dinge im Kontext liegen also außerhalb Ihres direkten Einflussbereichs.Abb. 1: Scope und KontextProdukt-Scope und Projekt-ScopeAbb. 2: Projekt-Scope vs. Produkt-ScopeNutzen Sie für die Scope-Festlegung Ihres Projekts eine visuelle Gesamtübersicht (Kontextdiagramm) des neuen oder zu modifizierenden Systems, zusammen mit den Nachbarsystemen 1 bis 4.Notationen für Scope und KontextZur Festlegung der Grenze zwischen Scope und Kontext reicht anfangs die Betrachtung der ein- und ausgehenden Daten Ihres Systems. Die klassische Darstellungsweise dafür ist ein sogenanntes fachliches Kontextdiagramm [1], wie Sie es als Beispiel für den Bordcomputer eines PKWs in Abbildung 3 sehen. Das System soll den Fahrer sowohl mit typischen Informationen wie Durchschnittsgeschwindigkeit, Treibstoffverbrauch, Außentemperatur etc. versorgen als auch Navigation ermöglichen, einen Tempomaten zur Verfügung stellen, Wartungsintervalle überwachen und den Fahrer über Radiosender und Telefonanrufe informieren. Abb. 3: Kontextdiagramm mit Ein- und Ausgaben des SystemsFalls Sie übrigens Diagramme nicht mögen, so wird unter [1] eine ganze Menge an alternativen Notationen dafür vorgeschlagen, im einfachsten Fall eine Tabelle mit allen Nachbarsystemen und deren Schnittstellen. Wichtig ist, dass Sie erstens Ihr System klar identifiziert haben, zweitens alle Nachbarn kennen und drittens die komplette Ein- und Ausgabe auf fachlicher Ebene verstanden haben.Entwicklung braucht (Schnittstellen-)DetailsBei Entwurf und Entwicklung des Systems müssen Sie bei jeder dieser externen Schnittstellen alle notwendigen Details entweder hinterfragen oder entscheiden. Unter [2] finden sich dazu viele pragmatische Hinweise. Sie müssen zum Beispiel festlegen, wer der aktive Partner ist (Push oder Pull), wie die Handshakes oder Protokolle aussehen, die an der Schnittstelle einzuhalten sind, welche zeitlichen, technischen oder organisatorischen Randbedingungen einzuhalten sind etc.Im arc42-Termplate [3] haben wir Abschnitt 3 (Kontextabgrenzung) für diese wichtigen Informationen vorgesehen. Abschnitt 3.1 enthält das fachliche Kontextdiagramm. Falls nötig, können Sie in Abschnitt 3.2. noch das technische Kontextdiagramm aufnehmen, das die technischen Kanäle zeigt, über die fachliche Informationen ...

Java Magazin
Kolumne: Requirements4Arc

Kolumne: Requirements4Arc

In der vorigen Folge haben wir Ihnen drei Zutaten vorgestellt, die Sie als Architekt(in) von anderen auf jeden Fall einfordern sollten, bevor Sie mit Designentscheidungen loslegen: klare Ziele, die Kenntnis der Stakeholder und die Festlegung Ihres Scopes. Starten wir mit dem Scope.

Peter Hruschka, Gernot Starke


Der Scope ist der Bereich, in dem Sie freie Entscheidungen treffen dürfen (Abb. 1). Im Kontext liegen die Schnittstellen zu Umsystemen oder Nutzergruppen. Änderungen daran müssen Sie mit den dafür Zuständigen verhandeln. Dinge im Kontext liegen also außerhalb Ihres direkten Einflussbereichs.Abb. 1: Scope und KontextProdukt-Scope und Projekt-ScopeAbb. 2: Projekt-Scope vs. Produkt-ScopeNutzen Sie für die Scope-Festlegung Ihres Projekts eine visuelle Gesamtübersicht (Kontextdiagramm) des neuen oder zu modifizierenden Systems, zusammen mit den Nachbarsystemen 1 bis 4.Notationen für Scope und KontextZur Festlegung der Grenze zwischen Scope und Kontext reicht anfangs die Betrachtung der ein- und ausgehenden Daten Ihres Systems. Die klassische Darstellungsweise dafür ist ein sogenanntes fachliches Kontextdiagramm [1], wie Sie es als Beispiel für den Bordcomputer eines PKWs in Abbildung 3 sehen. Das System soll den Fahrer sowohl mit typischen Informationen wie Durchschnittsgeschwindigkeit, Treibstoffverbrauch, Außentemperatur etc. versorgen als auch Navigation ermöglichen, einen Tempomaten zur Verfügung stellen, Wartungsintervalle überwachen und den Fahrer über Radiosender und Telefonanrufe informieren. Abb. 3: Kontextdiagramm mit Ein- und Ausgaben des SystemsFalls Sie übrigens Diagramme nicht mögen, so wird unter [1] eine ganze Menge an alternativen Notationen dafür vorgeschlagen, im einfachsten Fall eine Tabelle mit allen Nachbarsystemen und deren Schnittstellen. Wichtig ist, dass Sie erstens Ihr System klar identifiziert haben, zweitens alle Nachbarn kennen und drittens die komplette Ein- und Ausgabe auf fachlicher Ebene verstanden haben.Entwicklung braucht (Schnittstellen-)DetailsBei Entwurf und Entwicklung des Systems müssen Sie bei jeder dieser externen Schnittstellen alle notwendigen Details entweder hinterfragen oder entscheiden. Unter [2] finden sich dazu viele pragmatische Hinweise. Sie müssen zum Beispiel festlegen, wer der aktive Partner ist (Push oder Pull), wie die Handshakes oder Protokolle aussehen, die an der Schnittstelle einzuhalten sind, welche zeitlichen, technischen oder organisatorischen Randbedingungen einzuhalten sind etc.Im arc42-Termplate [3] haben wir Abschnitt 3 (Kontextabgrenzung) für diese wichtigen Informationen vorgesehen. Abschnitt 3.1 enthält das fachliche Kontextdiagramm. Falls nötig, können Sie in Abschnitt 3.2. noch das technische Kontextdiagramm aufnehmen, das die technischen Kanäle zeigt, über die fachliche Informationen ...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang