Benutzer:Centic/Komponentenbasierte Programmierung/Kritik

Hier die drei Gutachten zur Ausarbeitung. Erledigte Kritikpunkte sind durchgestrichen.

Gutachten 1

Abgearbeitet --Dashel 17:32, 22. Jan 2006 (CET)

Zusammenfassung: Zunächst erfolgt eine Vorstellung der objektorientierten Programmierung. Hierbei werden die Grundkonzepte erläutert, diese sind das Klassenkonzept, Vererbung, dynamische Bindung sowie Kapselung und Schnittstellendefinition. Als Vorteile der objektorientierten Programmierung werden Wiederverwendbarkeit und leichte Erweiterbarkeit von Software aufgeführt. Darüber hinaus wird dargestellt, dass parallele Programmierbarkeit sowie die Zusammenfassung von Funktionen und Daten zu Objekten ebenso für die objektorientierte Programmierung spricht.

Anschließend wird definiert was unter komponentenbasierter Programmierung, bzw. was generell unter Komponenten, zu verstehen ist. Motiviert wurde die komponentenbasierte Programmierung durch den Ansatz ein Problem in Teilprobleme zu zerlegen, daraus lassen sich die Eigenschaften von Komponenten ableiten: strenge Kapselung, Kommunikation über Schnittstellen, eigenständig lauffähig, Komponenten können wieder aus Komponenten bestehen, und Zustandslosigkeit nach außen. Als Vorteil der komponentenbasierten Programmierung wird die Spezialisierung auf die Implementierung der Geschäftslogik genannt. Dies ergibt sich, da viele Standard-Dienste durch die Laufzeitumgebung übernommen werden. Allerdings muss diese Umgebung auch kritisch betrachtet werden. In diesem Zusammenhang wird auch angeführt, dass in der komponentenbasierten Programmierung die Komponentenmodelle die Entwicklung aufbläht und teilweise verkompliziert. Anhand der Gesichtspunkte Standardisierung, Zustände, Ablaufumgebung, Binärstandards, Metadaten, Schnittstellen, Object Aliasing und Wiederverwendbarkeit erfolgt eine kritische Gegenüberstellung beider Technologien.

Als Schlussfolgerung wird gezogen, dass die komponentenbasierte Programmierung ein vielversprechender Ansatz ist und komponentenbasierten Programmierung und die objektorientierte Programmierung keine nebeneinanderstehenden Technologien sind, sondern vielmehr aufeinander aufbauen.

Anmerkungen:

• S.5 (Klassenkonzept): Hier sollte etwas genauer erläutert werden, was das Klassenkonzept beinhaltet, die Begriffe Typisierungs- und Modularisierungskonzept reichen nicht aus. Absatz erweitert.
• S. 5 (Dynamische Methodenauswahl und Subtyping): Der Begriff Subtyping wird nur genannt, er sollte auch genauer erklärt werden. Absatz erweitert.
• S. 5 (Kapselung): Die Formulierung über Schnittstellen ist undeutlich, es wird der Eindruck erweckt, dass nur eine Schnittstelle möglich ist. Es sollte auch klarer herausgearbeiztet werden, dass Schnittstellen das Mittel zur Kapselung sind, es klingt als seien sie nur ein Addendum. Beschreibung geändert.
• S. 9 (Programmiermodell, letzter Absatz): Neue Applikationserver schlagen bereits Brücken zwischen den Komponentenmodellen, deshalb lassen sich bereits Komponenten unterschiedlicher Welten "leicht" verbinden. Im Idealfall kapselt die Laufzeitumgebung die eigentliche Geschäftslogik soweit ab, dass das Programm ohne große Änderungen in eine andere Umgebung übernommen werden kann. Absatz etwas abgemildert.
• S. 9 (infrastrukturelle Dienste, Aufzählung Kritikpunkte): Infrastrukturelle Dienste sind nicht generell statisch, dies ist abhängig vom Applicationserver, vgl MBeans im Jboss. Außerdem wird die Standardisierung immer weiter vorangetrieben, so dass App-Server bereits jetzt eine Verbindung zwischen verschiedenen Komponentenmodellen erlauben. Kritikpunkte etwas überarbeitet.
• S. 10 (Zustand): Die Zustandslosigkeit wird aber nicht generell gefordert, bzw. Zustände sind durchaus erwünscht, vgl. Statefull-Session-Beans in EJB Absatz neu formuliert.
• S. 10 (Aublaufumgebung): Bei der Objektorientierung als reines Konzept existiert keine Ablaufumgebung, jedoch bei der technischen Realisierung schon, vgl. JVM Absatz überarbeitet
• S.11 (Metadaten): Metadaten sind nicht nur welche Schnittstellen eine Komponente anbietet, sondern z.B. auch Vorgaben, bzw. Verträge einer Schnittstelle oder der ganzen Komponente Absatz überarbeitet.
• Viele Tippfehler erschweren ein flüssiges Lesen. Text nochmal korrekturgelesen.

