Das sollten Sie in der Vorlesung lernen

Präsentation zum Thema: "Das sollten Sie in der Vorlesung lernen"—  Präsentation transkript:

1 Das sollten Sie in der Vorlesung lernen
Was ist ein Modell und wie können wir es einsetzen (Kap.0) Was ist eine virtuelle Anlage und was nutzt sie (Kap.2) Wie aufwendig ist der Bau virtueller Anlagen im Vergleich zu realen Anlagen (Kap.3) HEUTE Techniken zum Bau virtueller Anlagen Der Rational Unified Process als Vorgehensmodell für die Softwareentwicklung (Kap.10) Die Unified Modelling Language als Basis der Modellierung (Kap.4) Komponententechnologie als Basis der Implementierung (Kap.5) Produktmodelle als Basis der Systembeschreibung (Kap.6) Gewöhnliche Differentialgleichungen als Basis der Beschreibung des Verhaltens (Kap.8) Das V-Modell als Basis des Qualitätsmanagements (Kap.11) Techniken zum Bau virtuellerSysteme Architekturen verteilter Systeme (Kap.9) Agenten zur Erbringung von Dienstleistungen (Kap.9)

2 Simulation komplexer technischer Anlagen
Teil I: Reale und virtuelle Anlagen Kapitel 3: Elemente zur Modellierung, Implementierung und zum Betrieb virtueller Anlagen Inhalt Erfahrungen vom Bau realer Anlagen Objekte als Elemente der Modellierung Nutzen der Objektorientierung Zusammenfassung von Objekten zu Komponenten und Diensten Komponentenbasierte Systeme

3 Das sollten Sie im 3. Kapitel lernen
Grenzen des klassischen Softwareengineering Elemente zum Bau virtueller Anlagen Objekte zur Modellierung Komponenten als Bausteine Implementierung Dienste als Elemente einer Arbeitsumgebung Grundzüge komponentenbasierter Systeme

4 Kurzfassung Kap. 3 Problemstellung Ziel der Vortragseinheit
Die Verwendung objektorientierter Techniken erlaubt es, die Produktivität aller an der Planung, Erstellung und Wartung von Softwareprodukten Beteiligten entschieden zu steigern. Drei Gründe lassen sich dafür angeben: - Objekte erleichtern die Modellierung komplexer Prozesse. - Objekttechniken helfen, den Bruch zwischen Analyse, Entwurf und Implementierung komplexer Systeme zu vermeiden. - Systeme, in denen Objekte über Botschaften wechselwirken, enthalten Bausteine, mit denen, ähnlich wie mit Komponenten technischer Systeme, wiederverwendbare Softwarekomponenten zur Verfügung stehen, die vielfach verwendet, flexibel umgruppiert und in neuen Anwendungen zusammengestellt werden können. Damit lassen sich auch Anwendungen angehen, die sokomplex sind, dass sie mit tradionellen Mitteln kaum oder nur mit ungewöhnlichen Anstrengungen realisiert werden können. Ziel der Vortragseinheit Ausgehend von den Erfahrungen der technischen Realisation von komplexen Anlagen und Systemen formulieren wir Eigenschaften von Objekten der technischen Welt. Sie werden charakterisiert durch die Dimensionen Daten, Funktionen und Zeit. Die Komplexität in den Daten kann durch Einführung abstrakter Datentypen reduziert werden. Funktionen können in Form von Modulen Details von einem Nutzer verbergen. Die Kapselung von Daten und Methoden führt zu Objekten. Schließt man die Dimension Zeit ein, so erhält man Prozesse und Dienste. Diese Begriffe werden eingeführt und es wird gezeigt, zu welchen Konsequenzen dies für die Modellierung von Softwaresystemen führen kann.

