Einführung in die Informatik II Überblick Java, Java, Java R. Morelli Einführung in die Informatik II Überblick Prof. Bernd Brügge, Ph.D Institut für Informatik Technische Universität München Sommersemester 2004 20. April 2004 Letzte Änderung: 3/28/2017 2:12 PM 2 Copyright 2000 by Ralph Morelli. All rights reserved.

Aufgabe des Informatikers Java, Java, Java R. Morelli Aufgabe des Informatikers Unser Ziel: Informatik-Systeme von hoher Qualität zu produzieren. Wir unterscheiden dabei 3 Aktivitäten Analyse: Wir erfassen die Natur des Problems durch Interviews mit Experten, die Erstellung einer Taxonomie und das Aufbrechen des Problems in kleinere Subprobleme. Synthese (Entwurf): Wir erstellen oder benutzen existierende Teillösungen für die Subprobleme, und integrieren die Teillösungen in eine Gesamtlösung Implementation: Wir bilden die Gesamtlösung in eine Beschreibung ab, die auf einem bereits existierenden Informatik-System ausgeführt werden kann. Diese Aktivitäten werden allgemein beim Lösen jedes Problems benötigt. What is Software Engineering? The goal is to produce high quality software to satisfy a set of functional and nonfunctional requirements. How do we do that? First, and foremost, by acknowledging that it is a problem solving activity. That is, it has to rely on well known techniques that are used all over the world for solving problems. There are two major parts of any problem solving process: Analysis: Understand the nature of the problem. This is done by looking at the problem and trying to see if there are subaspects that can be solved independently from each other. This means, that we need to identify the pieces of the puzzle (In object-oriented development, we will call this object identification). Synthesis: Once you have identified the pieces, you want to put them back together into a larger structure, usually by keeping some type of structure within the structure. Techniques, Methodologies and Tools: To aid you in the analysis and synthesis you are using 3 types of weapons: Techniques are well known procedures that you know will produce a result (Algorithms, cook book recipes are examples of techniques). Some people use the word “method” instead of technique, but this word is already reserved in our object-oriented development language, so we won’t use it here. A collection of techniques is called a methodology. (A cookbook is a methodology). A Tool is an instrument that helps you to accomplish a method. Examples of tools are: Pans, pots and stove. Note that these weapons are not enough to make a really good sauce. That is only possible if you are a good cook. In our case, if you are a good software engineer. Techniques, methodologies and tools are the domain of discourse for computer scientists as well. What is the difference? Copyright 2000 by Ralph Morelli. All rights reserved.

Entwicklung von Informatik-Systemen: Lösen von Problemen Die Entwicklung von Informatik-Systemen ist nichts anderes als ein Spezialfall der Lösung von Problemen * Um Probleme zu lösen, benutzen wir Sprachen, Notationen, Definitionen, Techniken, Methoden(-sammlungen), Werkzeuge und Dogmen. If you can't solve a problem, then there is an easier problem you can solve: find it. *Sehr empfehlenswert: George Polya's Buch übers Problemlösen: "How to solve it", Princeton University Press, 1957, ISBN 0-691-08097-6 Zusammenfassung siehe: http://www.cis.usouthal.edu/misc/polya.html und http://www-gap.dcs.st-and.ac.uk/~history/Quotations/Polya.html

Was benutzen wir bei der Lösung von Problemen (bei der Entwicklung von Informatik-Systemen)? Sprache: Die Menge aller Worte über einem Alphabet. Notation: Die äußere Form, in der Worte einer Sprache ausgedrückt werden. Konzept: Wissenseinheit, die in Verbindung mit anderen Konzepten dazu beiträgt, Probleme und dazugehörige Lösungen zu verstehen. Eine Definition ist die formale Beschreibung eines Konzeptes. Technik: Ein in einer Notation beschriebenes Verfahren, das von jemandem ausgeführt wird, um ein Resultat zu produzieren. Werkzeug: Ein Instrument oder ein automatisiertes System, das eine bestimmte Technik ausführen kann. Ethik: Eine philosophische Anschauung, die sagt, was erlaubt ist und was nicht. Jede Ethik enthält Dogmen.