Gutachten 2

Nach einer starken Einleitung und einem guten Kapitel 2 flacht die Arbeit leider etwas ab.

• Warum kann sich ein Komponentenentwickler ganz auf die Implementierungen der Geschäfts- oder Applikationslogik spezialisieren? Sie setzen hier wohl die Existenz eines Containers voraus, in dem die Komponenten zum Einsatz kommen und der sie um gewisse Standardfunktionalität ergänzt. Aber ist das automatisch mit dem Komponentenbegriff verbunden? Umformuliert und einige andere Punkte aufgenommen.

• Warum ist es ein Nachteil der komponentenbasierten Programmierung, daß sich das Komponentenkonzept nicht unmittelbar umsetzen läßt, sondern vom Programmierer auf primitive Konzepte abgebildet werden muß (der erste Satz aus Abschnitt 3.4.1, der das wohl aussagen soll, ist etwas unglücklich formuliert)? Vielleicht gibt es ja eines Tages Programmiersprachen, die ein Schlüsselwort "component" haben und in denen sich Komponenten direkt umsetzen lassen! Ich lasse den jetzigen kurzen Punkt mit "komplex" einfach mal so drinnen stehen, ich denke das lässt sich argumentieren.

• Auch können die infrastrukturellen Dienste wohl kaum als Nachteil der komponentenbasierten Programmierung angesehen werden - allenfalls ist auch hier die bisherige technische Umsetzung zu schwach. Habe diesen Punkt aus den Nachteilen entfernt.

• Nicht klar ist mir, warum Komponenten keinen Zustand haben sollten (Seite 8 oben sowie Abschnitt 4.2). Wozu bieten dann Frameworks beispielsweise Persitenz als Dienst für Komponenten an? Was ist denn der Vorteil von zustandslosen Komponenten bzw. was wäre denn der Nachteil, wenn Komponenten Zustände hätten?

• Mir ist nicht klar, warum die Tatsache, daß Komponenten in übersetzter Form (als ausführbare Dateien) verteilt werden dazu führt, daß sie mehr Ähnlichkeit mit Objekten als mit Klassen haben. Sind Objekte nicht vielmehr Laufzeitgebilde und können deswegen gar nicht ausgeliefert werden? Werden zum Beispiel in Java nicht Klassen in ausführbare Dateien übersetzt? Umformuliert und Verlgeich zu Objekten entfernt.

• Auch stimmt es nicht, daß Standards für Komponenten meist auf den ausführbaren Code bezogen sind. Während Ihre bisherige Darstellung (insbesondere die Existenz von Containern) stark vom J2EE-Komponentenmodell geprägt war, scheint es in Abschnitt 4.4 auf einmal mehr um COM oder ähnliches zu gehen. Etwas umformuliert, Binärstandards sind nötig, nicht die Basis.

• In Abschnitt 4.6.2 schreiben Sie, daß das Verhalten von Komponenten durch Vor- und Nachbedingungen formell vergleichbar wird. Ist das wirklich so? Wie geht das? Und warum werden durch Vor- und Nachbedingungen Implementierungsdetails freigegeben?

Bitte nochmal querlesen. --Dashel 17:48, 22. Jan 2006 (CET)

• Abschnitt 4.7: Warum ist das Zuweisungsaxiom nicht mehr ohne weiteres gültig, wenn x und y Referenzen auf Objekte sind? Müßten sie dazu nicht viel mehr Referenzen auf Variablen sein? Außerdem beziehen Sie in diesem Abschnitt nur undeutlich zur Unterscheidung zwischen Objekten und Komponenten Position. Möchten Sie vielleicht vorschlagen, das Aliasing-Problem für Objekte als charakteristisch hinzunehmen und die komponententechnologie von der Objekttechnologie dadurch abzugrenzen, daß sie das Alias-Problem in den Griff bekommt? Das wäre ein hartes Kriterium für ein Komponentenbegriff!

• Kapitel 5, 1. Absatz: es ist nicht klargeworden, wo und in welchen Punkten die komponentenbasierte Software-Entwicklung Schwächen der rein objektorientiert aufgebauten Systeme vermeidet. Vielleicht könnten Sie das deutlicher herausarbeiten und zur Kernaussage Ihrer Arbeit machen.

Ich glaube mittlerweile, dass der Hauptvorteil der Komponentenbasierten Entwicklung die 'Paketierung' ist. Es gibt jetzt also auf höherer Ebene eine weitere, sehr strenge Kapselung an der Komponentengrenze. Siehst Du das anders? --Dashel 17:34, 22. Jan 2006 (CET)