5 Erfahrungen vom Bau realer Anlagen
Reduktion der Komplexität durch Strukturierung der Anlage Diversifikation der Funktionalitäten Formalisierung der Beschreibung Wiederverwendung bewährter Objekte Systematisierung der Weiterentwicklung Techniken Identifizierung von Einheiten Beschreibung über Schnittstellen, Funktionen und Parametern Verwendung in verschiedenen Zusammenhängen Verfolgung der Änderungen über gesamte Lebensdauer

6 Erfahrungen vom Bau realer Anlagen
Integration der Teile im System Systemumfang mehrerer Personenjahre Systementwicklung interdisziplinär und iterativ Systemverständnis dynamisch (Änderung im Entwurf angelegt) Systemgrundlage theoriegestützt (Gesamtsystem mehr als Teile) Validierung des Systems Qualitätssicherung bei Komponenten, Subsystemen und Gesamtsystem Risikoanalysen Systemüberwachung durch regelbasierten Vergleich von Indikatoren

7 Technische Objekte reduzieren Komplexität
Sie werden allgemein beschrieben Sie haben ein definiertes Verhalten Sie sind vielfach verwendbar Sie sind eindeutig identifizierbar Sie werden über Schnittstellen angesprochen Botschaften - Daten oder Methoden Sie verbergen innere Details durch Kapselung von Daten und Methoden Sie können selber aus Objekten aufgebaut sein und erben deren Daten und Methoden Sie verändern sich mit der Zeit

8 Die drei Dimensionen eines Objektes
Technische Objekte Objekte im Softwareengineering benötigen Beschreibung - Produktdaten / Zustand haben Verhalten - Operationen / Funktionalität erfahren Veränderungen - Versionen / Geschichte Funktionale Komplexität Komplexität des zeitabhängigen Verhaltens Echtzeit- Systeme Simulations- Systeme Informations- Systeme Daten- Komplexität

9 SE-Methoden zur Reduktion der Komplexität
Zerlegung in Teilaufgaben Zeitliche Zerlegung - Software-Lebenszyklus Strukturierung der Beschreibung - Datenabstraktion, strukturierte Analyse Funktionale Zerlegung - Modularisierung Zerlegung von Funktionalitäten - Basisprinzipien zur Kapselung Abstraktionsprinzip Beschreibung Geheimnisprinzip Implementierung Schichtenkonzept Teilsysteme

10 Modellpräsentation im Software-Lebenszyklus
Die Brüche zeigen den Wechsel von einer Methode zu einer anderen. Meist bedeutet dies, dass bei Änderungen eines Entities der unteren Ebene nicht auf die Definitionen des entsprechenden Entities der darüberliegenden Ebene durchgegriffen werden kann. Anwender grundlegender Wechsel der Modell-Repräsentation z.B. SA z.B. SD klassische Prog.-Sprachen Analyse Design Implementierung "..muss unbedingt.." PROC .... IF.... WHILE.. X:=... u.s.w.

11 Grenzen der klassischen Entwurfsmethoden
Zeitliche Zerlegung zu starr, statt Wasserfall - Kreislauf mit der Möglichkeit der Iteration und der Verbesserung in kleinen Schritten Informationsquellen oft nur iterativ erfassbar. (z.B. Anwendungskenntnis, Quellenstudium, grundlegende Ereignisse) Datenflüsse zu inflexibel, statt abstrakten Datentypen - Beschreibung von Teilsystemen - Objekten. Funktionale Zerlegung zu prozedural (nur im Kleinen anwendbar), statt Zeitscheiben - Vernetzung.

12 Was wir brauchen Kapselung von Daten und Methoden und
Konstrukte für adäquate Modellierung - Objekte Durchgängige Methoden von Modellierung bis Programmierung - der Rational Unified Process Wiederverwendbarkeit bewährter Lösungen auf allen Ebenen - Klassen, Frameworks und Komponenten Verteilte Entwicklung durch Identifikation von Komponenten mit Kapselung von Daten und Methoden und Schnittstellen, die auch Semantik berücksichtigen Verteiltes Betreiben durch Dienste und Standardisierung der Kommunikation Gemeinsame Interpretation durch Produktmodelle

