Einführung in die Informationsverarbeitung Teil Eide (auf Basis von Thaller 2014–15) Stunde VI: Suche Planen und Realisieren Köln 21. Januar 2016.

Präsentation zum Thema: "Einführung in die Informationsverarbeitung Teil Eide (auf Basis von Thaller 2014–15) Stunde VI: Suche Planen und Realisieren Köln 21. Januar 2016."—  Präsentation transkript:

1 Einführung in die Informationsverarbeitung Teil Eide (auf Basis von Thaller 2014–15) Stunde VI: Suche Planen und Realisieren Köln 21. Januar 2016

2 Googlesuche „Köln“ - 2016

3 Googlesuche „Köln“ - 2014

4 Googlesuche „Köln“ - 2013

5 Googlesuche „Köln“ - 2012

6 Googlesuche „Köln“ - 2011

7 Googlesuche „Köln“ - 2010

8 Googlesuche „Köln“ - 2009

9 Googlesuche „Köln“ - 2008

10 Google - ein „System“ URL Server URL Auflösung Sortieren PageRankSuchen Crawler Speicher Indizierer „Barrels“ Anker Doc Index Repository LexikonLinks

11 Sergey Brin and Lawrence Page: The Anatomy of a Large-Scale Hypertextual Web Search Engine. Proceedings of the seventh World Wide Web Conference (WWW7), Brisbane 1998, also in a special issue of the Journal Computer Networks and ISDN Systems, Volume 30, issues 1-7. http://infolab.stanford.edu/~backrub/google.html Vgl.: http://www.google.com/technology/pigeonrank.html „Ur Google“ 11

12 URL Server Crawler URL Server Doc Index Startet mit Anfangs URL. Liest weitere URLs aus einem Dokumenten-Index. Schickt URLs an Crawler um Seiten zu holen. 12

13 Crawler Holen Web-Seiten. Speichern individuelle Seiten in Speicher-Subsystem. Mehrere Crawler! "Robots Exclusion Protocol" - "Wohlverhalten" Speicher 13

14 Indizierer I Liest Seiten aus dem Repository und dekomprimiert sie. "Parsed" jedes Dokument und verwandelt es in "Treffer", bestehend aus der Wortform. der Position innerhalb des Dokuments. einer relativen Fontgröße. Anzeige der Großschreibung. Treffer sind "fancy" (in URL, Überschrift, Anker Text oder Meta- Tag) oder "plain" (alle anderen Fälle). RepositoryIndizierer 14

15 Indizierer II Verteilt Treffer in "barrels", wobei ein sortierter Index entsteht. Extrahiert Links und speichert sie {Start URL, Ziel URL, Text} in Anker Datei. Erzeugt Lexikon Datei. Indizierer „Barrels“ Anker Lexikon 15

16 WordIds = Wortidentifikationsnummern Entstehen, indem die Wortformen sortiert und durchnummeriert werden. Problem:

17 Beispiel: Sequentielles Suchen Suchzeit jedes Namens entspricht Rang in der Liste. Durchschnittliche Suchzeit: n / 2. Laufzeit steigt mit der zu durchsuchenden Anzahl Rückverweis: Algorithmen: Laufzeit 1Clio 2Melpomene 3Terpsichore 4Thalia 5Euterpe 6Erato 7Urania 8Polyhymnia 9Kalliope

18 Beispiel: Binäres Suchen Laufzeit steigt mit Logarithmus der zu durchsuchenden Anzahl. Algorithmen: Laufzeit 1Clio 2Erato 3Euterpe 4Kalliope 5Melpomene 6Polyhymnia 7Terpsichore 8Thalia 9Urania

19 1.linear. 2.logarithmisch. 3.exponentiell. Algorithmen: Laufzeit N=1N=10N=100N=1000 1101001000 13710 110 3 10 30 10 300

20 Relevanz? Verteilt Treffer in "barrels", wobei ein sortierter Index entsteht. Extrahiert Links und speichert sie {Start URL, Ziel URL, Text} in Anker Datei. Erzeugt Lexikon Datei. Indizierer „Barrels“ Anker Lexikon 20

21 WordIds = Woridentifikationsnummern Entstehen, indem die Wortformen sortiert und durchnummeriert werden. Relevanz: ?

22 Erinnerung URL Server URL Auflösung Sortieren PageRankSuchen Crawler Speicher Indizierer „Barrels“ Anker Doc Index Repository LexikonLinks

23 URL Auflösung I „Barrels“ Anker URL Auflösung Links Doc Index 23

24 URL Auflösung II Liest Anker Datei. Verwandelt relative URLs in absolute. Verwandelt absolute URLs in Dokumenten IDs. Fügt Anker Text in einen vorwärts gerichteten Index ein, zusammen mit den Dokumenten IDs auf die der Anker zeigt. Erzeugt eine Link Datenbank, die Paare von Dokumenten IDs enthält. (Wird für die Errechnung der PageRanks verwendet!) 24

