1. Historie und Ziele der Softwareentwicklung

Transkript

1 1. Historie und Ziele der Softwareentwicklung der Programmierung Bedeutung von Abstraktion Domain Specific Languages Model Driven Architecture Komponenten-Ansatz Komponenten-Architekturen 31

2 der Programmierung (1/2) Erste Rechner: Programmierung extrem HW-nah (Maschinenbefehle eng verwandt mit Stromschaltern) Assembler: Befehle wie Lege Wert der Speicherzelle X in Register R1 Wenn Wert in R1 gleich Null springe zu Zeile 4242 Ein Assemblerbefehl ersetzt mehre Maschinenbefehle Einfache Programmiersprachen, Fortran, Algol 60, z. B. n:=n+1 for q:=1 step s until n do A[q]:=B[q] Sprünge (goto), Unterprogramme und Funktionen Programmiersprachenbefehl umgesetzt als mehrere Assemblerbefehle 32

3 der Programmierung (2/2) Modularisierung von Programmen / Bibliothekennutzung z. B. Trennung von Header-Dateienund Implementierung stdio.h, math.h Objektorientierung Weitere logische Strukturierung mit Klassen Information Hiding Statische und dynamische Polymorphie Frameworks Programmierte Teillösungen für Standardaufgaben (z. B. Datenverwaltung, Transaktionsmanagement) Entwickler muss zur Nutzung Interfaces erfüllen 33

4 Abstraktion Abstraktionsgrad Framework Bibliothek Programmiersprache Assembler Maschinensprache auf/mit abstrakterer Ebene immer wesentlich schneller als auf unterer Ebene Jeder Abstraktionsschritt kann Performance kosten 34

5 Generelle Ziele der Softwareentwicklung Schnelle Keine fachliches Ergebnis doppelt Einfache Nutzung existierender Ergebnisse (ohne Detailkenntnisse) Qualitativ hochwertige Ergebnisse Nutzung validierter und verifizierter Verfahren Korrektheit und Performance Übertragbarkeit der Ergebnisse Schnelle Wiederverwendung bei ähnlichen Aufgaben Unabhängigkeit von konkreten Sprachen und Betriebssystemen Integrierbar in andere Software-Architekturen 35

6 Aktuelle Themen der Softwareentwicklung (1/4) Domain Specific Languages Problem: General PurposeSprachen sind sehr mächtig, aber für spezifische sbereiche geht sehr viel Energie in für den Bereich gleichartige Programmierung Spezielle ssprache für individuellen Bereich, spezielle komplexe Hochsprachelemente anbietet Neue Sprache z. B. mit XML (Syntax mit XML-Schema) darstellbar; Umwandlung in Programm mit Übersetzung (z. B. XSLT) ; hilfreich ist Visualisierungsmöglichkeit der DSL 36

7 Aktuelle Themen der Softwareentwicklung (2/4) Model Driven Architecture Ansatz: Häufig benötigt man die gleichen Ideen (z. B. Sortierverfahren) in sehr unterschiedlichen Sprachen; warum nicht in einer Sprache modellieren und dann in andere Sprachen transformieren? Zur Modellbeschreibung wird eigene Sprache mit eigener Semantik benötigt (Metamodell und Metametamodell) Ansatz: Umwandlung des CIM mit Transformationsregeln in ein PIM und dann ein PSM CIM: Computer Independent Model PIM: Platform Independent Model PSM: Platform Specific Model 37

8 Aktuelle Themen der Softwareentwicklung (3/4) Metamodell Verwaltung liname:string * element Element name:string typ:string Codegenerator Modell public class {Verwaltung.liname Verwaltung.liname} { <foreach Element e:verwaltung.element> private List<{e.typ}> {e.name e.name}; } Verwaltung liname= Hauptliste Element name= kunden typ= Kunde Element name= produkte typ= Produkt generierter Code public class Hauptliste { private List<Kunde> kunden; private List<Produkt> produkte; } jetzt Teil von Eclipse 38

9 Aktuelle Themen der Softwareentwicklung (4/4) Komponentenbasierte Idee: Software besteht aus Bausteinen Komplexe Software wird aus einfachen Bausteinen zusammengebaut Beispiel 1: GUI aus Buttons, ListBox, Slider, Panel,... Beispiel 2: Kundenverwaltung, Lagerhaltung, Bestellabwicklung, Finanzabwicklung Bausteine können getrennt genutzt werden; sind konfigurierbar Bausteine müssen zusammenarbeiten können Konkretes Beispiel: Eclipse mit Plugins Hinweis: Trotz üblichem Methodenkrieg können Teilideen aller Ansätze integriert werden 39