13 Die 3S im Softwareengineering
Simplifizierung durch bessere Konstrukte zur Modellierung Spezialisierung durch vertikale (Dienste) und horizontale (Komponenten) Kapselung von Daten und Methoden Virtuelle Anlagen Standardisierung von Schnittstellen und Kommunikation

14 Die 3 K im Softwareengineering
Kommunikation Elektronic Mail Adressbooks Shared Databases Kollaboration Electronic Discussions Electronic Meetings Shared Application Groupware Infrastructure Workflow Automation Scheduling Calendaring Koordination

15 Systemarchitektur Das Konzept für Kommunikation und Kooperation

16 Was ist ein Objekt ? [Meyers Enzyklopädisches Lexikon, 1976]:
Objekt: “Allgemeiner Gegenstand [des Interesses] insbesondere der einer Beobachtung, Untersuchung, Messung (...) unterworfene [materielle] Gegenstand [Jackson: "System Development", 1983] Reale Welt wird durch Entitäten beschrieben, sowie durch die Aktivität, die diese ausführen bzw. an ihnen ausgeführt werden ...enger Bezug zu Prozessmodell und geordneter Menge von Aktivitäten [Vetter: "Strategie der Anwendungssoftware-Entwicklung", 1988]: Realität manifestiert sich in Entitäten (individuelle, identifizierbare Exemplare von Dingen, Personen oder Begriffen ...) Entitäten repräsentieren die für eine Unternehmung relevanten Informationsobjekte [Booch, G.: Object-oriented Analysis and Design, 1994]: Ein Objekt hat einen Zustand, ein Verhalten und eine Identität: die Struktur und das Verhalten von ähnlichen Objekten ist festgelegt in ihrer gemeinsamen Klasse; die Begriffe Instanz und Objekt sind austauschbar.

17 Objekte und ihre Eigenschaften -1
sind identifizierbare Dinge, erinnern ihren eigenen Zustand, reagieren auf Anforderungen, ihren Zustand zu ändern, sind charakterisiert durch Eigenschaften vom Typ Daten (Instanz, Parameter, Zustandsvariablen) und Operation (Methoden), wechselwirken mit anderen Objekten durch Anfordern von Diensten oder Informationen. Objekte als identifizierbare Einheiten kapseln Daten und Operationen auf diese Daten, verbergen Implementierungsdetails (Beschreibung und Verhalten bilden Einheit) können Prozesse auf Rechner überdauern (Persistenz) Ein erster Ansatz für Objekte sind Datenobjekte als Instanzen abstrakter Datentypmodule

18 Wie beschreiben wir ein Objekt
Zustand - Menge von (normalerweise statischen) Eigenschaften, die das Verhalten des Objekts bestimmen (Attribute) - Die aktuellen (normalerweise dynamischen) Werte der Attribute. Verhalten - Definiert, wie ein Objekt auf Anfragen anderer Objekte reagiert - Wird durch eine Menge von Operationen für dieses Objekt definiert Identität - Die Identität eines Objekts ist die Eigenschaft, die es von allen anderen Objekten eindeutig unterscheidet - Name darf nicht mit Identität verwechselt werden.

19 1. Konstrukt: Klassen zur Beschreibung
Eine Klasse beschreibt eine Menge von Objekten mit gleicher Struktur und gleichem Verhalten Klassen existieren nicht als konkretes, greifbares Element Eine Klasse ist eine Abstraktion, die "Essenz eines Objektes" Eine Klasse verbirgt (kapselt) Datenstrukturen, Merkmale zur Implementierung und Kontrollfluss der Methoden Eine Klasse liefert Operationen, die verwendet werden, und Attribute, die Zustand beschreiben. Objekte sind Instanzierungen (konkrete Realisierungen) einer Klasse.