25 Sortierung „Barrels“ Sortieren Verwandelt einen Index der Dokumenten Ids in einen "invertierten Index", sortiert nach Wort Ids. "Short barrel" - invertierter Index von Treffern in Titel- und Ankertags. "Full barel" - invertierter Index der Bodytags. Enthält Offsets der Dokumentenposition für jede Wort Id. (Nachbarschaftsberechnung / Positionsanzeige.) 25

26 Page Rank Kann beschrieben werden als Modell des Verhaltens von Benutzern. Geht von einem "Zufallssurfer" aus, der von einer bestimmten Seite ausgeht und auf Links clickt. Er / Sie geht nie zurück und wird schließlich weitere Zufallsseite auswählen. Der "PageRank" ist die Wahrscheinlichkeit (p), dass der Surfer eine bestimmte Seite besucht. Die Wahrscheinlichkeit, dass BenutzerIn auf einer Zufallsseite landet ist 1-p. Links PageRank 26

27 Page Rank II Hoher PageRank kann anzeigen: Dass sehr viele Seiten auf eine Seite zeigen...... oder dass eine relativ kleine Anzahl von Seiten mit hohem PageRank auf diese Seite zeigen. 27

28 Erinnerung URL Server URL Auflösung Sortieren PageRankSuchen Crawler Speicher Indizierer „Barrels“ Anker Doc Index Repository LexikonLinks

29 Repository Voller (HTML) Text jeder Webseite. Seiten werden komprimiert gespeichert (ZLIB). Format: Dokumenten Id. Dokumentenlänge. URL des Dokuments. Inhalt des Dokuments. 29

30 Anker Beschreibung der Verweise in den Seiten {Start URL, Ziel URL, Text} Laut Google oft genauere Beschreibung der Seiten, als die Seiten selbst. Können auch nicht-Texte berücksichtigen. Problem: Tote Links... 30

31 Links Datenbank aller Paare von Dokumenten Ids. Basis aller PageRank Berechnungen. 31

32 Doc Index Datenbank aller verarbeiteten Dokumente (Web Seiten) Organisiert als ISAM Datei. (Indexed sequential access mode.) Geordnet nach DokumentenId. Jeder Eintrag enthält: Status des Dokuments. Prüfsumme des Dokuments. Statistiken zum Dokument. Angabe ob Seite von Crawlern schon durchsucht wurde. Sonst Verweis auf Liste abzuarbeitender URLs. 32

33 Lexikon 33

34 Barrels I Datenbank des Inhalts aller verarbeiteten Dokumente (Web Seiten) Beginnt mit einem Index von Dokumenten Ids, wird danach zu einem Index der Wort IDs sortiert. Die Suchmaschine sucht zuerst in den "short barrels" nach Treffern (Titel und Anker), erst danach in den "full barrels". 34

35 Barrels II 35

36 Google - ein „System“ URL Server URL Auflösung Sortieren PageRankSuchen Crawler Speicher Indizierer „Barrels“ Anker Doc Index Repository LexikonLinks

37 Suche I Besonderheiten der Googlesuche: Google analysiert nicht nur die Wortformen, sondern auch ihren (auch graphischen) Kontext. Jede Trefferliste enthält Informationen über die Position, den Schrifttyp und die Großschreibung. Zudem wird zwischen "fancy" und "plain" unterschieden - und der PageRank wird berücksichtigt. Ausgewogenheit zwischen diesen Faktoren. 37

38 Suche II – Abfragebearbeitung 1.Abfrage "parsen". 2.Worte in WortIds verwandeln. 3."Short barrel" auf Anfang der Dokumentenliste für jedes Wort der Abfrage positionieren. 4.Dokumentenliste durchsuchen, bis es Dokument gibt, dass alle Suchterme enthält. 5.Rang dieses Dokuments berechnen, relativ zu den anderen, die die Bedingungen erfüllen. 6.Wenn wir mit der Bearbeitung der "short barrels" fertig sind, wiederhole Schritt 3 ff. sinngemäß für die "full barrels". 7.Wenn wir noch nicht am Ende der Dokumentenliste sind, gehe zu Schritt 4. 8.Gefundene Dokumente nach Rang sortieren und n beste mitteilen. 38