Sprache bei der Entwicklung von Informatik-Systemen Definition: Die Menge aller Worte über einem Alphabet. Ich benutze die natürliche Sprache, um jemandem zu erklären, wie man Pfannkuchen herstellt. Wir benutzen formale Sprachen, um Informatik-Systeme zu beschreiben. Beispiele aus Info I/II: UML (Modellierungssprache) Java (Programmierungssprache) Andere Modellierungsprachen: SDL, OMT, SA/SD, .... Andere Programmiersprachen: C, C++, Fortran, Cobol, VisualBasic, Smalltalk, Eiffel, ...

Notation Definition: Die äußere Form, in der Worte einer Sprache ausgedrückt werden. Eine Notation ist also die Repräsention einer Sprache (zur Unterscheidung zwischen Nachricht, Repräsentation und Information, siehe Info I-Kapitel 10, Folie 7) Beispiele: Liste der Zutaten für ein Pfannkuchenrezept Tagesordnung für ein Besprechung Checkliste für eine Vorlesung Beispiele aus Info I: Textersetzungsystem (Notation für Programme) Termersetzungssystem Backus-Naur Form (Notation für Grammatiken) Syntax-Diagramm

Konzept Definition: Wissenseinheit, die in Verbindung mit anderen Konzepten dazu beiträgt, Probleme und dazugehörige Lösungen besser oder schneller zu verstehen, insbesondere Probleme in einer bestimmten "Problemlösungsklasse". Beispiele: Das Konzept der Bratpfanne Das Konzept der Klasse: Unterstützt sowohl die Modellierung als auch die Programmierung Das Konzept der Sortierung (Bubblesort, Quicksort, Mergesort) Das Konzept der Sortiertheit (Ordnung, Sortierkriterium) Das Kompositionsmuster (hilft, rekursive Strukturen beliebiger Tiefe und Breite zu modellieren) Das Konzept der Entwurfsmuster (Wiederverwendbares Wissen in der Entwurfsphase bei der Entwicklung von Software-Systemen).

Technik Definition: Ein in einer Notation beschriebenes Verfahren, das von jemand ausgeführt wird, um ein Resultat zu produzieren. Beispiele: Pfannkuchenrezept Spezifikation einer Schnittstelle Bubble-Sort Algorithmus Effizienzbetrachtungen für Algorithmen Beschreibung, wie man Objekte identifizieren kann

Werkzeug Ein Instrument oder ein automatisiertes System, das eine bestimmte Technik ausführen kann. Ofen Bleistift und Papier Software (Text-Editor, Java-Compiler, Java Virtuelle Maschine, Unix-Betriebssystem) Für die Erstellung der Info II-Vorlesung benutze ich folgende Werkzeuge: Erstellung der Vorlesungsfolien: Powerpoint v.X:mac Zeichnen von UML 2.0 -Diagrammen: ConceptDraw 1.59 Entwicklung von Java 1.4.2-Programmen: Codeguide 7.0, build 821

Methode Definition: Eine Sammlung von Techniken, die zur Lösung von Problemen angewandt werden können. Kochbuch Alle Techniken, die zum objekt-orientierten Problemlösen benötigt werden.

Java, Java, Java R. Morelli Ethik Definition: Eine philosophische Anschauung, die sagt, was erlaubt ist und was nicht. Jede Ethik enthält Dogmen. Beispiele für Dogmen: Fleischessen ist ungesund Objekt-orientierte Modellierung ist besser als funktionale Dekomposition. Beispiele für Dogmen aus Info I: Ein Attribut darf nie öffentlich sein. Ein Problem muss erst modelliert werden, bevor man es programmiert. Operationen müssen immer zu Klassen gehören. Operationen dürfen nicht "frei herumlaufen" wie bei der imperativen Programmierung. objekt-orientierte Programmierung ist ein Dogma! Copyright 2000 by Ralph Morelli. All rights reserved.