20 Objekte und ihre Eigenschaften -2
Objekte als Mitglieder einer Klasse Klassen beschreiben Struktur und Verhalten einer Menge von Objekten Unterklassen spezialisieren Oberklassen, indem sie von einer oder mehreren Oberklassen Instanzvariablen und Methoden erben Objekte als Teil eines neuen Ganzen - Komponenten Zusammengesetzte Objekte reduzieren Komplexität Zusammensetzung erfolgt über Assoziation, Kommunikation oder Relation Assoziationen verbinden Objekte zu größeren Einheiten Kommunikation vermittelt Anforderungen Relationen beschreiben gemeinsame Eigenschaften. Objekte als Klassen - geklonte Objekte Hat man eine Vielzahl gleicher Objekte, die sich nur durch ihre Identifikation unterscheiden, so kann man sie durch Klassen erzeugen (Serienproduktion). Das Objekt wirkt dann bezüglich der geklonten Objekte wie die Klasse bezüglich den Objekten.

21 Objekte und ihre Eigenschaften -3
Objekte und ihr Verhalten Polymorphie - verschiedene Objekte reagieren unterschiedlich auf die gleiche Botschaft Realisierung durch bedingte Eigenschaften Gleichzeitigkeit - Concurrency aktive Objekte sind laufende Prozesse Objekte und OOA Kapselung von statischem und dynamischem Verhalten (Daten und Methoden). Nicht alles sind Objekte. Keine Objekte sind z.B. Eigenschaften. Spezialisierung durch Vererbung ist nur dann sinnvoll, wenn die Unterklasse neue Eigenschaften hat. Zusammengesetzte Objekte sind nur dann sinnvoll, wenn sie neue Eigenschaften haben. Botschaften verbinden Objekte.

22 2. Konstrukt - Beziehungen
Beziehungen zwischen Objekten - Die Funktion eines Systems wird durch die Zusammenarbeit vieler Objekte erbracht - Objekte tauschen Botschaften - Objekte können aggregiert werden - Objekte können Methoden anderer Objekte benutzen. Beziehungen zwischen Klassen - Die Beschreibung eines Systems erfolgt durch Angabe der Klassen und ihrer Beziehungen - Wichtige Konstrukte Vererbung Klassen können erweitert werden Benutzung - Klassen können aus anderen Klassen aufgebaut werden Parametrisierung - Klassen können modifiziert werden

23 3. Konstrukt - Vererbung Klassen können Merkmale von einer (single-inheritance) oder mehreren (multiple-inheritance) Klassen übernehmen, modifizieren oder ergänzen. Die erbende Klasse heißt abgeleitete Klasse. Die vererbende Klasse ist die Oberklasse. Beispiel: - Klasse Bild referenziert - Klasse Fenster referenziert - Klasse Größe, Lage, Inhalt

24 Wie kann man Objekte finden ?
Als erste Antwort ergibt sich aus dieser Einführung: Objekte sind während der Modellierungsphase zu identifizieren - objektorientierte Analyse Objekte müssen durch Klassen beschrieben werden objektorientierter Entwurf. Bei der Abstraktion sind Konstrukte hilfreich wie Generalisierung - Spezialisierung Ganzes - Teil Benutzung Polymorphie Die ideale Aufteilung kann nur iterativ gefunden werden. Dabei nützen Methoden wie Datenmodellierung mit Entity Relationsship Diagrammen Funktionsmodellierung mit Modularisierungskonzept Verhaltensmodellierung mit Datenflussdiagrammen

25 Modellierung mit Objekten
sind Modelle der Eigenschaften und des Verhaltens von Elementen der realen Welt. Daher sind Objekte nicht wahr, aber brauchbar - nicht verifizierbar, aber validierbar - nicht richtig, aber nützlich. Das gilt bei der Suche nach Objekten und ihrer Abstraktionen in Klassen zu bedenken.

