Commit c219fa3a authored by Blanke, Daniela's avatar Blanke, Daniela
Browse files

Update architecture-components.html

parent d6c9d45f
Pipeline #8022 passed with stage
in 1 minute and 9 seconds
...@@ -16,7 +16,7 @@ ...@@ -16,7 +16,7 @@
<li><i>Physical View</i>: Die Verteilung der Komponenten auf Laufzeitumgebungen, insbesondere auf virtuelle und dedizierte Server, aus Sicht des für den Betrieb zuständigen Systemadministrators wird dargestellt, z.B. als Verteilungsdiagramm in der UML.</li> <li><i>Physical View</i>: Die Verteilung der Komponenten auf Laufzeitumgebungen, insbesondere auf virtuelle und dedizierte Server, aus Sicht des für den Betrieb zuständigen Systemadministrators wird dargestellt, z.B. als Verteilungsdiagramm in der UML.</li>
</ul> </ul>
</li> </li>
<li><b>Allgemeingültigkeit</b> (engl. <i>Generality</i>): Zu Beginn eines Softwareprojekts stellt sich die Frage, wie individuell die Architektur des zu konstruierenden Systems sein muss. Wenn ein bewährtes Framework bereits als passende Architekturvorlage vorliegt, ist es grundsätzlich empfehlenswert darauf aufzubauen. Bei der Wiederverwendung von erprobten Komponenten kann i.d.R. davon ausgegangen werden, dass der Aufwand für eine eigene Implementierung deutlich höher ausfällt als die Einarbeitungszeit in die API der wiederverwendeten Komponente. Außerdem können durch Wiederverwendung ansonsten häufig auftretende Schwachstellen vermieden werden. Die Vor- und Nachteile eines individuellen Architekturentwurfs gegenüber einer adaptierten Standardarchitektur sind sorgfältig abzuwägen. Es ist zu beachten, dass die Architektur eines neues Systems sich durch die eigenen Entwurfsentscheidungen manifestiert.</li> <li><b>Allgemeingültigkeit</b> (engl. <i>Generality</i>): Zu Beginn eines Softwareprojekts stellt sich die Frage, wie individuell die Architektur des zu konstruierenden Systems sein muss. Wenn ein bewährtes Framework bereits als passende Architekturvorlage vorliegt, ist es grundsätzlich empfehlenswert darauf aufzubauen. Bei der Wiederverwendung von erprobten Komponenten kann i.d.R. davon ausgegangen werden, dass der Aufwand für eine eigene Implementierung deutlich höher ausfällt als die Einarbeitungszeit in die API der wiederverwendeten Komponente. Außerdem können durch Wiederverwendung ansonsten häufig auftretende Schwachstellen vermieden werden. Die Vor- und Nachteile eines individuellen Architekturentwurfs gegenüber einer adaptierten Standardarchitektur sind sorgfältig abzuwägen. Es ist zu beachten, dass die Architektur eines neuen Systems sich durch die eigenen Entwurfsentscheidungen manifestiert.</li>
<li><b>Inkrementalität</b>: Inkrementalität basiert auf der Annahme, dass im Verlauf der Entwicklung Änderungen nicht zu verhindern sind und impliziert damit iteratives Vorgehen. Solange das Anwendungssystem weiterentwickelt wird, ist auch dessen Architektur i.d.R. nicht dauerhaft stabil. Die Evolution eines Anwendungssystems führt zu Unterschieden in der sogenannten präskriptiven und deskriptiven Architektur. Die präskriptive Architektur beschreibt, was durch die Architekten zur Entwurfszeit geplant war, während die deskriptive Architektur ausdrückt, was tatsächlich zur Laufzeit im Betrieb beobachtet werden kann, z.B. durch dynamische Code-Analyse mittels geeigneter <a href="https://www.gartner.com/reviews/market/apm">Application Performance Monitoring-Werkzeuge</a> wie <a href="https://www.appdynamics.com/">AppDynamics</a>, <a href="https://www.dynatrace.de/">Dynatrace</a> oder <a href="https://newrelic.com/">New Relic</a>. Wir sprechen von Software-Erosion, wenn der Soll-Zustand (präskriptiv) und der Ist-Zustand (deskriptiv) der Architektur stark voneinander abweichen.</li> <li><b>Inkrementalität</b>: Inkrementalität basiert auf der Annahme, dass im Verlauf der Entwicklung Änderungen nicht zu verhindern sind und impliziert damit iteratives Vorgehen. Solange das Anwendungssystem weiterentwickelt wird, ist auch dessen Architektur i.d.R. nicht dauerhaft stabil. Die Evolution eines Anwendungssystems führt zu Unterschieden in der sogenannten präskriptiven und deskriptiven Architektur. Die präskriptive Architektur beschreibt, was durch die Architekten zur Entwurfszeit geplant war, während die deskriptive Architektur ausdrückt, was tatsächlich zur Laufzeit im Betrieb beobachtet werden kann, z.B. durch dynamische Code-Analyse mittels geeigneter <a href="https://www.gartner.com/reviews/market/apm">Application Performance Monitoring-Werkzeuge</a> wie <a href="https://www.appdynamics.com/">AppDynamics</a>, <a href="https://www.dynatrace.de/">Dynatrace</a> oder <a href="https://newrelic.com/">New Relic</a>. Wir sprechen von Software-Erosion, wenn der Soll-Zustand (präskriptiv) und der Ist-Zustand (deskriptiv) der Architektur stark voneinander abweichen.</li>
<li><b>Früherkennung von Änderungen</b> (engl. <i>Anticipation of Change</i>): Aufbauend auf der inkrementellen Entwicklung eines Systems gilt es potentielle zukünftige Änderungen möglichst früh zu antizipieren und in der Architektur zu berücksichtigen. Eine gute Architektur ist flexibel erweiterbar, aber weiterhin möglichst einfach zu handhaben. Die Ursachen für Änderungen sind sehr verschieden, z.B. Beseitigung von Fehlern (korrektive Wartung), Verbesserung nicht-funktionaler Eigenschaften (perfektive Wartung), Anpassung der Funktionalität wegen sich ändernder Bedingungen (adaptive Wartung).</li> <li><b>Früherkennung von Änderungen</b> (engl. <i>Anticipation of Change</i>): Aufbauend auf der inkrementellen Entwicklung eines Systems gilt es potentielle zukünftige Änderungen möglichst früh zu antizipieren und in der Architektur zu berücksichtigen. Eine gute Architektur ist flexibel erweiterbar, aber weiterhin möglichst einfach zu handhaben. Die Ursachen für Änderungen sind sehr verschieden, z.B. Beseitigung von Fehlern (korrektive Wartung), Verbesserung nicht-funktionaler Eigenschaften (perfektive Wartung), Anpassung der Funktionalität wegen sich ändernder Bedingungen (adaptive Wartung).</li>
<li><b>Genauigkeit und Formalität</b>: Es geht hier nicht darum Kreativität zu verhindern, sondern das Ergebnis kreativer Entwurfsphasen möglichst präzise, z.B. in standardisierten Notationen, zu erfassen. Genauigkeit schafft Vertrauen für einen Entwurf. Formalität ist Genauigkeit in höchstem Maße, wobei jede Organisation bzw. jedes Team hier ein adäquates Maß für sich definieren muss. Es stellen sich dabei Fragen wie: Ist eine Verifikation für bestimmte Algorithmen erforderlich? Wie systematisch werden Testdaten und Testfälle erzeugt? Wie gründlich ist die Dokumentation von Aktivitäten?</li> <li><b>Genauigkeit und Formalität</b>: Es geht hier nicht darum Kreativität zu verhindern, sondern das Ergebnis kreativer Entwurfsphasen möglichst präzise, z.B. in standardisierten Notationen, zu erfassen. Genauigkeit schafft Vertrauen für einen Entwurf. Formalität ist Genauigkeit in höchstem Maße, wobei jede Organisation bzw. jedes Team hier ein adäquates Maß für sich definieren muss. Es stellen sich dabei Fragen wie: Ist eine Verifikation für bestimmte Algorithmen erforderlich? Wie systematisch werden Testdaten und Testfälle erzeugt? Wie gründlich ist die Dokumentation von Aktivitäten?</li>
...@@ -56,7 +56,7 @@ ...@@ -56,7 +56,7 @@
<div class="cite"><a href="http://lig-membres.imag.fr/donsez/ujf/m2r/glcs/composants/lau.pdf">" A software component model is a definition of (1) the semantics of components, that is, what components are meant to be, (2) the syntax of components, that is, how they are defined, constructed, and represented, and (3) the composition of components, that is, how they are composed or assembled." (Kung-Kiu Lau et al.)</a></div> <div class="cite"><a href="http://lig-membres.imag.fr/donsez/ujf/m2r/glcs/composants/lau.pdf">" A software component model is a definition of (1) the semantics of components, that is, what components are meant to be, (2) the syntax of components, that is, how they are defined, constructed, and represented, and (3) the composition of components, that is, how they are composed or assembled." (Kung-Kiu Lau et al.)</a></div>
<p>Aktuelle Komponentenmodelle sind z.B. <a href="https://docs.microsoft.com/de-de/dotnet/">Microsoft .NET</a>, <a href="https://jcp.org/en/jsr/detail?id=376">Java Platform Module System (JPMS)</a>, <a href="https://www.osgi.org/developer/specifications/">OSGi</a> und <a href="https://spring.io/">Spring</a>. Zu frühen Komponentenmodellen, die heute veraltet sind, gehören <a href="https://jcp.org/en/jsr/detail?id=220">Enterprise JavaBeans (EJBs)</a>, <a href="https://www.omg.org/spec/CCM/4.0/">OMG CORBA Component Model (CCM)</a> und <a href="https://docs.microsoft.com/de-de/windows/desktop/com/">Microsoft COM</a>. Auch die UML bietet ein Komponentenmodell an, das nicht wie die vorherigen auf eine konkrete Implementierung sondern auf die Spezifikation, Dokumentation und Kommunikation eines Architekturentwurfs ausgerichtet ist. Die folgende Abbildung zeigt wie Komponenten in einem UML-Komponentendiagramm dargestellt werden.</p> <p>Aktuelle Komponentenmodelle sind z.B. <a href="https://docs.microsoft.com/de-de/dotnet/">Microsoft .NET</a>, <a href="https://jcp.org/en/jsr/detail?id=376">Java Platform Module System (JPMS)</a>, <a href="https://www.osgi.org/developer/specifications/">OSGi</a> und <a href="https://spring.io/">Spring</a>. Zu frühen Komponentenmodellen, die heute veraltet sind, gehören <a href="https://jcp.org/en/jsr/detail?id=220">Enterprise JavaBeans (EJBs)</a>, <a href="https://www.omg.org/spec/CCM/4.0/">OMG CORBA Component Model (CCM)</a> und <a href="https://docs.microsoft.com/de-de/windows/desktop/com/">Microsoft COM</a>. Auch die UML bietet ein Komponentenmodell an, das nicht wie die vorherigen auf eine konkrete Implementierung, sondern auf die Spezifikation, Dokumentation und Kommunikation eines Architekturentwurfs ausgerichtet ist. Die folgende Abbildung zeigt wie Komponenten in einem UML-Komponentendiagramm dargestellt werden.</p>
<img src="media/architecture_uml_component_model.png" style="width:720px"> <img src="media/architecture_uml_component_model.png" style="width:720px">
<label>Notation des UML-Komponentendiagramms</label> <label>Notation des UML-Komponentendiagramms</label>
...@@ -147,7 +147,7 @@ public class SimpleRegressionModel { ...@@ -147,7 +147,7 @@ public class SimpleRegressionModel {
<h4>Kapselung auf Ebene von Klassen</h4> <h4>Kapselung auf Ebene von Klassen</h4>
<span>Bisher ist nur über Modularisierung und Kapselung auf Ebene von Komponenten gesprochen worden. Im Feinentwurf werden die Komponenten durch Klassen realisiert, die ebenfalls interne Daten- und Verhaltensstrukturen in Form von privaten Attributen und Methoden voreinander verstecken können. Dazu dienen in objektorientierten Sprachen insbesondere die Sicherbarkeitsmodifizierer <code>private</code> und <code>protected</code>. Wenn auf eine Klasse regelmäßig von außen zugegriffen wird, ist eine stabile Schnittstelle wichtig. Der Zugriff kann in diesem Fall sinnvoll über Getter- und Setter-Methoden gekapselt werden, um die zugrundeliegenden internen Strukturen verändern zu können, ohne den Zugriff von außen zu beeinflussen. Grundsätzlich stellt sich die Frage, vor welchen äußeren Zugriffen die internen Strukturen gekapselt werden sollen.</span> <span>Bisher ist nur über Modularisierung und Kapselung auf Ebene von Komponenten gesprochen worden. Im Feinentwurf werden die Komponenten durch Klassen realisiert, die ebenfalls interne Daten- und Verhaltensstrukturen in Form von privaten Attributen und Methoden voreinander verstecken können. Dazu dienen in objektorientierten Sprachen insbesondere die Sicherbarkeitsmodifizierer <code>private</code> und <code>protected</code>. Wenn auf eine Klasse regelmäßig von außen zugegriffen wird, ist eine stabile Schnittstelle wichtig. Der Zugriff kann in diesem Fall sinnvoll über Getter- und Setter-Methoden gekapselt werden, um die zugrundeliegenden internen Strukturen verändern zu können, ohne den Zugriff von außen zu beeinflussen. Grundsätzlich stellt sich die Frage, vor welchen äußeren Zugriffen die internen Strukturen gekapselt werden sollen:</span>
<ul> <ul>
<li>Vor Zugriffen aus Methoden in anderen Klassen im selben Modul?</li> <li>Vor Zugriffen aus Methoden in anderen Klassen im selben Modul?</li>
<li>Oder vor Zugriffen aus anderen Modulen durch externe Anwender, die das eigene Modul als abhängige Bibliothek einsetzen?</li> <li>Oder vor Zugriffen aus anderen Modulen durch externe Anwender, die das eigene Modul als abhängige Bibliothek einsetzen?</li>
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment