! Der Begriff des Systems! Definition eines Informatik-Systems! Wie entwickeln wir Informatik-Systeme?

Transkript

1 Überblick über Kapitel 2 der Vorlesung Grundlagen der Programmierung Dr. Christian Herzog Technische Universität ünchen intersemester 2006/2007 Kapitel 2: Informatiksysteme! Der Begriff des s! Definition eines Informatik-s! ie entwickeln wir Informatik-e? ie modellieren wir die Realität? Beschreibungstechniken! Aktivitäten bei der Entwicklung eines Informatik-s: Analyse, entwurf, Detaillierter, Implementation, Test! Typische Aktivitäten bei der Implementation! Verifikation und Validation von odellen Copyright 2006 Bernd Brügge, Christian Herzog Grundlagen der Programmierung TU intersemester 2006/07 Kapitel 2, Folie 1 2 Copyright 2006 Bernd Brügge, Christian Herzog Grundlagen der Programmierung TU intersemester 2006/07 Kapitel 2, Folie 2 Der Begriff des s, grenze, Umgebung! Definition eines s: Unter einem versteht man eine enge von Gegenständen, die in einem gegebenen Bezugssystem in einem Zusammenhang stehen, und die Beziehungen zwischen diesen Gegenständen. Die Gegenstände heißen Bausteine oder Komponenten.! Jedes hat eine grenze Die grenze legt fest, welche Komponenten zu einem gehören. Alle anderen Komponenten bezeichnet man als die Umgebung.! Definition -Schnittstelle: Die Beziehungen, die über die grenze laufen, d.h. die Beziehungen zwischen Komponenten des s und Komponenten in der Umgebung. K7 -Schnittstelle IF s = {(, ), (,)} Umgebung Beziehung grenze Komponente S = (K, B) wobei K = {,, } und B = {(,), (, )} Copyright 2006 Bernd Brügge, Christian Herzog Grundlagen der Programmierung TU intersemester 2006/07 Kapitel 2, Folie 3 Copyright 2006 Bernd Brügge, Christian Herzog Grundlagen der Programmierung TU intersemester 2006/07 Kapitel 2, Folie 4

2 Statt der olke benutzen wir einen Graphen Die Aggregations Beziehung! Aggregation:! S besteht aus, und. Ein Gegenstand besteht aus einem oder mehreren Gegenständen. Ein Gegenstand ist Teil von einem anderen Gegenstand.! ist Teil von S. S! Aggregation zwischen zwei Gegenständen G1 und G2 wird durch eine Kante zwischen G1 und G2 mit einem Rauten-Symbol an einem Ende bezeichnet.! Leseweise: Vom Rauten-Symbol aus: besteht aus Zum Rauten-Symbol hin: ist Teil von! Dies ist eine Darstellung in UL (Unified odeling Language).! ir werden in der Vorlesung UL verwenden bzw. uns stark an UL anlehnen. Copyright 2006 Bernd Brügge, Christian Herzog Grundlagen der Programmierung TU intersemester 2006/07 Kapitel 2, Folie 5 Copyright 2006 Bernd Brügge, Christian Herzog Grundlagen der Programmierung TU intersemester 2006/07 Kapitel 2, Folie 6 odellierung der Vielfachheit in Aggregationen! In der Aggregationsbeziehung kann die Vielfachheit (ultiplizität) von Komponenten angegeben werden.! Eine natürliche Zahl am Ende der Kante bezeichnet die Anzahl der Komponenten. 2 besondere Fälle: Vielfachheit 1 wird nicht explizit angezeigt, Vielfachheit viele wird durch ein Sternchen * angezeigt. Der begriff ist rekursiv! Die Komponenten eines s können selbst wieder (Sub-)e sein. Sub- Sub- Auto Sub- Sub- K7 Fahrer n * Bremse 2 4 Rad * Passagiere Copyright 2006 Bernd Brügge, Christian Herzog Grundlagen der Programmierung TU intersemester 2006/07 Kapitel 2, Folie 7 Copyright 2006 Bernd Brügge, Christian Herzog Grundlagen der Programmierung TU intersemester 2006/07 Kapitel 2, Folie 8