10 Komponentenidee genauer (1/2) Funktionalität nutzbar für andere (Schnittstelle) Benötigt klare Schnittstellendefinition Welche Methoden/Dienste werden angeboten (Parameter, Ergebnisse, Ausnahmen) Welche Objekte (die Schnittstellenspezifikationen erfüllen) werden benötigt Einstellungsmöglichkeiten z. B. spezielle Methoden z. B. Einstellungsdatei (XML) 40

11 Komponentenidee genauer (2/2) Funktionsgarantie Genannte Dienste werden immer (auch bei neuen Versionen) angeboten Dienstqualität (Korrektheit, Performance) ist garantiert direkt nutzbar Möglichst Installation durch Kopieren Möglichst plattformunabhängig Möglichst leicht in andere Systeme integrierbar 41

12 Komponentenframework Komponente muss bestimmte Schnittstellen befriedigen, damit Framework nutzbar wird Typische Aufgaben eines Frameworks: Framework kennt aktive Komponenten, kann so Konflikte lösen Framework ermöglicht es, dass Komponenten Informationen austauschen Framework bietet Standarddienste: Persistenz, Transaktionssicherheit, Anmeldung, Suche 42

13 Zentrale Aspekte der Komponentenorientierung 43

14 Komponentendiagramm Bilder zeigen zwei alternative Darstellungen Komponenten bieten Schnittstellen(realisierungen) (Kreis) und benötigen Schnittstellen(realisierungen) (Halbkreis) Komponenten können über Schnittstellen in Diagrammen verknüpft werden in Komponenten können zugehörige Klassen eingezeichnet werden 44

15 Zusammenspiel von Komponenten (1/3) Variante 1: Direkte Kommunikation Komponenten bieten Schnittstellen zur Nutzung und benötigen Objekte zur Ausführung Direktes Netzwerk von Komponenten Vorteil: wenig Restriktionen in (Individualentwicklung) Nachteil: keine Standardisierung; gleichartige Aufgaben evtl. mehrfach realisiert 45

16 Beispiel: direkt verbundene Komponenten 46

17 Zusammenspiel von Komponenten (2/3) Variante 2: Nutzung einer Kommunikationsplattform mit zentralen Diensten 47

18 Beispiele zentraler Dienste Plattform bietet Kommunikationsdienste Komponente abonniert sie interessierende Daten Komponente bietet neue Daten zum abonnieren an Lokalisationsdienst : Finden von Daten /Komponenten Darstellungsdienst: Visualisierung der Daten Transportdienst : transparenter und sicherer Datentransport der Komponenten untereinander Speicherungsdienst : Daten persistieren, Konsistenz, Replikation und Backup Sicherungsdienst : Sicherung der Integrität, Kontrolle von Nutzerauthentifizierung und autorisierung Vorteil: klar strukturiertes Kommunikationsverhalten; modularer Aufbau Nachteil: Plattform muss hoch performant sein; kein direkter Informationsaustausch 48

19 Beispiel mit Kommunikationsplattform 49

20 Zusammenspiel von Komponenten (3/3) Variante 3: Komponentenframework Komponente selbst läuft in einem Container Container stellt Dienste zur Verfügung (s. vorher) Plattform regelt Zusammenspiel der Container Vorteil: Konzentration auf Geschäftsprozess Container Nachteil: Abhängigkeit vom Framework; Performance(?) Hinweis: gibt weitere Varianten; Varianten nicht disjunkt 50

21 Beispiel: Komponenten in Containern 51

22 von Komponenten Zentrales Ziel der Komponentenentwicklung durchzieht gesamten sprozess Anforderungsanalyse: nicht-triviale unabhängige Teilaufgaben Generell typisch: zentrale Informationsverwaltung (z. B. Stammdaten) Komponentensysteme wachsen schrittweise Klärung zentraler Prozesse (Stammdatenverwaltung) Anschluss weiterer Prozesse Migration erfolgt ebenfalls schrittweise; häufig aber Beginn mit einzelnen Komponenten, die sich an Altsystem anschließen Komponentenentwicklung hat (einmaligen) Mehraufwand 52

23 Beispiele Komponentenarchitekturen Microsoft: ComponentObjectModel (COM, bzw. COM+, DCOM, ActiveX) OMG: Common Object Request Broker Architecture (CORBA) Sun: Java Beans und Enterprise Java Beans OSGi Alliance: OSGi(früher Open Services Gateway initiative ) Basis Java Virtual Machine Ziel ist Gerätevernetzung (Handy, Gebäudeautomatisierung, Automotive) Grundlage für Eclipse-Plugins(Equinox) 53