39 Suche III – Ranking, Einzelwort 1.Trefferliste erstellen. 2.Jedem Treffer Typ {Überschrift, Anker, URL, Großer Font, Kleiner Font...}, mit spezifischem Typwert, zuweisen. 3.Vector der Typen-Gewichte in der Reihenfolge der Typen erzeugen. 4.Typen zählen und Häufigkeiten in Häufigkeitsgewichtungen verwandeln. 5.Häufigkeitsgewichtung normalisieren, am Anfang linear, dann abnehmend. 6.Gewichtungsrang entspricht dem Skalarprodukt aus dem Vektor der Typengewichte mit dem Vektor der Häufigkeitsgewichte. 7.Kombination aus Gewichtungsrang und PageRank ergibt endgültigen Rang des Dokuments. 39

40 Rekapitulation 40 Der Gang der Argumentation 1.Der Rohstoff: „Information“ 2.Darstellung der Information auf dem Rechner: „Datenstrukturen.“ 3.Verarbeitung der Information auf dem Rechner: „Algorithmen“. 4.Verbindung der Bausteine im Kleinen: Simulationen 5.Verbindung der Bausteine im Großen: Google 6.Abstrakte Lösungen für den Entwurf von Systemen: Graphen

41 41 ?

42 Systemdesign / Systemplanung 42 (1)Entsteht Software, entstehen Informationssysteme als Ergebnis eines künstlerischen Prozesses? (2)Oder sind sie planbar? Die Grafiken dieser Stunde entstammen zum großen Teil den von M. Glinz unter http://www.ifi.unizh.ch/groups/req/ftp/ses/ bereitgestellten Materialien zu seiner Vorlesung "Spezifikation und Entwurf von Software".

43 Ein ernstes Problem … 43 Erfolg von IT Projekten laut Umfragen: 45,2 % aller Softwareprojekte erfolgreich. 19,4 % Zeit- und Kostenüberschreitungen. 35,4 % Fehlschläge.

44 Ein ernstes Problem … 44 In Abhängigkeit von der Teamgröße. Erfolgreiche Projekte bei einer Teamgröße von: Bis 4 Personen 60 % 4 – 8 Personen 38 % 8 – 20 Personen 32 % Mehr als 20 Personen 18 %

45 I. Was heißt Planung? 45

46 I. Was heißt Planung? 46

47 I. Was heißt Planung? 47 Der eben beschriebene Vorgang, angewendet auf informationstechnische Probleme: Requirements Engineering.

48 Ia. Requirements Engineering 48 Requirements Engineering bildet Modelle eines Ausschnitts der Realität.

49 Ia. Requirements Engineering 49 Systeme sind daher immer in einen Kontext eingebettet, der den direkt für den Entwurf des Systems relevanten Bestandteil der Realität beschreibt.

50 Ia. Requirements Engineering 50 Requirements Engineering legt die Grenzen des Systems gegenüber dem Kontext fest.

51 Ia. Requirements Engineering 51 Unterschiedliche, aus einander abgeleitete, Betrachtungsebenen Anforderung aus der Realität: Auf dem bestehenden Schiennenetz sollen mehr Leute transportiert werden. Daraus abgeleitete Anforderung an das System: Die Minimaldistanz zwischen zwei Zügen ist immer größer als der maximale Bremsweg des nachfolgenden Zuges. Daraus abgeleitete Anforderung an das umzusetzende Informationssystem ("die Software"): Der maximale Bremsweg muss alle 100 ms neu berechnet werden.

52 I. Was heißt Planung? 52 Wie kann man die formalisierte Beschreibung der Anforderungen in einen Gesamtprozess eingliedern, der ein Projekt zur Erzeugung eines Informationssystems insgesamt beschreibt? Konzept des Systems Designs / Software Engineering.

53 I b 1. Wasserfallmodell 53

54 I b 2. Iteratives Vorgehen 54

55 I b 3. „Extreme Programming“ 55

56 II. Wie kann man Planen? 56 Gesucht ist eine Ausdrucksweise für Planungen, die:  Ihre BenutzerInnen zur Disziplin zwingt.  Die Kommunikation über unterschiedliche Planungen erlaubt. 90‘er Jahre: Verschiedene Ansätze als Bestandteil des objektorientierten Paradigmas in der Softwareentwicklung.  James Rumbaugh: Object Modelling Technique (OMT)  Grady Booch: Booch Methode  Ivar Jacobson: Object Oriented Software Engineering (OOSE) Konvergenz seit 1996 zur UML (Unified Modelling Language) als allgemeine „Modellierungssprache“

57 II 0. UML 2.0 (2003 / 04 ff.) 57 UML ist eine Sammlung von "graphischen Sprachen", d.h. Regelsystemen für die Konstruktion graphischer Schemata, die:  unterschiedliche Perspektiven von Anforderungen an Systeme und Entwürfen von Systemteilen, sowie deren Zusammenwirken darstellen,  einander dabei überlappen können und  unabhängig voneinander verwendet werden können. Am wichtigsten:  Klassenmodelle beschreiben den strukturellen Aufbau eines Systems,  Anwendungsfallmodelle (Use Cases) beschreiben die Interaktion mit dem System aus Benutzersicht.