3 Rekursion in Informatik-en! Die Komponenten eines s können selbst wieder (Sub-)e sein. ir unterscheiden 2 Fälle: Das Subsystem ist ein schwarzer Kasten (black box): Das Subsystem wird als einzelner Gegenstand aufgefasst. Das Subsystem ist ein durchsichtiger Kasten (white box): Für das Verständnis des s ist die Zusammensetzung in Subsysteme und Komponenten wichtig. S1 S1 S2 Rekursion! Rekursion ist ein wichtiger Begriff in der Informatik, weil rekursive e skalierbar sind: Das Studium von en im Kleinen liefert Erkenntnisse, die auf größere e übertragbar sind.! Beispiel: Übung zu einer großen Vorlesung Problem: Erreichbarkeit der einzelnen Studenten Lösung: Einführung eines Subsystems Tutorgruppe Copyright 2006 Bernd Brügge, Christian Herzog Grundlagen der Programmierung TU intersemester 2006/07 Kapitel 2, Folie 9 Copyright 2006 Bernd Brügge, Christian Herzog Grundlagen der Programmierung TU intersemester 2006/07 Kapitel 2, Folie 10 Beispiel: Studentenverwaltungssystem Vorlesung 400 Student 400 Student Vorlesung 20 Tutor- Gruppe 20 Student Offenes vs. geschlossenes! Geschlossenes : Die Komponenten des s haben keine Beziehung zu den Komponenten der Umgebung.! Offenes : Die Komponenten des s haben eine Beziehung zu den Komponenten der Umgebung. Die schnittstelle kann sich sogar ändern. S1 S1 Copyright 2006 Bernd Brügge, Christian Herzog Grundlagen der Programmierung TU intersemester 2006/07 Kapitel 2, Folie 11 Copyright 2006 Bernd Brügge, Christian Herzog Grundlagen der Programmierung TU intersemester 2006/07 Kapitel 2, Folie 12

4 Beispiele von offenen en Kategorisierung von Informatik en! Ein Buchhaltungsystem, das die neuesten Steuergesetze berücksichtigen muss.! Ein Straßennavigationsystem, das die aktuellen Baustellen anzeigt.! Eine existierende Datenbank, die ans Internet anzuschließen ist.! Eine Studentenverwaltungssystem, das die neueste Prüfungsordnung berücksichtigen muss.! Die Aufgaben, die wir mit Informatik-en bearbeiten, haben wir in 4 Klassen eingeordnet: 1. Berechnung von Funktionen 2. Prozessüberwachung 3. Eingebettete e Offene e 4. Adaptive e Der Begriff geschlossenes ist eine Idealisierung. ir benutzen geschlossene e im Rahmen dieser Vorlesung aus didaktischen Gründen. In der Praxis hat der Informatiker fast nur mit offenen en zu tun. Copyright 2006 Bernd Brügge, Christian Herzog Grundlagen der Programmierung TU intersemester 2006/07 Kapitel 2, Folie 13 Copyright 2006 Bernd Brügge, Christian Herzog Grundlagen der Programmierung TU intersemester 2006/07 Kapitel 2, Folie 14 ie entwickelt man Informatik-e? Aktivitäten bei der Entwicklung eines Informatik-s! Anforderungen bei der Abbildung der Realität auf ein odell Funktionale Anforderungen " Gewünschte Funktionalität Nichtfunktionale Anforderungen (auch Leistungsmerkmale genannt) " Antwortzeit, Anzahl der unterstützen Benutzer! Unterscheidung von Entwicklungsaktivitäten: Analyse,, Implementation, Test, Lieferung Problemstellung Analyse des Problems einer Lösung Detaillierter Implementation der Lösung Copyright 2006 Bernd Brügge, Christian Herzog Grundlagen der Programmierung TU intersemester 2006/07 Kapitel 2, Folie 15 Copyright 2006 Bernd Brügge, Christian Herzog Grundlagen der Programmierung TU intersemester 2006/07 Kapitel 2, Folie 16

