So#waretechnologie für Fortgeschri4ene Teil Eide

Transkript

1 So#waretechnologie für Fortgeschri4ene Teil Eide Stunde V: Modelling (with contribu>ons from Chris>an-Emil Ore, Jon Holmen, and other colleagues at the Unit for Digital Documenta>on, University of Oslo and from Mar>n Dörr and Stephen Stead, CIDOC-CRM SIG) Köln 4. Februar 2016

2 Reminder: Event centric data model source à recording à result Media object Types External Analogue nega>ve Analogue posi>ve Digital photo Digital copy. Source of Event recording Types Photographing Repro Copying Scanning Results in when performed by where Media object Types Analogue nega>ve Analogue posi>ve Digital photo Digital copy. Time span Person Place

3 Reminder: Data model (example) Separa>on between informa>on object and informa>on carriers discipline cataloguing discipline cataloguing media_group (informa>on object) Is carrier of media_unit a nega>ve film media_unit b paper posi>ve media_unit c file from scanner Event 1 Camera, 1966 Event 2 Copying,? Event 3 Scan, 1997 media_unit d file Event 4 Resizing, 2004

4 Remember: Database Discipline schema 1 image_card media_group_id concent_metadata subject specific tables Common schema media_group id process_xml tech_metadata media_unit tech_metadata default {0, 1} schema_setup process_spec delete_limit process process_spec status {0, 1, 2, 9} Discipline schema 2 image_card media_group_id concent_metadata subject specific tables

5 Which discipline?

6 Which discipline?

7 Which discipline?

8 Which discipline?

9 Iden>cal photographs?

10 Which discipline?

11 Which discipline?

12 Which discipline?

13 Event centric data model Media Object A Type: Digital copy Skrik Source for Event Media Object D Media Object B Source for Type: Use of photoshop Results in Type: Collage The Imsdal man Meets Munch Type: Digital copi: The Imsdal man when Performed by when Timespan Person Place

14 Date model, concepts and things Conceptual object Media group -unit A Informa>on Object Skrik Media group - unit B Informa>on Object Media Object A Type: Digital copy Media Object B Type: Digital copy Based on Media Object C Type: Digital copy Conceptual object Media group -unit C Informa>on Object The Imsdal man Meets Munch The Imsdal man Physical thing

15 Model of vs. model for

16 Modelling strategies: examples Modelling for produc>on Computer science e.g. UML Digital Humani>es e.g. TEI Modelling for understanding Digital Humani>es (Humani>es, natural sciences, ) Modelling for data integra>on Computer science e.g. Seman>c Web Digital Humani>es e.g. TEI Cultural heritage e.g. CIDOC-CRM

17 Introducing CIDOC-CRM Historical Archives Type: Text Title: Protocol of Proceedings of Crimea Conference Title.Sub>tle: II. Declara>on of Liberated Europe Date: February 11, 1945 Creator: The Premier of the Union of Soviet Socialist Republics The Prime Minister of the United Kingdom The President of the United States of America Publisher: State Department Subject: Postwar division of Europe and Japan Metadata Documents About The following declaration has been approved: The Premier of the Union of Soviet Socialist Republics, the Prime Minister of the United Kingdom and the President of the United States of America have consulted with each other in the common interests of the people of their countries and those of liberated Europe. They jointly declare their mutual agreement to concert.and to ensure that Germany will never again be able to disturb the 17 peace of the world

18 Type: Image Title: Allied Leaders at Yalta Images, non-verbose Date: 1945 Publisher: United Press Interna>onal (UPI) Source: The Be_mann Archive Copyright: Corbis References: Churchill, Roosevelt, Stalin Photos, Persons Metadata About 18

