3. Kontextabgrenzung
(engl.: Scope of Product*)
Die Kontextabgrenzung grenzt das System oder das Produkt, für das Sie die Architektur entwickeln, von allen Nachbarsystemen ab. Sie legt damit die wesentlichen externen Schnittstellen fest.
Stellen Sie sicher, dass die Schnittstellen mit allen relevanten Aspekten (was wird übertragen, in welchem Format wird übertragen, welches Medium wird verwendet, ...) spezifiziert wird, auch wenn einige populäre Diagramme (wie z.B. das UML Use-Case Diagramm) nur ausgewählte Aspekte der Schnittstelle darstellen.
Die Festlegung der Schnittstellen zu Nachbarsystemen gehört zu den kritischsten Aspekten eines Projektes. Stellen Sie rechtzeitig sicher, dass Sie diese komplett verstanden haben.
Die folgenden Unterkapitel zeigen die logische und physische Einbettung Ihres Systems in seine Umgebung.
3.1 Fachlicher Kontext
Hier werden alle Nachbarsysteme des betrachteten Systems festgelegt und alle fachlich-logischen Daten, die mit diesen ausgetauscht werden. Zusätzlich evtl. Datenformate und Protokolle der Kommunikation mit Nachbarsystemen und der Umwelt (falls diese nicht erst bei den spezifischen Bausteinen präzisiert wird.
Dieses Kapitel soll klar und unmissverständlich aufzeigen, welche (logischen) Informationen mit Nachbarsystemen (in welcher Form) ausgetauscht werden.
Wir sind an vielen Stellen im Dokument zu Pragmatismus bereit: hier jedoch bestehen wir auf der vollständigen Auflistung aller (a-l-l-e-r) Nachbarsysteme. Zu viele Projekte sind daran gescheitert, dass sie ihre Nachbarn nicht kannten :-(
Als Notation können Sie das gute, alte Kontextdiagramm aus der Strukturierten Analyse verwenden. Bei Nutzung von UML simulieren Sie dieses durch ein Klassendiagramm, ein Use Case Diagramme erweitert um die Ein-/Ausgaben oder ein Kommunikationsdiagramm - kurz durch irgendein Diagramm, das das System als Black Box darstellen und die Schnittstellen zu den Nachbarsystemen (mehr oder weniger ausführlich) beschreibt. Auch Tabellen aller Nachbarsysteme mit Erwähnung der jeweiligen Ein-/Ausgaben erfüllen den Zweck.
3.2 Verteilungskontext
Hier legen Sie die physischen Kanäle zwischen Ihrem System und allen Nachbarsystemen fest, über die die logischen Ein-/Ausgaben von und zu Nachbarsystemen kommuniziert werden.
Das Kapitel soll aufzeigen, über welche Medien Informationen mit Nachbarsystemen bzw. der Umwelt ausgetauscht werden.
Als Form bietet sich z.B. ein UML Deploymentdiagramm mit den Kanälen zu Nachbarsystemen an. Sie ergänzen es um eine Mappingtabelle der logischen Ein-/Ausgaben aus Kapitel 3.1 auf die hier spezifizierten Kanäle.
(engl.: Scope of Product*)
Die Kontextabgrenzung grenzt das System oder das Produkt, für das Sie die Architektur entwickeln, von allen Nachbarsystemen ab. Sie legt damit die wesentlichen externen Schnittstellen fest.
Stellen Sie sicher, dass die Schnittstellen mit allen relevanten Aspekten (was wird übertragen, in welchem Format wird übertragen, welches Medium wird verwendet, ...) spezifiziert wird, auch wenn einige populäre Diagramme (wie z.B. das UML Use-Case Diagramm) nur ausgewählte Aspekte der Schnittstelle darstellen.
Die Festlegung der Schnittstellen zu Nachbarsystemen gehört zu den kritischsten Aspekten eines Projektes. Stellen Sie rechtzeitig sicher, dass Sie diese komplett verstanden haben.
Die folgenden Unterkapitel zeigen die logische und physische Einbettung Ihres Systems in seine Umgebung.
3.1 Fachlicher Kontext
Hier werden alle Nachbarsysteme des betrachteten Systems festgelegt und alle fachlich-logischen Daten, die mit diesen ausgetauscht werden. Zusätzlich evtl. Datenformate und Protokolle der Kommunikation mit Nachbarsystemen und der Umwelt (falls diese nicht erst bei den spezifischen Bausteinen präzisiert wird.
Dieses Kapitel soll klar und unmissverständlich aufzeigen, welche (logischen) Informationen mit Nachbarsystemen (in welcher Form) ausgetauscht werden.
Wir sind an vielen Stellen im Dokument zu Pragmatismus bereit: hier jedoch bestehen wir auf der vollständigen Auflistung aller (a-l-l-e-r) Nachbarsysteme. Zu viele Projekte sind daran gescheitert, dass sie ihre Nachbarn nicht kannten :-(
Als Notation können Sie das gute, alte Kontextdiagramm aus der Strukturierten Analyse verwenden. Bei Nutzung von UML simulieren Sie dieses durch ein Klassendiagramm, ein Use Case Diagramme erweitert um die Ein-/Ausgaben oder ein Kommunikationsdiagramm - kurz durch irgendein Diagramm, das das System als Black Box darstellen und die Schnittstellen zu den Nachbarsystemen (mehr oder weniger ausführlich) beschreibt. Auch Tabellen aller Nachbarsysteme mit Erwähnung der jeweiligen Ein-/Ausgaben erfüllen den Zweck.
3.2 Verteilungskontext
Hier legen Sie die physischen Kanäle zwischen Ihrem System und allen Nachbarsystemen fest, über die die logischen Ein-/Ausgaben von und zu Nachbarsystemen kommuniziert werden.
Das Kapitel soll aufzeigen, über welche Medien Informationen mit Nachbarsystemen bzw. der Umwelt ausgetauscht werden.
Als Form bietet sich z.B. ein UML Deploymentdiagramm mit den Kanälen zu Nachbarsystemen an. Sie ergänzen es um eine Mappingtabelle der logischen Ein-/Ausgaben aus Kapitel 3.1 auf die hier spezifizierten Kanäle.