5 Aktivitäten bei der Entwicklung eines Informatik- s! Problemstellung: Beschreibung des Problems und der Ziele, Lösungsanforderungen! Analyse: odellierung der Realität und Erstellung eines odells! (Design): Konstruktion einer Lösung, die die achbarkeit des odells demonstriert und den Anforderungen gerecht wird " -: Zerlegung der Lösung in Komponenten " Detaillierter : Spezifikation der Schnittstellen! Implementation: Programmierung der Lösung in einer Programmiersprache! Test: Überprüfung der Lösung: Sind die gewünschten Ziele erreicht? Copyright 2006 Bernd Brügge, Christian Herzog Grundlagen der Programmierung TU intersemester 2006/07 Kapitel 2, Folie 17 Entwicklungsaktivitäten am Beispiel eines Studentenverwaltungssystems! Problembeschreibung: Die Verwaltung von Studenten-Daten ist bisher ein papierbasierter Prozess (Scheine, Bescheide)! Ziel: Ein rechnerbasiertes (Informatik-) für die Verwaltung Fakultät und Studenten sollen sich jederzeit einen Überblick über den "Studienstatus" des Studenten machen können: " elche Scheine fehlen mir noch für die Zulassung zur Abschlussprüfung? Copyright 2006 Bernd Brügge, Christian Herzog Grundlagen der Programmierung TU intersemester 2006/07 Kapitel 2, Folie 18 Analyse-Aktivitäten! Analyse: er sind die Benutzer? Studenten, Prüfer, Prüfungsausschuss, Prüfungsamt, Studiendekan as sind die funktionalen Anforderungen, d.h. welche Funktionalität soll das bereitstellen? " Anmelden im " Eintragen neuer Studenten in ein Studentenverzeichnis " Suchen nach Studenten im Studentenverzeichnis " Sortieren des Studentenverzeichnisses " Studienstatus von Studenten as sind die nichtfunktionalen Anforderungen? " Die Antwortzeit des s soll kleiner als 1 Sekunde sein saktivitäten! -: elch Subsysteme hat das? " Benutzerschnittstelle, Datenbasis, Auswertungskomponente elche Schnittstellen stellen die Subsysteme bereit? " Einloggen, Sortieren, Suchen, Berechnung der Note für das Zeugnis! Detaillierter : Definition der APIs (Application Programmer Interface, detaillierte Schnittstellenbeschreibungen für den Programmierer) " Genaue Definition der Operationen für Student, Studentenverzeichnis, Schein und Bescheid /ahl von Algorithmen und Datenstrukturen " Sortieralgorithmen: Bubblesort, Quicksort oder ergesort? " Studentenverzeichnis: enge, Sequenz oder Baum? Copyright 2006 Bernd Brügge, Christian Herzog Grundlagen der Programmierung TU intersemester 2006/07 Kapitel 2, Folie 19 Copyright 2006 Bernd Brügge, Christian Herzog Grundlagen der Programmierung TU intersemester 2006/07 Kapitel 2, Folie 20

6 Schnittstellenbeschreibung Studentenverwaltungssystem Anmeldung (Name) Eintrag (Neuer Student, Studentenverzeichnis) Suche (Name, Studentenverzeichnis) Sortiere (Studentenverzeichnis, Suchkriterium) Studienstatus (Name, Studentenverzeichnis)! Die Liste dieser Operationen heißt die Schnittstelle des s Dienste im entwurf API (Application Programmer Interface) im detaillierten.! Der Benutzer eines s braucht nur dessen Schnittstelle zu kennen, um es zu benutzen.! Kenntnisse über die Implementation sind nicht nötig. Implementations- und Testaktivitäten...! Implementation: ahl der Programmiersprache (z.b. Java für web-basiertes ) Schreiben der Datenstrukturen und Algorithmen, Editieren, Compilieren, Ausführen! Test: von Tests. as wird getestet? Bedienbarkeit, gewünschte Funktionalität (siehe Analyse), Fehlermeldungen. ahl der Tester. Copyright 2006 Bernd Brügge, Christian Herzog Grundlagen der Programmierung TU intersemester 2006/07 Kapitel 2, Folie 21 Copyright 2006 Bernd Brügge, Christian Herzog Grundlagen der Programmierung TU intersemester 2006/07 Kapitel 2, Folie 22 f Entwicklungsaktivitäten sind odelltransformationen Analyse Analyse f A Analyse I f S f f Detail. f D I Detail Detail f Impl Impl Impl Subaktivitäten während Implementation und Test ( edit-compile-execute cycle )! Codieren: Übersetzung des detaillierten s mit Hilfe eines Editors in ein Quellprogramm in der ausgewählten Programmiersprache! Editieren: Verbesserungen/Veränderungen am Quellprogramm! Compilieren Transformation des Quellprogramms durch einen Übersetzer (Compiler) in ein ausführ-bares Programm (aschinenprogramm)! Ausführen Ausführen des Programms durch einen Interpreter auf einer aschine. Ausgabe Eingabe Codieren Editieren Compilieren aschinen program Ausführen Implementation Implementation Quellprogram Copyright 2006 Bernd Brügge, Christian Herzog Grundlagen der Programmierung TU intersemester 2006/07 Kapitel 2, Folie 23 Copyright 2006 Bernd Brügge, Christian Herzog Grundlagen der Programmierung TU intersemester 2006/07 Kapitel 2, Folie 24

