Get best of the week

Design auf Systemebene. Teil 2. Detaillierte Architektur

Im ersten Teil des Tutorials habe ich die Architektur eines Zugangskontrollsystems erhalten. Das erzielte Ergebnis hat bereits praktische Vorteile, reicht jedoch nicht aus, da die Architektur jetzt die Formate und Datentypen sowie die Art der Komponenten nicht berücksichtigt. In diesem Teil des Tutorials werde ich zeigen, wie Datenströme in einem System entworfen und mit Komponenten verschiedener Art gearbeitet werden.

Komponentenschnittstellen


Schauen wir uns das System vom ersten Teil an noch einmal an. Wir sehen, dass die Komponenten durch Pfeile verbunden sind. Diese Verbindungen sind immer noch abstrakt und stellen einfache Informationsverbindungen dar. Wir können den Abstraktionsgrad jedoch leicht reduzieren. Betrachten Sie die Ausgabe der DBHandler- Komponente .



Diese Komponente verfügt über einen AccessStatus-Exit. Versuchen wir es zu beschreiben. AccessStatus ist also ein Link, der Zugriffsstatusinformationen enthält. Der Zugang kann entweder gewährt oder nicht gewährt werden. Das heißt, es ist eine explizite boolesche Variable! Geben wir den Typ dieser Ausgabe an. Dazu müssen Sie in System Composer zunächst die entsprechende Schnittstelle erstellen :



Und dann geben wir an, dass die erstellte Schnittstelle dem AccessStatus-Port zugewiesen ist:



Dieser Vorgang muss an allen erforderlichen Ports ausgeführt werden. Wir können die folgende Aussage zusammenfassen und ableiten:

Indem wir Schnittstellen erstellen und diesen Ports zuweisen, geben wir Entwicklern, die das System implementieren, genaue Anweisungen darüber, welche Daten die entwickelten Komponenten verwenden und welche Daten an der Ausgabe benötigt werden.

Ein weiterer Vorteil von System Composer ist die Möglichkeit, den Datenfluss mithilfe von benutzerdefinierten Architekturansichten ( Architekturansichten) anzuzeigen . Wir können unsere Architektur nach bestimmten Kriterien filtern. Nehmen Sie als Beispiel die zuvor erstellte Schnittstelle. Erstellen Sie eine AccessStatus-Datenflussansicht.

Klicken Sie zunächst auf Modellierung -> Architekturansichten . Und dann erstellen Sie einen Filter:



Hier wird der Name der Ansicht festgelegt und ein Filter erstellt: Wählen Sie alle Komponenten mit einer Schnittstelle namens AccessStatus aus . Nach dem Klicken auf die Schaltfläche Übernehmen erhalten wir das folgende Bild:


Daher ist die Verwendung solcher Darstellungen für die Entwicklung nützlich, da Sie die erforderlichen Komponenten oder Fehler im Projekt oder Datenstrom schnell finden können.

Heterogenes Komponentenmanagement


Es wäre möglich, hier anzuhalten, da wir im Moment eine schöne Systemarchitektur haben, die bei der Implementierung hilft. Es gibt jedoch ein sehr großes Problem - das System besteht aus Eisen, dh physischen Komponenten, und aus Software. Was bedeutet das? Dies bedeutet, dass das System heterogen ist und wir diese Heterogenität irgendwie widerspiegeln müssen. System Composer verfügt über spezielle Funktionen - dies sind Profile und Stereotypen. Zum besseren Verständnis ist ein Stereotyp eine abstrakte Beschreibung einer Klasse von Komponenten mit Eigenschaften, und ein Profil ist eine Sammlung von Stereotypen. Ein einfaches Beispiel - Nehmen wir an, wir haben ein Stereotyp, das einen Mikrocontroller beschreibt. Jeder Mikrocontroller hat gemeinsame Eigenschaften - Kern, TDP, Versorgungsspannung, Frequenz usw. Es sind diese Eigenschaften, die sich im Stereotyp widerspiegeln sollten.

Erstellen Sie ein Profil und die notwendigen Stereotypen:


Zum Beispiel habe ich das Stereotyp von GenericComponent erstellt. So sieht es aus:



Hier sind mehrere Einstellungen wichtig:

  1. Gilt für - was das Stereotyp gilt - eine Komponente, Schnittstelle, einen Port oder eine Verbindung (ja, die Verbindungen selbst, diese Pfeile, können auch mit dem Stereotyp beschrieben werden).
  2. Das Basisstereotyp ist das übergeordnete Stereotyp. Stereotype erben die Eigenschaften übergeordneter Stereotypen
  3. Eigenschaftentabelle - Hier werden benutzerdefinierte Eigenschaften festgelegt. Zum Beispiel heißt mein Eigentum Workload, dh die Arbeit, die mit der Implementierung verbunden ist

2 weitere Stereotypen von HardwareComponent basieren auf diesem Stereotyp - für Hardware und SoftwareComponent für Software.

Nachdem wir das Profil und die Stereotypen erstellt haben, importieren wir sie in die Architektur und können beginnen, sie über ihre Elemente zu verteilen:



Als Ergebnis habe ich dieses Bild bekommen:


Aus Gründen der Klarheit habe ich folgende Präsentation gemacht:


Schauen wir uns den Mechanismus zum Erben der Eigenschaften von Komponenten in Aktion an. Wählen Sie die DoorLock-Komponente aus und sehen Sie sich ihre Eigenschaften an:


Die Workload-Eigenschaft wurde von der GenericComponent geerbt, die Cost-Eigenschaft ist jedoch spezifisch für das HardwareComponent-Stereotyp.

Um diesen Teil zusammenzufassen: Die

detaillierte Architektur ermöglicht eine vollständigere Beschreibung des zu entwickelnden Systems und die Vermeidung von Inkonsistenzen bei Schnittstellen und der Interaktion von Komponenten. Die Verwendung von Stereotypen für Details hilft, die Natur der Komponenten zu verstehen und ein vollständigeres Bild des zu entwickelnden Systems zu erhalten.

Im nächsten Teil des Tutorials werde ich über die Integration von System Composer in MATLAB, Simulink und das Anforderungsmanagement-Tool Simulink Requierements sprechen.

More articles:


All Articles