Wie benutzen wir Sprachen, Notationen, Konzepte, Techniken? Java, Java, Java R. Morelli Wie benutzen wir Sprachen, Notationen, Konzepte, Techniken? Der Informatiker als Wissenschaftler: Entwirft neue Sprachen für Entwurf und Programmierung Vergleicht und untersucht Informatik-Systeme Findet neue Techniken, beweist Theoreme über Techniken Definiert Schemata für die Notation von Wissen Definiert allgemeine Konzepte im Bereich der Informatik (ohne Zeitdruck) Der Informatiker als Ingenieur: Betrachtet Sprachen, Notationen und Techniken als Basis für (weitere) Techniken und Werkzeuge Setzt die Werkzeuge bei der Lösung eines Problem ein Definiert spezifische Konzepte im Bereich eines Problems (innerhalb einer bestimmten Zeit und mit einem begrenzten Budget) In Info II behandeln wir sowohl die wissenschaftlichen als auch die ingenieur-spezifischen Aspekte der Entwicklung von Informatik-Systemen. A computer scientist assumes that techniques, methodologies and tools are to be developed. They investigate in designs for each of these weapons, and prove theorems that specify they do what they are intended to do. They also design languages that allow us to express techniques. To do all this, a computer scientist has available an infinite amount of time. A software engineering views these issues as solved. The only question for the software engineer is how these tools, techniques and methodologies can be used to solve the problem at hand. What they have to worry about is how to do it under the time pressure of a deadline. In addition they have to worry about a budget that might constrain the solution, and often, the use of tools. Good software engineering tools can cost up to a couple of $10,000 Dollars (Galaxy, Oracle 7, StP/OMT) Object modeling is difficult. As we will see, good object modeling involves mastering complex concepts, terminology and conventions. It also requires considerable and sometimes subjective expertise in a strongly experience-based process. Beware of the false belief that technology can substitute for skill, and that skill is a replacement for thinking. offers this advise [cit Tillmann]. Many organizations are frustrated with a lack of quality from their tool-based systems. However, the cause of this problem is often the false belief that a tool can be a substitute for knowledge and experience in understanding and using development techniques. Although CASE tools such as StP/OMT or Objectory and similar tools have the potential to change how people design applications, it is a mistake to think they can replace the skills needed to understand and apply underlying techniques such as object, functional or dynamic modeling. You cannot substitute hardware and software for grayware (brain power) [cit Tillmann]: Buying a tool does not make a poor object modeler a good object modeler. Designers need just as much skill in applying techniques with CASE tools as they did with pen and paper. Another problem, that is often associated with tool-based analysis is that it is often insufficient or incomplete. Why is that? To a certain extent this problem has always existed. Systems developers are much better at collecting and documenting data than they are at interpreting what these data mean. This in unfortunate, because the major contribution an analysist can bring to system development is the thought process itself. But just as a tool is not a substitute for technique, knowledge and experience, technique skills cannot replace good analysis - people are still needed to think through the problem. So our message is: Being able to use a tool does not mean you understand the underlying techniques, and understanding the techniques does not mean you understand the problem. In the final analysis, organizations and practitioners must recognize, that methodologies, tools and techniques do not represent the added values of the object modeling process. Rather, the real value that is added, is the thought and insight that only the analyst can provide. Copyright 2000 by Ralph Morelli. All rights reserved.

Was machen wir in Info II? Weitere Konzepte, Methoden, Notationen und Techniken: für die Erstellung (Analyse, Entwurf und Implementierung) von Informatik-Systemen für die Beschreibung (Dokumentation) von Informatik-Systemen für die Überprüfung (Testen) von Informatik-Systemen Schwerpunkte: Fortgeschrittene Datenstrukturen (AVL-Bäume, Warteschlangen) Objekt-orientierte Entwicklung: Modellierung, Entwurf, Implementation Grundprinzipien des Software-Engineering Wichtige Entwurfsmuster (Modell-Sicht-Steuerung,...) Weitere Programmierstile (Ereignis-basiert, interaktiv, maschinennah) Umsetzung von höheren Sprachen in maschinenähere Sprachen

Spezifische Themen Notationen für die Beschreibung von Informatik-Systemen UML, Java, Grammatiken, Automaten Entwurf von Informatik-Systemen Wiederverwendbarkeit Polymorphismus Spezifikation, Verträge Programmierstile Ereignis-basierte Programmierung Interaktive Programmierung Maschinennahe Programmierung Zusammenfassung Übersicht und Bewertung der Programmierstile Ein zusammenfassendes Beispiel