26 Technische Objekte reduzieren Komplexität
Sie werden allgemein beschrieben Sie haben ein definiertes Verhalten Sie sind vielfach verwendbar Sie sind eindeutig identifizierbar Sie werden über Schnittstellen angesprochen Botschaften - Daten oder Methoden Sie verbergen innere Details durch Kapselung von Daten und Methoden Sie können selber aus Objekten aufgebaut sein und erben deren Daten und Methoden Sie verändern sich mit der Zeit

27 Objekte im SE reduzieren Komplexität
Sie werden allgemein beschrieben Klassen + Attribute Sie haben ein definiertes Verhalten Klassen + Methoden Sie sind vielfach verwendbar Klassen + Instanzen Sie sind eindeutig identifizierbar Identität Sie werden über Schnittstellen angesprochen Botschaften - Daten oder Methoden Sie verbergen innere Details hinter Schnittstelle durch Kapselung von Daten und Methoden Sie können selber aus Objekten aufgebaut sein und erben deren Daten und Methoden Beziehungen Sie verändern sich mit der Zeit

28 1. Konstrukt: Klassen zur Beschreibung
Eine Klasse beschreibt eine Menge von Objekten mit gleicher Struktur und gleichem Verhalten Klassen existieren nicht als konkretes, greifbares Element Eine Klasse ist eine Abstraktion, die "Essenz eines Objektes" Eine Klasse verbirgt (kapselt) Datenstrukturen, Merkmale zur Implementierung und Kontrollfluss der Methoden Eine Klasse liefert Operationen, die verwendet werden, und Attribute, die Zustand beschreiben. Objekte sind Instanzierungen (konkrete Realisierungen) einer Klasse.

29 2. Konstrukt - Beziehungen
Beziehungen zwischen Objekten - Die Funktion eines Systems wird durch die Zusammenarbeit vieler Objekte erbracht - Objekte tauschen Botschaften - Objekte können aggregiert werden - Objekte können Methoden anderer Objekte benutzen. Beziehungen zwischen Klassen - Die Beschreibung eines Systems erfolgt durch Angabe der Klassen und ihrer Beziehungen - Wichtige Konstrukte Vererbung - Klassen können erweitert werden Benutzung - Klassen können aus anderen Klassen aufgebaut werden Parametrisierung - Klassen können modifiziert werden

30 3. Konstrukt - Vererbung Klassen können Merkmale von einer (single-inheritance) oder mehreren (multiple-inheritance) Klassen übernehmen, modifizieren oder ergänzen. Die erbende Klasse heißt abgeleitete Klasse. Die vererbende Klasse ist die Oberklasse. Beispiel: - Klasse Bild referenziert - Klasse Fenster referenziert - Klasse Größe, Lage, Inhalt und darin Objekte

31 Nutzen der Objektorientierung
Adäquate Modellierung Durchgängigkeit der Methoden Geheimnisprinzip und Lokalität Wiederbenutzbarkeit von „Komponenten“ und Klassen können verteilt entwickelt, implementiert und gewartet werden.

32 Adäquate Modellierung durch neue Konstrukte wie
Abstraktion Prozedurale Abstraktion Datenabstraktion Klassifikation Ordnung von Wissen Zuordnung Objekte zu Klassen Diversifikation Ganzes + Teile Aggregation Zusammenfassung von Teilen Verteilung Client-Server Strukturen Tausch von Botschaften über Schnittstellen Kapselung Dadurch wird es möglich komplexere Systeme einfacher zu beschreiben (modellieren). Notwendig Modellierungssprache mit entsprechenden Konstrukten

33 Durchgängigkeit der Methodik
Die Modellierung muss unterstützt werden durch adäquate Umsetzung bei Entwurf und Implementierung. Werkzeuge zur Unterstützung der Entwicklung objektorientierter Software müssen daher das Konstrukt Klasse in allen Phasen des Lebenszyklus unterstützen und eine möglichst automatisierbare Verwaltung der Objekte gewährleisten. Durchgängigkeit umfasst den horizontalen Methodenverbund (verschiedene Sichten innerhalb einer Phase im Lebenszyklus), den vertikalen Methodenverbund (Verwaltbarkeit aufeinander aufbauender Methoden zweier Phasen). Das erfordert Methoden für objektorientierten Entwurf und objektorientierte Programmierung, die Speicherung von Objekten und an die Objektorientierung angepasste Vorgehensmodelle zur Softwareerstellung und zum Qualitäts-management