58 II 1. Klassendiagramme 58 Objekt „Mitarbeiter“ (kann Attribute und Methoden haben)  Programmierung

59 II 1. Klassendiagramme 59 Binäre Assoziation beschreibt die Beziehungen zwischen Klassen

60 II 1. Klassendiagramme 60 Multiplizität gibt an, wie viele Objekte an einer Assoziation beteiligt sein können.

61 II 1. Klassendiagramme 61 Reflexive Assoziation verbindet Objekte einer Klasse miteinander.

62 II 1. Klassendiagramme 62 Aggregation verbindet beliebig viele Klassen zu einer übergeordneten.

63 II 1. Klassendiagramme 63 Generalisierungsbeziehung zwischen Superklasse und Subklasse.

64 II 2. Anwendungsfalldiagramme 64 Das Verhalten eines Systems kann als Sammlung von Anwendungsfällen ( = use cases) beschrieben werden. Ein Anwendungsfall beschreibt eine Klasse möglicher Interaktionen. Konkrete Anwendungsfälle heißen auch Szenarien. (  scenario based design.) Anwendungsfälle werden in strukturiertem Text beschrieben. Alle möglichen Anwendungsfälle - oder ein für ein bestimmtes Teilsystem relevanter Teil - werden als Anwendungsfalldiagramm realisiert.

65 II 2. Anwendungsfalldiagramme 65 Anwendungsfall als strukturierter Text (auch als Aktivitäts – oder Zustandsdiagramme) Beispiel: "Buch an einem Selbstausleiheautomaten ausleihen" Normallfall: 1.BenutzerIn liest Ausweis in System ein; System validiert Ausweis. 2. BenutzerIn wählt "Ausleihen"; System aktiviert Ausleihfunktion. 3.BenutzerIn liest Buchcode ein; System identifiziert das Buch, registriert Ausleihe, deaktiviert das Diebstahletikett. Auch Sonderfälle

66 II 2. Anwendungsfalldiagramme 66 Akteur

67 II 2. Anwendungsfalldiagramme 67 Anwendungsfall

68 II 2. Anwendungsfalldiagramme 68 Anwendungsfall- diagramm

69 II 2. Anwendungsfalldiagramme 69 Include: Bindet anderen Anwendungsfall ein, der an mehreren Stellen genutzt werden kann.

70 II 2. Anwendungsfalldiagramme 70 Extend: Modelliert Varianten, die einen Basisanwendungsfall abwandeln.

71 II 3. Zustandsdiagramme 71 Zustandsdiagramme modellieren das dynamische zeitliche Verhalten eines Systems. Auch state machine  state diagram Mögliche Zustände der Objekte einer Klasse oder eines Teilsystems. Dynamik des Systemverhaltens: Reaktionen auf äußere Ereignisse.

72 II 3. Zustandsdiagramme 72

73 II 4. Aktivitätsdiagramme 73 Aktivitätsdiagramme beschreiben Abläufe in einem System. Verbinden Aktivitäten, einen Steuerfluss und Objektzustände miteinander. Erinnern stark an traditionelle "Flussdiagramme" (und haben auch alle ihrer Nachteile).

74 II 4. Aktivitätsdiagramme 74

75 II 5. Interaktionssicht 75 Ziel: Darstellung der Interaktion ausgewählter Objekte in zeitlicher Folge. Entweder als Sequenzdiagramme, die die Zeitachse in den Mittelpunkt rücken … … oder als Zusammenarbeitsdiagramme die Objektstruktur und Aufrufe der Objekte in den Vordergrund rücken. (Beide Diagrammtypen sind logisch äquivalent!)

76 II 5. Interaktionssicht 76 Als Sequenzdiagramm …

77 II 5. Interaktionssicht 77 … und als Zusammenarbeitsdiagramm.

78 II 6. Paketdiagramme 78 Ziel: Aufteilung eines großen auf mehrere kleine Systeme. Innerhalb der Pakete müssen Namen eindeutig sein – aber eben nicht zwischen Ihnen. (Vgl. Namespacekonzept in XML.)

79 II 6. Paketdiagramme 79

80 II 7. Komponentendiagramme 80 Ziel: Aufteilung der Gesamtfunktionalität eines Systems auf mehrere Softwaremodule, die:  Möglichst unabhängig voneinander entwickelt / gewartet werden können.  Nur über genau definierte Schnittstellen miteinander kommunizieren.

81 II 7. Komponentendiagramme 81

82 II 8. Verteilungsdiagramme 82 Ziel: Aufteilung der Gesamtfunktionalität eines Systems auf mehrere Hardwaremodule (Server).

83 II 8. Verteilungsdiagramme 83

84 84 Herzlichen Dank!