Der eine oder andere Rechtschreibfehler wartet noch auf Verbesserung :)

Gutachten 3

Abgearbeitet --Dashel 17:31, 22. Jan 2006 (CET)

Zusammenfassung: Die vorliegende Arbeit stellt die objektorientierte Programmierung der komponemtenbasierten Softwareentwicklung gegenüber und stellt Verbindungen zwischen beiden her. Dabei werden die Gemeinsamkeiten, aber auch die Unterschiede der beiden Paradigmen dargestellt und in Bezug gesetzt.

Offene Punkte / Fragen:

• worin liegt der Unterschied zwischen Klassifikation und Klassenkonzept in Abschnitt 2.1 / 2.1.1?

Klassifikation ist erstmal eine allgemeine Einordnung. Das Klassenkonzept dagegen ist ein Strukturmittel der Objektorientierung. Zusammen mit Subtyping setzt es das Klassenkonzept um.

• Ist es wirklich so, dass die komponentenbasierte Programmierung aus der objektorientierten entwickelt wurde? Meines Wissens nach hat sie sich eher OOP zu einem bestimmten Zeitpunkt als neue, dann zur Verfügung stehende Basis angeeignet, da sie besser geeignet erschien als bisher vorhandenes. Das war in der Schlussfolgerung ganz zu Beginn, habs etwas umformuliert.

• Gibt es keine Sprachen, die die Anforderungen bzw. Implementierungsrestriktionen durch den Compiler überprüfen (Abschnitt 3.4.1)? Habe den Abschnitt etwas umformuliert, aber generell würde ich sagen "Nein", da ja CBD vom Grundprinzip her flexibel ist und Komponenten austauschbar sein sollen, da können dann gewisse Sachen einfach nicht mehr zur Laufzeit überprüft werden.

Verbesserungsvorschläge:

• Abschnitt 3.4.2: "Applikationsserver (engl. Container)" - das ist so sicherlich nicht richtig. Entweder "genauer gesagt Container" oder die richtige Übersetzung "Application Server".

Kann ich nichts zu sagen, das Kapitel ist glaub ich von Dir, oder? --Dashel 20:41, 16. Jan 2006 (CET) Ausgebessert.

• Abschnitt 4.6.1: In Java können Schnittstellen direkt im Code dargestellt werden, dies ist aber als schlechter Stil bekannt und wird normalerweise durch die explizite Verwendung von Interfaces ersetzt, und damit wie in ADA behandelt

Den Kommentar versteh ich nicht. Auch nicht, wohin er führen soll. --Dashel 15:09, 21. Jan 2006 (CET) Ich denke das spielt darauf an, dass auch Java eine Art "unabhängige Schnittstelle" zulässt und somit der Kommentar im Abschnitt nicht ganz korrekt ist. Habs mal ein wenig umformuliert.

• durchgängige Verwendung einer Akkürzung für komponentenbasierte Softwareentwicklung. Mal wird CBSE, mal CBSD verwendet. Weiterhin wird die mir bekannteste, auch in der Literatur verbreitete Abkürzung CBD (Component based Development) überhaupt nicht erwähnt).

Ich denke, da hat er recht, wir sollten uns auf eine der Abkürzungen einigen. Welche ist mir egal. Du kannst also gern entscheiden. --Dashel 20:41, 16. Jan 2006 (CET) Generell CBD verwenden, CBSE und CBSD erwähnt.

Fazit: Die Arbeit lässt sich sehr gut lesen, und sie vermittelt einen guten Einstieg in die Thematik. Trotz einiger kleinerer Rechtschreibfehlern ist die Form sehr angenehm und durchgängig. Inhaltlich habe ich persönlich einige kleinere Kritikpunkte, die vermutlich auf meiner persönlich Einschätzung beruhen.

• So wird in der anfänglichen Zusammenfassung erwähnt, dass das Hauptaugenmerk auf Specification Matching und Object Aliasing liegt, wobei im eigentlichen Text dann speziell Ersteres nur sehr kurz behandelt wird.

• Weiterhin erscheinen mir einige Aussagen, z.B. in Abschnitt 2.2 oder 3.1, recht unreflektiert aus der jeweiligen Literatur (die ja jeweils einen bestimmten Fokus hat) übernommen worden zu sein. Dies hinterlässt bei mir den Eindruck, dass bestimmte Teile lediglich eine Zusammenfassung der in bestimmter Literatur verbreiteten Meinung sind, ohne eigene Interpretation. Das ganze ist ja vom Ansatz her eine Literaturarbeit, daher werden wir diesen Kommentar eher nur am Rand beachten.

Trotz dieser Kritikpunkte halte ich die Arbeit für durchaus gelungen, und als Einführung in die Materie für gut geeignet.