34 Geheimnisprinzip und Lokalität
Information Hiding Wird beispielsweise ein ADT-Matrix erstellt, könnte er eine Datenstruktur enthalten, die die Repräsentation von Zeilen in einer Datenbank entspricht. Der Zugriff auf diese Struktur wird von außen zum Beispiel durch Funktionen wie "Gib Element (x,y)" oder "Berechne Determinante" vorgenommen. Wie die Matrix in der Datenbank bzw. im ADT dargestellt ist oder wie die Determinante bestimmt wird, ist das Geheimnis des ADT. Dieses erfolgreiche Prinzip kann allgemeiner eingesetzt werden Lokalität von Entscheidungen Entscheidungen werden dort getroffen, wo sie anfallen. Damit bleiben die Auswirkungen von Änderungen dieser Entscheidungen auf einen Modul beschränkt. Sprachen, die den Begriff der Ausnahme kennen, mögen durch die unterschiedliche Handhabung von Algorithmen für Normalfälle und zur Behandlung von Fehlern zur Vereinfachung der Programmstruktur beitragen, sie begünstigen aber die Trennung von Entdeckung und Behandlung von Fehlern und behindern so die Modulgeschütztheit. Verwendet man statt ADT's Klassen, so lassen sich diese Prinzipien konsequenter umsetzen.

35 Wiederverwendbarkeit und Änderbarkeit
Der Wunsch nach Wiederverwendbarkeit entsteht aus der Erfahrung, dass viele Teile von Software-Systemen nach ähnlichem Muster aufgebaut sind. Wiederverwendbarkeit ist deshalb wünschenswert, weil sie alle anderen Aspekte der Software-Qualität beeinflusst. Existierende und getestete Software genügt eher den Anforderungen nach Korrektheit und Robustheit und sie muss nicht mehr erstellt werden. Wiederverwendbarkeit ist anzustreben in den Bereichen Analyse, Entwurf und Implementierung Durch eine starke Kapselung nach innen (Information Hiding) und die lose Kopplung nach außen (Lokalität der Entwurfsentscheidungen) entstehen Code-Blöcke, die isoliert vom Rest eines Gesamtsystems betrachtet werden können. Das erhöht die Änderbarkeit und unterstützt die Wiederverwendbarkeit des Bausteins.

36 Technische Objekte sind mehr als Objekte des SE
Sie haben ein definiertes Verhalten, das sich nicht nur auf eine Datenstruktur bezieht - Komponenten und Dienste Sie sind vielfach verwendbar, auch in unterschiedlichen Kontexten - Verwendung der Semantik der Schnittstellen Sie verbergen innere Details durch Kapselung von Daten undIoder Methoden Sie sind in der Regel aus Objekten aufgebaut und erben deren Daten und Methoden Sie verändern sich mit der Zeit Diese Eigenschaften können im Rahmen der OO umgesetzt werden, sind aber nicht selber angelegt - Übergang zu Komponenten

37 Von Klassen zu Komponenten und Diensten
Aus Klassen werden Komponenten und Dienste, wenn sie außer Funktionalität auch Introspektion (Metainformation) anbieten Komponenten und Dienste geben dadurch der Entwicklungsumgebung Auskunft über ihre Schnittstelle (Parameter und Modelle) Komponenten und Dienste verbergen hinter ihrer Schnittstelle Details ihrer Implementierung. Diese muss daher nicht in einer oo-Sprache erfolgen Komponenten und Dienste ermöglichen eine neue Dimension der Anwendung und der Anwendungsentwicklung. Diese erfolgt unter Verwendung von Klassen, Pattern, Frameworks und Komponenten, die der Entwicklungskultur angepasst werden. Komponenten: Verwendung von Software (Entwicklungsaspekt) Dienste: Verwendung von Ergebnissen (Verteilungsaspekt)