Aufteilung der Themen auf Vorlesungsblöcke I. Beschreibung von Informatik-Systemen (Modellierung) Block 1: UML-Überblick (Ende April/Anfang Mai) II. Wichtige Techniken beim Entwurf von Informatik-Systemen Block 2: Polymorphismus (Mitte Mai) Block 3: Spezifikation, Entwurf durch Verträge (Ende Mai) III. Programmierstile Ereignis-basierte Programmierung (Juni) Block 4: Ereignisse und Ereignis-Verarbeitung (Anfang Juni) Block 5: Automaten und Grammatiken (Mitte Juni) Block 6: Interaktive Programmierung (Ende Juni) Block 7: Maschinennahe Programmierung (Anfang bis Mitte Juli) IV. Zusammenfassung Block 8: Übersicht und Bewertung der Konzepte (ca. Mitte Juli) Block 9: Ein zusammenfassendes Beispiel (Ende Juli)

Motivation für Block 1: Modellierung In Info I haben wir uns auf die Modellierung der statischen Aspekte eines Systems konzentriert. Ziel 1: Die Beschreibung der funktionellen Anforderungen und der dynamischen Aspekte bei der Ausführung eines Informatik-Systems muss auch möglich sein. Frage: Wie beschreibe ich die Funktionalität des Systems? ® Szenarien, Anwendungsfälle Frage: Wie beschreibe ich die dynamischen Aspekte des Systems? ® Ablaufbeschreibungen Ziel 2: Bei der Erstellung eines Informatik-Systems müssen die Wünsche verschiedener Interessengruppen ("stake holders"), z.B. Kunde, Benutzer und Entwickler des Systems berücksichtigt werden. Frage: Wie beschreibe ich das System für unterschiedliche Benutzer, ohne dabei inkonsistent zu werden?

Block 1: Modellierung Überblick über UML Die wichtigsten UML-Diagramme (Notationen) Wiederholung und Verfeinerung aus Info I: Klassendiagramme Neu in Info II: Anwendungsfalldiagramme, Sequenzdiagramme Wann setzt man welche Diagramme ein? Taxonomie der Benutzer von Klassen Benutzer, Spezifizierer, Implementierer, Erweiterer

Information zu Block 1 [Fowler]: "UML konzentriert", Kapitel 4 und 5, pp. 43-69: Klassendiagramme und Sequenzdiagramme [Bruegge]: "Object-Oriented Software Engineering", Kapitel 2: Modeling with UML.

Motivation für Block 2: Polymorphismus Idee: Informatik-Systeme kann man komponenten-basiert erstellen (ähnlich dem Bau von Fertighäusern). Ziel: Austauschbarkeit einzelner Komponenten, ohne andere Komponenten informieren oder ändern zu müssen. Beispiel: Ersetzung eines langsamen/unsicheren Verschlüssungsalgorithmus durch einen neuen (schnelleren/sicheren) Algorithmus Frage: Wie kann ich den Implementierungsaufwand reduzieren, wenn ich eine existierende Komponente durch eine neue ersetze oder eine neue Komponente in das System einbringe? Polymorphismus Frage: Wie kann man dem Benutzer garantieren, dass seine Erwartungen auch nach dem Komponententausch erfüllt sind? Entwurf durch Verträge

Block 2: Polymorphismus (Mitte Mai) Polymorphismus bei Anwendungen Verkaufsautomaten als Beispiel Polymorphismus bei Klassenbibliotheken Behälter (Container) als Beispiel Verschiedene Container Implementierungen Reihung, Baum, Hash-Tabelle Stapel, Warteschlange (® Block 6: maschinennahe Programmierung) Vererbung Die verschiedenen Arten der Vererbung ("Taxonomie der Vererbung") Vererbung vs Delegation Strategiemuster Vergleich: Strategiemuster vs Brückenmuster

Information zu Block 2 [Goos II], "Vorlesungen über Informatik II", Kapitel 9: Objektorientiertes Programmieren, pp. 143-259. [Gilbert] "Object-oriented Design in Java", Kapitel 9: Implementing Class Relationships: Inheritance and Interfaces, pp. 279-289. [Gamma], "Entwurfsmuster", Strategiemuster (strategy pattern), pp. 315, Brückenmuster (bridge pattern), pp. 151. [Lafore], "Data Structures & Algorithms in Java", Kapitel 9 (AVL-Baum), Kapitel 11 (Hash-Tabelle)

