Diskussion:Modul (Software)
Füge neue Diskussionsthemen unten an:
Klicke auf , um ein neues Diskussionsthema zu beginnen.| Zum Archiv |
| Auf dieser Seite werden Abschnitte ab Überschriftenebene 2 automatisch archiviert, die seit 30 Tagen mit dem Baustein {{Erledigt|1=--~~~~}} versehen sind. |
Modul vs. PlugIn
BearbeitenSehr unscharf formuliert, Plugin und Modul sind nicht identisch, ... -- S.K. 18:37, 4. Dez 2004 (CET)
Keine klare Abgrenzung zwischen Modul und Komponente
BearbeitenEs sollte dringend eine Abgrenzung von Software-Modul, -Komponente und -Service erfolgen. Dies ist heute insbesondere in Bezug auf Systemarchitekturen und SOAs notwendig.
Sind denn nun eigentlich Komponente und Modul das gleiche? Das geht aus diesem Artikel nicht hervor...
---
Das würde mich auch sehr interessieren. Ich schreibe gerade eine Dokumentation zu einem Studienprojekt bei der ich momentan noch wild mit den Begriffen Komponente und Module umher werfe und mich gar nicht von dem Problem befreien kann, denn mein Thema handelt um komponentenorientierte Anwendungen. In einer zu untersuchenden Anwendung ist aber die Rede von Modulen, nicht von Komponenten. Die Abbildung von Komponenten und Modulen in Java (C++ etc. wahrscheinlich auch) scheint aber gleich. Die Definition von Software-Komponenten kann man zum Beispiel von Szyperski übenehmen (Component Software - Beyond object-oriented programming):
A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties.
Ok, was soll nun eine abgeschlossene Komponente sein? Sind Komponenten und Module nicht ohnehin "abgeschlossene" Bereiche, deren Kommunikation in OO-Systemen über Schnittstellen definiert wird und die Kommunikation NUR über die in den Methoden definierten Methoden stattfindet? Sind Module schlichtweg nur eher ein Implementationsbegriff und Komponenten ein Begriff aus der Modellierung, bei dem sich bisher niemand die Mühe gemacht hat, entweder klar abzugrenzen oder zu sagen: "Das ist das gleiche" ?
Vielleicht besitzt ein Modul auch nur eine Teilmenge der Anforderungen, welche in einer Komponente gefordert werden, z.B. die Definition von Vertragsverbindung. Vertragsbedingungen können durch angemessene Programmierung schon zur Entwicklungszeit berücksichtigt werden, so dass eine Modulimplementation diese für die Laufzeit nicht mehr berücksichtigen muss. (Stichwort: Statische Analysen der Vertragsbedingungen) Kann man folglich eine Komponente als eine Metabeschreibung eines Moduls definieren, bei der Kriterien sowohl implizit als auch explizit im Quelltext umgesetzt werden?
--Miwoe 13:28, 24. Apr. 2009 (CEST)
-- 1. Eine Komponente definiert seine Schnittstellen nach Flexibilität, wegen der Wiederverwendbarkeit die erzielt werden soll. Denn nur so, ist dann dieser Software-Teil wiederverwendbar an mehreren Stellen. Die Flexibilität geht aus der Definition hervor: "Eine Software-Komponente ist ein Software-Element, das konform zu einem Komponentenmodell ist und gemäß einem Composition-Standard ohne Änderungen mit anderen Komponenten verknüpft und ausgeführt werden kann.". Daraus folgt: -1- Ein "Komponentenmodell" muss durch seine angeforderte Verknüpfungs- bzw. Kompositionsmöglichkeiten flexibel gestaltet sein. -2- Eine Komponente besitzt durch die genannten "Composition-Standards" flexibel ausgelegte Schnittstellen (Komponenten-Interfaces) -3- Damit "Komponenten verknüpft" werden können müssen die Schnittstellen flexibel sein.
2. Software-Module und Softwarekomponenten sind beides Teile einer Software. Software-Module sind zwar oft wiederverwendbar, aber sie sind nicht gezielt entwickelt worden um wiederverwendbar zu sein, sondern sie wurden aus anderen Gründen als ein abgekapselter Software-Teil erstellt. Beispielsweise werden Software-Module im Ausland, anderem Entwicklungs-Team oder in einer Fremdfirma erstellt und sollen später an ein anderes (Nachbar-)Modul oder ein Hauptsystem gekoppelt werden. Ein anderes gutes Beispiel in der Praxis, dafür dass Module abgekoppelt von anderen Systemen erstellt werden ist, dass gewisse Teile der Software aus Sicherheitsgründen nicht gesehen werden sollen. Daher kommt der Begriff 'Software-Modul' auch aus dem Management-Bereich. Deswegen werden die Schnittstellen eines Moduls auf ihr Nachbarmodul oder Hauptsystem hin abgestimmt (d.h. die Schnittstellen werden so bereitgestellt, dass sie später zu den Nachbarmodul oder Hauptsystem passen) und sind nicht unbedingt für das wiederholte Einsetzen gedacht.
3. Die folgende Beschreibung ist falsch: "Nicht zu verwechseln ist ein Modul mit einer Komponente, die in der Funktionalität eine Hierarchieebene höher angesiedelt ist und hier funktionale Module zu Diensten zusammenfasst.", da mich brennend interessieren würde, welche Hierarchieebene das sein sollen. Etwa die des Funktionalitätsumfangs? Das Komponenten durch ihre hohe Anpassungsfähigkeit an mehrere Umgebungen, mehr Funktionalität besitzen, kann man so beschreiben. Das ist aber dann indirekt beschrieben. Mich stört dass Komponenten angeblich funktionalen Module zu Diensten zusammenfassen soll. Das sind oft nicht nur Module die da zusammengefasst werden! Das können auch monolithische Implementierungen sein, Funktionen im Quellcode, Teilkomponenten oder eine (vielseitige) Mischung aus diesen.
Fazit: Hauptziel eines Software-Moduls ist nicht die Wiederverwendbarkeit, da dies neben der Anpassungsfähigkeit das Hauptziel einer Softwarekomponente ist. Das Hauptziel eines Software-Moduls ist die Abkapselung zu einem anderem Software-System, um beispielsweise unabhängig neben anderer Software entwickelt werden zu können.
-- (nicht signierter Beitrag von 82.195.74.129 (Diskussion) 16:55, 3. Feb. 2012 (CET))
- Soweit ist das wohl richtig. Jetzt muss voriger Beitrag nur noch sinnvoll in den Artikel wandern - nicht jeder Satz davon ist einfach zu verstehen oder unmissverständlich ausgedrückt.
- Ach was soll's, das kommt jetzt einfach 1:1 in den Artikel, soll's dort schrittweise Verbesserung erfahren...
- --arilou (Diskussion) 16:36, 20. Jun. 2012 (CEST)
- Bitte zuerst ausdiskuttieren - du kannst nicht einfach die Diskussion (inkl. Aussagen wie ~"das was oben im Artikel steht ist falsch") in den Artikel reinnehmen. Zuerst bitte für den Artikel umformulieren - so wie du selbst gesagt hast: "Jetzt muss voriger Beitrag nur noch sinnvoll in den Artikel wandern - nicht jeder Satz davon ist einfach zu verstehen oder unmissverständlich ausgedrückt.".
- Ähm, nö, bin ich anderer Meinung (siehe auch Inklusionismus sowie (ausführlicher) in meta:Inklusionismus).
- Etwas angepasst hab' ich's bereits, soll der Abschnitt doch weiter im Artikel reifen.
- Bei dem derzeit grausigen Zustand des Artikels ist das 'ne Verbesserung. Und bzgl. "nicht jeder Satz davon ist einfach zu verstehen oder unmissverständlich ausgedrückt" - jeder darf es gerne im Artikel überarbeiten.
- --arilou (Diskussion) 09:56, 22. Jun. 2012 (CEST)
- PS: Hier sind Beiträge von Apr.2009, und selbst obiger ist vom Februar und schon Monate alt. Wenn niemand was unternimmt (was ich jetzt getan habe), tut sich da nix mehr.
- PPS: Lieber Benutzer:Sebastian.Dietrich, da gibt's eine schöne Sitte, dich sich mittels --~~~~ pflegen lässt...
- @Unterschrift - sorry, hab ich vergessen
- @Verbesserung - ist es nur dann, wenn es nicht dem Rest des Artikels widerspricht. Aussagen wie "Eher falsch ist: <das was oben steht>" sind keine Verbesserung. Zu den Punkten selbst vermute ich, dass das die Meinung einer IP ist und nirgendwo belegbar ist. Ich vermute auch, dass das prinzipiell nicht falsch ist, aber mit einem Beleg wärs wesentlich besser. Ausserdem ists mMn viel zu viel Geschwafel nur für eine Abgrenzung. Wenn dann sollte der Satz "Nicht zu verwechseln ist ein Modul mit einer Komponente, die in der Funktionalität eine Hierarchieebene höher angesiedelt ist und hier funktionale Module zu Diensten zusammenfasst." verbessert/ergänzt werden und nicht ein riesiger Abschnitt für die Abgrenzung. --Sebastian.Dietrich ✉ 17:07, 22. Jun. 2012 (CEST)
- "Eher falsch ist: <das was oben steht>" ist imho durchaus eine Verbesserung - wenn das, was weiter oben steht, tatsächlich eher falsch ist.
- Zu viel Geschwafel: Du darfst es gerne kürzer ausdrücken.
- Wenn ich die Zeit dazu finde, tob' ich mich vielleicht selbst etwas aus - aber bis dahin: Sei mutig! --arilou (Diskussion) 18:48, 22. Jun. 2012 (CEST)
Kritik an den Begriffsdefinitionen
BearbeitenDer Begriff des Moduls ist im Duden als "austauschbares, komplexes Element innerhalb eines Gesamtsystems, eines Gerätes oder einer Maschine, das eine geschlossene Funktionseinheit bildet" definiert. Im Artikel heißt es "Ein Modul kann selbst weitere Module aufrufen". Dies bedarf zumindest eines Quellenverweises, da die Duden-Definition diese Auslegung nicht mit einschließt und diese auch nicht als logisch erscheint. Da ein Modul eine abgeschlossene Einheit darstellt ist nachvollziehbar, dass andere Module gekapselt (beinhaltet) werden können, jedoch eben nicht aufgerufen.
Ein Modul sei außerdem "Nicht zu verwechseln .. mit einer Komponente". Anhand der gegebenen Informationen umfasst eine Komponente mehrere Module, wobei diese unterschiedliche Aufgaben (geschlossene Funktionseinheiten) bereit stellen können. Laut der Informationen verbinden Komponenten Module zu Services, was bedeuten würde, dass ein Service unterschiedliche Funktionseinheiten beinhalten muss (ist das so?).
Man sollte den Text außerdem so ändern, dass er eine andere Interprätation des Begriffes Komponente zulässt, da eine Komponente nicht zwangsweise ein Service darstellen muss.
Da ich das Thema aus Sicht eines SW-Testers analysieren wollte, muss ich zudem anmerken, dass die Begriffe Modul und Komponente hier wieder anders verstanden werden. Unter einem Modul(-Test) wird nämlich meist das gleiche verstanden wie unter einem Unit(-Test), also ein Test, welcher sich nur auf eine einzelne Methode bezieht, während sich Komponenten(-Tests) auf die Kommunikation zwischen einzelnen Methoden beziehen. Eigentlich hatte ich gehofft hier lesen zu können, dass der Begriff des Modultests meist falsch in der Literatur verwendet wird, da ein Modul eben mehrere Methoden beinhalten kann und somit eher mit einem Komponenten-Test gleichgesetzt werden sollte. Anhand des Wikipedia-Artikels kann ich jedoch noch nicht einmal den Begriff des Moduls definieren, da dieser wie beschrieben von der im Duden genannten Def. abweicht. (nicht signierter Beitrag von 80.254.148.43 (Diskussion) 16:10, 14. Okt. 2013 (CEST))
- Siehe auch Modultest--Sebastian.Dietrich ✉ 17:21, 14. Okt. 2013 (CEST)
- Wie bei vielen Informatik-Themen (v.a. jenen Begriffen, die's seit Jahrzehnten gibt), wird der Begriff "Modul" (selbst beschränkt auf die Software-Entwicklung) an vielen Stellen verwendet, oft in (mehr oder weniger) unterschiedlicher Bedeutung. Den allgemeinen Duden sollte man da tunlichst außenvor lassen; allenfalls eine spezielle Informatik-Version könnte ernsthaft beitragen. Die Einleitung ist daher ziemlich unspezifisch gehalten, um den Großteil der Bedeutungen abzudecken.
- 1) Duden-Definition: Soweit ich das sehe, liegt der Artikel doch recht dicht an der Duden-Definition? "abgeschlossene funktionale Einheit" vs. "geschlossene Funktionseinheit"
- 2) "einbinden/aufrufen": Ja, (fast) richtig. Aus Sicht eines Compilers/Linkers: Es ist natürlich unsinnig, ein Modul (bzw. eine Methode daraus) aufrufen zu wollen, das nicht eingebungen ist (dann fehlt ja die zugehörige Implementierung) - aber genauso, ein Modul einzubinden, ohne daraus etwas zu verwenden ~ dann kann man's auch weglassen. Fazit: Ein Modul muss sowohl eingebunden als auch aufgerufen werden. Ich war mal so frei, das im Artikel entsprechend ein wenig umzuformulieren.
- 3) "Modul/Komponente/Service": Nun, es soll auf jeden Fall verdeutlicht werden, dass es eine "Rangordnung" oder "Hierarchie" gibt:
- Modul < Komponente < Dienst(/Service)
- Der Artikel schließt nicht aus, dass eine Komponente auch nur 1 Modul einbinden kann (mehrere = 1..n); auch kann eine Komponente mehrere Dienste anbieten, oder umgekehrt ein "Dienst" die Zusammenarbeit mehrerer Komponenten benötigen. Dennoch ist ein "Dienst" oder "Service" hierarchisch i.A. höher einzustufen, als eine Software-Komponente. Insofern bleibt: "Ein Dienst stellt mindestens 1 Funktionalität zur Verfügung, wofür die (den Dienst bereitstellende) Softwarekomponente mindestens 1 Modul einbinden muss." So klarer?
- 4) Im Artikel fällt der Begriff "Service" nicht, sondern "Dienst". Sei vorsichtig damit, hier einfach eine 1:1-Übersetzung anzunehmen. Eine Bibliothek bietet einem Hauptprogramm durchaus Dienst(leistung)e(n) an, was noch lange kein SOAP-/XML-Service darstellt. Hier im Artikel wird das Wort "Service" nämlich durchaus bewusst vermieden.
- 5) Dass ein "Unittest" auf genau 1 Methode beschränkt wäre, ist mir neu. Steht auch hier in der Wikipedia durchaus anders (siehe Modultest): Er steht für das Testen einzelner Methoden, eines Moduls, bis hin zu einer kompletten Komponente. Mehrere Komponenten wird dann ein Integrationstest.
- Ich denke, du bist genau über meine erste Aussage gestolpert, dass Begriffe wie "Modul", "Komponente", "Unit", an vielen Orten und in vielen Zusammenhängen immer wieder (mehr oder weniger) unterschiedlich verwendet werden. Wenn (in deinem Umfeld) "Modul" mit "einzelne Methode" gleichgesetzt wird, und du für eine "Menge funktional zusammengehöriger Methoden" schon "Komponente" benötigst, tja.
- --arilou (Diskussion) 10:08, 15. Okt. 2013 (CEST)
Defekter Weblink
Bearbeiten| Der folgende Weblink wurde von einem Bot („GiftBot“) als nicht erreichbar erkannt. |
|---|
|
- http://office.microsoft.com/de-ch/access-help/erstellen-einer-visual-basic-prozedur-HP005186705.aspx
- Vielleicht ist eine archivierte Version geeignet: archive.org