38 Komponenten Eine Komponente ist ein unabhängiger, austauschbarer Teil eines Softwaresystems, der eine sinnvolle Aufgabe im Kontext einer Softwarearchitektur erledigt. Eine Komponente ist auch eine standardisierte, wiederverwendbare und im Vorfeld implementierte Einheit, welche benutzt wird, um Konstrukte einer Programmiersprache zu erweitern und Softwareanwendungen zu bauen. Eine Komponente kann mehrere Klienten haben, kennt aber nicht den Kontext in dem sie benutzt wird.

39 Anforderungen an Komponenten
Komponenten folgen einem oder mehreren Standards. Komponenten sind in sich geschlossen. Komponenten spezifizieren genau, was sie verlangen und liefern können. Komponenten sind konfigurierbar.

40 Die Stärken von Komponenten und Objekten
Objektorientierte Programmiersprachen wie Java, C++ und Smalltalk sind gut geeignet, um Komponenten und Applikationen zu realisieren. Objekte  programmiersprachliche Einheiten aus Datenstrukturen und Funktionen  Programmiermechanismen: Kapselung, Vererbung und Polymorphie  als Einheiten der Wiederverwendung zu klein  Klassenbibliotheken, Frameworks und Entwurfsmuster unterstützen Wiederverwendung, sind aber nicht leicht zu handhaben Analyse, Entwurf und Implementierung Komponenten  einsetzbare Software-Einheiten mit eigenständiger Funktionalität  über Schnittstellen schnell zu kompletten Applikationen kombinierbar  programmiersprachliche Realisierung im Prinzip egal  wichtigste Architekturen: COM, Java Beans und EJB, CCM  Komponentenmarkt insgesamt noch klein Anwendung

41 Eigenentwicklung vs. Komponentensoftware
Eigenentwicklung Komponentensoftware Vorteile: Entwicklung unterliegt eigener Kontrolle eine optimale Anpassung möglich Vorteile: standardisiert Wartung wird vom Komponenten-Anbieter übernommen Nachteile: teuer mit sehr großem Aufwand wartbar meistens „zu spät“ Nachteile: verlangt eine Anpassung an den Standard keine Wettbewerbsvorteile Entwicklung unterliegt nicht eigener Kontrolle

42 Komponentenarchitekturen
Komponentenarchitekturen stellen einen verteilungs-transparenten Kommunikationsmechanismus bereit. Komponentenarchitekturen regulieren Interaktion zwischen Komponenten und ihrer Umgebung. Komponentenarchitekturen definieren die Rollen einzelner Komponenten im System.

43 COM-Ansatz Component Object Model
IUnknown Bestandteile von COM: Schnittstelle (Interface) Implementierung Apartments COM Services IOleObject IDataObject IPersistStorage IOleDocument

44 Ziele der Komponentenorientierung
Beschleunigung der Anwendungsentwicklung Wiederverwendung vorgefertigter Bausteine Qualitätssteigerung Kostensenkung Einsatz unterschiedlicher Programmiersprachen Einbindung von Fremdkomponenten Skalierbarkeit der Anwendung Verteilte Anwendungen Plattform-Unabhängigkeit Als größer dimensionierte Software-Bausteine erleichtern Komponenten die Wiederverwendung und die Anwendungsentwicklung.

45 Software-Komponenten Eigenschaften in Bezug auf Bildung von Systemen
Besitzt Interkommunikationsfähigkeit - Einsatz über die Grenzen von Netzen, Sprachen, Protokollen, Adressräumen, Betriebssystemen und Werkzeugen hinweg Besitzt klare Schnittstelle - Von Implementierung getrennt - Wohldefinierte Kommunikation mit Außenwelt Ist keine vollständige Applikation Ist frei kombinierbar mit anderen Komponenten