7 Interaktion odell <-> Realität! ir benutzen odellvorstellungen um die Realität zu steuern.! Beispiel: Ich komme abends nach Hause und gieße meinen Garten 20 inuten lang. Danach schalte ich den Gartenschlauch ab. ein odell: enn mein Garten trocken ist, dann sind 20 inuten Bewässerung gut genug, so dass die Pflanzen nicht verderben. Die Realität: Ob das wahr ist, bleibt offen.! Frage: ie kann man in der Realität überprüfen, ob der odellschluss stimmt? --> Verifikation und Validation ahrheitsgehalt von odellen! Definition Spezifikation: Eine irklichkeit, die unserer Gedankenwelt entstammt, oder ein odell.! Die Übereinstimmung einer Spezifikation mit einem odell lässt sich mit mathematischen und logischen Schritten prüfen. Definition Verifikation: Die Überprüfung des ahrheitsgehaltes eines odells 2 gegen eine Spezifikation 1. 1 R 2 2 kann gegen 1 verifiziert werden! enn die Realität gegeben ist und nicht selbst der elt des Denkens entstammt, dann können wir den ahrheitsgehalt eines odells nur durch Experimente feststellen: Definition Validation: Überprüfung des ahrheitsgehaltes eines odells gegen die Realität R. muss gegen R validiert werden Copyright 2006 Bernd Brügge, Christian Herzog Grundlagen der Programmierung TU intersemester 2006/07 Kapitel 2, Folie 25 Copyright 2006 Bernd Brügge, Christian Herzog Grundlagen der Programmierung TU intersemester 2006/07 Kapitel 2, Folie 26 Verifikation und Validation von odellen ethoden zur Validation von odellen f Analyse Validation Analyse f A Analyse Verifikation f S Detail. f D Verifikation Detail Detail Implementation Verifikation f I Impl Impl! Bei der Validation muß das odell mit einem Informatik- realisiert werden, bevor man prüfen kann, ob es realitätsgetreu ist und die Anforderungen erreicht.! Es gibt zwei öglichkeiten: Simulation Prototypische Realisierung I f f I Copyright 2006 Bernd Brügge, Christian Herzog Grundlagen der Programmierung TU intersemester 2006/07 Kapitel 2, Folie 27 Copyright 2006 Bernd Brügge, Christian Herzog Grundlagen der Programmierung TU intersemester 2006/07 Kapitel 2, Folie 28

8 Simulation Prototypische Realisierung! an realisiert einzelne komponenten und ihre Beziehungen untereinander soweit, dass man die gewünschten Aussagen über die anforderungen an Einzelfällen überprüfen kann.! Bei der Simulation wird die Funktion des simulierten s oft nicht berücksichtigt. Eine Simulation beschränkt sich oft nur auf die nichtfunktionalen Anforderungen.! Beispiele: Der Interrupthandler des Startsystems der Space Shuttle darf nicht mehr als 50 ikrosekunden für einen Interrupt verwenden. Das GPS Subsystem im Navigationssystem eines Autos muss zwischen minus 70 C und plus 100 C funktionieren.! ie kann man diese simulieren?! Beschränkt sich auf die funktionalen Anforderungen des s. Die nichtfunktionalen Anforderungen (Leistungsmerkmale) werden in einem Prototyp nicht berücksichtigt.! Das Ziel eines guten Prototypen ist die Überprüfung des odells aus der Analyse. odellierungsfehler sollte man eher zu früh als zu spät entdecken. Die Behebung eines Fehlers, der während oder am Ende der Analyse entdeckt wird kostet weniger als die Behebung während der Implementation. Copyright 2006 Bernd Brügge, Christian Herzog Grundlagen der Programmierung TU intersemester 2006/07 Kapitel 2, Folie 29 Copyright 2006 Bernd Brügge, Christian Herzog Grundlagen der Programmierung TU intersemester 2006/07 Kapitel 2, Folie 30 Zusammenfassung! begriff, Umgebung, Schnittstelle! Offenes vs. geschlossenes! Aktivitäten bei der Entwicklung eines Informatik-s Analyse, entwurf, Detaillierter, Implementation! Aktivitäten bei der Implementation Editieren, Compilieren, Ausführen, Testen! Unterschied Simulation und Prototyp Copyright 2006 Bernd Brügge, Christian Herzog Grundlagen der Programmierung TU intersemester 2006/07 Kapitel 2, Folie 31