19 Places and Objects TGN Id: Names: Yalta (C,V), Jalta (C,V) Types: inhabited place(c), city (C) Posi>on: Lat: N,Long: E Hierarchy: Europe (con>nent) < Ukrayina (na>on) < Krym (autonomous republic) Note: Site of conference between Allied powers in WW II in 1945;. Source: TGN, Thesaurus of Geographic Names Places, Objects About Title: Yalta, Crimean Peninsula Publisher: Kurgan-Lisnet Source: Liaison Agency 19

20 The Integration Problem (1) Problem 1: identification of things Actors, Roles, proper names: Places Events The Premier of the Union of Soviet Socialist Republics Allied leader, Allied power Joseph Stalin. Jalta, Yalta Krym, Crimea Crimea Conference, Allied Leaders at Yalta, conference between Allied powers Postwar division Objects and Documents: The photo, the agreement text 20 20

21 The Integra4on Problem (2) Problem 2: hidden (implicit) entities (typically under title ) Actors Allied leader, Allied power Places Yalta, Crimea Events Solution: Crimea Conference, Allied Leaders at Yalta, conference between Allied powers Postwar division Make better metadata structures: but what are the relevant elements? 21 21

22 Explicit Events, Object Identity, Symmetry E39 Actor E52 Time-Span February 1945 P82 at some within time E7 Activity P7 took place at E53 Place E39 Actor E39 Actor Crimea Conference P86 falls within E65 Creation Event * P81 ongoing throughout E52 Time-Span E38 Image E31 Document Yalta Agreement

23 The Intellectual Role of the CRM Conceptualization? approximates explains, motivates Data structures & Presentation models organize World Phenomena 23 Data bases Legacy Legacy systems systems Data in various forms

24 Top-level classes useful for integration E55 Types E41 Appellations refer to / identify refer to / refine E28 Conceptual Objects E39 Actors E18 Physical Thing participate in affect or / refer to location E2 Temporal Entities E52 Time-Spans within at E53 Places 24

25 Event centric data model Media Object A Type: Digital copy Skrik Source for Event Media Object D Media Object B Source for Type: Use of photoshop Results in Type: Collage The Imsdal man Meets Munch Type: Digital copi: The Imsdal man when Performed by when Timespan Person Place

26 Visual Content and Subject E24 Physical Man-Made Thing P128 carries (is carried by) P62 depicts (is depicted by) P62.1 mode of depiction P67 refers to (is referred to by) E55 Type E1 CRM Entity P65 shows visual item (is shown by) E73 Information Object P138 represents (has representation) P138.1 mode of depiction E84 Information Carrier E36 Visual Item E38 Image 26 E37 Mark E34 Inscription

27 Date model, concepts and things Conceptual object Media group -unit A Informa>on Object Skrik Media group - unit B Informa>on Object Media Object A Type: Digital copy Media Object B Type: Digital copy Based on Media Object C Type: Digital copy Conceptual object Media group -unit C Informa>on Object The Imsdal man Meets Munch The Imsdal man Physical thing

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

29 II 1. Klassendiagramme Objekt Mitarbeiter (kann Attribute und Methoden haben) è Programmierung 29

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

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

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

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

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

35 II 2. Anwendungsfalldiagramme 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. 35

36 II 2. Anwendungsfalldiagramme 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 36

37 II 2. Anwendungsfalldiagramme Akteur 37

38 II 2. Anwendungsfalldiagramme Anwendungsfall 38

39 II 2. Anwendungsfalldiagramme Anwendungsfalldiagramm 39

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

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

42 II 3. Zustandsdiagramme 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. 42

43 II 3. Zustandsdiagramme 43

44 II 4. Aktivitätsdiagramme 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). 44

45 II 4. Aktivitätsdiagramme 45

46 II 5. Interaktionssicht 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!) 46

47 II 5. Interaktionssicht Als Sequenzdiagramm 47

48 II 5. Interaktionssicht und als Zusammenarbeitsdiagramm. 48

49 II 6. Paketdiagramme 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.) 49

50 II 6. Paketdiagramme 50

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

52 II 7. Komponentendiagramme 52

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

54 II 8. Verteilungsdiagramme 54