Motivation zu Block 3: Entwurf durch Verträge Ziel: Überprüfbarkeit bestimmter Anforderungen und Eigenschaften von Informatik-Systemen. Beispiele: "Das System muss 500 Anfragen pro Sekunde unterstützen" "Das System unterstützt 500 Anfragen pro Sekunde" "Die Suche ist äußerst effizient" "Das System ist sehr einfach zu benutzen" Wie überprüfen wir Anforderungen und Eigenschaften? Validierung: Tests gegen die Realität (Validierung) Verifikation: Tests gegen andere Modelle Frage: Wie legen wir Anforderungen und Eigenschaften fest, um sie überprüfen zu können? Frage: Wer ist für die Erstellung und Überprüfung von Verträgen und Schnittstellen verantwortlich?

Block 3: Spezifikation (Ende Mai) Kapselung, Komponentenbegriff Motivation für Zugriffsrechte und Schnittstellen-Spezifikation Zugriffsrechte: "Wer bearbeitet welche Teile einer Komponente?": Spezifizierer einer Komponente (abstract) Implementierer der Komponente (private) Erweiterer der Komponente (protected) Benutzer der Komponente (public) Schnittstellen-Spezifikation: Entwurf durch Verträge [Spezifikation von Klassen und Methoden] Vor- und Nachbedingungen, Invarianten OCL: Werkzeug zur Beschreibung von Verträgen JavaDoc: Werkzeug zur Dokumentation von Verträgen Zusicherungen [Spezifikation von Anweisungen] Zusicherungskalkül (Hoare): Technik zur Verifikation von Programmen

Information zu Block 3 [Goos II] : "Einführung in die Informatik II", Zusicherungskalkül, Prädikatenlogik. [Gilbert] "Object-Oriented Design in Java", pp. 282-287: Vending machine [Fowler] "UML Konzentriert", pp. 54-56: Entwurf durch Verträge [Küchlin] "Einführung in die Informatik", Kapitel 7, Kapselung und Zugriffskontrolle, Kontrakt und Aufrufschnittstelle [Gries] "A logical approach to discrete math", Assertions, Hoare Logic.

Block 4: Ereignis-basierte Programmierung (Juni) Arten von Ereignissen erwartete und unerwartete Ereignisse (Events, Exceptions) Ereignisse als Nachrichten (Codierung, Fehlererkennung) Beschreibung von Ereignissen, die zwischen Objekten ausgetauscht werden Behandlung von Ereignissen (Event Handling) Beobachter-Muster (Observer Pattern) Modell-Sicht-Kontroller (Model-View-Controller) Ein- und Ausgabe Java Applets Graphik-Programmierung Endliche Automaten (als ereignisverarbeitende Systeme) Beschreibung von endlichen Automaten UML-Notation: Zustandsdiagramm

Information zu Block 4 [Fowler] "UML Konzentriert", Kapitel 5, Sequenzdiagramme, pp. 59-63 [Gamma] "Entwurfsmuster", Kapitel 1 und Beobachtermuster 293

Block 5: Automaten und Grammatiken (Mitte Juni) Die Chomsky-Hierarchie Chomsky 3 Grammatiken als Beschreibung von endlichen Automaten (einseitig lineare Grammatiken) Chomsky 2 Grammatiken als Beschreibung von Kellerautomaten (kontextfreie Grammatiken) Kellerautomaten Das Keller-Prinzip zur Zwischenspeicherung von Daten Zusammenhang zwischen Automaten, Grammatik und Sprache Pumping Lemma für CH3-Sprachen Festlegung von Syntaxregeln für Programmiersprachen (wie z.B. Java) durch eine Chomsky 2 Grammatik Analyse/Überprüfung der Syntax eines Java-Programms mit einem geeigneten Kellerautomaten

Information zu Block 5 [Goos I] "Vorlesungen über Informatik I", Chomsky-Hierarchie, pp. 33-40, Endliche Automaten, pp 84-97. [Fowler] "UML konzentriert", Kapitel 8, pp 107-114, Zustandsdiagramme

Motivation zu Block 6 Idee: Die Zustandsübergänge in einem System folgen vorgegebenen Regeln. Ein System kann deshalb durch diese Regeln beschrieben werden. Ziel: Festlegung der Regeln durch ein Regelsystem Beispiele: Markov-Algorithmen (siehe Info I) Regeln für Spiele (Schach, Doppelkopf, Tic-Tac-Toe,…) Fragen: Wie konstruiere ich ein regel-basiertes System? Wie führe ich ein Programm regelbasiert aus, wenn immer mehrere Regeln anwendbar sind?