46 Systeme aus Objekten, Komponenten und Diensten
Homogene Systeme ADT-Modul FKT-Modul Sammlung von Methoden, die auf eine Datenstruktur wirken Methode zur Verarbeitung von Datenstrukturen Implementierung als Folge von Methoden von ADTs Implementierung als Samm- lung von Fkt-Modulen Verteilte Systeme Dienst FKT-Modul als Prozess Multiuserfähig, eigenes Repository Objekte und Komponenten ADT-Modul als Prozess Vererbung von Daten und Methoden Systmbausteine Verwaltung mit ORB der OMG Steuerung mit Vorgangs- bearbeitung nach WfMC Komponenten- und diensteorientierte Systeme Können Dienste die sie betreffenden Metainformationen selber verarbeiten, so spricht man von Agenten.

47 Architektur eines objektorientierten Systems
common facilities application objects CAD Arch. CAD HKLS INTESOL Client LifeSPACES Client Simulation FM Kommunikationsschiene (Middleware) bedarfsgerechte Betriebsführung Facility Management Datentopf für Dokumente Datentopf für IFC Objekte LOTUS Notes Workflow Service DB Service object services

48 Diese Fragen sollten Sie jetzt beantworten können
Was ist ein Objekt und wie beschreiben wir es Was ist eine Klasse und zu was nutzt sie Welche Beziehungen zwischen Klassen verwendet man zur Modellierung Wie erweitert man Klassen durch Vererbung Warum fasst man Klassen zu Komponenten zusammen Was sind Komponenten und Dienste Wie sieht die Grundstruktur komponentenbasierter Systeme aus

49 Objekte als Repräsentation von Dingen - der ontologische Ansatz -1
Die Welt besteht aus Dingen mit Eigenschaften und Zuständen Es gibt keine zwei Dinge mit identischen Eigenschaften. Eigenschaften können ein oder mehrere Dinge betreffen, haben begrenzten Wertebereich, können einander bedingen. Zustand von Dingen Eigenschaften werden über Attribute beschrieben. Die Summe aller Attribute bildet das Modell der Dinge. Die Werte der Attribute zu einem Zeitpunkt definieren den Zustand der Dinge. Dynamik von Dingen Dinge ändern ihren Zustand. Zustandsänderungen werden durch Ereignisse ausgelöst und durch Übergangsgesetze beschrieben.

50 Objekte als Repräsentation von Dingen - der ontologische Ansatz -2
Wechselwirkungen Dinge können den Zustand anderer Dinge beeinflussen. Wechselwirkungen sind gemeinsame Eigenschaften der wechselwirkenden Dinge. Vereinigung Dinge können zu neuen Dingen vereinigt werden. Bei der Vereinigung entstehen neue Eigenschaften, die das vereinigte Ding charakterisieren. Klassifizierung Dinge mit einer vorgegebenen Menge von Eigenschaften bilden eine Art. Eine Art ist beschrieben durch die Menge ihrer Eigenschaften und die sie verbindenden Beziehungen.

51 Objekte als Repräsentation von Instanzen - der Ansatz der Klassifizierungstheorie
bedeutet das Wissen von der Existenz eines Dinges in der Welt, wird beschrieben durch Eigenschaften. Eigenschaften beschreiben Instanzen durch - Angaben zum Ding (Struktur) - Angaben zu seinen Beziehungen zu anderen Dingen (Relation) - Angaben zu möglichen Veränderungen der Werte von Eigenschaften (Verhalten) Konzepte (Modelle) fassen die Eigenschaften, durch die Instanzen beschrieben werden, zusammen, können erweitert werden, um andere Sichten zu erlauben. Zusammengesetzte Instanzen Eine Instanz kann aus Teilinstanzen bestehen, eine zusammengesetzte Instanz hat eigene Eigenschaften.