Andere Kunden interessierten sich auch für
![Automatisierte Windows 10-Installation mit der Baramundi Management Suite]( "Automatisierte Windows 10-Installation mit der Baramundi Management Suite")
Automatisierte Windows 10-Installation mit der Baramundi Management Suite17,95 €![Grundlagen zur Steuerung von Komponenten der Thermostation mit dem]( "Grundlagen zur Steuerung von Komponenten der Thermostation mit dem")
Grundlagen zur Steuerung von Komponenten der Thermostation mit dem35,90 €![Segmentierung von Textkomponenten mit der Analyse verbundener Komponenten im DAR]( "Segmentierung von Textkomponenten mit der Analyse verbundener Komponenten im DAR")
Segmentierung von Textkomponenten mit der Analyse verbundener Komponenten im DAR43,90 €![Automatisierte Personalsysteme]( "Automatisierte Personalsysteme")
Automatisierte Personalsysteme39,90 €![Automatisierte Lösungen zur Software-Fehlersuche]( "Automatisierte Lösungen zur Software-Fehlersuche")
Automatisierte Lösungen zur Software-Fehlersuche39,90 €![Automatisierte Diagnostik]( "Automatisierte Diagnostik")
Automatisierte Diagnostik19,50 €![Arbeitsabläufe und Software-Komponenten]( "Arbeitsabläufe und Software-Komponenten")
Arbeitsabläufe und Software-Komponenten39,90 €
Diplomarbeit aus dem Jahr 2006 im Fachbereich Informatik - Software, Note: 1,5, Freie Universität Berlin (Mathematik und Informatik, Informatik), Sprache: Deutsch, Abstract: Inhaltsangabe:Zusammenfassung:
Die komponentenbasierte Software-Entwicklung ist die Lösung der Softwaretechnik zu einer Modularisierung der Software, die zu einer erhöhten Wiederverwendung, Qualität, Wartbarkeit und Flexibilität führt. Es haben sich mittlerweile mehrere Komponentenmodelle (COM Component Object Model von Microsoft, Java Beans, Enterprise Java Beans, .NET, CORBA Component Model usw.) mit verschiedenen Vor- und Nachteilen in der Software-Industrie etabliert. Die Investitionen in die Entwicklung von Komponenten sind in den letzten Jahren enorm gestiegen und es besteht bereits ein beachtlicher Bestand an Software-Komponenten.
Immer häufiger wird der Weg der Integration einer bestehenden Komponente als die Neuentwicklung gewählt. Wegen der Heterogenität der Komponentenmodelle und ihrer Laufzeitumgebungen kann man leider nicht ohne weiteres eine Komponente für eine bestimmte Laufzeitumgebung in einer anderen Laufzeitumgebung, die mit der ersten inkompatibel ist, nutzbar machen. Wenn die Interaktionsstile in den beiden Umgebungen aufrufbasiert und die Unterschiede nur technischer Natur sind, kann eine aufrufbasierte Middleware für Fernaufrufe wie CORBA weiterhelfen, die Implementierungen in vielen Programmiersprachen vorzuweisen hat. Wenn die Laufzeitumgebungen vom Prinzip her unterschiedliche Interaktionsstile aufweisen, kann der Ansatz von Prof. Dr.-Ing. Klaus-Peter Löhr zum Einsatz kommen, der dieser Arbeit zugrunde gelegt wurde.
Er stellt eine weitgehende Generalisierung des generator-gestützten Vertreter-Treiber-Ansatzes von CORBA dar (bekannt im Englischen als Proxy/Driver oder Stub/Skeleton ). Ziel ist es, dass die Vermittlung zur Komponente für den Nutzer völlig transparent abläuft, so dass der Anschein erweckt wird, als wäre die Komponente speziell für die gewünschte Umgebung geschaffen worden. Zu diesem Zweck wird ein kanonischer Interaktionsstil definiert, auf den alle zu unterstützenden Interaktionsstile abgebildet werden können. Die Schnittstelle der Komponente wird in AID (Abstract Interface Definition), eine speziell für den kanonischen Interaktionsstil entwickelte Sprache, beschrieben. Nun können auf dieser Basis die Generatoren für die gewünschte Umgebung bzw. die Umgebung der Komponente einen Vertreter bzw. einen Treiber zur Komponente erstellen. Vertreter und Treiber kommunizieren über einen Kommunikationskanal, da sie in unterschiedlichen Umgebungen laufen.
Im Rahmen dieser Arbeit wurde eine Lösung zur Realisierung des kanonischen Interaktionsstils zwischen Vertreter und Treiber mittels CORBA-Fernaufrufen konzeptionell erarbeitet und praktisch umgesetzt. Nach einer Analyse des Interaktionsstils und der Schnittstellen von .NET-Komponenten wurde die Abbildung des Interaktionsstils von .NET auf den kanonischen und umgekehrt spezifiziert und im Vertreter und Treiber für das .NET Framework praktisch realisiert. Zu guter Letzt werden die Vertreter und Treiber mit Hilfe des entwickelten Generators automatisiert generiert.
Die Semantik, die Syntax und das Typsystem von AID mussten zusammen mit Prof. Löhr, seinen wissenschaftlichen Mitarbeitern und Daniel Nowak genau konkretisiert werden. Nur dadurch konnte ein für alle Generatoren verbindliches AID-IDL Mapping spezifiziert werden. Parallel zu dieser Arbeit liefen die Entwicklungsarbeiten an Generatoren für die Interaktionsstile bei Message-Driven Beans, Unix-Filter-Programmen und Komponenten, die über Java Tuplespaces interagieren.
Inhaltsverzeichnis:Inhaltsverzeichnis:
KurzfassungV
InhaltVII
1.Einleitung und Zielsetzung1
1.1Wiederverwendung von Software1
1.2Komponentenbasierte Software-Entwicklung1
1.3Integration von Komponenten1
1.4Interak...
Hinweis: Dieser Artikel kann nur an eine deutsche Lieferadresse ausgeliefert werden.
Die komponentenbasierte Software-Entwicklung ist die Lösung der Softwaretechnik zu einer Modularisierung der Software, die zu einer erhöhten Wiederverwendung, Qualität, Wartbarkeit und Flexibilität führt. Es haben sich mittlerweile mehrere Komponentenmodelle (COM Component Object Model von Microsoft, Java Beans, Enterprise Java Beans, .NET, CORBA Component Model usw.) mit verschiedenen Vor- und Nachteilen in der Software-Industrie etabliert. Die Investitionen in die Entwicklung von Komponenten sind in den letzten Jahren enorm gestiegen und es besteht bereits ein beachtlicher Bestand an Software-Komponenten.
Immer häufiger wird der Weg der Integration einer bestehenden Komponente als die Neuentwicklung gewählt. Wegen der Heterogenität der Komponentenmodelle und ihrer Laufzeitumgebungen kann man leider nicht ohne weiteres eine Komponente für eine bestimmte Laufzeitumgebung in einer anderen Laufzeitumgebung, die mit der ersten inkompatibel ist, nutzbar machen. Wenn die Interaktionsstile in den beiden Umgebungen aufrufbasiert und die Unterschiede nur technischer Natur sind, kann eine aufrufbasierte Middleware für Fernaufrufe wie CORBA weiterhelfen, die Implementierungen in vielen Programmiersprachen vorzuweisen hat. Wenn die Laufzeitumgebungen vom Prinzip her unterschiedliche Interaktionsstile aufweisen, kann der Ansatz von Prof. Dr.-Ing. Klaus-Peter Löhr zum Einsatz kommen, der dieser Arbeit zugrunde gelegt wurde.
Er stellt eine weitgehende Generalisierung des generator-gestützten Vertreter-Treiber-Ansatzes von CORBA dar (bekannt im Englischen als Proxy/Driver oder Stub/Skeleton ). Ziel ist es, dass die Vermittlung zur Komponente für den Nutzer völlig transparent abläuft, so dass der Anschein erweckt wird, als wäre die Komponente speziell für die gewünschte Umgebung geschaffen worden. Zu diesem Zweck wird ein kanonischer Interaktionsstil definiert, auf den alle zu unterstützenden Interaktionsstile abgebildet werden können. Die Schnittstelle der Komponente wird in AID (Abstract Interface Definition), eine speziell für den kanonischen Interaktionsstil entwickelte Sprache, beschrieben. Nun können auf dieser Basis die Generatoren für die gewünschte Umgebung bzw. die Umgebung der Komponente einen Vertreter bzw. einen Treiber zur Komponente erstellen. Vertreter und Treiber kommunizieren über einen Kommunikationskanal, da sie in unterschiedlichen Umgebungen laufen.
Im Rahmen dieser Arbeit wurde eine Lösung zur Realisierung des kanonischen Interaktionsstils zwischen Vertreter und Treiber mittels CORBA-Fernaufrufen konzeptionell erarbeitet und praktisch umgesetzt. Nach einer Analyse des Interaktionsstils und der Schnittstellen von .NET-Komponenten wurde die Abbildung des Interaktionsstils von .NET auf den kanonischen und umgekehrt spezifiziert und im Vertreter und Treiber für das .NET Framework praktisch realisiert. Zu guter Letzt werden die Vertreter und Treiber mit Hilfe des entwickelten Generators automatisiert generiert.
Die Semantik, die Syntax und das Typsystem von AID mussten zusammen mit Prof. Löhr, seinen wissenschaftlichen Mitarbeitern und Daniel Nowak genau konkretisiert werden. Nur dadurch konnte ein für alle Generatoren verbindliches AID-IDL Mapping spezifiziert werden. Parallel zu dieser Arbeit liefen die Entwicklungsarbeiten an Generatoren für die Interaktionsstile bei Message-Driven Beans, Unix-Filter-Programmen und Komponenten, die über Java Tuplespaces interagieren.
Inhaltsverzeichnis:Inhaltsverzeichnis:
KurzfassungV
InhaltVII
1.Einleitung und Zielsetzung1
1.1Wiederverwendung von Software1
1.2Komponentenbasierte Software-Entwicklung1
1.3Integration von Komponenten1
1.4Interak...
Hinweis: Dieser Artikel kann nur an eine deutsche Lieferadresse ausgeliefert werden.