Block 6: Regel-basierte Programmierung (Ende Juni) Regel-basierte Systeme Horn Klausel Konflikt-Resolutionsstrategien Experten-Systeme als Beispiel von regel-basierten Systemen

Motivation zu Block 7: Maschinennahe Programmierung Idee: Die Realität ist durch Modelle beschreibbar. Ziel: Die Modelle eines Informatik-System können in Modellierungssprachen und Programmiersprachen formuliert werden. Frage: Wie übersetze ich diese Modelle in eine Sprache, die von einem Rechner verstanden wird?

Block 7: Maschinennahe Programmierung (Bis Mitte Juli) Schichten ("Abstraktionsebenen") strenge Schichten-Architektur vs. offene Architektur Das Konzept der abstrakten Maschine Interpreter [als Beispiel] Umsetzung von höheren Sprachen auf maschinennahe Sprachen UML ® Java Java ® PMI (Bytecode) Unterprogrammaufrufe maschinennahe Umsetzung mit Hilfe des Kellers Rekursion [als Spezialfall] Speicherorganisation Halde (Objekte, Reihungen) Keller (lokale Variablen)

Information zu Block 7 [Fowler ] "UML konzentriert“ Kapitel 11: UML und Programmierung [Küchlin&Weber] "Einführung in die Informatik", Kapitel 6 insbesondere Variablen, Referenzen und Zuweisungen, Parameterübergabe, Spezifikation von Unterprogrammen, Implementation von Rekursion und Kapitel 7.2.6, Verwaltung von Objekten im Speicher [Lafore] "Data structures and algorithms in Java", Kapitel 12 Heap, Kapitel 13 Graphs.

Block 8: Zusammenfassung (Ende Juli) Übersicht, Vergleich und Bewertung der in Info I und Info II behandelten Konzepte Vergleich der Programmierstile Funktionale Programmierung Objekt-basierte Programmierung Imperative Programmierung als Teil der objekt-basierten Programmierung Objekt-orientierte Programmierung Ereignis-basierte Programmierung Regel-basierte Programmierung Maschinennahe Programmierung Andere Entwurfsmethodologien und Programmiersprachen Vorausschau auf andere Vorlesungen

In Info II verwendete Literatur G. Goos: "Vorlesungen über Informatik" Band 2: Objekt-orientiertes Programmieren und Algorithmen, 2. Auflage, Springer 1999, ISBN 3-540-64340-0 Vertiefende Literatur: M. Fowler: "UML Konzentriert“ 3. Auflage, Addison-Wesley 2000, ISBN 3-8273-2126-3. E. Gamma, R. Helm, R. Johnson und J. Vlissides: "Entwurfsmuster", Addison-Wesley 1996, ISBN 3-89319-950-0. W. Küchlin und A. Weber, "Einführung in die Informatik:Objekt-orientiert mit Java", 2. Auflage, Springer 2003, ISBN 3-540-43608-1.

In Info II verwendete englisch-sprachige Literatur Martin Fowler, Kendall Scott: "UML Distilled“ Addison-Wesley 2000, ISBN 3-8273-1617-0. B. Bruegge & A. Dutoit: "Object-Oriented Software Engineering“ Prentice Hall 2003, ISBN 0-13-191179-1 E. Gamma, R. Helm, R. Johnson, J. Vlissides: "Design Patterns“ Addison-Wesley 1996, ISBN 0-201-63361-2. S. Gilbert& Bill McCarty: "Object-Oriented Design in Java“ Mitchell Waite Series 1998, ISBN 1-57169-134-0. D. Gries & F. Schneider, "A logical approach to discrete math” Springer Verlag 1996, ISBN 0-387-94115-0 J. Warmer & A. Kleppe: "The Object Constraint Language” Addison-Wesley, 2000, ISBN 0-20137940. R. Lafore: "Data Structures and Algorithms in Java” Mitchell Waite Series 1998, ISBN 1-57169-095-6

Ein Versuch zur Verbesserung der Vorlesung

Nächste Vorlesung Vorlesung am Donnerstag fällt aus Nächste Vorlesung am Dienstag, 27. April 2004