Home

Informationssystem-Entwicklung

1. 82 6566 s sd ulusu See INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 123 aktiv Element Von Dialogausdruck basiertAuf Szene C aktiv involviert Szene Story Dialogschritt ausdruck Repr senta tionsstil Emphasis Default Content Objekt 1 1 v 1 n Rechte kategorie S Umst nde Plattform Kanal Dialog ID Ausr stung Gruppe Profil Bild 45 Repr sentation der Elemente von SiteLang Rollen kategorie 0200 Event Condition Do AcceptCondition Das Ausspiel der Oberfl che wird durch entsprechende XML Architekturen besonders unterst tzt In diesem Fall kann mit einer Architektur nach dem Zwiebelprinzip in Bild 46 vorgegangen werden Mit dieser Generierung erreicht man nicht nur eine h here Flexibilit t sondern auch eine Vereinfa chung der gesamten Anwendung Direktdarstellung des Story Raumes Eine Datenbank Unterst tzung ist nicht in jedem Fall f r den Story Raum notwendig Wir k nnen auch anstelle einer vollst ndigen Datenbank direkt die folgenden OLAP Elemente betrachtet werden die z T allerdings redundante Informationen enthalten Dialogszene In einer Dialogszene werden die involvierten Akteure das genutzte Content Objekt und die Dialogschritte beschrieben Dialogschritt Ein Dialogschritt ist die kleinste Story Einheit Sie erlaubt die Darste
2. Land Berlin VERKAUF Brandenburg 10 1 Meck Pomm KundenNr FName ProduktNr Datum Menge Umsatz 25 7 Sachsen Buch 56 Elektronik 4 Hardware Software Jan Febr Mar Apr Zeit Branche Bild 73 Die 3 dimensionale Aggregation von VERKAUF In der Aggregation f r Januar in der Branche Software und im Land Sachsen wurden z B 4 Produkte bestellt Aufgrund der Tabellendefinitionen kann leicht ber unterschiedliche Aggregationen der Tabellen inhalt von VERKAUF zusammengefa t werden Damit k nnen auch weitere Aggregationen ber den bereits betrachteten SQL Anfragen definiert werden Beispielsweise wird die Anfrage Welche Software Hersteller wurden von weiblichen Kunden in Berlin im 1 Quartal 2003 favorisiert durch die folgende Anfrage berechnet select p Hersteller sum v Anzahl from Verkauf v Filiale f Produkt p Zeit z Kunde k where z Jahr 2003 and z Quartal 1 and k Geschlecht W and p PGruppe Software and f Land Berlin and v Datum z Datum and v ProduktNr p ProduktNr and v FName f FName and v KundenNr k KundenNr group by p Hersteller Analog kann Roll up durch Elimination eines Attributes aus der Group By Klausel berechnet werden Drill down wird durch Hinzufiigen eines Attributes in der Group By Klausel berechnet Durch eine Definition von Sichten und deren Materialisierung kann ein Datenbank Warenhaus zusammengestellt werden Demzu
3. virtuelle materialisierte Retrieval Funktionen f r berblick Indexierung Ein Ausgabe Navigation Integration in andere Komponenten Service Pakete Verpackungsfunktionen Funktionen f r Dialogszenen und Szenario Adaption an Akteure Ausr stung Kanal etc Erweiterung um Dekomposition Historie und Stil Bild 46 Der Zwiebelzugang zur Generierung der Oberfl chen von Anwendungen Einf hrung von Identifikatoren f r die Elemente sinnvoll Dialogschritte k nnen spezifiziert werden durch Tabellen der folgenden Form Dialog on event Vorbedingung Content zugelassene zugelassene Akteur accept on schritt Objekt Operationen Manipulations name operationen Es sind auch graphische Repr sentationen wie in Bild 47 sinnvoll Der Spezifikationsrahmen f r Dialogschritte Die Spezifikation der einzelnen Dialogschritte wird in sechs Dimensionen aufgef chert Die Intentionen der einzelnen Dialogschritte folgen der allgemeinen Mission der Anwendung und wer den durch entsprechende Metaphorik gut unterst tzt Der Story Raum wird durch die Handlungsverl ufe der Anwendung bestimmt Er zerf llt in Szenen die wiederum in Dialogschritte zerlegt werden Die Spezifikation der Benutzung basiert auf einer Darstellung der Akteure ihrer Rollen Rechte und Verantwortlichkeiten sowie der Pr sentation Der Content der einzelnen Dialogschritte wird du
4. 118 Algorithmisches Verhalten versus Mensch Maschine Verhaltes eines oder mehrerer Ak ae he ee ee oe 121 Der Interaktionsraum verglichen mit dem Systemraum 121 Repr sentation der Elemente von SiteLang 1 0 ee 123 Der Zwiebelzugang zur Generierung der Oberfl chen von Anwendungen 124 Sichtenstern f r eine Dialogszene mit entsprechenden SiteLang Elementen 125 b i EEE hee 2 00 INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 187 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 79 Der Spezifikationsrahmen f r Arbeitsgruppen Sites 126 Der Spezifikationsrahmen f r Beitr ge von Arbeitsgruppenmitgliedern 126 Szenario in einem Story Raum aoaaa aaa 128 Szene zur kollaborativen Planung eines Lehrveranstaltungsangebotes eines Lehrstuhles 129 Dialogschritte innerhalb eines Suchszene 129 Das Zwiebelprinzip zum Einbringen von Kontext 131 Die Vorgehensweise zur Zusammenstellung von Benutzungsoberfl chen 137 Dimensionen des Gestaltungsrahmens 22 2 nn nn nn 141 Die Implementationsschicht eines verteilten Systems 146 Eine Schichten Architektur f r verteilte System 147 CORBA auf IDL Grundlage 153 OMG Architektur 0 0 0 0 0
5. Bild 31 Ein berlagertes und verwirrendes Workflow Programm die Auseinandersetzung mit kondensierten und berlagerten Programmen wie in Bild 31 dargestellt Da die Programmierung von einer klaren Semantik profitiert erlauben wir diese Art von Konfusion nicht bei der Spezifikation Dieses Programm vermischt Ausf hrung Sequentialit t und Nebenbedingungen zur Entscheidung Die Alternativen sind vereinfachbar wenn sicher ist da z B W Fa vor W F terminiert und mit den Resultaten von W F bereinstimmt dann kann W Fs ohne Ber cksichtigung von W Fo nur auf W F aufbauen Das Programm in Bild 31 besitzt gleichzeitig auch die klassische AND OR Falle Analog kann auch die OR AND Falle spezifiziert werden Beide Fallen sind in Bild 32 illustriert W Fs W F V Fy V A V FA WFA V WF W Fo W Fo Bild 32 Ein OR AND und ein AND OR Workflow Programm Diese Fallen sind relativ leicht aufzul sen wenn man die Resultatssemantik betrachtet In diesem Falle sind beide Programme durch AND AND Programme repr sentiert Betrachtet man dagegen die Ausf hrungssemantik dann klaffen die beiden Programme auseinander Noch schwieriger sind Workflow Semantiken bei denen eine Synchronisation sowohl am Ende als auch zu Beginn einer Verzweigung erfolgen kann In diesem Fall erh lt auch die Verzweigung eine andere Semantik Aus diesen
6. Das Sicherheitsprofil eines Akteurs wird durch Sicherheitsoptionen mit denen die gesamte Siche rung des Systemes dargestellt werden kann charakterisiert Zur Durchf hrung von Aufgaben im Rah men des Story Raumes werden entsprechende Medien Typen bereitgestellt Da diese den Aufgaben zugeordnet sind werden Sicherheitsoptionen mit vier Parametern spezifiziert Akteure werden mit entsprechenden Sicherheitsoptionen zur Erf llung von Aufgaben ausgestattet Aufgaben determinieren die erlaubten Aktionen erfordern Aktionen oder determinieren spezifische Sicherheitsprofile Rollen von Akteuren entsprechen den bereits besprochenen Rollen im Story Raum F r Sicherheits profile sind au erdem Rollen von Interesse die einer Gruppe von Akteuren zugeordnet werden Eine Sicherheitsoption basiert entweder auf erlaubten Aktionen oder expliziten Verboten Ein Benutzer wird einem Akteur zugeordnet Er kann gleichzeitig einer Reihe von Akteuren zugeord net werden Die Darstellung des Arbeitsrahmens und Benutzer und Akteurportfolio Das Portfolio des Akteurs wird beschrieben durch e die Beschreibung des Inhaltes der Aufgabe e die Spezifikation der Rechte des Akteurs im entsprechenden Dialogschritt e die Beschreibung der Rolle des Akteurs und e die Ausf hrungsmodelle f r das Agieren mit Angaben zur Zeitdauer minimal maximal normal sowie zu den Ausf hrungspriorit ten Eine Aufgabe ist eine Vorgabe f r zielorientiertes
7. ffentliche Art Existenz G ltigkeit Private Funktionalit t Content mn R ume Arbeitsresultate Bild 48 Der Spezifikationsrahmen fiir Dialogschritte Die Assoziationen werden gleichzeitig mit dem Rahmen dargestellt So sind z B Content Objekte mit Akteuren assoziiert Sie k nnen ffentlich sein von Akteuren gemeinsam benutzt werden oder auch privat sein Akteure beteiligen sich in Dialogschritten in unterschiedlichen Rollen und Verant wortlichkeiten Die Content Objekte werden als Content Suite mit einer entsprechenden Funktiona lit t bereitgestellt F r Arbeitsgruppen sind Dokumente und Arbeitsr ume typische Content Objekte Die Content Objekte sind ggf nicht dauerhaft g ltig und k nnen erzeugt modifiziert und gel scht werden Die Dialogschritte werden zur Bew ltigung von Aufgaben mit bestimmten Intentionen be nutzt Als typisches Beispiel kann die Untersetzung des Spezifikationsrahmens f r Dialogschritte von En 2 0 z L L 9 12 oe ik a y 2 1 ane 08 126 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 7 INTERAKTIVIT T Die Akteure sind Arbeitsgruppenmitglieder Arbeitsgruppenleiter und verantwortliche insbesonde re Administratoren Der Story Raum besteht aus einer Reihe von Dialogschritten wie z B dem Zusammenarbeitsschritt Die Content Objekte z B die Gruppendokumente k nnen auch spezielle Dokumente wie Tages ordnungen allgemeine Nachrichten oder pers nl
8. 2 Tina Musterfrau Benutzer zufalliger in der Nutzer DBMS Falle A parametrische relationales i HERM Datenbank 2 Ausdr cke schema Such anforderung Such Anfrage Q Anfrage konzept form query schnittstelle Ergebnis Antwort SQL Anfrage Daten konzept form menge bank Antwort DBMS Antwort auf Suche repr sentation BS Bild 10 Konzept und begriffsbasierte Anfrageschnittstellen von Informationssystemen werden Deshalb ist die Architektur in Bild 11 eine sinnvolle Alternative die unserem Vorhaben des integrierten Entwurfes entgegenkommt Wir unterscheiden damit zwischen Retrieval Sichten und Mo difikationssichten Dieses Bild zeigt zugleich auch die Unterschiede in der Betrachtungsweise relativ gut auf F r den Benutzer oder eine Benutzergruppe ist die Anwendung stets lokal Er nutzt Dialoge um mit dem Informationssystem bestimmte Aufgaben zu l sen Dabei werden ihm entsprechende Daten zusammengestellt und bermittelt Diese Zusammenstellung fassen wir mit einem Container zusammen Au erdem besitzt dieser Container auch die entsprechende Funktionalit t um den Um gang mit den Daten entsprechend den Dialoganforderungen zu erleichtern Die Modifikationssichten und die Retrievalsichten sind hierbei entsprechend zusammengefa t Das DBMS unterst tzt die An wendung durch die Bereitstellung von Prozessen die Speicherung der Daten und die Erzeugung und Verarbeitung der Sichten Unsere Vorstellungen
9. a 020 PEES t z 22 x 2 a 0 xa 7 AL s 0 GR gt 1 1 1 INFORMATIONSSYSTEM ENTWICKLUNG IM Co DESIGN ZUGANG 8 105 Das verallgemeinerte Seeheim Modell Das DBIS Modell f r Informationssysteme Informationssystem Pr sentations Story Raum komponente Stories Akteure Graphik Szenario Kontext Content Typen Raum Struktur Funktionalit t Anwendungskomponente Container Dialog Strukturierung Funktionalit t Proze management Struktur Prozesse generator system Statische Dynamische Integrit ts Integrit ts Sichten DBMS bedingungen bedingungen generator Pragmatik Pragmatik a b Bild 38 Spezifikation von Informationssystemen Gestaltungsrahmen Bei der Gestaltung von Benutzungsschnittstellen ist es angebracht einem ein heitlichen Schema zu folgen Wir fassen den Style Guide zur Gestaltung von Interfaces die Metaphorik und die allgemeinen Gestaltungsrichtlinien im Gestaltungsrahmen zusammen Arbeitsrahmen Informationssysteme sollen bei der Bew ltigung von Arbeitsaufgaben eingesetzt wer den Deshalb m ssen auch das Portfolio das Aufgabenspektrum der einzelnen Benutzer und die L sungsschritte f r die Arbeitsaufgaben angemessen bei der Gestaltung ber cksichtigt werden Interaktivit t im Abstraktionsschichtenmodell Wie bereits in den vorhergehenden
10. 49 Beziehungen der Objekte im Vorlesungsbeispiel 50 Die Zerlegung von R in zwei Relationship Typen 51 Die Arbeitsprodukte im Abstraktionsschichtenmodell f r die Strukturierung 53 Die Arbeitsprodukte im Abstraktionsschichtenmodell f r die Funktionalit t 55 Petri Netz Darstellung von formalen Handlungen 56 Gesch ftsvorfall Erstellung eines Angebotes f r eine Lehrveranstaltung 57 Die Zust nde einer Transaktion 65 Generische und entfaltete Workflows 77 Ein berlagertes und verwirrendes Workflow Programm 79 Ein OR AND und ein AND OR Workflow Programm 79 Die Arbeitsprodukte im Abstraktionsschichtenmodell f r die Sichtenentwicklung 83 Content Typen zur Archivsicht auf gehaltene Lehrveranstaltungen 86 Hierarchische Schalen des Typen Kurs in der Archivsicht 94 Teil des Schemas f r den Content Typ Arbeitsplatz ohne Attribute und Beschr nkungen 100 Partielle Schema Morphismen zur Sichtenkooperation 102 Spezifikation von Informationssystemen 105 Die Arbeitsprodukte im Abstraktionsschichtenmodell f r den Story Raum Dialogaspek 7 7 106 Das Fremdbild des Bayern 115 Die Zusammenarbeit von Akteuren zum Erreichen von Zielen 2 117 Das Sicherheitsprofil von Akteuren 2
11. Sn t Ubdate l v M Als l 12 17 und le yields P U yields IF THENP ELSE ER U yields Q R V yields IF THENP ELSE Q ERO V yields P en ER U yields r t1 ty U Die angegebene Workflow Maschine erlaubt eine allgemeine Spezifikation des Verhaltens des Daten banksystems Mit dieser Grundlage k nnen wir eine pragmatischere Spezifikationssprache im weiteren a 12 2 falls JE true falls ole false mit r ti tn P INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 71 Dynamische Integrit tsbedingungen Dynamische Integrit tsbedingungen werden in der Literatur meist aufgrund ihrer Kompliziertheit weggelassen Sie sind jedoch f r die Datenbank Entwicklung nicht minder wichtig Deshalb f hren wir auch einige Klassen explizit ein Wir betrachten dazu temporale Klassen vom Typ R Jedem potentiellen Objekt o von dom R kann eine Lebenszeit Ir o C IN in der Datenbank zuge ordnet werden Damit k nnen wir e temporale Klassen RC Ir und ihre Schnappsch sse S i R Ia o dom R i Ir o einf hren Gegeben seien eine Formel a ber R eine temporale Klasse R lp ber R und Schnappsch sse S 0 RC IR S i RO IR S mazT RC lp Wir k nnen nun eine Frf llbarkeit von Formeln analog zur Modallogik definieren Ein Zeitrahmen ZR besteht aus einem Paar T S W v
12. AZq eiqose yzydur sofeuoryefol jedny OPEL u uorer y rq yu su T sopeuoryefoy uoryegoe1lddy 1192 SSETM eypeids SLIOSU I 84391 INZ T DOYV Tomuszue4su S pun 3nz INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 19 2 Sprachen zur Modellierung von Informationssystemen Denn eben wo Begriffe fehlen Da stellt ein Wort zur rechten Zeit sich ein Mit Worten l t sich trefflich streiten Mit Worten ein System bereiten An Worte l t sich trefflich glauben von einem Wort l t sich kein Jota rauben J W Goethe Faust Erster Teil Studierzimmer Mephistopheles Wir wollen im weiteren zeigen wie sich die vier Aspekte Strukturierung Funktionalitat Inter aktivit t und Verteilung verbinden lassen Eine allgemeine Vorstellung der integrierten Elemente vermittelt Bild 5 Generelle Aspekte von Informationssystemen Strukturierung Funktionalit t Interaktivit t Verteilung N _ ui Struktur Prozesse Content Objekte Stories Dienste Kollaborationsrahmen _ Statische Dynamische Integrit tsbedingungen Integrit tsbedingungen Szenarien Benutzergruppen Aufgaben Konzeptionelle Spezifikation von Informationssystemen ee en ER Schema Datenbank Maschine Interaktionsraum Diensteraum Story Raum Drehbuch Sicht Container Akteure Funktionalit t Szenen Content Typen Architektur Kollaborati
13. Bearbeitungsfunktionen erm glichen die Bearbeitung von Daten aus der Datenbank von Sichtendaten und von pers nlichen Daten der Benutzer Datenbank Modifikationsoperationen erlauben dem Akteur seine Daten in die Datenbank einzu bringen in der Datenbank Informationen zum Arbeitsverlauf vorzuhalten und Daten aus Sichten nach ihrer Bearbeitung durch den Benutzer in die Datenbank zur ckzuspeichern Sichten Objekt Modifikationsoperationen erm glichen eine tempor re Ver nderung der Daten in den Sichten Diese Daten k nnen materialisiert oder mit dem Erl schen der Sicht auch gel scht werden Bearbeitungsfunktionen f r den eigenen Arbeitsplatz unterst tzen die Bearbeitung von Contai nern zu Sitzungen die tempor re Haltung von Daten das Einlagern Modifizieren und Streichen von eigenen Daten Integrationsfunktionen erlauben dem Benutzer aus dem Dialogverlauf heraus f r sich Daten zu ent nehmen bzw einzubringen Exportfunktionen sollen eine ganze Reihe von Funktionen unterst tzen Ausgabe in Druck Dokumente Eine Druckausgabefunktion erlaubt die Ausgabe in vorgegebener Form z B als Formatting Object Damit wird einem Benutzer nicht nur der Inhalt seiner Sitzung oder seiner Arbeitssichten bereitgestellt sondern es werden auch die Daten des Content Objektes f r eine Ausgabe aufbereitet Integration in andere Dokumente Mitunter sind die Auswahl von Daten die erarbeiteten Daten oder Sichten auf das Content Objekt auch in an
14. Read only Zugriff f r Replikate Die Zuverl ssigkeit und Effizienz insbesondere f r parallele Zugriffe ist bei Read only Zugriffen auf Replikaten h her Zugleich entsteht aber ein Update Problem Read and write Rechte f r Replikate Die Zuverl ssgkeit und unter gewissen Umst nden die Effizienz sinken Ein Update wird analog zu Triggermechanismen vorgenommen Je nach Umfang der Replikation k nnen verschiedene Probleme entstehen Damit ist f r jede Anwendung abzuw gen inwieweit eine Replikationsstrategie g nstig ist Art der Replikation volle teilweise keine Anfrageberechnung einfach zn DD Verwaltung einfach oder nicht existent Steuerung der Parallelit t mittel hoch einfach Zuverl ssigkeit sehr hoch hoch niedrig Realistische Anwendungen m gliche Anwendung realistische Anwendung m gliche Anwendung Die Analogie zu Diensteplattformen ergibt hier einen der Implementationsans tze wie in Bild 59 und 60 dargestellt In konventionell realisierten verteilten Datenbanksystemen wird die Verteilung in den Anwendun gen selbst realisiert Die Anwendungsprogramme k nnen miteinander kommunizieren Dadurch wer den an den Entwurf der Schnittstellen dieser Programme hohe Anforderungen gestellt In verteilten Datenbanksystemen wird die Verteilung ber das verteilte Datenbankmanagementsystem bernom men Die Verteilung der Daten ist f r das einzelne Anwendungsprogramm nicht mehr sic
15. die Gesch ftsproze schicht zur Spezifikation der Gesch ftsprozesse der Ereignisse zur Grobdarstel lung der unterlegten Datenstrukturen und zur Darstellung der Anwendungsstory die Aktionsschicht zur Spezifikation der Handlungen der Detailstruktur der Daten im Sinne eines Vorentwurfs zur Darstellung eines Sichtenskeletts und zur Darstellung von Szenarien zu den einzelnen Anwendungsstories die konzeptionelle Schicht zur Darstellung der Prozesse des konzeptionellen Schemas der konzeptio nellen Sichten und der Dialoge in zusammenh ngender Form die Implementationsschicht zur Spezifikation der Programme der physischen und logischen Schemata der externen Sichten und zur Darstellung der Inszenierung Die Motivationsschicht kann als strategische Schicht aufgefa t werden Es werden alle strategischen Entscheidungen zum Informationssystem getroffen Die Gesch ftsproze schicht wird oft auch als An forderungsspezifikationsschicht bezeichnet Im Rahmen dieser Schicht werden neben den Anforderungen jedoch auch konkrete Entscheidungen zur Realisierung getroffen so da wir diese Schicht zur Spe zifikation der Anforderungen der pragmatischen Annahmen der Systemumgebung und der System organisation und architektur erweitern m ssen Die Aktionsschicht ist mit dem Abstraktionsschich fl 30 s0z41 5 x A Sk SIEGEN 5 8 0 x 200 1 00 mi eae See Pn PERS Cerne ae Pannen x ox B n 2 5030 s INFORMATIONSSYS
16. 100 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 6 SICHTENSUITE Aufgaben Ziele typ nutzt bffentlichuhgs organ Ve Content MH T t yP ar Akteur t rbeit Portfolio 1 art u Wet islei gr ppiert unkti od zu Person P Content at Profi Objekt Ber a Re l Container x ehe Bild 36 Teil des Schemas f r den Content Typ Arbeitsplatz ohne Attribute und Beschr nkungen wird einem Benutzer ein anderer Arbeitsplatz zur Verf gung stehen Damit besitzt eine Person un terschiedliche Rechte Akteure sind dann z B der Administrator der Leiter einer Arbeitsgruppe und der Besitzer von Content Objekten oder Containern Die Au endarstellung f r den anonymen Benutzer wird ber das Nachrichtenbrett realisiert Auf dem Content Typ Arbeitsplatz kann zur Laufzeit ein Sitzungsobjekt aufgesetzt werden Damit dies in allgemeiner Form m glich ist f hren wir Sichten ber dem Content Typ ein die wir Sitzungs Schema SArbeitsplatz Parameter nennen Fin Sitzung Objekt SO Arbeitsplatz 4 5 stellt eine Instantiierung des Sitzungs Schemas und eine Einbettung in den Kontext dar Ein Sitzungs Schema ist eine parametrisierte Sicht auf den Content Typ Arbeitsplatz Parameter eines Sitzungs Schemas sind dann Auswahl Objekte mit denen die Daten und Funktionen f r eine Sitzung freigeschaltet werden k nnen Im Beispiel von Bild 36 ist
17. Ff ra fC rely RT o y 62 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 5 FUNKTIONALIT T Potenzmenge Die Potenzmenge P R M M C REC ist eine geschachtelte Klasse ber dem Typ R Umbenennung Gegeben sei ein Typ R Es sei amp eine bijektive Abbildung auf der Markie rungsmenge L mit der Einschr nkung da f r Namen A B in R mit d A B auch dom A dom B gelten mu Die Umbenennung von R mit amp bildet die Klasse R auf eine Klasse pg R R ber R ab Verbund Der Verbund RC M S ist definiert durch den Ausdruck Irus o pn Sellrns 5C2 Rot 502 Aggregationsoperationen werden in OLAP Anwendungen vielf ltig angewandt Eine Aggregati onsoperation ist definiert als Familie F fo fk fu mit Funktionen fr Bag Num die Multimengen mit k Elementen vom Typ T auf einen numerischen Datentyp Num abbilden Wir lassen nur solche Typen zu die ein minimales und ein maximales Element in dom T besitzen Es m ssen zwei Eigenschaften bez glich der Ordnung auf dom T erf llt sein Es gelten die Gleichungen fk min min min und f max max maz f r die minimalen und maximalen Elemente in dom T e Die Funktionen sind monoton bzgl der Ordnung von dom T Da Nullwerte explizit zugelassen sind benutzen wir zwei Hilfsfunktionen f r die struktu relle Rekursion ey 0 falls s NULL f u f s falls s NULL p ndef Gye undef falls s N
18. dem logischem Schema ILD mit einem objekt relationalen oder semistrukturierten Sche ma und entsprechenden logischen Typen den Programmen wie stored procedures Transaktionen Trigger ILF der Datenbank Maschine der Inszenierung Programme des Dialogverwaltungssystemes und Oberfl chen ILS zur Dar stellung der Interaktion und des Pr sentationsraumes im Rahmen des Dialogverwal tungssystemes den Programmen des verteilten Systemes ILV mit einer logischen Spezifikation der Ver teilung den gew hlten Protokollen den Call Programmen und der Qualit tsverwal tung sowie der logischen Sichten Suite ILC mit den entsprechenden Sichtenschemata zur Unterst tzung Jar aaa INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 179 die physischen Schemata IP der Implementation sowie die Sicherheitsarchitektur S und das Fehlerverwaltungsschema F um eine Robustheit des Systemes zu sichern Schrittweise Entwicklung von Anwendungen Eine Methodik bedarf neben einer Theorie auch eine Systematik die auch einer strengen Bewer tung der Software Entwicklung standh lt Deshalb wurde die Co Design Methodik einer Bewertung durch das SPICE 2 0 Framework im Sommer 2003 unterzogen SPICE unterscheidet f nf Niveaus der Reife des Software Entwicklungsprozesses Niveau 1 Definierter Proze Der Entwicklungsproze ist mit einer Schrittfolge definiert Alle er forderlichen Produkte sind definiert und entstehen im E
19. verteiltes Commit Protokoll Recovery globale Deadlock Behandlung Lastverteilung balancierung Lastverteilung balancierung parallele Anfrageverarbeitung Administration Administration besondere Probleme in ortsverteilten Syste men Netzwerkpartitionierungen Knotenau tonomie Oft wird eine vollst ndige Integration von verteilten Systemen angestrebt Da das Integrations problem algorithmisch unentscheidbar ist kann kein Integrationsalgorithmus existieren Integrierte Systeme haben ein gemeinsames konzeptionelles DB Schema Der DB Zugriff erfolgt wie im zentralen Fall womit auch Verteilungstransparenz gew hrleistet ist Damit besitzen die beteiligten DBMS eine eingeschr nkte Autonomie Die einfachste Verwirklichung geht von identischen DBS Instanzen aus wodurch ein homogenes verteiltes System entsteht Beispiele solcher Systeme sind verteilte DBS und Shared disk DBS Andererseits ist eine vollst ndige Integration auch nicht das Ziel Meist ist eine F deration oder eine Kooperation von Systemen ausreichend Damit k nnen auch weitgehend unabh ngige DBMS mit privaten konzeptionellen DB Schemata verwaltet werden Es wird eine partielle Exportierung von Schemainformationen f r externe Zugriffe modelliert Eine Heterogenit t ist sowohl bei Daten modellen als auch bei der Transaktionsverwaltung m glich Damit entstehen allerdings Probleme mit der semantischen Heterogenit t Eine Verteilungstransparenz i
20. m ek INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 151 Der Kollaborationsvertrag wie stellt dar e welche Partner wer mit wem e welche Dienstekomponenten was e mit welcher Qualit t mit welchen Verantwortlichkeiten woraus e auf welcher allgemeinen Vertragsgrundlage worauf und e mit welchem Workflow wie benutzen oder bereitstellen Das Qualit tsmodell in welcher Qualit t stellt die allgemeinen Qualit tsparameter zusammen Das Zeitmodell wann stellt analog zu Ablaufmodellen den Verlauf der Kollaboration dar Das Kontextmodell warum stellt den Kontextrahmen dar Das Akteurmodell wer legt die Partner mit ihren Rollen und Rechten fest Der Kollaborationsvertrag dient der Sicherung der Qualit t des Dienstes Er regelt die Herange hensweise bei einer Vertragsverletzung die Verantwortlichkeiten und die Rollen der einzelnen Kollabo rationspartner Er kann ggf durch eine zentrale Konfliktbehebung unterst tzt werden Wir verwenden zur Sicherung des Kollaborationsvertrages eine Systemkomponente den Qualit tsparameterpr fer Der Qualit tsparameterpr fer basiert auf zwei zentralen Modellen Fehlermodell Es existieren eine Reihe von Techniken zur Bearbeitung von Fehlern Erkennung von Fehlern Damit Fehler erkannt werden k nnen m ssen gesonderte Pr fmecha nismen den Spezifikationen hinzugef gt werden Typisch
21. nn FEAT EFT WE eg 0 RE q a AT Oe EA oe INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG 8 153 Common Facilities Object Request Broker Object Services Betriebssystem Transportdienste Bild 59 CORBA auf IDL Grundlage Services realisieren Basisfunktionen f r die Erzeugung und Verwaltung von Klassen und Objekten zur Namensverwaltung und f r die Persistenz von Datenbank Objekten Mit den Common Facilities werden allgemeine Hilfsfunktionen Klassenbibliotheken zur Verf gung gestellt Anwendungs Common objekte Facilities Object Request Broker Objektdienste Bild 60 OMG Architektur In der Realisierung von OMA in der Common Object Request Broker Architecture CORBA in Bild 61 sind statische und dynamische Methodenaktivierungen Aufrufschnittstellen realisiert Die ORB Schnittstelle erm glicht einen Zugriff auf Infrastrukturfunktionen z B f r die Verwaltung globaler OIDs und die Registrierung von Objekten Die Kommunikation zwischen ORBs wird ber das IIOP Internet Inter ORB Protokoll realisiert Client Objekt Implementation Object Adapter IDL Interface Implementation Repository Repository Bild 61 CORBA Architektur Damit erhalten wir eine Spezialisierung des Kollaborationsrahmens zu einem Kommunikations rahmen Kommunikation Funktionsmanager Stummel Form Syn Formie Raum Si Regeln
22. oa RO Eine oft verwendete Definition basiert auf dem Ausdruck RC og RC U R Da mit wird jedoch ein anderer Effekt erzielt Gilt z B og R und R 4 dann wird die urspr ngliche Intention verloren Dieser Einf hrung liegt jedoch die oft praktizierte Ersetzung von Update R o durch die Folge Delete RC o InsertUpdate R o zugrunde Typ bildende Operationen erzeugen neue Klassen und Typen Gegeben seien die Typen R und S und entsprechende Klassen R und S Kartesisches Produkt Die Klasse R x S 0 0 0 R of S ist definiert ber dem Typ R S Das Kartesische Produkt kann auch in entfalteter Form ber eine Konkatenation der Ob jekte gebildet werden Projektion Es sei R ein Teiltyp von R Die Projektion RC von RC auf R durch eine Reduktion aller Objekte von R auf den Typ Ru Mitunter wird auch die Notation R R anstelle von Il RC verwendet Schachtelung Es sei R ein Element von R Dann wird die Schachtelung vr RC von PC entlang von R definiert als Klasse ber dem Typ T RN R Ur R mit der Menge von Objekten o Dom T 30 RC olRNa R olRNR R A o Rf 0 R o R A o R r X R N Entschachtelung Es sei R ein Mengenelement von R Die Entschachtelung BER einer Klasse definiert einen neuen Typen T R r R o R f r die Konkatenation o und die neue Klasse rf nv V r 171 T TT fr rey
23. 20 21 7 La EN 23 244 24a 24b 24c 244 gt 25 25 Implementations gt 5 b 28a 28b 28c 284 Bild 17 Schritte in unserem Vorgehensmodell INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 41 6 T 10 11 12 13 14 15 16 Z 18 19 20 21 22 23 24 25 26 27 28 Spezifikation der Business Prozesse Formulierung der Funktionalit t f r das Pflichtenheft Aktionsschicht Spezifikation der Szenario der Anwendung Beschreibung der Haupttypen der einzelnen Sichten und deren Assoziationen Entwicklung der Integrit tsbedingungen und deren Erzwingungsstrategie Spezifikation der Benutzeraktionen Rollen Skizzierung der Content Typen Spezifikation der Qualit tsanforderungen und deren Umsetzung im System Entwicklung von Sicherungsstrategien Konzeptionelle Schicht Spezifikation des Story Raumes Spezifikation der Akteure ihrer Portfolio Rollen Rechte Profile Spezifikation der Sichten Suite der Dienste und Austauschrahmen Entwicklung der Workflows Kontrolle der Content Typen anhand von Content Objekten Validierung der statischen Seman tik Kontrolle der Integrit tserzwingung Spezifikation der Szenen der Dialogschritte der Bedingungen f r die Stories der Handlungs berg nge Spezifikation der Content Typen Suite der notwendigen Funktionalit t zu deren Unterst tzung Modulare Verfeinerung der Datentypen Normalisierung
24. Alle Programme beginnen mit dem gleichen Zustandsraum DO P Eine parallele Ausf hrung ist erfolgreich durchgef hrt wenn g keine konkurrierenden Ver nderungen der Datenbank mit DO unterschiedlichen Werten fiir die gleichen Datenbankobjekte 2 4 erfolgen Ausf hrung nach Zuweisung von Werten zu Variablen LET x t IN P D0 P Es k nnen Werte den Parametern in einem Programm P zugewiesen werden Diese Zuweisung gilt nur lokal np Ausf hrung nach Ausvvahl eines VVertes CHOOSE x WITH o DO P Es wird ein x Wert unter einer Bedingung gew hlt 5 CHOOSE x WITH DO P Damit wird das Programm ausgefiihrt 9 Ausf hrung f r alle zutreffenden Werte FOR ALL x WITH DO P Alle Werte f r einen Parameter die zutreffen werden gew hlt Es wird daf r das Programm P parallel aus FOR ALL x WITH o gef hrt SKIP Programmschritt zur Darstellung des leeren Programmschrittes SKIP Konzeptionell kann auch der Programmschritt ohne Auswir N es sg san 122 DO SKIP INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 69 Modifikationsschritt zur Durchf hrung einer Modifikation der Datenbank DO Tig Sq t Es wird ein paralleler Update fiir eine Datenbank Klasse DO i ausgef hrt mit den Parametern 81 Sn 7 Her sn Aufruf eines Programmes aus der Programmbibliothek DO 71 Cis se tia Es kann ein Programm aus der Programmbibliothek aufge DO
25. Anschlie end zeigen wir wie ein schichtenorientiertes Vorgehensmodell im Sinne eines allgemeinen Top down Modelles sinnvoll einfach und im Zusammenhang angewandt werden kann Mit unserem Vorgehen entsteht f r eine etwas umfangreichere Anwendung mit etwa 500 Entity Relationship und Cluster Typen im ersten Schritt ein kurzes sechsseitiges Essay mit der Beschrei bung der Ideen und Motive ein l ngeres 30 seitiges Treatment Lastenheft zur groben Darstellung der Strukturen Prozesse Dialoge und Zusammenh nge ein 100 seitiges Rohbuch Pflichtenheft zur Darstellung der Aktionen Vorentw rfe Handlungen Sichtenskelette Szenarien ein 200 seitiges Buch zur Darstellung des konzeptionellen Entwurfes und ein 500 seitiges Werk zur Darstellung der Implementation Diesem Vorgehen kann entgegengehalten werden da ein von Intuitionen gepr gter Entwicklungsproze eher geeignet ist ein Ziel zu erreichen Damit kann ein einfacher Entwurf ent stehen der in einem Lehrbuch etc dargestellt werden kann nicht aber ein komplexerer Datenbank entwurf Wie sehr ein intuitiver Stil gepflegt werden kann h ngt auch von der Professionalit t der Entwerfer ab die wie die DB bzw ID community zeigt z T umfangreiche verarbeitete bewu te und vor allem unbewu te Kenntnisse ber die Strukturen Prozesse und Dialoge einer Anwendung besitzen In den n chsten Teilkapiteln stellen wir zuerst die Datenspezifikation die Funktionsspezifikation
26. Es konnte festgestellt werden da unsere Entwicklungsmethodik dem SPICE Framework Stufe 3 gen gt Da nur weni ge Entwicklungsmethodiken SPICE Stufe 1 erf llen keine andere SPICE Stufe 2 erf llt kann die HERM Methodik als die modernste und ausgereifteste Methode verstanden werden Ich m chte meinen Mitarbeitern und Studenten in Rostock und Cottbus und meinen Projekt partnern in Chile Deutschland Finnland Indien Jordanien Kuwait Neuseeland Oman Ru land Ungarn und Schweden sehr f r die kritische Begleitung dieses Projektes danken Mein Dank abschlie Bend an meine Familie f r ihre Geduld und ihre Inspiration Abk rzungen und Annotationen Wir folgen den blichen Notationen des ER Modells obwohl dies nicht einheitlich erscheint So wird z B ein ER Typ mit einer Gleichung E Attributmenge Semantik eingef hrt ein Typ im allgemeinen jedoch durch seinen Konstruktionsausdruck der Form Name lt Konstruktor gt lt Komponentenfolge gt Wir verwenden Buchstaben verschiedener Alphabete mit einer Systematik Grundbegriffe werden mit lateinischer Schrift z B T f r einen Typen f f r Funktionen dom B f r Werte bereiche bei Kollektionen mit kalligraphischen Buchstaben bezeichnet z B ER f r ein ER Schema Abgeleitete Konstrukte werden mit gotischen Schrift Typen bezeichnet f r Sichten f r Container Theorien und Umgebungen werden mit erweiterten mathematischen Schriften dargestellt Zum Beispiel bezeich n
27. In der Kolloaborationsform werden die Konfigurations und Zugriffsparame ter die Freignisverarbeitung die Synchronisation und die Parameter des Kollaborationsvertra ges untersetzt Eine alternative Darstellung wird durch eine Darstellung von Architektur Formation und Berechnung wie im Arbeitsblatt auf Seite 157 gegeben Spezifikation auf der Implementationsschicht Das Dienste und Kollaborations verwaltungssystem Das Dienste und Dienste und Kollaborationsverwaltungssystem wird mit einer Dienstnehmer Dienstgeber Architektur in die Infrastruktur eingepa t Dazu unterscheiden wir zwischen Daten ber tragung und Datenverwaltung f r jede Komponente Zur allgemeinen Darstellung von verteilten Sy stemen f r die Implementationsschicht verweisen wir auf Monographien und Lehrb cher zu verteilten Systemen wie z B ALSS03 Produkte des Spezifikationsprozesses f r die Verteilung Produkte der Spezifikation der Verteilung sind je nach Abstraktionsschicht Im Pflichtenheft werden die Dienste der Kollaborations und der Qualit tsvertrag festgehalten Die Spezifikation des kollaborativen Systemes umfa t zur Spezifikation des Kollaborationsraumes den Kollaborationsrahmen die Dienste aus der Benutzersicht und die Qualit tsparameter die ein Benutzer beurteilen kann Das Dienste und Kollaborationssystem spezifiziert den Diensteraum mit den Content Typen den Kollaborationsrahmen und die Architektur des Dienste und Kollaborationssys
28. Netz und Vermittlung Transport Anwendung wie z B Middleware und des verallgemeinerten 5 Schichten ANSI Modelles extern intern phy sisch Segment Datei mit Erweiterungen zu einer dritten Dimension die durch HW SW Systeme determiniert wird sich eine bersicht zu verschaffen Anwendungssysteme wie Middleware Systeme unterst tzen die Kopplung von Informationssystemen Middleware kann bei der berwindung der He terogeniet t durch entsprechende Transformationsmechanismen zur Typkonversion und Aufrufumfor mung unterst tzen Diese Umformungen k nnen auf der Grundlage von Regeln vorgenommen werden Stummel Objekte werden dienstnehmerseitig erzeugt und Ger st Objekte werden dienstgeberseitig bereitgestellt Es wird ein Funktionsaufruf wie in Bild 13 realisiert Die Vermittlung von Dienstgebern basiert auf einem Vermittlungsdienst einem Namendienst mit einem Namensraum und einer entsprechenden Navigationsunterst tzung Innerhalb des verteilten Systemes werden Dienste aktiviert und beendet Lasten verteilt die Sicherheit und die Persistenz ga rantiert und eine verteilte Transaktionsverwaltung mit einem Ressourcen Verwalter einem Synchroni sationsdienst und einem Transaktionsverwalter unterst tzt Typische Architekturen f r Middleware Systeme sind CORBA und Web Dienste Wir sind jedoch mehr an einer konzeptionellen Modellierung der Verteilung interessiert Eine CORBA oder Web Dienste Spezifikation ist eine physische oder logische Umsetzun
29. Wir erweitern dieses Mo dell zu einem Higher Order Entity Relationship Modell HERM Es umfa t die folgenden Konstrukte e Attribut Typen k nnen einfache oder auf der Grundlage von Konstruktoren wie Mengenkon struktor Tupelkonstruktor Listenkonstruktor Multimengenkonstruktor induktiv konstruierte komplexe Attribut Typen sein Sie werden induktiv definiert Basis Datentypen sind parametrisierte Typen T dom T ops T pred T des DBMS Sie sind gegeben durch eine Bezeichnung T evt auch mit Abk rzung einen Wertebereich dom T eine Menge von Funktionen 6 und eine Menge pred T von Pr dikaten Oft wird auch der Basis Datentyp mit einem Informationstyp assoziiert Ein Beispiel ist der Typ der ganzen Zahlen in der 4 Byte Repr sentation integer IntegerSetapyte 10 s lt mit der Nachfolgefunktion s Basis Datentypen verf gen neben dem Wertebereich auch ber Funktionen und Pr dikate Sie sind au erdem durch eine Reihe von Eigenschaften eingeschr nkt die im Datenbank system zu beachten sind und oft im Entwurf bersehen werden Die Pr zision und Genauigkeit sind ggf f r Typen wie REAL eingeschr nkt Die Granularit t von Daten kann sehr unterschiedlich sein Die Skalierung von Da tentypen kann sich ggf auch auf die Funktionalit t auswirken Datentypen verf gen nur ggf ber eine eigene Ordnungsbeziehung Datentypen verf gen ggf ber eine Klassifikation innerhalb der Dat
30. Zuerst stellen wir unseren Zugang zum Gestaltungsrahmen vor Der Gestaltungsrahmen ist durch Playout mit Werkzeugen a Zr ik 138 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 7 INTERAKTIVIT T Metaphern Akteure und Qualit tsanforderungen spezifiziert Die unterschiedlichen Layoutentscheidungen werden in Monographien zu graphischen Benutzungs schnittstellen ausf hrlich behandelt F r die Spezifikation des Gestaltungsrahmen wollen wir uns allerdings auf generelle Typen von Layoutentscheidungen konzentrieren Deshalb wird nicht im De tail diskutiert werden ob gr n oder pastellgr n passende Farben sind Die Charakterisierung der Akteure haben wir bereits bei der Spezifikation des Story Raumes vorgenommen Diese Spezifikation wird nun mit den Profilen und den Portfolios kombiniert Die Qualit tsanforderungen haben wir be reits im Detail eingef hrt Wir werden sie jedoch im weiteren zu Qualit tsvorgaben f r die Interfaces verfeinern Die einzelnen Komponenten des Gestaltungsrahmens sind die folgenden Werkzeuge zur Gestaltung der Benutzungsoberfl chen in den 90er Jahren sind in einer Vielfalt ent wickelt worden da eine bersicht schwerf llt Zugleich f llt ins Auge da fast alle diese Werk zeuge keine gro e Verbreitung gefunden haben Eine Ursache ist sicherlich auch der Hang zur featuritis Die Werkzeugentscheidung sollte sich an einer Klasse von Interfacewerkzeugen orientieren Mit der Anga
31. angeschlossen werden Dieser Methodik sind eine Reihe von methodischen und inhaltlichen Br chen eigen Die Schwierig keit eines kompletten Datenbankentwurfs ist jedoch in vielen F llen auf diese Br che zur ckzuf hren Es werden unterschiedliche Sprachen verwendet und unterschiedliche Personen bringen unterschied liche Interpretation und Sichtweisen auf das Informationssystem ein F r die Spezifikation aller Aspekte von Informationssystemen d h der Strukturierung Funktiona lit t Verteilung und Interaktivit t entwickeln wir eine Reihe von miteinander integrierten Spezifikati onssprachen Die Sprachen unterst tzen die Entwicklung von Informationssystemen mit Hilfe des Abstraktionsschichtenmodelles Die Schrittfolge zur Entwicklung von Informationssystemen im Co Design Zugang wird in der Folgearbeit darge stellt Die Komponentenkonstruktion wurde in einer Reihe von Konferenzarbeiten vorgestellt und in der Dissertation TT m 13 1 Ty q 2 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 0 VORWORT Das Skript soll kein Theoriebuch ersetzen Es extrahiert aus der Theorie des Entity Relationship Modelles Tha00 die Elemente die f r den Entwurf gro er Systeme notwendig sind Hauptziel dieses Skriptes ist die Pr sentation einer in sich geschlossenen und konsistenten Entwurfsmethode mit der der Entwurf gro er Anwendungen noch berschaubar und nachpr fbar gestaltet werden kann Ad hoc Methoden und Sprachen bringen meist
32. ber sichtlich In den ersten Abstraktionsschichten stellt es aber eine gute Alternative zum HERM Diagramm zum de ent Diplomand Diploma Sine Person Universitatsmitarbefiter Professor Proyektmitarbeiter Bild 21 Hierarchisches ER Diagramm versus HERM Diagramm Aggregation Wir k nnen die Konstruktion von Relationship Typen zu einer allgemeinen Ag gregationskonstruktion erweitern indem wir weitere Konstruktoren zulassen e Vereinigung e Mengenbildung e Aggregation durch Beziehungsklasse und e Abstraktion durch Komponentenbildung Klassen werden mit der hochgestellten Annotation C und dem Typnamen bezeichnet Z B sind Person und InGruppe Klassen entsprechenden Typs Statische Integrit tsbedingungen Die Semantikspezifikationssprache umfa t Schl ssel und Inte grit tsbedingungen wie funktionale Abh ngigkeiten Exklusions und Inklusionsabh ngigkei ten mehrwertige Abh ngigkeiten Viele Eins Bedingungen Seinsbedingungen Existenzbezie hung Verweisbedingungen Teiltypenbedingungen und Regeln wie z B die Gesamtheitsregel die Verneinungsregel und die Sichtregeln sowie vor allem Komplexit tsbedingungen Kardi nalit tbedingungen zur Spezifikation der Beziehung zwischen einem Relationship Typen und seinen Komponenten Statische Integrit tsbedingungen werden als Formeln der hierarchischen Pr dikatenlogik allge mein dargestell
33. ber den Namen des Pro grammes durch eine Instantiierung der formalen Parameter durch aktuelle Parameter und durch die Angabe des Nutzers und der Steuerungsumgebung angegeben Die Angabe des Nutzers der ein anderes Programm oder ein Benutzer sein kann erfolgt nicht nur f r Abrechnungs sondern auch f r Benachrichtigungszwecke Die Steuerungsumgebung er laubt eine detaillierte Angabe der Steuerung der Priorisierung der Ausf hrung auf an deren Knoten Zur Angabe kann au erdem eine Spezifikation der Ausnahmenbehandlung geh ren wie z B f r den Fall eine konkurrierenden Abarbeitung Steuerungsspezifikation Zur Steuerungsspezifikation unterscheiden wir drei R ume e Im Nachrichtenraum werden sowohl die Benutzernachrichten als auch die System nachrichten verwaltet Im ersteren Falle sind Informationen zur Sichtbarkeit Notifika tion und zum Datenstrom des Benutzers im letzteren zur bertragung Signoff und RN o nn on BL Ad eee ann au INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 67 e Im Parameterraum werden alle aktuellen Parameterzuweisungen wie Status Priorisie rung Ausf hrungsmodi stand alone eingebettet remote applet servlet Bindungen und Einschr nkungen verwaltet Au erdem erfolgt hier die Speicherung des Benutzer portfolios und des aktuellen Benutzerprofils e Im Ressourcenraum wird die Allokation von Daten Routen Knoten etc zu den aktu ellen Prozessen dargestellt Weitere Modelle sin
34. e Ein maskierter Benutzer kann einen Dienst durch eine Vielzahl von Anforderungen er sticken Durch explizite Spezifikation der Verweigerung von Diensteangriffen wird dem entgegengewirkt e Ein maskierter Benutzer kann W rmer trojanische Pferde oder Viren mit dem Ziel versenden sich unberechtigten Zugang zu den Daten oder Leistungen des Dienstes zu verschaffen Deshalb ist eine Sicherung des mobiles Codes und der mobilen Daten erfor derlich Bedeutungstreue erfordert die Integration der Benutzerwelt in die Spezifikation Sie umfa t unter schiedliche Aspekte Benutzerverst ndnis Das Verst ndnis der Benutzer ber den Content ist frei von Konflikten Unterschiedliche Content Suiten besitzen eine verschiedene Bedeutung Temporale Aspekte Content Suiten entwickeln sich ber die Benutzungszeitr ume Die Zeit aspekte k nnen konzeptionell mit den Content Suiten verbunden werden d s a TT eA 5 Pe ne ax b a St CL E ii T 2346 90 INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 149 Bedeutungstreue kann durch eine Theorien und Modellierungswelt und eine abgestimmte Begriffslandkarte unterst tzt werden Die Entwicklung einer Spezifikationsmethode zur Un terst tzung der Bedeutungstreue ist jedoch noch ein Forschungsthema Heterogenit t ist in verteilten Systemen die Regel Sie tritt in unterschiedlichen Facetten auf Heterogenit t der Netzwerke Hetero
35. lt 1 gilt Eine Menge U T si 1 Sin 01 1 lt i lt m von objekt basierten Anderungsoperationen ist konsistent falls aus T si 1 Simni Tj 8j 1 8jn f r 1 lt i j lt m die Gleichheit folgt Das Resultat der Ausf hrung einer konsistenten Menge U von nderungsoperationen f hrt zu einer Zustands nderung der Datenbank R zu ER U Update 1 8154 falls ls oi E U C p is Di l Sinis 95 ili 1s SiNi i RR ER andernfalls f r Objekte o of ER Ein parametrisiertes Programm r z1 n P der Stelligkeit n besteht aus einem Programm namen r einer Transitionsregel P und einer Menge 21 2 von freien Variablen von P Eine Datenbank ER ist ein Modell von amp kurz bezeichnet als R falls oer true 2 m dl a i hy cee SEEN ok eee 0 70 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 5 FUNKTIONALIT T Eine Workflow Maschine W ER E RC P basiert auf einem Datenbank Schema ER einer initialen Datenbank R einer Menge von parametrisierten Programmen und einem ausgezeichneten Programm das Hauptprogramm genannt wird sowie den dynamischen Integrit tsbedingungen Eine Transitionsregel P f hrt zu einer Menge U von nderungsoperationen in einem Zustand ER falls dieser konsistent ist Sie ver ndert den Zustand der Datenbank mit einer Variablenbelegung zu yields R
36. t Informationssysteme stellen eine Vielzahl von Funktionen eine Anfrageschnittstel le eine Modifikationsschnittstelle eine Transaktionsverarbeitungskomponente Programme etc zur Verf gung F r eine Anwendung werden Prozesse auf der Grundlage dieser Funktionen entwickelt F r die Prozesse gelten dynamische Integrit tsbedingungen Wir fassen die Prozes se und die dynamischen Integrit tsbedingungen in der Datenbank Maschine zusammen die die Funktionalit t der Anwendung beschreibt Verteilung Informationssysteme werden heutzutage in andere Systeme eingepa t sind selbst oft nur Bestandteile einer Infrastruktur und kooperieren miteinander Wir entwickeln hier eine all gemeine Spezifikation der Verteilung basierend auf dem Konzept der Dienste der Austauschrah men und der Kooperationsbedingungen Diese Spezifikation verallgemeinert Zug nge aus dem Bereich der Kommunikationssysteme der verteilten Systeme und der Betriebssysteme Interaktivit t Ein Informationssystem soll den Benutzer bei einer Vielzahl von Aufgaben un terst tzen Es werden je nach Anwendungskontext unterschiedliche Handlungsabl ufe ausgel st Wir fassen diese Abl ufe im Story Raum zusammen Gruppen von Benutzern werden abstrakt durch Akteure dargestellt Die einzelnen Arbeitsschritte fassen wir in Szenen zusammen Die ben tigte Unterst tzung durch das Datenbanksystem erfolgt durch Content Objekte die eine Verallgemeinerung von Sichten darstellen und um eine Funktio
37. 6 63 null null null SQL To _ u 7 a nu nu count count count indef null s null null 21 undef 29 undef undef count count count ull 1 undef SQL benutzt eine Variante die nicht die intuitivste ist Wir pr ferieren in der HERM Algebra die mit annotierten Varianten f r den Fall von Klassen mit Nullwerten Die Funktionen avg und avg of werden dabei der SQL Form avg vorgezogen Die algebraischen Operationen k nnen zur Bildung von komplexeren Ausdr cken benutzt werden Eine HERM Anfrage ist ein komplexer Ausdruck in der HERM Algebra Erweiterte HERM Spezifikation von Operationen Wir erweitern die HERM Algebra um die Spezifikation einer Umgebung Sicht Ausf hrungsbedin gungen als Vorbedingung und Nachbedingung und Nachfolgeoperationen In diesem Fall erhalten wir einen allgemeinen Definitionsrahmen der Form Operation o Sicht lt Sichten_Name gt Vorbedingung lt Aktivierungs_Bedingung gt Aktivierte_Operation lt Spezifikation gt Nachbedingung lt Akzeptanz Bedingung gt Erzwingene Operation lt Operation Bedingung gt Sprachen zur Darstellung von Workflows Die Arbeitsvorg nge werden in Einzelschritte zerlegt Die Einzelschritte werden durch Prozesse ver feinert Der Zusammenhang der Arbeitsvorg nge wird durch verallgemeinerte Transaktionsmodelle dargestellt In der Datenbank ver ndern Prozesse die Zust nde Deshalb werden die Zustandsver nde run
38. AD93 BS03 KK93 1 LL99 Leo92 LM78 Mai83 MR92 PBGG89 Tha91 Tsa89 Weiterfiihrende und interessante Literaturquellen sind besonders im Bereich des Drehbuch designs zu finden Wir verweisen hier auf die weiterfiihrende Literatur auf unserer Website Die Literatur zur Gestaltung graphischer Benutzungsschnittstellen ist un berschaubar Wir ben ti gen davon wie bereits erl utert nur einige zentrale Werke wie MS95 Die Theorie der Gestaltungs raster und der Gestaltungsrahmen basiert auf origin ren Arbeiten von T Moritz Mor03 Die Theorie der Kollaborationsrahmen ist ebenso wie diese Theorie noch nicht publiziert und am Lehrstuhl DBIS entstanden 182 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 LITERATUR Literaturverzeichnis AABT98 M Albrecht M Altus E Buchholz H Cyriaks A D sterh ft J Lewerenz H Mehlan M Steeg ABH97 AD93 Ago86 AHV95 ALSS03 Alt Alt96 BCN92 BDKO1 Bek92 Bes95 BHG87 Bis95 BL93 BP98 Bra94 Bro00 BS97 503 CP84 Dad96 DGHO03 Dre95 DT04 TT 341 K D Schewe and B Thalheim Radd rapid application and database development compiled readings of papers published in the radd project BTU Cottbus Computer Science Institute 1998 P M G Apers H M Blanken and M A W Houtsma Multimedia Databases in Perspective Springer Heidelberg 1997 P Atzeni and V De Antonellis Relational database
39. Angaben zur Art der Durchf hrung 1 1 3 Best tigung oder Modifikation der Zielgruppe f r die Lehrveranstaltung 1 1 3 1 Best tigung oder Modifikation des Studienganges 1 1 6 Angaben zur Nebenbedingungen der Lehrveranstaltung 1 1 6 1 Angaben zu Terminw nschen 1 1 6 2 Angaben von Parallelveranstaltungen 1 3 Zusatzangaben zum Lehrbericht parallel zu 1 1 3 1 1 6 DO UNTIL END_Of_LIST optional optional Diese Tabelle kann als eine Auffaltung oder Verfeinerung der Tabelle von Seite 57 betrachtet werden Damit sind wir in der Lage die Konsistenz der Entwicklungsschritte direkt zu betrachten Die Algebra des erweiterten Entity Relationship Modelles Alle Funktionen basieren auf einer entsprechenden Algebra die zum einem Elementar Operationen bereitstellt und zum anderen die Konstruktion von komplexeren Operationen auf der Grundlage vorhandener Operationen erm glicht Wir erlauben eine komplexere Strukturierung von Typen Deshalb verallgemeinern wir f r die Definition von Operationen Teilstrukturen und Vergleiche 0 0 0 ma 5 zi i x 5 h 2 Xo s 5 xn 60 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 5 FUNKTIONALIT T Die Definition von Teilstrukturen basiert auf der Ordnung lt die als kleinste bin re Rela tion ber der Menge G aller Strukturen definiert mit folgenden Eigenschaften A x X f r jedes X 6 A A1 An B B Bn fal
40. Arbeitssituation 4 Arbeitsvorgang 118 Architektur 177 Archivdatenbanksystem 169 Aspekt orientierte Programmierung 129 Attribut Typ 43 Aufgabe 56 117 Aufrufspezifikation 66 Ausbildungsprofil 114 Ausf hrungsmodell 119 Austauschrahmen 146 Auswahl von Objekten 61 Barrierefreiheit 139 Bedeutungstreue 148 Begriffslandkarte 149 Benutzer 113 Benutzer Arbeitsplatz 99 Benutzer Gesichtspunkt 104 Benutzungskontext 130 Benutzungspraferenz 116 Beweglichkeit 148 Closed world assumption 5 Cluster Klasse 46 Cluster Typ 46 YrYu a KATI 35 Container 95 Content Klasse 85 Content Objekt 85 Content Typ 85 Corporate design 135 Corporate identity 139 CSCW 146 Daten Typ 36 Daten Warenhaus 171 Datenbank Farm 168 Datenbank Schema 51 Datenbanksystem 3 Dauerhaftigkeit 149 DBMS 3 Delete 61 Deontische Bedingung 72 Dialogschritt 37 107 109 123 Dialogszene 37 123 Dienstverhalten 29 Dienstvertrag 29 Differenz 61 Diskurs 105 176 Drehbuch 104 Durchschnitt 61 Effekt 64 Einf gen von Objekten 61 Einf hrungsschicht 35 Entfaltbarer Workflow 77 Entfalteter Workflow 77 Entity Klasse 45 Entity Typ 45 Entschachtelung 61 Entwicklungsschritte 176 ER Diagramm 48 ER Modell 48 Ereignis 107 177 Erreichbarkeit 148 Ersetzungsfamilie 60 Evolution res System 169 Exklusionsabh ngigkeit 51 Fragmentierung 159 Freiz gigkeit 148 Funktionale Abh ngigkeit 49
41. Aufgabenbezug Benutzerf hrung Beispiele Einf hrung und Vor einstellungen Aus dem Profil k nnen wir die Art und die Form der Informationspr sentation und das Infor mationsbeschaffungsverhalten der Akteure ableiten Weiterhin kann man Benutzungspr ferenzen der Akteure skizzieren Akteure k nnen mit anderen Akteuren zusammenwirken Im Zusammenwirken spielen Ziele eine Rolle Ein Modell zur Darstellung der Ziele stellen wir in Bild 41 kurz zusammen Im Zielmodell unterscheiden wir zwischen unscharfen oder weichen Zielen und harten Zielen Weiche Ziele besitzen kein genau darstellbares Erf llungskriterium Harte Ziele sind dagegen durch ein Erf llungskriterium charakterisiert Zum Erreichen von Zielen k nnen Akteure zusammenarbeiten Einem Akteur kann ein Sicherheitsprofil zugeordnet werden Wir verwenden dazu eine Daten struktur wie in Bild 42 15Die Erfahrung im Projekt FuEline deutete auf eine Halbwertszeit von weniger als 3 Monaten hin wodurch der Verfall eines wie perfekt auch immer gestalteten Informationsbestandes innerhalb kurzer Zeit vollst ndig ist wenn nicht m xY 177 PR Te 11 ooo m ideen Ch CO EEE a TEE Te Pe ar INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 117 Mit arbeit Zusammenarbeit Von Erf llungs kriterium Medien Typ Aufgabe Bild 41 Die Zusammenarbeit von Akteuren zum Erreichen von Zielen
42. Content Objektes f hren weil die Beladungskapazit t des Containers f r Einzelelemente ggf be schr nkt ist e Die Auswertungsfunktion kann entsprechende Zeit erfordern Mit einem Pr dikat success eval t wird der Erfolg gemeldet inspect m t t Semt e choose M w hlt ein Element aus einer Multimenge aus Wir ben tigen nur vier Zustandsver nderungsfunktionen zur Ver nderung von Z Z M O mit Elementen t Tupelg und Mustern Muster Schnelle Beladung Die Funktion load Z x Tupelge Z mit load Z M O t 1 MU eval t O erlaubt eine sofortige Beladung von Containern Langsame Beladung Die Funktion lazzyload Z x Tupele gt Z mit lazzyload T M t success eval t gt Z MU eval t 0 unterst tzt eine verz gerte Beladung ohne auf die Beendigung der Berechnung von eval zu warten Lesen im Containers Die Funktion read Z x Muster x Tupele mit read Z M O m t choose inspect Z M O m t generiert ein Resultat auf die Anfrage t mit dem Muster m Lesen und L schen im Container Die Funktion read Z x Muster x Tupele Ox M mit read Z M O m t 1etz choose inspect Z M O m t x M lx generiert ein Resultat auf die Anfrage mit dem Muster m und l scht dieses Resultat aus dem Content Raum des Containers Wir haben die Definition des Containers und seiner Operationen so allgemein gehalten damit wir Container sowohl mit CORBA oder anderen Midd
43. Die Erlaubnis ist dual zur Obligation KD4 Fo Po Verboten heiBt nicht erlaubt Weitere allgemeing ltige Formeln der deontischen Logik sind z B Oo Pa O o A 8 o Oa A O Oo A e P av 8 o Pav PB Oav OB 6 Oa OfoV P iaA B gt Pad PB Fa F a B Oo A PB P o A 0 fv A Mil x FINN u INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 73 ParnOla gt PB 8 Fa F6A Fr A Ofa y Fa 8 A Fo A e Oo A O o A 8 y gt O O a a gt Oa O o 6 Fa O a 6 O a O a 6 e a o O o A 7a Oo A O a 6 A A o gt false a Wir werden uns jedoch im weiteren auf Transitionsbedingungen und Vor und Nachbedingungen konzentrieren sowie auf weiche Integrit tsbedingungen der deontischen Logik Unterscheidung von Handlungsabl ufen f r Funktionalit t und Interaktivit t In klassischen Ans tzen werden Handlungsabl ufe zur Spezifikation der Funktionalit t und zur Spezifikation der Interaktivit t auf gleiche Art und Weise durch Workflows dargestellt Diese Dar stellung ist aufgrund einer ganzen Reihe von Gr nden irref hrend und f hrt zu einem Workflow Impedance Mismatch e Workflows zur Spezifikation der Funktionalit t umfassen auch Prozesse der Systeme d
44. Entwicklungsproze kann an die unterschiedlichen Kontextbedingungen angepa t und auch optimiert werden Niveau 4 und 5 sind bislang von keiner Entwicklungsmethodik erreicht worden Es gibt wenige Bei spiele f r Entwicklungsmethodiken die bereits das Niveau 1 berschritten haben Die Co Design Entwicklungsmethodik ist eine der wenigen die bereits das Niveau 3 erreicht hat Sie basiert auf einer Schrittfolge in der in jedem Schritt die folgenden Parameter dargestellt werden Teilschritt 1 Schritt xy Teilschritt 2 Teilschritt z aal Verwendbare Dokumente aa2 aal Betroffene Dokumente aa3 oo Obligationen 4 aa5 Erstellte Dokumente oo Obligationen Resultate rel rr2 rr3 ek osa d ae an 180 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 9 DOKUMENTATION Beteiligte cc dd Theoretische Grundlagen e ee ef Methoden und Heuristiken gg Beginnbedingung hh Abschlu bedingung kk Dieser allgemeine Rahmen erlaubt eine genaue Erfassung des Entwicklungsfortschrittes Gleichzei tig entsteht eine Dokumentation der Gesamtentwicklung die auch die Einzelentscheidungen sichtbar macht Es werden weiterhin die Heuristiken die zu bestimmten pragmatischen Annahmen f hren mit erfa t Damit kann auch zu einem sp teren Zeitpunkt nachvollzogen werden warum ein Entwick lungsschritt zu einem bestimmten und nicht zu einem anderen Resultat
45. Entwurfes wird eine Transformation hin zur logischen Spezifikation vorgenommen Dieser Zugang erfordert weni ge Korrekturen im Entwicklungsproze und erscheint deshalb besonders geeignet Er wird im weiteren pr feriert Wir kombinieren diese Vorgehensmodelle zu einem schichtenbasierten Vorgehensmodell Innerhalb einer Abstraktionsschicht determiniert der Interaktionsraum die anderen Aspekte Damit erhalten wir ein Vorgehensmodell dessen Schrittfolge in Bild 17 dargestellt wird und das als Grundlage f r die einzelnen Entwicklungsschritte dient Die einzelnen Schritte in Bild 17 sind die folgenden Motivationsschicht 1 Entwicklung der Motivation und der Ziele der Anwendung Informationsanalyse 2 Entwicklung des Lastenheftes zur Anwendung Gesch ftsproze schicht 3 Separation der Systemes in Komponenten und Entwicklung der Architektur des Systemes 4 Skizzierung des Story Raumes Formulierung der Interaktivit t f r das Pflichtenheft 5 Skizzierung der Sichten Suite f r die einzelnen Komponenten der Dienste und des Austauschrah AI EEEIEE EES EN 2380 A A AR sa IN uu z 5 a Ro I os o AE a 40 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 3 ABSTRAKTIONSSCHICHTENMODELL Fkt Struktur Verteilung Dialoge Funktionen Str 1 Motivations schicht 9 3 Gesch fts proze schicht 5 4 6 Be Aktionsschicht 1 9 11 16 13 15 18 17 Konzeptionelle 19 Schicht
46. Existenzbeginns und endes grundlegend zur Umsetzung von Handlungen innerhalb der Datenbank Wir unterscheiden bei der Beschreibung der Funktionalit t in der Modellierung zwischen Produktfunktionen des Lastenheftes die in allgemeiner Form die Hauptfunktionen mit den Ein schr nkungen der Anwendung darstellen Arbeitsschritten des Pflichtenheftes die die Funktionalit t auf dem Niveau der Gesch ftprozesse und Gesch ftsvorf lle in ihrem Ablauf unter Ber cksichtigung der Organisationsstruktur dar stellen Aktionen der Nutzer Maschine zur vollst ndigen Beschreibung aller Handlungen von Benutzern aus deren Sicht Prozessen der Workflow Maschine zur vollst ndigen konzeptionellen Spezifikation der Funktio nalit t der Anwendung und Programmen der Datenbank Maschine auf dem Niveau der logischen Maschine bis hin zur Codie 2820585552 kx F aa pn 0 Se d dua a ls o INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 55 Produktfunktionalitat Motivations schicht Vorstudie Skizzierung Produktfunktio Lastenheft Funktionen 5 Gesch ft Gesch ftsproze esch ftprozesse schicht Feinstudie Verfeinerung Arbeitsschritt Pflichtenheft Funktion Handl Aktions schicht Entwurf Entwicklung l Aktionen gt Nutzer Maschine konzeptionelle Workflow Schicht Implementation Transformation Prozesse Workflow Maschine Implementations Mo
47. Ge sichtspunkten und allgemeinen Anwendungsf llen anstreben ist das Komponenten Schema die Grundlage f r die Entwicklung des Informationssystemes in unserem Vorgehensmodell Pflichtenheft P Das Pflichtenheft f r die Entwicklung von Informationssystemen stellt eine Erwei terung des Pflichtenheftes nach dem IEEE SRS Software Requirements Specification Standard dar Das Lastenheft dient zur Kurzbeschreibung des Pflichtenheftes Alle Elemente des Lastenheftes wie z B die Beschreibung zum Produkteinsatz und zur Produktumgebung die Qualit tsmerk male die externen Schnittstellen behalten ihre G ltigkeit Zielbestimmung PZ Es werden die allgemeinen Entwicklungsziele die Produktziele wichtig ste Vergleichsprodukte und die Anforderungen an das Produkt kurz und pr zise darge stellt Weiterhin werden Annahmen und Abh ngigkeiten innerhalb der Komponenten und der Komponenten untereinander dargestellt Au erdem sollten Einschr nkungen wie z B Entwicklungsrestriktionen und funktionale Anforderungen ihren Niederschlag finden Die Zielkriterien k nnen in Mu kriterien f r unabdingbare Eigenschaften Wunschkriteri en f r anstrebbare Eigenschaften und Abgrenzungskriterien f r nicht anzustrebende Ei genschaften enthalten Es k nnen externe Schnittstellen erforderlich sein so da deren Anforderungen beschrieben werden Beschreibung der Strukturierung PD Es werden die Struktur und wichtigsten statischen In tegrit tsbedingun
48. Generative Programmierung 129 Generischer Workflow 77 Gesch ftsproze 177 Gesch ftsproze schicht 34 SSF Pea ACCT fr i A194 d r 1405 INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG Global and local as view 167 Global as view 167 Grober Typ 177 Gruppenarbeit 146 HERM 48 HERM Algebra 60 HERM Anfrage 63 HERM Diagramm 48 Heterogenit t 149 Hierarchisches ER Diagramm 48 Historie 128 Hypergraph 93 Implementationsschicht 34 Information 3 Informationsbed rfnis 115 Informationsbedarf 119 Informationsbeschaffungsverhalten 116 Informationslogistik 107 Informationspr sentation 116 Informationssystem 3 Inklusionsabh ngigkeiten 51 Inkrementelles System 169 Insert 61 Integrationsschema 81 101 Integrit tsbedingung 42 Interaktionsdiagramm 120 Interaktivit t 3 104 Interpunktion 5 Kardinalit tsbeschr nkung 49 Kartesisches Produkt 61 Klasse 43 Kollaboration 146 Kollaborationsrahmen 29 134 152 Kollaborationsvertrag 151 Kommunikation 146 Kommunikationsrahmen 111 Konkurrenz 65 Konsistenz 149 Kontext 85 109 Konzept 176 Konzeptfeld 74 Konzeptionelle Schicht 34 Konzeptionelle Spezifikation 37 Konzeptlandkarte 176 Konzeptrahmen 74 Kooperation 146 154 Koordination 146 154 Kuvert 95 Lastenheft 37 176 Linguistik 5 Toscana er BY 6 189 Logische Spezifikation 37 Logistik 107 Lookup Notation 49 M glich g ltig 71 Mehrwert
49. Gr nden bevorzugen wir die etwas rigidere Semantik der Workflow Maschine mit der Semantik der abstract state machine Sie hat zugleich auch den Vorteil eine Verfeinerung zuzulassen und auch Konflikte auf Datenebene durch Zur cknahme aufl sen zu k nnen 80 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 6 SICHTENSUITE 6 Sprachen zur Darstellung der Sichtensuite Zwei Seelen wohnen ach in meiner Brust Die eine will sich von der andern trennen Die eine halt mit derber Liebeslust Sich an die Welt mit klammernden Organen Die andre hebt gewaltsam sich von Dust Zu den Gefilden hoher Ahnen Goethe Faust Erster Teil Vor dem Thor Faust Die Sichtenspezifikation kann analog zur Spezifikation der Strukturierung vorgenommen werden Sie basiert au erdem auf den Informationen ber die Dialoge Wir unterscheiden drei Arten von Sichten Arbeitssichten mit denen eine Bearbeitung von Daten das Retrieval von Daten und die Ein und Ausgabe von Daten auf dem Datenbankschema aufsetzend erm glicht wird Sichten zur Interaktion von Systemen die zur Unterst tzung von verteilten f derierten oder interoperablen Systemen erstellt werden und Sicherungssichten mit denen die Zugriffs und Modifikationssicherung f r die Datenbank erfolgen kann Sicherungssichten werden w hrend der Spezifikation von Sicherheitsanforderungen eingef hrt und interessieren uns hier nicht vordergr ndig DBMS Interaktionssichten werden in der konzeptione
50. Handeln und wird durch die folgenden Aspekte beschrieben e Die Darstellung der Aufgaben geht von einer Zielstruktur aus Diese Zielstruktur kann im zu standsorientierten Zugang zur Modellierung durch Angabe des Zielzustandes erfa t werden 118 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 7 INTERAKTIVIT T 277 Verbote Aufgabe 7 Akteur G n m Benutzer ruppe Rolle rolle Bild 42 Das Sicherheitsprofil von Akteuren e Durch eine Wissensprofil werden die Details des Aufgabenwissens erfa t e Die Beschreibung der Arbeitsmittel basiert auf der Darstellung des Content und der erforderli chen Funktionalit t e Die Erf llung einer Aufgabe erfolgt in Arbeitsabl ufen die in einzelne Arbeitsvorg nge struktu riert sind e Es kann ein allgemeines Abarbeitungsmodell f r die Wege zum Zielzustand vorgegeben sein In stark strukturierten Arbeitsfeldern wird gerade auf die genaue und detaillierte Darstellung die ses Abarbeitungsmodelles viel Wert gelegt Eine Spezifikation der Arbeitsvorg nge umfa t folgende Bestandteile Die allgemeine Struktur wird beschrieben durch e einen Ausl ser e eine organisatorische Einheit e eine T tigkeit des Benutzers e verwendete Hilfsmittel und e eine Ablage und einen Adressaten Das Resultat der Ausf hrung f hrt zu einem e einem Ergebnis e das unter bestimmten Bedingungen akzeptiert wird Die
51. INFORMATIK I 15 2003 KAPITEL 5 FUNKTIONALITAT durch Flexion die Variantenvielfalt sowie die Ausnahmen auffaltbar sind Flexionsregeln erlauben eine Erweiterung mit dem Akteursprofil und portfolio mit dem Wiederholungsprofil mit dem Zeitprofil mit dem deontischen Modus und mit den Aktionsformen und der Handlungsrichtung Diese Erweiterung wurde bereits in einigen Arbeiten die Workflow Spezifikationen aus der Sicht der Praxis kritisierten gefordert Es wurde insbesondere beobachtet e da ein Arbeitsablauf hoch parallel ist e da ein Arbeitsablauf eine R ckkopplung mit Wartezeiten erfordert und e da die Organisation der Arbeit oft fremdgesteuert ist Wir verallgemeinern diese Formenlehre von Handlungsstr ngen und f hren dazu allgemeine Workflow Felder ein Das Er ffnungsfeld ist gekennzeichnet durch e die Darstellung des Kontextes der bei Assoziation des Workflow Feldes mit anderen Fel dern den Kontext dieser Felder dominiert e die Darstellung der Akteure e die Darstellung der Situation und e die Assoziation mit Sichtentypen sowohl fiir die Input als auch die Retrieval als auch die Outputdaten Das Ausgangsfeld dient zur Meta Spezifikation und erlaubt au erdem noch eine Einbettung der r umlichen und zeitlichen Rahmenbedingungen sowie auch der Motivation und der Ursachen Das Handlungsschrittfeld wird spezifiziert durch e die Angabe der Verbindungsparameter e die Angabe der Begleitelemente und Kontextbedingun
52. Klassen in denen Workflows als Einzelelemente enthalten sind einem Workflow als Objekt einer Workflow Klasse und Workflow Feldern mit denen ein Rahmen der Workflow Klasse angegeben werden kann Ein Typ einer Workflow Klasse kann aus einer oder mehreren Stammformen bestehen Ein Workflow Feld besteht aus einer Menge von Stammformen einer Menge von dynamischen Integrit tsbedingungen denen die Workflows eines Feldes gen gen m ssen einer Menge von Bildungsformen zur Assoziation mit anderen Workflow Feldern und einer Menge von Flexionen zur Ableitung von Workflows aus dem Workflow Feld Wir nehmen oft vereinfachend an da ein Workflow Feld nur eine einzige Stammform besitzt und da eine Workflow Klasse nur Workflows eines Workflow Feldes enth lt Sie mu nicht alle m glichen Workflows dieses Feldes enthalten sondern kann auch nur einige aktuelle Workflows enthalten Diese Unterscheidung wurde in unserer Arbeit erstmals f r eine e Learning Site konzipiert Diese Site erlaubt eine Entfaltung einer Lerneinheit je nach Meta Information Handlungs Akteurs und Datenkontexten sowie der Handlungsvorgeschichte Damit kann ein Lernfeld als allgemeine Lernein heit angesehen werden bei der die Stammform als Ausdruck ber Lernelementen gegeben ist die durch Ableitungsregeln zu einem komplexen Lernmodul erweitert wird so dass ein Lernender auch 6 2 so SOROS CNRS RE s 0020 ar a al 21 1 06 As 76 B THALHEIM PREPRINT BTU
53. LM73 Mac90 In T2091 A K Elmagarmid editor Database transaction models for advanced applications Morgan Kauf mann San Mateo 1992 D W Embley Object database development Concepts and principles Addison Wesley Reading Mass 1998 R Elmasri and S Navathe Fundamentals of database systems Addison Wesley Reading 2000 T Fernandes Global interface design Addison Wesley Boston 1995 S Fowler and V Stanwick The GUI style guide Academic Press Amsterdam 1995 C C Fleming and B von Halle Handbook of relational database design Addison Wesley Reading MA 1989 M L Gillenson Database step by step John Wiley amp Sons New York second edition 1990 P Gloor Elements of hypermedia design Techniques for navigation amp visualization in cyberspace Birkhauser Boston 1996 GMUW00 H Garcia Molina J D Ullman and J Widom Database systems implementation Prentice Hall 2000 J Gray and A Reuter Transaction processing Concepts and techniques Morgan Kaufmann San Mateo 1994 Y Gurevich Sequnetial abstract state machines capture sequential algorithms ACM TOCL 1 1 77 111 2000 T A Halpin Conceptual schema and relational database design Prentice Hall Sydney 1995 R Hausser Foundations of computational linguistics Springer Berlin 2000 in German I T Hawryszkiewycz The art of database design MacMillan 1990 I Horrocks Constructing the user interface with statec
54. Modellierung keine Rolle mehr nachdem die Urteile zur Modellierung gef llt wurden Ebenso wie in der Modellierung spielen pragmatische Annahmen eine Rolle So werden z B die aktuelle Kommunikationssituation mit der vierstelligen Beziehung zwischen Sender insbesondere sei nem Verst ndnis dem Inhalt der Beziehung zwischen Sender und Empf nger einer Nachricht und dem Empf nger insbesondere seinem Verst ndnis mit betrachtet Ein Analogon der Kommunikati onssituation ist die Anwendungssituation Daraus k nnen wir eine semiotische Triade zu einem Informationssystem ableiten Der Content bestimmt den syntaktischen Aspekt Der semantische Aspekt wird durch die Konzeptwelt dargestellt Der pragmatische Aspekt wird ggf durch eine Anwendungssituation determiniert und durch eine Begriffslandkarte repr sentiert In Bild 6 stellen wir die Verbindung zwischen den einzelnen Aspekten Repr sentationswelten Datenwelten Erweiterte Sichten Content Content Syntax Syntax Allgemei rst ndnis Erzeugbarkeit Dars keit Verwaltbarkeit Semantik Pragmatik Semantik Pragmatik Konzepte Begriffe Konzepte Beste Theorienwelten Benutzeryelten Konzeptionelle Begriffslandkarte Modellierungswelten je nach ruppen Theorien common sense Bild 6 Semiotik Darstellung von Content Konzepten und Begriffen kurz dar Damit sind auch die theoretischen Grundlagen von CMS gegeben wie in der folgenden Tabelle Content Konzepte Begriffe Th
55. Nachbedingung Ein Paar von Formeln a und 6 hei t Vor und Nachbedingungen falls aus R lp i ZRpunkt Oa die G ltigkeit von RC p i 1 ZRpunkt O8 folgt Wir notieren allgemeine Vor und Nachbedingungen auch durch a en Wird der Zeitrahmen durch die Anwendung eines Prozesses P oder Programmes P definiert 5 P dann schreiben wir a 8 Temporale Formeln sind mit R 14 i ZRvon B bzw RC Ir i ZRvon 08 im Sinne der Modallogik notwendig oder m glich g ltig In analoger Form k nnen damit auch allgemeine G ltigkeiten temporaler Formeln eingef hrt werden immer in der Zukunft Vp immer in der Vergangenheit einmal in der Zukunft p einmal in der Vergangenheit a ist g ltig bis 9 g ltig wird Weiche deontische Integrit tsbedingungen werden fiir Z Rgchrit eingef hrt Obligation Eine Obligation Oa ist durch die Giiltigkeit von ies lr 1 ZRschritt Oa definiert Erlaubnis Eine Erlaubnis Pa ist durch die Giiltigkeit von Re lr 1 ZRgchritt F Oa definiert Verbot Ein Verbot Fa ist durch die G ltigkeit von RE lr 1 ZRschritt Oa definiert Wir k nnen daraus direkt einige Ableitungsregeln ableiten KDO Jede Formel der HERM Logik ist eine deontische Formel KD1 O a 8 Oa KD2 Oa Pa Obligationen umfassen Erlaubnisse KD3 Pa 7 O7a
56. Pa Ver Ar Part Dis Part Gruppe Dien Port Organi rung ralle trag beits ner kurs ner ste folio sation lit t proze typ Die Koordination ist der dritte Bestandteil der Kollaboration Es gibt relativ wenig Literaturquellen zur Darstellung der Koordination Im Rahmen unserer Sprache zur Spezifikation der Verteilung Dist Lang streben wir eine umfassende Spezifikation der Kollaboration an so da wir auf eine Spezifikation der Koordination nicht verzichten wollen Es werden nicht nur die Zeit und Vertragsbeschr nkungen abgebildet sondern vor allem die Art des Zusammenwirkens spezifiziert Eine Spezifikation der Koordination umfa daher die folgenden Elemente Durch die Koordinationsform werden die Form der Koordination die Rollen in der Koordination die Vor und Nachbedingungen f r die Formierung die Abstimmung bzw Synchronisation der Partner und das Fehlermodell zusammengefa t Die Aufgabenverwaltung basiert auf einer Spezifikation der Aufgaben der Zuordnung der Aufgaben zu den Partnern und dem Verlauf der Koordination Der Koordinator stellt die einzelnen Partner die Rolle der Partner in einer Gruppe die verwendete Infrastruktur Dienste die Aufgaben und die Abbildung der verwendeten Namen in einer integrierten Form zusammen Als Beispiel kann das koordinierte Zusammenwirken beim Erstellen eines Vorschlages f r eine Lehr veranstaltung betrachtet werde
57. Provider Customer Relationship Manage ment E Commerce L sungen E Marketing Online Payment e Dokument Verwaltung Archivierung und Suche Unterst tzung von Dokumenten Arbeitsabl ufen e Intelligente benutzerspezifische Erzeugung von Inhalten e ASP L sungen Media Asset Management e Group Ware L sungen Intranet L sungen e Redaktionssystem Ausspielsystem Erneuerungssystem e Skalierbare L sung Agententechnologien Performance Monitoring Sicherheitstechnologien Hoch verf gbarkeit e Open Source L sungen Community L sungen Diese Liste ist zu umfangreich Au erdem wird damit der Begriff Content vollst ndig tiberladen Stattdessen bevorzugen wir eine Separation von Gesichtspunkten Begriffsbildungen und Aspekten so wie sich dies in der Semiotik der Linguistik und der Mathematischen Logik eingeb rgert hat Wir unterscheiden deshalb zwischen Content als Extension eines Referenzobjektes Intension als eine Menge oder i a Kollektion von Daten Nachrichten oder Informationen Konzept als Plan als Zusammenfassung eines Vorhabens oder Begriffes in konsistenter berschau barer und nachvollziehbarer Form mit dem die Gesamtheit der Merkmale zusammengefa t wird und Begriff als Intension oder als Versuch des Zeichenbenutzers Erscheinungen zu erfassen in einer ko gnitiven Einheit zusammenzufassen und in einen Zusammenhang zu bringen der eine Abstrak tion enth lt die das Wesentliche f r den Interpreten
58. Redundanz e Dezentralisierte Datenbanksysteme zur Reduktion des Kommunikationsaufkommens und der Abh ngigkeit vom Netz Mehrrechnerdatenbanksysteme sind eine typische Realisierungsform von homogenen integrierten Datenbanksystemen Im Wesentlichen sind drei Realisierungsvarianten entwickelt worden e In der Shared Everything Architektur sind sowohl Systempuffer als auch Sperrtabelle global e In der Shared Disk Architektur wird wie in der vorhergehenden Variante die Platten Peripherie ber eine Variante von Bussystemen gemeinsam genutzt Die einzelnen Anfragen werden lokal durch eigene Rechner mit eigenem Hauptspeicher verarbeitet In der Shared Nothing Architektur wird ein vollst ndig verteiltes System aufgebaut dessen ein zelne Systeme durch schnelle Kommunikationverbindungen miteinander verbunden sind F derative Datenbanken folgen dem Besitzer Benutzer Prinzip wobei zus tzlich noch einem Be nutzer Leserechte durch den Besitzer verweigert werden k nnen Sie wirken aufgrund einer Spezifika tion der Kooperation zusammen Bei Kopplungen mu auch die lokale Effizienz gewahrt bleiben Wir unterscheiden dabei e singul re F derationen bei denen die lokalen DBMS heterogen sein k nnen die jedoch auf einem globalen Schema basieren und dieses f r die Berechnungen benutzen und e multiple F derationen bei denen die einzelnen Systeme auch eigene anderen nicht zug nglich gemachte Daten besitzen die nicht mehr auf einem global
59. System und einem Markierungssystem L f r Attributnamen induktiv ausschlie lich durch die folgenden beiden Regeln definiert e Ein Attribut Typ ist f r eine Markierung A und einen Basis Datentyp durch einen Ausdruck A T gegeben Der Wertebereich dom A des Attribut Typs ist der Wer tebereich des Basis Datentyps Der Wertebereich des leeren Datentyps A besteht aus 4 Sind X1 Xn Y Attribut Typen und A B C D Markierungen dann sind A X1 Xn Tupel oder Produkt Konstruktor A Y Mengen Konstruktor A lt Y gt Listen konstruktur A Y Konstruktor f r optionale Elemente Af Y Konstruktor f r Multimengen Die entsprechenden Wertebereiche sind durch Anwendung der Konstruktion gegeben 2 B dom A X1 Xn dom X1 x x dom Xn und dom A Y dm N Markierungen k nnen auch weggelassen werden Beispiele von komplexeren Attributen sind Name Vornamen lt Vorname varstring15 Benutzung stringl gt Familienname varstring30 Geburtsname varstring30 Titel AkademischeTitel varstring10 U FamilienTitel varstring10 Kontakt Tel dienstl varnumbersequence20 privat varnumbersequence20 email emailType Geburtsdatum date Attribute k nnen in einer verk rzten Notation verwendet werden wenn dies eindeutig im Sche ma bleibt Das Attribut Kontakt ist z B dann auch ohne seine Bestandteile verwendbar Attribute sind hierarchisch strukturiert wie im Falle
60. Teilen diskutiert unterscheiden wir zwischen dem Diskurs den Handlungsrahmen dem Storyboard dem Drehbuch und der Inszenierung der Dialoge In unter schiedlichen Entwurfsetappen werden die Dialoge im Abstraktionsschichtenmodell spezifiziert Infor mationssysteme sind meist auf unterschiedliche Benutzergruppen ausgerichtet die unterschiedliche Anforderungen an die Benutzung an das intuitive Verst ndnis der einzelnen Schritte an die Funk tionalit t und die Gestaltung der Oberfl chen haben Da eine zusammenh ngende Darstellung nach unserer Kenntnis nicht existiert stellen wir unsere Methodik ausf hrlicher vor Das Finden der Motive und Ideen und die Darstellung des Diskurses kann auf den Informationen die wir bereits in der Anwendungsanalyse erhalten haben aufsetzen Wir entwickeln erste gro be und bruchst ckhafte Ideen Sp ter k nnen wir aus diesen Ideen eine Auswahl treffen In dieser Etappe ist eher eine Methode wie das mind mapping angebracht Damit ist ein Ent werfer voll gefordert Oft ist nicht die objektivste Auswahl von Ideen die beste sondern eine subjektive Auswahl Dabei zeigt sich da das Ideenmaterial eigene Prinzipien hat und auch widerspr chlich sein kann Es wird in diesem Schritt das Anwendungsgebiet mit den einzelnen Anwendungsschritten skizziert Das Ergebnis ist die Darstellung des Diskurses im Lastenheft Die Entwicklung des Handlungsrahmens kann nun zu einer groben Darstellung der Aktionen der Ak teure f hre
61. U Die Semantik einer Transitionsregel wird durch einen Kalk l mit Regeln der Form Voraussetzung Voraussetzung Bedi Folgerung mn definiert Wir verzichten hier auf die vollst ndige Angabe der Semantik und verweisen auf die Literatur Als Beispiel f hren wir die folgenden Regeln an ohne auf den Beweis dieser Regeln einzugehen yields P R U yields Q R V 2 UUV konsistent yields DO P PAR ER UUV Die Konsistenzbedingung kann weggelassen werden wenn man die Theorie der partiell geordneten Durchl ufe f r ASM anwendet Wir wollen jedoch hier nicht im Detail auf die Theorie eingehen yields P ERS x a U a wobei a EE yields LET t IN P DOP ER U Ya I yields P R lz al Ua yields FOR ALL WITH DOP ER User Ua wobei I range r 6 R Der Wertebereich range x 6 R ist definiert durch die Menge o ER HER true zma yields P ER C x a U yields CHOOSE x WITH DO P ER U wobei a range z 6 R 6 falls range x o ER 0 yields CHOOSE x WITH DO P ERO 0 yields P R U yields Q ER U V yields DO P Q ERF 6 U YV yields R U yields DO P Q ER U falls U konsistent ist falls U inkonsistent ist yields SKIP ER C bei l 282 sn d v ter yields f s1
62. bzw I I2 W und i Wir bezeichnen die zeitweilige volle G ltigkeit mit RC Ir I 1 ZR Oa Wir k nnen damit die G ltigkeit zwischen Phasen definieren Die Formel a ist g ltig in RC Ip und ZR falls R lp i a f r jeden Zeitpunkt i jedes Intervalls 7 des Zeitrahmens bezeichnet mit R la ZR o In diesem Fall ist a eine statische Integrit tsbedingung falls yes 1 minT S maxT S Die Formel a ist m glich g ltig in R lp und ZR falls f r ein i yers 1 R amp I i H a bezeichnet mit R lp ZR a Besitzt ein Zeitrahmen ZR Unterbrechungen dann wird f r die Formel a keine Forderung erhoben Ein Zeitrahmen wird f r die Implementationsschicht direkt durch Phasen repr sentiert Damit kann die G ltigkeit von Formeln und die Zul ssigkeit von Prozessen zu gewissen Zeitpunkten direkt modelliert werden Wir k nnen damit auch unterschiedliche Klassen von dynamischen Integrit tsbedingungen einf hren Daf r werden der Zeitrahmen Zsenis 1000 li m tli i i 1 2 N und TT Pes F D of r x 85 r T TAN Sm SOREN URN s 72 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 5 FUNKTIONALIT T Transitionsbedingung Eine Formel o hei t Transitionsbedingung falls notwendig g ltig in allen Intervalle von Z Rschritt ist ae 4 next Wir notieren Transitionsbedingungen auch durch a a Allgemeine Vor und
63. dardisierten Werkzeugen Obwohl die Maus in vielen Anwendungen zum normalen Arbeitsinstrument geworden ist sollte stets auch die Tastatur unterst tzt werden Sie ist meist schneller und bei sinn voller Anordnung der einzelnen Arbeitsschritte kann sogar der Tabulator f r das Beenden eines Teil schrittes und den Beginn des n chsten Teilschrittes benutzt werden Sind unterschiedliche Gruppen von Benutzern zu ber cksichtigen dann sollte auch ein unterschiedliches Bedienniveau implementiert werden Die Bediensprache ist dem Benutzer und seinem Anwendungsgebiet mit anzupassen Jede Art von Benutzung f hrt zu einem Feedback durch das System Damit wird einem Benutzer der n chste Schritt erleichtert Weiterhin determinieren die F higkeiten der Benutzer und ihren Bed rfnissen ob ein black box Zugang der dem Benutzer Details der Implementation vollst ndig vorenth lt ein glass box Zugang der dem Benutzer auch gestattet die Arbeitsweise des Systems insbesondere das input output Verhalten zu verstehen und sein Verhalten dementsprechend zu ver ndern oder ein Mix dieser beiden Zug nge anzustreben ist Da eine Vielzahl von Oberfl chen in einer Anwendung zu entwickeln sind ist auch bei der Ge staltung die Wirtschaftlichkeit zu beachten Die Oberfl chen sollten generisch bzw parametrisch sein oder zumindest einem Standard folgen der mit der Anwendung korreliert Die Wiederverwendung von existierenden Oberfl chen erleichtert ebenso wie die Sta
64. der auch das System ohne Benutzerinteraktion seinen Zustand ndert wobei diese nderung ggf auch f r einen Benutzer nicht mehr verstehbar oder nachvollziehbar ist Das Verhalten wird noch weniger einsichtig wenn das System seinen Zustand aufgrund einer Interaktion mehrerer Benutzer ndert In letzteren Fall kann dadurch das Verhalten eines Systemes f r den Einzelbenutzer zuf llig oder chaotisch aussehen obwohl das System selbst deterministisch ist Wir unterscheiden deshalb in Bild 44 zwischen dem Systemraum der das Systemverhalten widerspiegelt und f r den wir das erweiterte ER Modell zur Spezifikation verwenden und dem Interaktionsraum der den Content des Benutzers enth lt auf einer Begriffs Konzept oder Content Algebra aufsetzt aber einer anderen Logik unterliegt Systemraum H ERM Strukturierung H ERM Funktionalitat H ERM Logik Berechenbare Funktion Systemraum ia Interaktionsraum Zeit Rat m beschr nkt Content Content Algebra Deontischer Situationskalk l Interaktions raum Bild 44 Der Interaktionsraum verglichen mit dem Systemraum Der Interaktionsraum setzt in unserem Verst ndnis auf dem Systemraum auf erweitert diesen jedoch um Benutzeraspekte Wir fassen diesen Spezifikationsansatz in der Sprache SiteLang zur Entwicklung von Storyboards zusammen Wir f hren dazu weitere Begriffe ein Der Story Raum widerspiegelt die Menge aller Stories Der Story Rau
65. der entwickelten Datentypen Kontrolle des Story Raumes anhand der Szenario Ableitung weiterer m glicher Szenario Blockie rung unerw nschter Szenario Ableitung der Verlinkungs und Navigationsstruktur Kontrolle der unterst tzten Funktionalit t Spezifikation der Funktionalit t Kontrolle des Verhaltens der Anwendung Abstimmung der Unterst tzung f r Dienste Austauschrahmen Kollaboration Integration der Sichten Suite anhand der Architektur des Systemes Aufl sung der Entwurfsob ligationen Implementationsschicht Transformation der konzeptionellen Modelle in logische Modelle zur Darstellung der Struktu rierung Funktionalit t Interaktivit t und Verteilung Restrukturierung und Optimierung auf der Grundlage von Performanzbetrachtungen und des Tuning Ableitung des Dienstverwaltungssystemes der Protokolle und der Funktionen zur Unterst tzung der Verteilung Transformation der logischen Modelle in physische Modelle des DBMS Kontrolle der Dauerhaftigkeit und der Skalierbarkeit der L sung Entwicklung von Erweiterungs und Migrationstrategien unter Ber cksichtigung m glicher Technologieentwicklungen und Ver nde rungen in der Anwendung 42 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 4 STRUKTURIERUNG 4 Sprachen zur Darstellung der Strukturierung Was du ererbt von deinen Vatern hast Erwirb es um es zu besitzen Was man nicht niitzt ist eine schwere Last Nur was der Augenblick erschafft das kann man
66. der statischen und dynamischen Integrit tsbedingungen gepr ft wer den mu oder beim Zur ckfahren zum inaktiven Zustand falls die Pr fung der Konsistenz eine Inkonsistenz ergeben hat oder beim Abschlu wobei dann alle Ressourcen wieder freigegeben INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 65 lnaktiv Zur ckgewiesen BOT A IC falseh EOT Aktiv oe Beendigung 4 wahr Bereit zum Abschlu Bild 29 Die Zust nde einer Transaktion Zur Implementation von Transaktionssystemen steht eine Reihe von Update Optionen wie Update in place auf der Platte Update in private mit einem Transaktionspuffer oder Update im Schattenspeicher zur Verf gung Das klassische Transaktionsmodell definiert Transaktionen ber das ACID Konzept Transak tionen sind atomar werden ganz oder gar nicht wirksam konsistenzerhaltend werden isoliert ausgef hrt und f hren zu dauerhaften Ver nderungen Diese Auffassung postuliert die Existenz einer implementierenden Maschine Auf der konzeptionellen Schicht k nnen wir sie deshalb nicht verwenden Die beiden ersten Bedingungen sind in unsere Definition eingeflossen Die letzte Bedingung ist eine Forderung an Informationssysteme im allgemeinen Die Isoliertheit wird gew hnlich ber die Serialisierbarkeit definiert Da dies jedoch auch ein Implementations konzept ist verwenden wir einen anderen Zugang Die Read Write Mengen read wr
67. des konzeptionellen Entwurfes vollst ndig in das konzeptionelle ER Schema und das Drehbuch eingebettet sein Zus tzlich zu den entwickelten Sichten werden die Sicherungssichten und die DBMS Interakti onssichten entwickelt Logische Sichten Suite Die Sichten Suite wird je nach gew hlten Transformationsmodus f r die Ab bildung des ER Schemas auf das logische Schema im Anschlu an die Transformation des ER Schemas auf Sichtenkonzepte des DBMS bzw der Plattform abgebildet Dazu werden entspre chende Operationen Programme oder Module der Datenbank Maschine verwendet Die Sichtenkonzepte werden je nach Funktionalit t des DBMS als externe Sichten oder materia lisierte Sichten in die Beschreibung der Struktur der Datenbank eingebettet Aus den konzeptio nellen Sichten kann durch Transformation die jeweilige logische bzw bei einer Materialisierung die physische Sicht erzeugt werden Relationale DBMS unterst tzen oft nur typ basierte Sichten In diesem Fall wird f r jeden Typ einer Sicht eine Sichtentypanfrage angegeben Der Zusammenhang der Sichten wird mit einer integrierten Sichtenanfragemenge in der logischen Sichten Suite gew hrleistet Werden semi strukturierte Datenbank Maschinen verwendet dann kann auch eine Sicht z B durch eine DTD angegeben werden Der Zusammenhang innerhalb einer Sicht wird dann durch XML Dokumente direkt dargestellt Unterschiedliche Sichtweisen auf ein XML Dokument k nnen durch entsprechende XSL Regeln un
68. drei Teilspezifikationen angegeben Der Diskurs bestimmt den Ablauf der Kollaboration Er basiert auf den anderen drei Bestand teilen des Co Design Ansatzes Die Daten werden zu Content verdichtet und durch Sichten ber dem Datenbanksystem angegeben Die Funktionalit t wird durch Angabe der unterst tzenden Systemfunktionen dargestellt Die Interaktivit t basiert auf dem Storyboard der Anwendung Der Stil der Kollaboration legt die vertraglichen Vereinbarungen fest Er wird durch e die Unterst tzungsprogramme wie Sitzungsverwaltung Benutzerverwaltung und der Abrechnung e den Datenzugriffsrahmen mit den Varianten zwischen broadcast und peer to peer dem gemeinsamen Benutzen von Ressourcen und den Zugriffsformen und e die Art wie peer to peer oder der Ereignis oder der Komponentenkollaboration sowie e den Koordinations Workflow mit den Partnerbeziehungen dem Diskurstyp dem Na mensraum und den Workflow Regeln determiniert Die Kollaborationsarchitektur bzw das Kollaborationsmuster verbinden die Komponenten Das Kollaborationsmuster ist eine Verallgemeinerung der Protokolle mit einer Darstellung der Partner ihrer Aufgaben ihrer Rollen und Rechte Wir unterschieden zwischen e Proxy Kollaboration e Broker bzw Trader Customer Kollaboration Client Dispatcher Kollaboration e Publisher Subscriber Kollaboration und e Model View Controller Kollaboration Die Architektur kann als Verallgemeinerung der Architektur verteilter Date
69. durch 1 F r den Benutzer Nat rlichkeit impliziert ein einfaches Verstehen und einfaches Formulieren von Anfragen Des halb ist f r die Akquisition die Darstellung semantischer Einheiten von zentralem In teresse Schemata werden leicht lesbar und selbsterkl rend wobei enkryptische Namen vermieden werden und die Bedeutung einfach erhalten werden kann Dadurch werden In tegrit tsbedingungen in verst ndlicher Form formulierbar und k nstliche abstrakte Typen vermieden Minimalit t impliziert ein eindeutiges Verstehen der Komponenten des Schemas Unterschiedli che Gesichtspunkte werden vermieden Ein Schema ist konzeptionell minimal wenn nicht alle m glichen Teilf lle sondern nur die relevanten dargestellt werden Sichtendarstellung f r einzelne Benutzergruppen unterst tzt die Verst ndlichkeit und die Be nutzbarkeit des Schemas Systemunabh ngigkeit und das Ausschlie en unnat rlicher Systembeschr nkungen erm glichen eine Konzentration auf die inhaltlichen Konzepte der Anwendung Verst ndliche Darstellung komplexer Zusammenh nge vereinfacht das Erfassen und Verstehen kom plexer Integrit tsbedingungen und eine hohe Anzahl von Integrit tsbedingungen Ein Verst ndnis der Speicherung gibt dem Benutzer einen intuitiven berblick ber die Imple mentation der Datenbank 2 F r die Unterst tzung durch das System Wenig oder keine Redundanz verringert den Pflegeaufwand der durch das System zu leisten ist Damit werd
70. durch den Zusammenhang der Arbeitsvorg nge und der Vorgehensweise zur Aufgabenerf llung Die Wahrnehmungen des Benutzers unterst tzen die schnellere Erfassung der anstehenden Aufgaben Die k rperliche Aktivit t unterst tzt die Erf llung der Aufgaben Die Strukturierbarkeit des Arbeitsbereiches erlaubt eine Anpassung an die Arbeitsweise und Arbeits methodik des Benutzers Zur Spezifikation der Arbeitsgestaltungsdimension verwenden wir ein Gestaltungspolarit tenprofil mit entsprechenden antonymen Charakterisierungen wie z B f r den Arbeitsvorgang zum Erstellen der Lo ee eee a 2 se S o AT en SE ne De ee a Vereen Tener NN E 120 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 7 INTERAKTIVIT T Spielraum Kollaborationi Belastung Zeitrahmen Variabilit t Wahrnehmung Aktivit t Strukturier barkeit voll Abstimmung nebenl ufi Ablieferungs hoch mit wohl Direkt Aufgabenblatt kommen im Lehr ge T tig zeitpunkt Sitzung strukturiert eingabe mit Ord eigen stuhl keit volle Un ohne Maus bernahme nung nach st ndig terst tzung vorhande Erf llungs ner Daten stand Durch Interaktionsdiagramme werden die Story die Szenario und das Drehbuch unterlegt Inter aktionsdiagramme sind gerichtete Graphen deren Knoten Zust nde des Systemes und deren Kanten Transitionen darstellen die durch einen Akteur ausgel st werden k nnen Es kann ein Akteur in s
71. ein Analogon zu generischen Operationen wie insert delete und update dar bei denen eine Instantiierung durch Angabe der Strukturen der Typen er folgt f r deren Klassen sie angewandt werden Ebenso wie generische Operationen k nnen generische Workflows durch Instantiierung in konkrete Workflows berf hrt werden Die Parameter k nnen auch abh ngig voneinander sein Wir unterscheiden hierbei die folgenden speziellen Typen Entfaltbare Workflows sind generische Workflows mit einem generischem Laufzeit Workflow bei denen die instantiierbaren Parameter keine Nebenbedingungen auf andere Parameter besitzen Sie k nnen zur Laufzeit voll entfaltet werden Typische entfaltbare Workflows sind Workflows f r Gruppenarbeitspl tze die jedem Mitglied die gleiche Arbeitsplattform bieten Parallelisierte Workflows sind generische Workflows bei denen ein Zwischenstand und To Do Listen mitgef hrt werden und zur Laufzeit mit entsprechenden Werten belegt werden k nnen die zu anderen Workflows Beziehungen besitzen z B durch Ressourcen Sharing und gemeinsam mit diesen ausgef hrt werden k nnen Multiple choice Workflows sind generische Workflows die Varianten f r Rollen f r die freie Auswahl von Daten und die B ndelung mit anderen Workflows bereitstellen Transaktions basierte Meta Workflows sind generische Workflows deren Ausf hrungsmodell eine Ressourcen und Rollenverwaltung einschlie t die auch ber R cknahme oder Kompensationsteilfelder
72. einem Rahmen Wir k nnen diesen Rahmen als Start f r die Spezifikation eines Gestaltungsrahmens oder zumindest eines Gestaltungsrasters f r die Gestaltung der Oberfl chen benutzen Es stehen neben Rahmen f r Fenstersysteme auch Rahmen f r beliebig formatierbare Dokumente zur Verf gung Ein solcher Rahmen wird in Analogie zu den blichen Beziehungen Anwendungsgebiet Element allgemeine Struktur Datenbanksysteme Tupel Relationen Typ XML Technologie XML Dokument XSchema Suite oder DTD Suite Benutzer Schnittstellen Technologie Fenster Stil Regeln XML Generatoren XSL Regel 77 Kommunikationssysteme 77 77 entvvickelt Diese Rahmen sind etwas komplexer als die Stil Regeln f r Benutzer Schnittstellen weil wir auch die Anwendergruppe deren Profile und deren Portfolio mit ber cksichtigen wollen Zur Gestaltung entwickeln wir Gestaltungsrahmen die die Art der Gestaltung die allgemeinen Prin zipien und den Umgang mit multimedialen Elementen darstellen Mit dem Gestaltungsrahmen wird vorgegeben wie die Oberfl chen gestaltet werden Au erdem sollen die Arbeitsoberfl chen das Arbeiten mit dem System vereinfachen Dazu er scheint es g nstig auch die Art des Zusammenwirkens die Beziehungen der unterschiedlichen Akteure und die Darstellung des Zusammenwirkens durch den Arbeitsplatz zu kanonisieren Daf r werden entsprechende Kommunikationsrahmen entwickelt Die Art der Kollaboration bzw Kooperation die Art des Zusammenw
73. erhoben validiert und in die Daten bank eingebracht Eine typische Zeitdimension ist Tag Woche Jahr die mit der Dimension Tag Monat Quartal Jahr verkn pft sein kann Anwendungskategorie bzw dimension Anwendungsobjekte k nnen unter unterschiedlichen Gesichts punkten gruppiert werden z B ein Produkt nach Produktgruppen und diese nach Branchen Diese Dimensionierung sowie Mi verst ndnisse bei der Anwendung des Sichtenkonzeptes haben zu eigenst ndigen Entwicklungen mehrdimensionaler Datenbanken gef hrt Relationale Tabellen mit N Attributen k nnen auch als N dimensionale Gebilde verstanden werden Verkn pfen relationale Tabellen M verschiedene Objekte anderer Tabellen miteinander und ordnen diesen Assoziationen Werte zu dann kann man diese Tabellen durch Relationship Typen mit M Komponenten verstehen Die Tabelle Verkauf KundenNr FName ProduktNr Datum Menge Umsatz kann zu einer 3 dimensionalen Assoziation Region Branche Zeit aggregiert werden die die Anzahl der Verk ufe nach Regionen Branchen und Zeitpunkten wie in ACER I PIE LT RT En TPFt RE Sn NE En INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 175 KUNDE KundenNr KundenName Geschlecht Alter PRODUKT ProduktNr PName PGruppe Branche Hersteller Farbe Preis ZEIT Datum Tag Monat Quartal Jahr FILIALE FName Ort Land Region und besitzt au erdem die Attribute Anzahl Umsatz
74. erscheint fast unm glich Um eine weitergehende Lekt re zu erleichtern verwenden wir deshalb die folgende Klassifikation Hauptliteratur zum Co Design ist das Buch Tha00 Literatur zur Strukturierung von Informationssystemen Die Literatur zur Spezifikation der Strukturierung von Informationssystemen ist in Tha00 ausf hrlich zusammengetragen und erl utert Als weiterf hrende Literaturquellen empfehlen wir BCN92 Bis95 Dre95 00 Emb98 Gil90 Hal95 Haw90 Mac90 RS97 RG94 Ris88 Sim94 Bek92 89 FvH89 Literatur zur Funktionalit t von Informationssystemen Es gibt relativ wenige B cher au Ber Tha00 die die Funktionalit t von Informationssystemen berhaupt betrachten Als wei terf hrende Literatur zu den Zug ngen dieses Skripts k nnen jedoch die folgenden Quellen genannt werden Alt96 BDKO1 Bes95 BP98 Elm92 Emb98 GR94 Mok96 Literatur zur Verteilung von Informationssystemen Zur Verteilungsspezifikation im Rahmen der oberen Spezifikationsschichten existiert keine Literatur Erg nzende Literaturquellen sind dazu BS97 BL93 BHG87 Bra94 Bro00 84 Rah94 Dad96 Literatur zur Interaktivit t von Informationssystemen Dazu existieren kaum Literaturquel len Die Literatur konzentriert sich auf die Gestaltung von Graphik Gute Quellen in der letzten Kategorie sind ABH97 Hau00 MS95 Hor99 Pae00 Ebe94 Fer95 FS95 G1096 Literatur zur Theorie des integrierten Designs ist z B AHV95 Ago86
75. f hrte Es wird neben der Dokumentation der Entwicklung auch eine Erfassung der verbliebenen und z T neu entstehenden Arbeitsaufgaben vorgenommen Dazu geh ren insbesondere auch Listen von Obligationen die beim Entstehen weiterer Obligationen erweitert werden und die beim Erf llen von Obligationen verk rzt werden INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 181 Weiterf hrende Literatur Eine Literaturliste zum Co Design von Strukturierung Funktionalit t Verteilung und Interaktivit t w rde sehr lang sein Die Entwicklung von Informationssystemen mit einer integrierten Spezifikation von Strukturierung und Funktionalit t wurde bei einer ganzen Reihe von Zug ngen der Objekt orientierung versucht Leider Web95 wurde aber die Objekt Orientierung zu stark mit Konzepten berladen ohne auf deren Integrierbarkeit zu achten Au erdem wurde mit der Orientierung auf die Einzelobjektspezifikation den Belangen der Massendatenverarbeitung zuwider gehandelt Deshalb fristen objekt orientierte Datenbanksysteme z Z ein Nischendasein Eine Abkehr von der klassischen Objekt Orientierung wurde durch die Entwicklung objekt relationaler Systeme vorgenommen Eine gute Literaturquelle f r objekt relationale Systemspezifikation kennen wir bislang nicht Die klassische Datenbankliteratur ist riesig und fast un bersehbar Jedes Jahr erscheinen selbst im deutschsprachigen Raum Dutzende neue B cher Eine Klassifikation oder gar eine bersicht
76. f r den Benutzer f r eine Gruppe und f r einen Kontext Die Pragmatik wird durch eine Reihe von pragmatischen Axiomen gepr gt e Man kann nicht nicht kommunizieren Jedes Verschweigen ist auch eine Darstellung Im allgemeinen akzeptieren wir f r die Modellierung eine closed world Annahme bei der die Nichtdarstellung von Dingen der Realit t auf der Irrelevanz f r die Anwendung beruhen e Jede Modellierung hat einen Inhalt und einen Beziehungsaspekt wobei der letztere den ersteren bestimmt Es wird implizit oder ggf explizit die Beziehung zwischen Benutzer und System dargestellt e Die Spezifikation wird durch die Interpunktion der Darstellung mitbestimmt Interpunkti on tritt beim Austausch von Mitteilungen auf bei der zwei Seiten eine unterschiedliche Dekomposition der Mitteilung in Bestandteile und die Bedeutungszuordnung f r diese Be standteile vornehmen Dadurch entstehen unterschiedliche Sichtweisen auf den gleichen Ausdruck und entsprechende Beziehungskonflikte e Kommunikation in den Anwendungen bedient sich digitaler Repr sentation Da aber die Beobachtungen oft analog m glich sind entsteht durch falsche Digitalisierung bzw Abta stung ggf ein falsches Bild wie z B in der Monatsabrechung bei Lagerhaltungsanwendun gen oder Monatsstatistiken Kommunikationsabl ufe sind entweder symmetrisch oder asymmetrisch je nachdem ob Facetten der Kollaboration auf Gleichheit oder Unterschiedlichkeit beruhen Die unter schie
77. hren zu Klassen vom gleichen Typ Mengen Operationen Es seien RC und R Klassen vom Typ R Dann k nnen wir folgende Operationen definieren Vereinigung R U R2 o o R Voe RC Durchschnitt R N R o o R AoE R Differenz R R o o R Ao g RO Auswahl von Objekten aus einer Klasse Gegeben sei ein Pr dikat a ber R Die Selektion a R wird induktiv eingef hrt durch strukturelle Rekursion mit Or Ur NR und Oo R sreep yu R bzw in der aufgel sten Form oa 0 Up R oo R 22 falls R Np R gilt Wir nutzen eine andere Einf hrung als die viel verwendete doppelte Induktion wegen der komplexeren Teilstrukturierung der Typen Die beiden Definitionen sind jedoch quivalent Abgeleitete Elementaroperationen sind die Modifikationsoperationen der Datenbanksysteme Einf gen von Elementen Die insert Operation Insert R o ist durch die Vereinigung Ufo von Mengen f r Klassen R und Objekte o vom gleichen Typ R beschreibbar Streichen von Elementen Die delete Operation Delete RY o ist durch die Differenz R N o von Mengen f r Klassen R und Objekte o vom gleichen R definierbar Analog kann man auch das Streichen von Mengen delete R RC einf hren Update von Elementen Die Modifikation Update R a 7 von Klassen R ist f r Pr di kate a und Ersetzungsfamilien y o R ist definiert durch die Menge yayu 2 o
78. initiiert werden kann einem Datenaustausch mit der ben tigte Daten f r die Ausf hrung bereitgestellt und wieder in das Informationssystem eingepflegt werden k nnen einer Aufgabenablaufsteuerung mit der sequentielle und nebenl ufige Abl ufe dargestellt werden einem Arbeitsbereich auf dem mehrere unterschiedliche Aufgaben abgelegt werden k nnen und einem Synchronisationsmodell zum Abgleich der Ausf hrung von Aufgaben die sich im Arbeitsbe reich befinden 5erg nzt werden Aus der Darstellung der Aufgaben k nnen wir den Informationsbedarf ableiten Der Informa tionsbedarf ist nach einer genauen Analyse des augenblicklichen Wissensstandes und der Ziele der Wissensvermittlung ableitbar und sogar in Gesch ftsprozesse abbildbar Die Qualit t der Aufberei tung von Informationen wird durch den augenblicklichen Informationsbedarf mit determiniert Das Portfolio wird mit den Arbeitsgestaltungsdimensionen f r die Gestaltung humaner Arbeit er weitert Der Entscheidungsspielraum kennzeichnet das Ausma in dem ein Benutzer seinen Arbeitsproze selbst gestalten kann Die arbeitsbezogene Kollaboration dient der Abstimmung von Teilen der Arbeitsaufgabe mit anderen Akteuren Einschr nkungen durch psychische Belastungen k nnen durch entsprechende Hilfsmittel minimiert wer den Der Zeitrahmen kennzeichnet die M glichkeit den Arbeitsablauf zeitlich selbst ndig durch den Ak teur zu gestalten Die Variabilit t ist bestimmt
79. k nnen dann liegt ein Konflikt vor Ein Beispiel daf r ist das exklusive Schreiben von Daten f r h chstens einen Benutzer Dazu ben tigen wir eine Konfliktl sungsstrategie je nach Intensit t der Absicht und unterscheiden Hindernisse von Komplikationen und diese von Gegenabsichten Unkritisch sind dagegen inaktive Zust nde die nach Erreichen eines Zieles erreicht wurden Hauptabsichten und Teilabsichten Gew hnlich ist ein Gesch ftsproze bzw ein Szenario keine Kette von Ereignissen Wir finden ein Netzwerk von Motiven Absichten und Zielen vor Die Absichten k nnen in Teilabsichten die den Hauptabsichten dienen und Haupt absichten kategorisiert werden Damit ergibt sich auch eine zeitliche Ordnung und eine Variation in der Reihenfolge Dabei k nnen die Absichten gemeinsam dargestellt werden die sich einem gemeinsamen Zweck unterwerfen Gesetz von der Einheit des Zwecks Teilabsichten sind nderungen unterworfen Hauptabsichten dagegen nicht Teilabsichten sollten stets beendbar sein Sie besitzen auch Hilfsziele Wirkungen auf den Benutzer Die Art und Weise wie verschiedene Kategorien von Benut zern in ihren Rollen auf Ereignisse reagieren wird in die Gestaltung des Drehbuches mit einbezogen Wir untersuchen dazu f r die Benutzergruppen auch die Antizipationsf hig keit den Erfahrungsschatz und die F higkeiten zur Bew ltigung von Schwierigkeiten und benutzen f r die Gestaltung der Szenen diese Informationen Eine kluge und d
80. konsistente Struk tur mit einer minimalen Menge von Hilfsmitteln unter Beriicksichtigung der Aufnah mef higkeit des Akteurs Es werden dabei die Gestaltungsgesetze das Bildschirms und der visuellen Gestaltung auf die Darstellung der Content Typen erweitert Der allgemeine Repr sentationsstil wird durch style sheets unterst tzt Darin werden nicht nur die Typographie und Farbkodierung festgelegt sondern auch die genutzten Metaphern und Darstellungselemente Diese k nnen parametrisiert werden Damit kann zur Laufzeit eine Adaption an den Benutzer erfolgen Inhaltsbasierter Repr sentationsstil Durch die Konstruktion des Sichtenschemas k nnen wir auch die Sichtendefinition und die Funktionalit t des DBMS direkt nutzen um unterschiedliche Darstellungsformen des gleichen Content Objektes zu erm glichen Wir unterscheiden eine Reihe von Zug ngen Zuordnung einer Menge von Sichten zum Content Typ Jedes Objekt kann auf unterschied liche Art und Weise betrachtet werden Die unterschiedlichen Gesichtspunkte auf das gleiche Objekt erlauben auch einen schnelleren und situationsbezogenen ber blick ber das gleiche Content Objekt Das gleiche Objekt wird aus unterschiedlichen Sichtweisen dargestellt Diese Sichtweisen werden durch Sichten d h Ausdr cke der HERM Algebra dargestellt Dieser Zugang wird in XML Ausspielsystemen bereits praktiziert durch die Angabe von XSL Regeln die dann ein variables Darstellen des gleichen XML Dokumentes e
81. logische Sichten Suite Demzufolge k nnen wir die Entwicklungsprodukte f r die entsprechenden Abstraktionsschichten wie auf der folgenden Seite darstellen PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 3 ABSTRAKTIONSSCHICHTENMODELL B THALHEIM 38 USFJIIYDSSUoIJFeIIsqyY Uspusyoeidsyue me 3YnpoadsZunfy2Lmgug XL u quoo uedf L YusIuog ur 9zanusq s qy qu soJoy mns u sq rs qms u qq rssuoniyy Yd sep Tieguegypig u sel s p m su q rs WII QIetuespide1 poyu uond zuoy dAyurey q sraoyo uo np dAT dAquayepyyNpoig 149029 4821 Vwo DIS PPPS JIS 9ZZINS yyd susgeppnpoig 1422S XL u quoo u dZ 1L 1u quoo ys Tp izinu q s p soqjou yonqyeiq preoq 101g usIse s p Tregsinystq UII J101usse del 1111 088 uomuy GWAL STUFTOIISFTUNPUOMUY LIYsssuUNpUSsMUY uorydozuoy q mp yylayossoretq q mp yr yasZoferq q mp ylIyossoTRiq 1114 1010 q rq s p q rq s WIT u zS JO q WI v zg AIO IOUID UT 9USZG s9Unpu xuy ur n zs auazg L u quoo u dZL u quoo ur 323nu q soqyoyuey V MOHYXIOAA urq oseu zinN s p T qu uon yunq se s p TIeyusuoryun UII J107usseidel HTS Honxuny uorydozuoy uonyy g zorq sir qry W np gezorg yynporg q
82. mit Blick auf unbegrenzte Ressourcen ent worfen Mit dem Internet II aber auch schon bei einer Vermittlung von Informationen ber Modems sollte man sich bei der graphischen Gestaltung auf die Informationsvermittlung besinnen und auf graphische Arabesken und Manierismen sowie intergalaktische Multimedia Effekte verzichten Oberfl chen sollten im allgemeinen der Anwendungsphilosophie der Anwendungslogik und dem Anwendungszweck folgen Deshalb sollte eine Anwendung immer als Ganzes entworfen werden Die Organisation der Oberfl chen und die visuelle Struktur der einzelnen Oberfl che folgen der Anwen dungslogik Sind die Oberfl chen zur Pr sentation bestimmt dann ist auch die Firmenstrategie mit einzubeziehen Das Corporate Design von der Werbung bei der Beratung teuer als das Entwurfswis sen eingebracht ist nicht von der Darstellung zu trennen Bestimmte Bedienelemente wie z B die rechte Maustaste k nnen f r spezielle Effekte in einer ganzheitlichen Gestaltung reserviert werden Die Informationsdarstellung die Darstellung des Arbeitsprozesses und die davon abh ngige Dar lege ER 2 s o de na 225 00 00 00 10 1080 2158 En E A REY P A 136 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 7 INTERAKTIVIT T in separaten Einheiten gehalten werden Insbesondere sollten der Suchmechanismus und die verschie denen Verkn pfungsnetze nicht mit der Information gemeinsam dargestellt sein Eine Integration bed
83. nktem Medium wie z B einem Wap Handy oder auch mit einem interaktionsbeschr nkten Medium wie z B Tele Text entgegennehmen und bearbeiten k nnen Deshalb mu ein Auslieferungsmedium eine hohe Allgemein heit und eine sehr hohe Anpa barkeit besitzen Wir f hren dazu den Begriff des Containers ein Ein Container soll beladen an den Benutzer versandt und von ihm benutzt werden k nnen Durch die enthaltenen Content Objekte wird einem Benutzer die erforderliche Datenmengen und Funktionalit t bereitgestellt Aufgrund dieser Anforderungen bedienen wir uns der Zug nge von Skriptsprachen Dadurch kann auch eine Realisierung von Containern mit den Mitteln von Skriptsprachen erfolgen Ein Container wird durch eine abstrakte Zustandsmaschine beschrieben 96 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 6 SICHTENSUITE einem Namen zur Bezeichnung des Containers Zustandsr umen Input Raum Content Raum Output Raum zur Aufnahme von Content Objekten die wir dem Benutzer zur Verfiigung stellen wollen Wir unterscheiden dabei drei verschiedene R ume Input Raum Z Zur Beladung der Container mit Inhalten wird ein Input Raum zur Verf gung gestellt Output Raum Aus dem Container wird auf Anforderung des Benutzers ein passendes Content Objekt ausgew hlt und ihm zur Verf gung gestellt Content Raum M In einem Container befinden sich verpackte Content Objekte Diese haben die folgende Struktur Das Content Objekt stellt die Date
84. notwendig dann ist auch der Zusammenhang explizit darzustellen Die Informationsdarstellung mu klar einfach und intuitiv verst ndlich sein Negative Information und negative Anfragen erfordern vom Benutzer ein genaues Verst ndnis der unterlegten Logik Besser ist es diese Information in positiver Logik zu formulieren Farben k nnen Information tragen Sie soll ten aber stets der Informationsdarstellung untergeordnet werden In verteilten Anwendungen sollte man mit Farben sparsam umgehen und den Schwarz Wei Test nicht auslassen Warnhinweise sollten auch als solche unmi verst ndlich zu erkennen sein Fehlermeldungen sollten kontextsensitiv minimal und auch f r den Normalbenutzer intuitiv verst ndlich sein Die Darstellung von wesentlichen Infor mationen sollte plattformunabh ngig erfolgen Die Statusleiste kann auch eine Kurzhilfeinformation mit einbeziehen Skalierung Kontrast und Gr enverh ltnisse sind der Informationsdarstellung zu unterwerfen Oberfl chen sollten an die Fertigkeiten und F higkeiten der Benutzer angepa t sein Die Benut zer k nnen nach den Kriterien von Alt charakterisiert werden positive Erfahrungen wie z B Ar beitssprache negative Erfahrungen z B Fehler Entscheidungen Wortwahl und Fertigkeiten bzw F higkeiten z B Wissen motorische visuelle Fertigkeiten Abstraktions und Formulierungsf higkei ten etc Damit hat auch die Orientierung auf den Benutzer Vorrang vor dem Testen von nichtstan
85. nur in einfachsten praktischen Anwendungen Er folg Komplexere Anwendungen sind dagegen stets eine Herausforderung f r den Entwerfer In der Literatur gibt es zwei Herangehensweisen Entweder der Entwerfer verl t sich auf ein Entwurfstool und die damit propagierte Methodik oder der Entwerfer besitzt eine profunde Fachkenntnis verf gt ber tiefgr ndige Kenntnisse in der Datenbanktechnologie und ist au erdem in der Lage beliebig abstrakt sein Wissen und seine Erkenntnisse darzustellen Beide Zug nge haben ihre Nachteile Ein Werkzeug das den ersten Zugang vollst ndig mit tr gt gibt es noch nicht Entwerfer der zweiten Kategorie sind selten und meist nicht zur Hand Das Material dieses Skriptes basiert neben der Datenbanktheorie auf umfangreichen Feldstudien und auf der Kenntnis einer Vielzahl von Entwurfsprojekten die mit dem System DB sp ter 722 durchgef hrt wurden Die hier propagierte Methodik wurde diesem System zugrundegelegt Eine Vielzahl von Tips die wir hier vorstellen wurde aus den Projekten abgeleitet Die hier vorgestellte Pragmatik wurde in einer Reihe von Projekten erprobt Die Sprachen zum Datenbankentwurf die wir im weiteren hier umfassend darstellen sind auch methodisch unterlegt worden Es wurde eine Methodik mit einem schrittweisen Entwurf von Da tenbankanwendungen herausgearbeitet Diese Entwicklungsmethodik wurde sowohl in der Lehre und Projekten erprobt als auch mit den Anforderungen von SPICE 2 0 validiert
86. onAbort onError unloadErrorLog useErrorLog notifyMode und e allgemeine Weitergabeparameter wie onSend onReceive forUser toNode fromNode onTime validUntil onLoad onEventTransfer onMouseCapture whoCausedEvent und returnValue Die Parameterliste kann beliebig verkleinert oder vergr ert werden Im letzteren Fall m ssen ad quate Formen f r die Umsetzung in die Implementation gefunden werden Au erdem unterscheiden wir verschiedene Variablentypen Statische Variablen sind analog zu den globalen Variablen von Pascal oder den Klassenva riablen von Java mit einer an das Programm gekoppelten Lebenszeit ausgestattet Statische Variablen k nnen global oder lokal Per Default sind sie lokal e Kellervariable besitzen ebenso wie lokale Variablen oder Parametervariablen nur eine Le benszeit w hrend der Ausf hrung einer Funktion Explizite Speichervariablen nutzen einen tempor r zugeordneten Speicher e Implizite Speichervariablen werden erst mit einem Speicherplatz verbunden wenn ihnen ein Wert zugewiesen wird In analoger Form k nnen der G ltigkeitsbereich und die Bindung an Namen Stellen und Werte zur Entwurfszeit Implementationszeit bersetzungszeit Linkzeit Ladezeit oder Laufzeit von Variablen und Parametern behandelt werden Wir verwenden diese Konzepte zur Spezifikation des Aufrufes einer Transaktion und der Steue rung der Ausf hrung Aufrufsspezifikation Ein Aufruf eines abstrakten Programmes wird
87. semantischen Rahmenbedingungen sind definiert durch e Bedingungen unter denen der Arbeitsvorgang ausgefiihrt werden kann und e organisatorische Randbedingungen Arbeitsabl ufe werden durch Aktivit tenfolgendiagramme beschrieben Sie bestehen aus einem Aktivit tstyp zur Kategorisierung von gleichartigen Aktivit ten einer Transition von Input Outputdaten durch die Aktivit t und 280 nut Zu l o a x 26 2 1 a XE no una EBEN a ee Xo xa 2 hab INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 119 Mit dieser Spezifikation k nnen wir Aktivit tenfolgendiagramme mit Workflow Programmen assozi ieren Aktivit tenfolgendiagramme k nnen sowohl zustandsorientiert durch Zustandsaktivit tendia gramme als auch ereignisorientiert durch Ereignisfolgendiagramme dargestellt werden Rechte eines Akteurs werden durch Zuordnung von Funktionen des Content Objekt Suite darge stellt die ein Akteur zur Erf llung der Arbeitsaufgabe erh lt Mit der expliziten Zuordnung wird ggf der Spezifikationsaufwand h her Wir k nnen jedoch diese Zuordnung auch durch entsprechende Rechtetypen darstellen Damit wird f r die Spezifikation der Rechte nur eine Zuordnung zum Typ erforderlich Die Rolle eines Akteurs baut auf einer Kategorisierung der Erf llung der Arbeitsaufgabe und auf dem Organisationsmodell auf Das Ausf hrungsmodell besteht aus einem Aufgabenaufruf mit dem die Ausf hrung
88. theory Addison Wesley Redwood City 1993 M Agosti Database design A classified and annotated bibliography Cambridge University Press 1986 S Abiteboul R Hull and V Vianu Foundations of databases Addison Wesley Reading MA 1995 S Abeck P C Lockemann J Schiller and J Seitz Verteilte Informationssysteme Integration von Datentibertragungstechnik und Datenbanktechnik dpunkt Verlag Heidelberg 2003 M Altus A modular design strategy for a flexible graphical database design environment An experimental study pages 146 162 S Alter Information systems A management perspective Benjamin Cummings Menlo Park 2nd edition 1996 C Batini S Ceri and S Navathe Conceptual database design an entity relationship approach Benjamin Cummings Redwood City 1992 E Best R Devillers and M Koutny Petri net algebra Springer Berlin 2001 J H Ter Bekke Semantic data modelling Prentice Hall London 1992 E Best Semantik Theorie sequentieller und paralleler Programmierung Vieweg Wiesbaden 1995 P A Bernstein V Hadzilacos and N Goodman Concurrency control and recovery in database systems Addison Wesley Reading MA 1987 J Biskup Foundations of information systems Vieweg Wiesbaden 1995 In German A J Bernstein and P M Lewis Concurrency in programming and database systems Jones and Bartlett Sudbury MA 1993 M Blaha and W Premerlani editors Object oriented modeling an
89. und die Sichtenspezifikation in aller K rze vor Anschlie end f hren wir exemplarisch die Dialogspezi fikation detailliert ein Da f r die ersten drei Spezifikationen bereits viele Untersuchungen existieren f r die letzte aber kaum Material existiert versuchen wir damit auch zugleich eine L cke in der Datenbankliteratur zu schlie en Resultate der Entwicklung auf unterschiedlichem Abstraktionsniveau Das Abstraktionsschichtenmodell erlaubt die Darstellung der Entwicklungsresultate auf unter schiedlichem Abstraktionsniveau Wir folgen hier im wesentlichen dem induktiven Ansatz zur Be schreibung Damit ist jedes Resultat aus jeder Sichtweise Strukturierung Funktionalit t Interakti vit t Unterst tzung der Interaktivit t als generelle Einheit oder Basiseinheit spezifizierbar Resul tate der Entwicklung der Informationssystemanwendung sind Produkte zur Darstellung der Strukturierung sollen die Strukturierung der Daten auf unter schiedlichem Abstraktionsniveau beschreiben Wir nutzen dazu eine Separation der Spezifikation in Schema zur Beschreibung der gesamten Strukturierung und Daten Typ zur Beschreibung der einzelnen Struktur und der Integrit tsbedingungen Produkte zur Darstellung der Funktionalit t sollen eine Darstellung der Funktionsaspekte er m glichen Wir unterscheiden Workflows zur Darstellung der Folgen von Y m AysandJund INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 37 Produkt
90. werden Durch die Informationen aus dem Storyboard und den Zusammenhangs der Sichten k nnen Obligationen f r den Entwurfsproze abgeleitet werden Eine Bereinigung von Integrationskon flikten kann auf der Grundlage des Sichtenintegrationsschemas erfolgen Deshalb wird dieses Schema weiter parallel verfeinert Sichten Suite Die Sichten Suite stellt auf der konzeptionellen Schicht eine Menge integrierter Sich tenschemata dar die auch durch entsprechende Strukturen des ER Schemas und durch Anfra gemengen unterst tzt wird Die einzelnen Sichten werden nun im Detail entworfen F r jeden Typ einer Sicht wird angegeben ob dieser Typ aus der Sicht der Datenbank ein Inputtyp ein Outputtyp oder ein Modifikationstyp ist Auf der konzeptionellen Schicht werden die Typen fiir die Strukturierung durch ein detailliertes HERM Diagramm angegeben Diese Typen stellen eine Verfeinerung der Typen des Anwen dungsschemas dar Die Verfeinerungsbeziehung wird direkt zur Erzeugung der Sichten Suite ge nutzt Der Entwurf der Sichten kann nach den Entwurfsmethodiken des konzeptionellen Schemas angestrebt werden Bei Bereinigung von Integrationskonflikten kann nun auch eine Sichtenintegration angestrebt werden Da uns das Integrationsschema bekannt ist und dieses fortgeschrieben wurde kann eine Integration durch Generalisierung durch Verschmelzung und Kombination oder im Extremfall durch Kooperation der Sichten angestrebt werden Die Sichten werden am Ende
91. z B Lehrveranstaltungen nach Vorlesungssemestern Studieng ngen und Stu dienabschniten in dieser Reihenfolge geordnet werden Angabe von Dekompositionen bzw Separationen des Content Typen Wir k nnen den inne ren Zusammenhang eines Content Typen der durch sein Sichtenschema gegeben ist direkt verwenden Ein Sichtenschema erlaubt eine Reihe von Sichtweisen auf die Daten Diese Sichtweisen k nnen als Sichten dem Sichtenschema zugeordnet werden Welche oy RR S k si x Za OT La ON 21 re RI m za on o 3 1 0 EEIE o ne INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 93 zur Laufzeit entschieden werden Da nicht alle Typen des Sichtenschemas in der glei chen Form miteinander assoziiert sind kann die St rke der Assoziierung direkt mit den Typen verbunden werden Wir nutzen daf r eine Adhdsionsmatriz die zwischen den Typen des Sichtenschemas definiert ist Es sei types G die Menge aller Typen des Sichtenschemas 6 Eine Adh sionsma trix AM ordnet jedem Paar von Typen T T G eine nat rliche Zahl oder 0 zur Darstellung des Abstandes zwischen den Typen in 6 zu Die Adh sion ist umso niedriger um so enger die Typen zusammengeh ren Wir nehmen an da AM T T 0 f r jeden Typen T von types G gilt Die Zuordnung mu nicht vollst ndig f r Teiltypen eines Typen T angegeben sein Ist AM T T2 nicht definiert dann nehmen wir als Adh sion den Ab stand in der Typendefinition der Type
92. zugleich unterschiedliche Sichten auf die gleichen Daten Daten die in dieser Phase entstehen k nnen sp ter ggf modifiziert werden e In der Bauphase werden die Architekturentw rfe realisiert Es werden dabei die Objekte um Baudaten erweitert Die Daten werden in die Verwaltungsdaten partiell injiziert e In der Verwendungsphase werden die Daten schrittweise um die Verwendungsgeschichte der Geb ude ihrer Bestandteile ihrer Pflege ihres Ersatzes ihrer Erweiterung und um Problem aufzeichnungen erweitert Eine Architektur f r inkrementelle Systeme ist in Bild 71 f r das Beispiel von Facility Management Systemen skizziert Wir nutzen Zusatzddatenbanksystem zur Unterst tzung des Facility Management Systemes Mit diesem System werden Informationen zu Standards zur Kundenbeziehung zur Berechnung zu Vor schriften usw in die entsprechenden Systeme injiziert Zusatz datenbank system SP O Xor injiziert modifizierbar Insert Injektion er Planungs phase injiziert r Zusatz Zusatz Zusatz datenbank datenbank datenbank system system system injiziert injiziert injizie 3 DBS S Use 4 s O Moc O Xor O Nom modifizierbar modifizierbar Insert gt Insert gt Injektion r gt Injektion injiziert injiziert DBS der iene ae ges wen Verwendungs phase P phase Bild 71 Die
93. 0 0 0 0 0 0 0 1 a 153 CORBA Architektur 0 0 0 0 0 0 0 0 0 0 0 0 0 153 Die Arbeitsprodukte im Abstraktionsschichtenmodell f r die Verteilung 156 Grunds tzliche Architektur verteilter DBMS 158 Partitionierungskonzepte 0 0 nn 160 Die Architektur von f derativen Datenbanksystemen 163 Namensaufl sung setsit moon 164 Namensaufl sung ber Synonyme 2 2 rn nn 165 Zug nge f r Mehrrechnersysteme 165 Verallgemeinerung der Dreiebenen Architektur zu einem verteilten Schema 168 Generelle Architektur von Datenbank Farmen 169 Die allgemeine Architektur f r inkrementelle Evolution von Datenbanksystemen 170 Die drei Komponenten eines Datenbank VVarenhan ses 171 Die 3 dimensionale Aggregation von VERKAUF 175 Index Abarbeitungsmodell 118 Abstrakt 94 Abstrakte Spezifikation 65 Abstraktionsschicht 33 Aggregation 48 Akt 110 Akteur 37 99 113 Akteurmodell 120 Aktionsschicht 34 Aktionsspezifikation 37 Aktivit tenfolgendiagramm 118 Algebra 60 Allgegenwart 148 Anforderungsspezifikationsschicht 34 Anfrage 63 Anwendungsgebiet 105 176 Anwendungsschritt 105 176 Arbeitsablauf 118 Arbeitsgestaltungsdimension 119 Arbeitsgruppe 99 Arbeitsoberfl che 111 Arbeitsplatz 99 Arbeitsprofil 114 Arbeitsschritt 177
94. 01 Titel DB Programmierung Typus TypusID1 Erfuellung gehalten gt lt geplant durch Fak Ref Schenk gt lt Dozent Name beta gt lt Raum SR1 gt lt Zeit AB Mittwoch 7 30 9 00 gt lt Aenderung Datum 1 1 2000 gt lt Vorschlag gt lt Zeit gt lt von gt Montag lt von gt lt in gt Mittwoch lt in gt lt Vorschlag gt lt Aenderung gt lt geplant gt lt Studiengang Name Informatik Phase Hauptstudium gt lt Typus ID TypusID1 gt lt Art gt Normalvorlesung lt Art gt lt Umfang gt 2 2 2 lt Umfang gt lt Typus gt lt Kurs Name Datenbanken III gt lt Inhalt ID 4711 gt lt Inhalt gt lt Kurs gt lt Semester gt Sommersemester 2000 10 4 2000 15 7 2000 lt Semester gt lt Verantwortlicher gt lt Lehrveranstaltung gt lt Dozent Name beta gt lt Uebung Name Feyer gt lt Praktikum Name Vestenicky gt lt Lehrveranstaltung gt lt Planung gt lt geplant durch gt Fak Ref Schenk lt geplant durch gt lt Datum gt 1 4 1999 lt Datum gt lt Planung gt lt Vorschlag ID 08015 Von KK gt lt Sonderwunsch gt lt Zeit gt AB Montag 7 30 11 00 lt Zeit gt lt Raum gt lt Ausstattung gt Beamer Netzanschlu amp szlig lt Ausstattung gt lt Raum gt lt Nicht Parallel gt Datenbanken I lt Nicht Parallel gt lt Sonderwunsch gt lt Vorschlag gt lt Lehrveranstaltung gt Die erste Methode wird meist f r die Speicherung und Verarbeitung in relationalen und o
95. Akteure durch Angabe der Metapher Einbettung mit den Parametern f r die Funktion der Metapher in der Suite die Anwendbarkeit der Metapher im Gestaltungsrahmen z B als Vollseiten Teilseiten Beiwerk Metapher das Ursprungsgebiet der Metapher die Abstraktionsrichtung Generalisierung Spezialisierung die Richtung vom Lebewesen zum Gegenstand vom Gegenstand zum Lebewesen dem beabsichtigten Effekt pr dikativ oder berzeugend attributiv genitiv kompositional Ap position und die Repr sentationsform als Auswahl unter den verschiedenen m glichen Repr sentationsformen der Metapher sowie durch Angabe der Intention der Metapher mit Parametern f r den Kontext Intention f r Akteur Erwartungen des Akteurs Co Notationen soziale und emo tionale der Funktion intern pr dikativ heuristisch emotional sozial rhetorisch sthetisch und dem Typus der Metapher konventionell kreativ Ex Metapher Re Metapher Wir k nnen wiederum anstelle einer Tabelle Arbeitsbl tter zur Darstellung der Metaphern verwenden Der Gestaltungsrahmen wird au erdem durch eine Spezifikation der Betonung Dominanz Transparenz und der E hy NEE W E are INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 145 erg nzt Mit dieser Darstellung k nnen wir auch die Akzeptanz die Wahrnehmung die Aufnahme des Inhaltes seine Verarbeitung und die Stimmung beeinflussen Diese Spezifikation kann auch als Interface Polar
96. Architektur Verteilung Protokolle Bild 62 Die Arbeitsprodukte im Abstraktionsschichtenmodell f r die Verteilung VERTEILUNG Dienstanforderungen Kollaborationsvertrag Kollaborationsrahmen Kollaborationsrahmen INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 157 folgt zusammengestellt werden Trader Kommunikation Kooperation Koordination Kollaborations rahmen Architektur Asynchroner Client Kooperationsmanager Koordinationsmanager Content Suite Management System Formation Modell Protokoll Trader X P2P Kontrakt TA FIFO Abarbeitung Release Login Hierarchisch Sharing Lebensspanne Datenaustausch Stub Fehleraufzeichnung ffentlicher pers nlicher Replica der Suiten Raum Interplay Freignis offener Raum reaktiv proaktiv Handeln buchen bezah len Berechnung Modell Message passing Trader FIFO Programme IP5 Workspace Nutzerab Session Manager rechnung Datenaustausch Push through Token Partielles 2 Phasen Halb synchron volle basiert Locking Synchronisation mit DBS Interplay IP5 sequencing auf Anforderung 2 Phasen Commit Verteilte Datenbanksysteme als spezielle kollaborative Systeme Eine verteilte Datenbank ist eine inhaltlich zusammenh ngende Datenbank die auf mehreren phy sisch unabh ngigen Knoten Rechner Speichermedien verteilt wird Die auf den Knoten abgelegten Partitionen der Datenbank k nnen dabei auch nicht separiert voneinander sein Datensh
97. Ausf hrungspriorisierungen werden die Zeitparameter festgelegt Entscheidungsregeln spezifizieren im weiteren welche T tigkeit zu welchem Resultat f hren mu kann bzw sollte Wir k nnen dazu Entscheidungstabellen benutzen Es werden aus den Gesch ftsfalldaten d h den Daten die w hrend eines Gesch ftsprozesses anfallen und den Gesch ftsdialogen entsprechende Entwurfsobligationen f r andere Entwurfsschritte abgeleitet Jeder Aktion k nnen aktionsspezifische Integrit tsbedingungen zugeordnet sein Unter den Aktionen kann eine Ordnung existieren die als kausale Abh ngigkeit f r parallelisierte Aktionen dargestellt wird Weiterhin werden den Handlungen verschiedene Varianten von Aktionen zugeordnet Wir verwenden dazu eine Erweiterung der tabellarischen Darstellung der Tabelle zu Gesch fts vorf llen von Seite 57 Eine graphische Darstellung wird in den Schritten zur Feinstudie aufgezeigt Die tabellarische Darstellung stellt ein Kollaborationsdiagramm dar und beinhaltet die folgenden An gaben Handlungen des Akteurs Ausl ser Organisatorische Einheit Hilfs und Zusatzinformation Integrit tsbedingungen obligatorisch erlaubt verboten Methodenregeln Ausf hrung Umgebung Zeitparameter Aktionen des Akteurs f r i Handlung Akteur Rechte Pflichten Rolle ij Aktion Integrit tsbedingung a EEE o a EP SD 112 2 6 5 ee En o a aa INFORMATIONSSYSTEM ENTW
98. Benutzer oder auch Benutzergruppen im weiteren repr sentiert durch Akteure enth lt und vom Unwesentlichen im derzeitigen Kontext abstrahiert Diese Separation von Gesichtspunkten entspricht dem Herangehen der Semiotik in der zwischen verwendeter Syntax der unterlegten Semantik und der Art der Verwendung Pragmatik unter schieden wird In der Semiotik wird unterschieden zwischen Zustands Vorgangs T tigkeits und Handlungsdarstellungen Syntaktische Formen werden oft in der klassischen SPO Notation gegeben Das Subjekt ist Geschehnistr ger T ter Handelnder Akteur das Pr dikat ist der Aussagekern Objekte sind Sinnerg nzungen Au erdem werden freie adverbiale Bestimmungen zur Charakterisie rung des Kontextes verwendet Die Semiotik unterscheidet vier Aspekte Syntaktischer Aspekt zur 11Obwohl auch diese Arbeit eine weitgehende Verwendung deutschsprachiger Begriffe bevorzugt m ssen wir beim Begriff Content bleiben Die richtige deutsche bersetzung f hrt zum Begriff Inhalt Da dieser Begriff in der 171 T te ee ee em tm INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 21 Darstellung der Beziehung der Zeichen zueinander sigmatischer Aspekt zur Widerspiegelung der objektiv realen Wirklichkeit semantischer Aspekt zur Interpretation der Welt durch die Sprache pragmatischer Aspekt zur Konventionalisieurng der sigmatischen semantischen und syntaktischen Relationen Der sigmatische Aspekt spielt in der
99. Benutzungsaspekte werden im Zachman Modell vernachl ssigt Es geh ren hierzu insbesondere das Aufgabenportfolio und das Organisationsmodell Unser Modell der Entwicklung von Informationssystemen im Co Design Zugang folgt den ersten drei Aspekten Strukturierung Funktionalit t und Verteilung und betrachtet anstelle der letzten drei Aspekte das Storyboard d h die Interaktivit t Wir f gen dem Zachman Modell noch weitere Dimensionen hinzu Kompetenz wof r Es werden die Aufgaben die durch das Informationssystem unterst tzt werden sollen explizit dargestellt Kontext in welcher Umgebung Meist werden Kontextentscheidungen implizit in die Modellie rung eingebracht Dazu geh ren nicht nur die technische und organisatorische Umgebung son dern auch die Strategie des Betreibers des Systemes Qualit tsgarantien in welcher Qualit t Es wird explizit dargestellt inwieweit bestimmte Qua lit tskriterien durch das System unterst tzt werden und welche Qualit tskriterien nicht oder nur bedingt erf llt werden Laufzeitcharakteristiken wie derzeit Da die Arbeitsumgebung auch durch Ausnahmesituationen durch aktuelle Parameter durch zeitweilige Verschiebung der notwendigen Schritte zum Ab schlu und durch benutzungsspezifische Aspekte gepr gt ist sollte die Anpassung des Systemes PEREOS EET OP LORIE T EEPE 1 PATEE A MEE aE ROOTS ib cr s EB h ETET 228 INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGA
100. Benutzungsoberfl chen und die Dokumentation erstellt 11 Systemkonfiguration Nach Erstellung der Einzelkomponenten wird das Gesamtsystem entwickelt und konfiguriert 12 Aus und Weiterbildung der Mitarbeiter Die Mitarbeiter im Betrieb werden schrittweise an das neue System herangef hrt 13 Pr fen der Systemsicherheit Wirtschaftlichkeit und Ergonomie Das System wird anhand von Qualit tskriterien wie e Sicherheitskriterien z B Integrit t Verbindlichkeit Verf gbarkeit Vertraulichkeit e Wirtschaftlichkeit wie Anpassungsf higkeit an ver nderte Proze abl ufe Durchlaufzeit Durchschaubarkeit Nachvollziehbarkeit der Prozesse Investitionen und Betriebskosten Zahl und Qualifikationsniveau der Mitarbeiter analysiert 14 Inbetriebnahme des Systemes Nach einem Migrationsplan wird das System schrittweise in die Praxis berf hrt Diese und andere Methodiken zeichnen sich z T durch sehr gro e Detailliertheit aus sind aber in den wesentlichen Teilen zu unscharf und wenig brauchbar Ein anderer ebenso wenig praktikabler Zugang wird in der klassischen Datenbankliteratur ver folgt Der klassische Entwurf einer Informationssystemanwendung ist von einer Reihe von Br chen gekennzeichnet Struktur Funktionsbruch Die meisten Methodiken und Werkzeuge unterst tzen beim Entwurf keine gleichgewichtige Sicht auf Strukturierung und Funktionalit t von Informationssystemen Prozes se werden meist nur in einer rudiment ren Fo
101. EER INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 147 Anwendungsdienst mit einer Darstellung des Verhaltens auf Anwendungsebene abstrakter Dienst der Aktionsschicht mit einer Darstellung der Kollaboration konzeptioneller Dienst mit einer Darstellung des Kollaborations und Dienstesystemes auf kon zeptioneller Ebene und Systemdienst mit einer Angabe der Systemroutinen programme und Protokolle Diese Dienste k nnen wie in Bild 58 geschichtet werden Anwendungsdiens Abstrakter Dien stemdienste Bild 58 Eine Schichten Architektur f r verteilte System C J Date stellte 12 Regeln f r verteilte DBS auf 1 Gr tm gliche lokale Autonomie und lokale Verwaltung von lokalen Daten 2 Keine Abh ngigkeit vom zentralen Knoten 3 Permanenter Betrieb 4 Ortsunabh ngigkeit Ortstransparenz d h die physische Lokation von Daten mu verborgen bleiben und Datenumverteilungen d rfen keine Auswirkungen auf Programme haben 5 Partitionierungsunabh ngigkeit 6 Replikationsunabh ngigkeit 7 Verteilte Anfrage Bearbeitung die f r den Zugriff auf externe Daten und die Optimierung verteilter Anfragen erforderlich ist 8 Verteilte Transaktionsverwaltung einschlie lich Synchronisation Recovery verteiltes Commit Protokoll 9 Hardware Unabh ngigkeit 10 Betriebssystemunabh ngiskeit 11 Netzwerkunabh ngigkeit 12 DBMS Unabh ngiskeit Nicht jedes dieser Kriterien wird durch die kom
102. Eigenschaften von Interesse sind Es gibt eine ganze Reihe von Urteilen die f r uns von Interesse sind Existenzurteile konstatieren die Existenz von Dingen e Belegurteile dienen dem Belegen von Beobachtungen e Beziehungsurteile stellen Dinge in ihren Beziehungen dar e Bestimmungsurteile dienen der Assoziierung von Urteilen mit Eigenschaften Assoziierungsurteile erlauben die Assoziierung die Aggregation und die Komposition e Abh ngigkeitsurteile stellen semantische Beschr nkungen dar Ein Urteil ist bei weitem nicht absolut Wir stellen deshalb die Modalit t explizit dar Die Modalit t erlaubt je nach Urteilsart auch die Entwicklung logischer Theorien Ein Modellierungsurteil kann eine Annahme eine Meinung eine Hypothese eine Gedankenverbindung oder auch eine Frage darstellen Ein Modellierer ist ein Individuum das in einem Kontext z B der Anwendung oder in einem kulturellen Kontext Urteile f llt Oft folgt das Modellierungsurteil einer Referenzdarstellung Dem zufolge fassen wir ein Modellierungsurteil als tern re Beziehung zwischen Eigenschaft Theorien und Einen ersten Ansatz liefert die Arbeit Kas03 in der ein Theorieansatz angegeben wird Wir verdichten diesen di 4 16 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 1 EINFUHRUNG den im Kontext agierenden Individuen auf Weiterhin kann im Entwicklungsproze ein Urteil wieder revidiert werden Unsere Vorstellung vom Modellierungsurteil haben w
103. Entwurfsdokumente sind abzustimmen Komponentenlieferant in Abh ngigkeit vom Entwicklungsmodell Das Komponentenmodell ist orthogo nal zu den anderen Entwicklungsmodellen und wird deshalb auch in die anderen Entwurfsdo kumente integriert Je nach Abstraktionsschicht erfolgt eine unterschiedliche Einbindung Das Zachman Modell der Rollen w hrend der Entwicklung von Informationssystemen ist noch relativ grob Wir k nnen feiner unterscheiden z B Rollen aus dem Umfeld Genehmigungsbeh rden Einspruchsberechtigte ffentlichkeit Rollen der Bestellung Bauherr Eigent mer Finanzgeber Investor Finanzierender Subventionsge ber Betreiber Verwaltung Erhaltung Benutzer Projektleiter Besteller Berater Rollen der Lenkung Gesamtleitung Leitung Projektierung Leitung Programmierung Leitung Ad ministration Leitung Infrastruktur Rollen der Gestaltung Projektierung Architekt Berater und Rollen der Ausf hrenden Entwerfer Graphikdesigner Programmierer Das Zachman Modell verdeutlicht unterschiedliche Abstraktionsschichten mit unterschiedlicher Spezi fikation und unterschiedlicher Detaillierung Ein integrierter Entwurf mu deshalb auch unterschied liche Detaillierungsgrade erm glichen G nstig ist wenn die Entwurfsdokumente aufeinander Bezug nehmen bzw eine Untersetzung der Entwurfsdokumente der n chsth heren Schicht wie in Bild 14 darstellen tesezesececcsceceuces Bild 14 Entwurfse
104. Funk Proto PartnerGruppel Rechte Port Proto chro rung Zeit 1 cher tio koll folio koll nisa heit nen dis ablauf tion kurs 154 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 8 VERTEILUNG Kooperation basiert auf kooperierenden Sichten Es werden dazu koordinierende Formeln angege ben die Typen eines Schemas mit Typen eines anderen Schemas assoziieren Zur Spezifikation der Kooperation werden die drei Bestandteile dargestellt e Mit der Kooperationsform wird die Art der Kooperation dargestellt Es wird das Zustandekom men einer Kooperation durch die gew hlte Form durch die Geschichte des Zustandekommens die Parallisierbarkeit und den gew hlten Vertrag charakterisiert e Die Kooperation unterliegt einem Ablauf den wir im Arbeitsproze der Kooperation zusam menfassen Es werden die Organisation der Kooperation die Partner und der Ablauf der Ko operation beschrieben e Die Kooperation wird durch Dienste unterst tzt Wir fassen die Dienste deren Nutzung Be reitstellung und Ver nderung im Austauschrahmen zusammen Die einzelnen Partner haben innerhalb von Gruppen spezifische Arbeitsaufgaben f r die Dienste zur Verf gung gestellt wer den wobei die Organisation der Kooperation mit erfa t wird Wir erhalten damit den folgenden Kooperationsrahmen Kooperationsform Arbeitsproze verwaltung Austauschrahmen Form Rolle Formie
105. Generelle Architektur von Datenbank Farmen z B im Denda Projekt eine Datenbank Farm realisiert bei der die Integrit t Sicherheit und der gemeinsame Betrieb auf der Grundlage der Datenbank Farm Technologie gesichert wurden Datenbank Farmen m ssen auf m glichst einfachen Schemata aufsetzen Wir nutzen f r die einzel nen Teildatenbanken Stern oder Schneeflockenschemata LL03 Tha01 die als Komponentensysteme Rie99 Tha02 verstanden werden k nnen Die Komponentensysteme werden mit einer Verbindungs technologie wie oben dargestellt miteinander gekoppelt Die Kopplung folgt dem Skelett der Anwen dung Die Kopplungsoperatoren dazu sind der Verbund X der Theta Verbund die verallgemeinerte Vereinigung U und die verallgemeinerte Projektion vr Aus den Verbindungsoperatoren k nnen die Modifikationsoperationen auf der Grundlage des Datenbank Farm Vertrages abgeleitet werden Der Vertrag versichert auch die Einhaltung der In tegrit tsbedingungen Inkrementelle Farmen von Datenbank Systemen Die angef hrte Methodik zur Entwicklung von Informationssystemen erlaubt eine inkrementelle Evolution von Datenbanksystemen Sie ist eine spezielle Form der Systemevolution Anwendungen im Facility Management Bereich erfordern oft die abgestimmte Entwicklung von Farmen von Systemen Jede einzelne Datenbank hat ihre spezifische Funktionalit t und ggf auch Strukturierung Zugleich werden Objekte der einen Datenbank an andere Datenbanken bergeben
106. HALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 6 SICHTENSUITE als Paar fi fG von Funktionen definiert so da fig eine partielle Finbettungsfunktion von Typen von in Typen von mit dem Definiti onsbereich def fi2 S12 ist ist die korrespondierende Einbettung von Klassen von ev in die von 6S d h 62 und TG ez mit der Eigenschaft Hr zl p r falls fiz definiert ist f r den Typen T d h die Abbildung fig erh lt die Semantik von G2 Damit kommutiert das linke Diagramm in Bild 37 Die Partialit t von fi2 TS definiert ein Sichtenschema G11 in G und eine Sicht f12 Gi1 in Es sei au erdem ein partieller Sehema Morphismus f21 fH von Si und G2 gegeben G 62 Sf ey 12 sc 6 0 ozun 6 I RT fai H H oec H f 20 i f x z C Bi C 63 GI Bild 37 Partielle Schema Morphismen zur Sichtenkooperation Die Schema Morphismen fi2 fG und fK definieren eine Sichtenkooperation falls f r jeden Typ T S N fa S21 und jedem Typ 72 Gai N fi2 G11 f r jedes Paar der entsprechenden Klassen T GY TY GY die Funktionen fS TO FE TL 5 GT definiert sind und die kommutierenden Gleichungen fS fG TP TE T gelten Durch die Sichtenkooperation wird ein Input eines Schemas mit dem Output eines a
107. ICKLUNG IM CO DESIGN ZUGANG Oby 6 59 Handlungen des Akteurs Eintrag einer Lehrveranstaltung nach Aufforderung Ausl ser Organisatorische Einheit Hilfs und Zusatzinformation Integrit tsbedingungen obligatorisch Beendigung_Bis_Termin erlaubt Entfernung von Angebot verboten Parallelangebot zu anderem Lehrstuhl Methodenregeln Ausf hrung Mit_Unterbrechung Ansicht Erfolgsmeldung Gruppenarbeit Erinnerungsskripte tempor re Umgebung Sitzungsobjekt Onli ne Interface konfigurierbare Oberflache Zeitparameter Tempor re Ablage wiederhol ter Aufruf niedrige Priorit t Aktionen des Akteurs f r 1 Eintrag von Angeboten zu Lehrveranstaltungen Beauftragter des Lehrstuhles Rechte Eintrag Abschlu Einsicht in Lehrstuhlangaben Einsicht in Anforderungsliste Eintragen Streichen und Modifikation von Angeboten Pflichten vollst ndige Abarbeitung der Liste Rolle Datenbereitstellung 1 1 Entgegennahme der Einzelaufgaben 1 1 1 Auswahl aus der Aufgabenliste 1 1 1 1 Lehrveranstaltungsidentifikation best tigen 1 1 1 2 Auswahl der Lehrveranstaltungsart 1 1 1 3 Best tigung oder Modifikation der Bezeichnung der Lehrveranstaltung 1 1 1 4 Best tigung oder Modifikation der Inhaltsbeschreibung der Lehrveranstaltung 1 1 1 5 Zuordnung der Lehrenden zur Lehrveranstaltung 1 1 2 Angaben zur Art der Lehrveranstaltung 1 1 2 1
108. IS mpprypy W9 o 0A sounje oyuauoduroyf sop gwag Fwegsurfo0401 74307 y suey sq reg peysqy A SUISOJWIIIOLT oqofuoq piofspoqay ossojysboufny s p s pfu uy zjDjdspaqgay d S s5um 2s z UIYLUn DUIYIJS 60 1 4190 UIWUDSNZ 8 01104009110 suo p40q0 o 7 bupr ig ulozmu SLIOAUF Ulezynueg UOA ueddniy ewoyssmapfy Jazynueg g uoa SSETY Suerr is suorjestues19 Sunr fil poT Zurpreog A1028 w ne1 k1oIg TUNLIEU9ZS OLTEU ZS Suv qig 104S SOLIOIS umey uodAy 14914 OSSEIM dA4T 9u uo7 quayuoy 1091002 queyuoy Zuerfong rq yu Su T uoe wIgasIy mg u q rs dAgu q rg eur q su rs oy fqou qq rg aSSEpUITIIG INMAH IVMHH opuszings oqun Sewo og MOJIM 11307 HUFUOS AA stu ud sop yryueureg TVHHH yezodum T q srureu q euwog ypelqo OSSEIM Suppe N SS ZOL wIUTeIsOLg MOP LION MOPP ION MOPJIOM WYAH VIS penysqy yr rseq YA SEUWUOS YA yIyueuIog YSIS S D YHuveu s 7 TNMGH Pif oru eyipesq AA n snes dAL anyyn g drysuoryepy FROTS UH 4 9SSEIM Wud q yu su ry y rseq q u dun3urp q mey SYE4LISOYUT
109. Informationssystem Entwicklung Die integrierte Entwicklung der Strukturierung Funktionalit t Verteilung und Interaktivit t von gro en Informationssystemen Bernhard Thalheim Institut f r Informatik Brandenburgische Technische Universit t Cottbus Postfach 101344 D 03013 Cottbus Germany thalheim informatik tu cottbus de Preprint BTU Cottbus Computer Science Institute 15 2003 21 September 2003 Erweitertes Skriptum zu den Vorlesungen Datenbankmodellierung Teil Sprachen Information Systems Engineering Teil Sprachen Systematische Entwicklung informationsintensiver Websites Co Design Zugang 0 Vorwort Was diese Wissenschaft betrifft Es ist so schwer den falschen Weg zu meiden Es liegt in ihr so viel verborgenes Gift Und von der Arznei ist s kaum zu unterscheiden Goethe Faust Ein Fragment Nacht Mephistopheles Die Spezifikation der Strukturierung Funktionalit t und Interaktivit t einer Informationssy stemanwendung ist Aufgabe des Informationssystementwerfers Gew hnlich wird eine Entwurfsme thodik empfohlen die vom Strukturentwurf ausgeht mit dem Entwurf der Funktionalit t auf der Grundlage der entworfenen Strukturen fortsetzt und gegebenenfalls mit dem Entwurf der Oberfl chen endet Der Entwurf der Semantik kann jeweils im Anschlu an den Strukturentwurf Entwurf der sta tischen Semantik und den Funktionalit tsentwurf Entwurf der dynamischen Semantik bzw des Verhaltens
110. KAPITEL 7 INTERAKTIVIT T Kommunikationsbeziehungen sowie das Organisationsmodell Gruppen verf gen ber spezifische Formen der Kollaboration Diese Kollaboration basiert oft auf relativ festgeschriebenen und demzufolge abzubildenden Beziehungsstrukturen Rechte werden mit der expliziten Darstellung der Kollaboration in Rechte zu Kooperation Koordination und zur Kommunikation untersetzt Portfolio werden den Einzelaufgaben zugeordnet wobei die Art des Zusammenwirkens auch die Art der Abarbeitung des Portfolios determiniert Die Organisation wird durch die Darstellung der Dramaturgie der Kollaboration verfeinert Der Kollaborationsrahmen wird noch einmal bei der Spezifikation der Verteilung betrachtet dort allerdings mit einer Konzentration auf die technische Unterst tzung Zu Spezifikation der Kollabora tion k nnen wir die folgende Tabelle oder auch ein Arbeitsblatt wie bereits bei der Spezifikation der Szenen und der Dialogschritte verwenden Kollaborationsrahmen Kollaboration Art des Zusammenwirkens Arbeitsplatz Form Rollenl Formie Raum Ver Bezie Arten Diskurs Ak Gruppe Rechte Port Organi rung Zeit trag hungen typ teure folio sation Wir unterscheiden die Kopplungsmechanismen nach Seite 98 in Interaktionskopplung Kopplung im Story Raum Komponentenkopplung Container Kopplung und Vererbungskopplung Sie k nnen auch im Kombination v
111. KTIVIT T Portfolio und Benutzungsgeschichte etc vor Es werden au erdem die Erwartungshaltung die allgemeinen Gruppeneigenschaften der Bildungs und Arbeitshintergrund klassifiziert Qualit tsvorgaben Informationssysteme sollen sich durch eine hohe Benutzbarkeit auszeichnen Be nutzbarkeit kann man auf Qualit tsanforderungen abbilden Verst ndlichkeit Es sind alle Funktionen die Navigation und Aufforderungen unmi verst ndlich f r einen Benutzer Einfachheit Das System ist einfach gehalten Das System lenkt nicht von der L sung von Auf gaben ab Erlernbarkeit Es soll einem Benutzer der das System das erste Mal benutzt und einem Be nutzer der das System nach l ngerer Pause wieder benutzt ein einfacher Einstieg in die Benutzung des Systemes ohne hohen Lernaufwand m glich sein Diese Anforderungen kann man auf Merkmale des Systemes abbilden Erscheinungsform des Interfaces Das Interface ist einfach nicht berladen besitzt ein anspre chendes Layout und eine akteurbezogene Inhaltsgestaltung Durchschaubarkeit des Story Raumes Der Story Raum wird so optimiert da ein Benutzer sei ne Aufgaben mit dem einfachsten Szenarium bew ltigen kann Hilfreich ist hierbei eine angemessene Navigation im Story Raum Les und Browsbarkeit des Content Der Content soll in einer Form pr sentiert werden die so wohl das Lesen als auch das schnelle Durchmustern erlaubt die keine Sprachbarrieren aufbaut weder fremdsprachig noc
112. May 2003 2003 M Sh Tsalenko Modeling of semantics for databases Nauka Moscov 1989 in Russian B F Webster Pitfalls of object oriented development a guide for the wary and entusiastic M amp T books New York 1995 S Yigitbasi B Thalheim K Seelig S Radochla and R Jurk Entwicklung und Bereitstellung einer Forschungs und Umweltdatenbank f r das BTUC Innovationskolleg In F H ttl D Klem and E Weber editors Rekultivierung von Bergbaufolgelandschaften pages 269 282 Walter de Gruyter Berlin 1999 INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG 8 185 Danksagung f r die Mitarbeit Diese Arbeit stellt eine Zusammenfassung der Arbeiten zum Co Design Modell dar Sie ist in vie len Diskussionen mit den Mitgliedern meiner Arbeitsgruppen in Rostock und Cottbus entstanden denen ich sehr danke Wir haben in Cottbus parallel zwei Co Design Ans tze entwickelt den hier behandelten Top Down Zugang und einen Bottom Up Zugang unter der Leitung von Wolfram Clau und sp ter Thomas Feyer auf der Basis von Stellen Transitionsnetzen Beide Zug nge haben ihre Berechtigung Methodisch ist der erste Zugang einfacher F r Detailbereiche wie z B die Interak tionsmodellierung ist die zweite Methode einfacher und effizienter Inhaltlich sind beide Zug nge gleichwertig In der Praxis wird sich ein Mix dieser beiden Methoden durchsetzen Eine Methode ist erst dann reif wenn sie sowohl in der Entwicklungspraxis a
113. Motive Absichten und Ziele gepr gt Damit ist auch ein Skelett der Handlung gegeben Auf der Grundlage dieses Skeletts kann die Geschichte eine Struktur erhalten Sie sollte frei von Widerspr chen und nur beschr nkt rekursiv sein Ein System wird nur dann akzeptiert wenn es einen intuitiv erkennbaren Nutzen bringt und echte Bed rfnisse von Akteuren in einfacher Form befriedigt Ein System ist damit auch vom Zeitgeist abh ngig sollte sich diesem aber nicht vordergr ndig verpflichtet f hlen Jede Szene ist klar und deutlich zu entwerfen und mu mit einem entsprechenden Inhalt an der richtigen Stelle mit der richtigen Hintergrundinformation und mit ad quaten Aufgaben komponiert werden Au erdem sind f r jede Szene die Informationen den Akteuren in der richtigen Sorte in der richtigen Dosis in der richtigen Form in vollem Umfang und zu akzeptablen Kosten zur Verf gung zu stellen Allen Akteuren ist klar und deutlich darzustellen worin der n chste Arbeitsschritt besteht in welcher Szene der Story er sich befindet und welche Probleme nun gel st werden sollen und k nnen Eine Anwendung kann auf eine F lle von Zielgruppen oder auf einige wenige Akteure orien tiert werden Anstatt eine Story drauflos zu entwickeln bevorzugen wir eine methodische Entwicklung Wir arbeiten uns von der Idee zur Grobstruktur und weiter ber verschiedene Zwischenstadien bis zur Endfassung vor Die drei wichtigsten Entwicklungsstadien sind Expose Treat
114. NG BY 6 5 Kollaboration mit wem Arbeitsaufgaben werden oft in Gruppen bew ltigt Die Kollaboration von Gruppen mu deshalb explizit dargestellt werden Wir unterschieden zwischen Kommunikation Kooperation und Koordination und stellen dazu Kollaborationsrahmen dar Damit wird das Akteursmodell weiter ausspezifiziert Diese Dimensionen untersetzen z T die Zachman Dimensionen Da im Verlaufe des Modellierungs prozesses alle Aspekte der Anwendung explizit dargestellt werden sollten umfa t unsere Methodik auch diese Betrachtungswinkel Die Semiotik und die Linguistik unterscheiden f r Sprachen drei unterschiedliche Betrachtungs weisen die auch f r unsere Spezifikationssprachen gelten Die Syntaktik bzw Syntax untersucht die Beziehungen der Zeichen Worte selbst stellt Regel systeme zur Erzeugung korrekter Ausdr cke der Sprache bereit und f hrt oft zu einem Beweis system mit dem bestimmte Eigenschaften f r Kollektionen von Ausdr cken dargestellt werden k nnen Die Semantik untersucht die Beziehung zwischen Worten und Ausdr cken einer Sprache und den Objekten bzw Dingen der Realit t Es werden demzufolge Welten Kollektionen von Aus dr cken gegen ber gestellt Typische Gegen berstellungen sind die G ltigkeits bzw die Erf ll barkeitsrelation Die Pragmatik untersucht die Beziehung zwischen Worten und Ausdr cken einer Sprache und dem Wort bzw Ausdruckbenutzer und konzentriert sich auf Aspekte der Bedeutung
115. PRINT BTU INFORMATIK I 15 2003 KAPITEL 5 FUNKTIONALIT T eine Stammform zur Parametrisierung der unterschiedlichen Dimensionen wie z B Zeitdimension und Akteurdimension die Wortbildung d h durch Regeln zur Assoziation von W rtern zu komplexeren Ausdr cken wie z B Ableitung Zusammensetzung und Abk rzung und die Flexion zur Ableitung von Varianten und zur Erfassung von Ausnahmen Ein morphologisches Merkmal erlaubt die Kennzeichnung der Ableitungsdimensionen eines Begriffes je nach seiner Kategorie Verb Nomen Artikel Pronomen Adjektiv Partikel durch Deklination der drei Merkmale e Kasus mit dem eine Assoziierung der Worte zu thematischen Rollen und der Art der Assoziierung Nominativ wer was Akkusativ wen wohin wie lange Genitiv wessen Dativ wem f r wen Ablativ wodurch womit von wem weswegen wann und Vokativ zur direkten Anrede determiniert wird e Genus mit dem eine Kategorisierung z B zum Geschlecht Maskulinum Femininum Neu trum vorgenommen wird und e Numerus mit dem eine Einzelbehandlung oder eine Gruppenbehandlung erm glicht wird Konjugation zur Instantiierung von n wertigen valenten Beziehungen mit e Numerus zur Assoziierung mit Kardinalit t Singular card R E 0 1 Dual card R E 0 2 bzw Plural card R E 0 n Personalformen zur Ausrichtung der Beziehung ich gt
116. Prozesses Programme der Workflow Maschine Elementarprogramme sind alle zugelassenen Ausdr cke der HERM Algebra Wir unterlegen dabei eine Semantik der Abstract State Machines Sie wird im folgenden kurz eingef hrt In diesem Buch werden wir die Semantik nur anwenden so da wir auf eine detaillierte Erkl rung verzichten k nnen F r die graphische Darstellung schlie en wir uns den blichen Darstellungsformen f r sequentielle Programme an wobei wir eine Verwechslung mit Konstrukten des ER Modelles vermeiden wollen Deshalb sind ovale Boxen sowohl Programmschritten als auch dem Test vorbehalten Wir k nnen damit induktiv komplexere Programme konstruieren Sequentielle Ausf hrung von Programmen DO Pi Ein Programmschritt kann auf einen anderen Programm schritt folgen 00 Pi H DO P gt Verzweigung mit einer logischen Bedingung if o then P else Ps true Fin Programmschritt kann verzweigen unter einer Bedin 7 bo 21 IF a gung false po P VViederholte Ausf hrung mit einer logischen Bedingung DO P LOOP a Der Bequemlichkeit halber f hren wir auch eine Programm D0 P Al schleife ein Diese ist auch durch andere Konstrukte abstrak ter Maschinen ausdr ckbar LOOP a 4 Parallele Ausf hrung mehrerer Programme ohne Einschr nkung DO P PAR PAR DO Pk Programme k nnen parallel ausgef hrt werden Die parallele Do P Ausf hrung ist beendet wenn alle Programme beendet sind
117. Spezialisierungsbeziehung mit Content unterlegt werden k nnen Diese Parameter k nnen optional oder auch allgemein oder obligatorisch sein Wir k nnen die Spezifikation von Konzepten mit einem Definitionsrahmen unterst tzen oder durch ein Konzeptnetz der Form von Bild 7 Im allgemeinen wird diese Darstellung durch Konzeptnetze allerdings nicht ausreichend ber sichtlich sein Deshalb kann man nach einer anderen Darstellung suchen Wir benutzen neben dieser Darstellung auch eine graphische Darstellung durch erweiterte ER Modelle bei denen optional Para meter durch eckige Klammern Identifikationsparameter durch eine Unterstreichung und allgemeine Parameter nicht extra ausgewiesen werden Im Falle des Person Konzeptes k nnen wir drei wichtige Parameter auszeichnen die Charakteri sierung von Personen mit ihren Eigenschaften die Angabe des Beziehungsumfeldes der Personen und eine Darstellung des Kontextes Diese Aspekte sind durch entsprechende Logiken unterlegt Da wir Personen in einer gewissen Allgemeinheit behandeln wollen wird die Semantik und damit die Theorie mit einer epistemischen temporalen Logik spezifiziert Wir betrachten Personen nur im betrieblichen Umfeld und nur aufgrund der Aufgaben die durch das Informationssystem unterst tzt werden Da mit kann man das Person Konzept holzschnittartig durch eine allgemeine Spezifikation unterlegen der folgenden Form Person _charakteristik beziehung kontext 77007 E MpPerson 27757 _bet
118. Springer Berlin 1978 In German L A Maciaszek Database design and implementation Prentice Hall Sydney 1990 ir ei 0 BE 2 46 a a r Vie ii O In En nn et eo en Cee Oy CEO ee 44 r 184 Mok96 Mor03 MR92 MS95 Pae00 PBGG89 Pro72 Rah94 RG94 Rie99 Ris88 RS97 Sch96 Sim94 89 Tha91 Tha00 Tha01 Tha02 Tha03 Tsa89 Web95 YTS 99 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 DANKSAGUNG C Mok Designing business Hayden 1996 T Moritz Szenographie interaktiver informationssysteme BTU Cottbus Informatik Manuskript 2003 H Mannila and K J R ih The design of relational databases Addison Wesley Wokingham England 1992 K Mullet and D Sano Designing visual interfaces Prentice Hall Englewood Cliffs 1995 B Paech Aufgabenorientierte Softwareentwicklung Springer Berlin 2000 J Paredaens P De Bra M Gyssens and D Van Gucht The structure of the relational database model Springer Berlin 1989 V J Propp Morphologie des M rchens Carl Hanser Verlag M nchen 1972 E Rahm Mehrrechner Datenbanksysteme Grundlagen der verteilten und parallelen Datenbank verarbeitung Addison Wesley Bonn 1994 M Reingruber and W W Gregory The data modeling handbook John Wiley amp Sons New York 1994 J Rieckmann Component ware for supporting transport logistics In B Scholz Reiter H D Stahlmann a
119. TEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 35 k nnen Im klassischem Systementwurf wird diese Schicht meist bergangen und zu einem sp teren Zeitpunkt durch entsprechende Sichten Suiten hinzu gef gt Damit entsteht ein Systembruch den wir mit der expliziten Darstellung vermeiden k nnen Die Betrachtung der physischen Realisierung ist keine Aufgabe des Informationssystementwur fes und wird ebenso wie die Pflege und Einf hrungsschicht in diesem Buch nicht behandelt Die Verteilungs und die Sicherheitsaspekte sind orthogonale Aspekte und werden mit den Entwicklungs schritten verflochten Das Abstraktionsschichtenmodell in Bild 16 erlaubt eine Entwicklung von Informationssystemen im Zusammenhang Wir k nnen ein schichtenorientiertes Vorgehensmodell ebenso wie ein Modell anwenden das sich zuerst auf einen der Aspekte orientiert Motivations schicht Vor studie Gesch fts proze schicht Fein studie Aktions schicht Spezifikation der Verteilung Ent wurf Spezifikation derAnteraktivit t Konzeptionelle Schicht Imple men tation Spezifikation der Strukturierung Implementations schicht Spezifikation der Funktionalit t Bild 16 Das Abstraktionsschichtenmodell des Informationssystem Entwicklungsprozesses Die Spezifikationssprachen k nnen sich f r die Schichten und die einzelnen Spezifikationsteile stark unterscheiden Eine solche Sprachvielfalt ist jedoch nicht immer angeb
120. ULL fo 6 1 Fs falls s NULL VVir k nnen nun die folgenden blichen Aggregationsfunktionen einf hren Summierung in unterschiedlichen Varianten abh ngig von der Behandlung von Nullwerten e Summierung f r Klassen ohne Nullwerte sum Sreco Id e Summierung f r Klassen mit Nullwerten die durch die 0 ersetzt werden null sum STECO Ao 3 e Summierung fiir Klassen mit Nullwerten die durch die undef ersetzt werden null _ sum m STECO 4 7 blich ist die Anwendung der zweiten Option Z hlen der Objekte je nach Behandlung der Nullwerte F r Klassen ohne Nullwerte count sreco 1 e F r Klassen mit Nullwerten count srecp not 3 k null _ e Alternativ f r Klassen mit Nullwerten count under STECO under 4 Genutzt wird oft die zweite Option Bildung der maximalen bzw minimalen Werte in Abh ngigkeit von den Ordnungen f r NULL e Die leere Menge erlaubt keine Bestimmung von minimalen bzw maximalen Wer ten MAXNULL STECNULL Id mae bzw minNULL STECNULL Id min MAaXundef STECundef Id max bzw minundef ST ECundef Id min Diese Funktionen h ngen davon ab wie die Nullwerte in dom T eingeordnet wer den Bildung des Durchschnittes Die Durchschnittsbildung ist eine komplexere Funktion Es gibt daf r eine Reihe von M glichkeiten sum sum sum Po 77 ma 77 mall INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY
121. WICKLUNG IM CO DESIGN ZUGANG BY 6 143 die Repr sentation der Prozesse wie z B die Orientierung im Nutzungsraum auf der Grundlage von Feedback mentalen Modellen Metaphern zur Orientierung und Gestaltungsrastern und der Nutzungsdramaturgie der Interaktivit t durch Verfeinerung der Repr sentationen d h durch Unterlegung der Repr sentation mit gestalteri schen Mitteln Layout und Playout k nnen zum Nutzungsraum zusammengefa t werden Die Spezifikation des Gestaltungsrahmens wird somit durch folgende Spezifikation unterst tzt e Beschreibung der Benutzer der Akteure der Benutzergruppen e Spezifikation der Story e Spezifikation der Prozesse e Spezifikation des Content e Spezifikation der Repr sentation der Daten e Spezifikation der Repr sentation der Prozesse und e Angaben zur technischen Umgebung des Benutzers Der Gestaltungsrahmen legt die Gestaltungsgrundlagen fest Dabei werden e Prinzipien der visuellen Kollaboration e Prinzipien der visuellen Wahrnehmung und e Prinzipien der visuellen Gestaltung f r die konkrete Aufgabe verfeinert Dazu werden Gestaltungslemente und Gestaltungsmittel eingesetzt Die Umsetzung des Gestaltungsrahmens Wir erhalten eine Charakterisierung des Gestaltungsrahmens in tabellarischer Form Playout Layout Metapher Akteure Quali t t Funk tion Auf Dar Kol Funk Wahr Kom Bild der der Ziel Pola Adap gabe stel labo ti
122. all wird der Cluster Typ durch eine Raute mit den Attributen repr sentiert Objekte von Cluster Typen sind analog zu den Objekten anderer Typen durch entspre chende Zuordnung zu den Element Typen eingef hrt So k nnen z B die Objekte 6 LIM CottbusNet e V juristische Personen sein Relationship Typ h herer Ordnung Ein Relationship Typ i ter Ordnung besteht aus einer nicht leeren Folge von Entity und Relationship Typen einer Ordnung von maximal i 1 wobei ein Typ i 1 ter Ordnung sein mu einer Menge von Attributen und einer Menge von statischen Integrit tsbedingungen Eine Menge von der Struktur des Relationship Typen ist eine g ltige Menge wenn sie den statischen Integrit tsbedingungen gen gt Eine Iden tifikation kann sowohl aus den Elementen bestehen als auch aus den Attributen Es ist mitunter vorteilhaft ber Relationship Typen h herer Ordnung zu verf gen wie Bild 19 zeigt Im oberen Diagramm mu eine zus tzliche Integrit tsbedingung zwischen den Typen eingeschriebenIn und Vorlesung gelten weil man sich nur dann einschreiben kann wenn diese Vorlesung existiert Ein etwas komplexeres Beispiel ist das Beispiel in Bild 20 Eine Lehrveranstaltung z B eine Vorlesung wird durch einen Lehrstuhl angeboten Dieses Angebot kann angenommen werden Dann wird die Lehrveranstaltung geplant Wird sie auch gehalten dann werden die aktuellen Daten in der Klasse zum Typ GehalteneLehrveranst gespeichert Der Typus und die Raumz
123. allgemeine Architektur f r inkrementelle Evolution von Datenbanksystemen Inkrementelle Systeme verwenden eine spezifische Form der Sichtenkooperation Insert Daten werden den Partnern zur Verf gung gestellt und k nnen ver ndert werden wobei die Ver nderung ggf auch im Ursprungssystem durch berschreibung oder durch das Anlegen einer neuen Version mitgef hrt wird Ver nderungen im Ursprungssystem werden i a auch mit der nderungsgeschichte bzw dem nderungskuvert gef hrt Injektion Daten werden den Partnern zur Verf gung gestellt und k nnen nicht ver ndert werden Werden diese Daten im Ursprungssystem ge ndert dann k nnen die Ver nderungen bei den Partnern je nach Vertrag nachgezogen werden oder auch nicht ver ndert werden Im letzte ren Falle werden die urspr nglichen Daten zur Wahrung der Konsistenz im Ursprungssystem s E DESE SPE A gue INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 171 Diese Schemakomponenten werden mit zwei Sichtenkooperationsformen unterst tzt Injektionsformen unterst tzen die Injektion von Daten in Partnersysteme Die Struktur ist durch eine Sicht Set Ys auf die exportierende Datenbank gegeben die in eine Sicht S der importierenden Datenbank eingebettet werden kann Die Funktionalit t O777 So der Sicht des exportierenden Systemes wird ebenso in die Funktionalit t Nor des importierenden Systemes eingebettet wobei alle Modifikationsoperationen aller
124. andensein von Zeitschranken oder bei Synchronisie rung auf Ein Proze kann nicht rechtzeitig ausgef hrt oder ein Resultat kann nicht rechtzeitig bertragen worden sein Au erdem kann der Abstimmungsproze oder die Zeitmessung fehlerhaft sein Skalierbarkeit Ein verteiltes System soll invariant gegen ber Ver nderungen in der Anzahl der Res sourcen und Benutzer sein Skalierbarkeit erfordert die L sung einer Reihe von Problemen wie z B die folgenden Kostenkontrolle der physischen Ressourcen Falls das verteilte System sein Leistungsspektrum aussch pft sollte eine Erweiterung m glich sein ohne eine Re Modellierung Re Implementation oder Austausch der Infrastruktur vornehmen zu m ssen Wird eine Erweiterung notwendig dann kann diese Erweiterung ohne Kostenexplosion realisiert werden Kontrolle des Leistungsverlusts Mit der Erweiterung des Systems soll der Anstieg der Kosten kontrollier und absch tzbar sein Durch eine entsprechende Architektur des Systems wie z B hierarchische Strukturierung kann der Leistungsverlust minimiert werden Verhinderung des Aussch pfens der Ressourcen Ressourcen wie Adre und Namensr ume soll ten sich beliebig erweitern lassen sobald der Bedarf ansteigt Vermeidung von Leistungsengp ssen Sind einige Komponenten eines verteilten Systems dauer haft an der Leistungsgrenze dann mu eine effektive und einfache Abhilfe m glich sein Leistungsengp sse kann man durch Replikation und kontro
125. arbeit Ein typische Form dieser Zusam menarbeit kann man in Videokonferenzen beobachten Verschiedene Content Objekte und synchrone Zusammenarbeit CASE Werkzeuge realisieren diese Art der Zusammenarbeit Verschiedene Content Objekte und asynchrone Zusammenarbeit Diese Zusammenarbeit ist z B f r elektronische Post typisch Charakterisierung nach Kooperationsvertrag Der Kooperationsvertrag dient dem Abgleich der Interessen der kooperierenden Benutzer Es werden sowohl Absprachen zu den Inhalten als auch zu den zu w hlenden Szenario sowie die Einordnung in Arbeitsr ume und Zeitr ume getroffen Art des Zusammenwirkens Kollaboration basiert auf einer expliziten oder impliziten Kommunikation auf Regeln des Zusammenwirkens und einer Dramaturgie des Zusammenwirkens Die Art des Zusammenwirkens wird oft in kanonischer Form vorgegeben In diesem Fall wird das Zusam menwirken durch kleine Szenario bestimmt die miteinander kombiniert werden k nnen Die Art des Zusammenwirkens wird oft mit einem Vertrag der Kollaboration gekoppelt Be standteile des Vertrages sind die klassischen juristischen Fallfragen Wer arbeitet zusammen wie mit wem zu welchem Gegenstand was 2 45 t nT an ee mmr amp 1 INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG 8 133 Diese Fallfragen verallgemeinern wir zu Spezifikationsrahmen f r die Art des Zusammenwirkens Die Bezie
126. aring Ein verteiltes System ist gekennzeichnet durch e eine Anwendungsschnittstelle f r verschiedene Endbenutzer e eine Validierungsfunktion zur Analyse der Datenanforderungen e eine Transformationskomponente zur Berechnung der Anforderungen an die Komponenten e eine Anfrageoptimierung die die Verteilung ber cksichtigt e ein Input Output Interface f r die Daten e eine Formatierungsfunktion zur Anpassung der generierten Daten an die Benutzeranforderun gen e ein Sicherheitsmanagement um Datensicherheit zu gew hrleisten e Backup und Wiederanlauffunktionen e eine Datenbankadministration e eine Steuerung f r den konkurrierenden Zugriff ber das Netz und e eine Transaktionsverwaltung Damit besteht ein verteiltes DBMS aus Rechnern denen Knoten zugeordnet sind einem Kommuni kationsnetzwerk zur Verbindung der Knoten aus einem Netzwerk Hard und Software aus Transak a zn an eke u 2 5x u2 asbauu n Tul TTNM 158 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 8 VERTEILUNG TP ER ommunikations netzwerk DP Lokales DBMS DP Lokales DBMS Bild 63 Grunds tzliche Architektur verteilter DBMS Die verteilte Datenbank pr sentiert sich gegen ber den Endbenutzern bzw Anwendungsprogram men wie eine zentrale Datenbank Dieses Ziel erfordert das Verstecken aller st renden Aspekte Die L sun
127. atenstrukturierung des Lastenhefts Es wird ein allgemeines HERM Diagramm mit den Haupttypen entwickelt Datenstrukturierung des Pflichtenhefts Es wird ein grobes HERM Diagramm mit entsprechenden In tegrit tsbedingungen angegeben das die Typen des Lastenhefts verfeinert Die Verfeinerung findet durch Spezialisierung der Typen Dekomposition strukturelle Erweiterung semantische Einschr nkung Separation von Aspekten und durch Instantiierung statt Zus tzlich werden weitere Typen eingef hrt Anwendungsschema Das Anwendungsschema repr sentiert alle Typen die f r den Anwender eine Bedeutung haben Die Typen stellen eine Verfeinerung der Typen des Pflichtenhefts dar oder sind neu eingef hrt Konzeptionelles ER Schema Auf der konzeptionellen Schicht wird ein detailliertes HERM Diagramm erstellt das u a auch f r alle Typen des Anwendungsschemas entsprechende Verfeinerungen RE 0 a 0 EA 05 285 1 ER S 52 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 4 STRUKTURIERUNG Logisches Schema Das HERM Schema wird in ein entsprechendes Schema des logischen Datenbank Modelles transformiert Es kann blicherweise ein objekt relationales oder relationales Schema aber auch eine Beschreibung als XML Schema oder DTD Datei document type definition sein Diese Schemata sind aufeinander abbildbar Demzufolge kann jede Entwurfseinheit einer h heren Schicht so wie in Bild 14 auf Seite 33 dargestellt einer M
128. ations und Diensteverwaltungssystemen Wir modellieren die Verteilung von Informationssystemen als Kollaboration oder Zusammenarbeit von Systemen Systeme oder Akteure arbeiten tempor r zur gemeinschaftlichen L sung von Aufgaben zusammen Sie bilden einen tempor ren Verbund oder eine tempor re Arbeitsgruppe verf gen ber gemeinsame Arbeitsinstrumente z B eine Objekt Suite und folgen einem Kollaborationsvertrag Die Kollaboration hat dabei drei Facetten Koordination Das ordnende Zusammenfassen die Abstimmung und die Zuordnung verschiedener Ar beitsaufgaben wird durch einen Koordinationsrahmen gew hrleistet Koordination bezeichnet also jene Teile der Kollaboration die zur Abstimmung aufgabenbezogener T tigkeiten notwen dig sind Kommunikation Die Abstimmung der Partner in einer Kollaboration wird durch einen Nachrichten austausch zwischen den Partner mit einem entsprechenden Austauschrahmen realisiert Kooperation ist die T tigkeit mehrerer Partner zur Verwirklichung eines Zieles bei der jeder Partner bestimmte Teilaufgaben bernimmt diese dem Partner gegen ber abrechnet und bei Nich terf llung der Verpflichtung eine kompensierende Teilaufgabe ausl st Kooperation bezeichnet also jene Teile der Kollaboration die zur Koordination und zur Vereinbarung gemeinsamer Ziele notwendig sind Diese unterschiedlichen Blickwinkel m ssen bei einer Modellierung der Verteilung mit unterlegt wer den Deshalb benutzen wir das Kollaborati
129. aturverfeinerungskopplung Implementationsver feinerungskopplung und Erweiterungskopplung Durch die Koh sion wird die Bindung zwischen den einzelnen kooperierenden Objekten beschrie ben Aufgrund der Modellierung existieren verschiedene Arten Die Funktions Koh sion zuf llige Koh sion logische Koh sion temporale Koh sion prozedurale Koh sion Kommunikationskoh sion sequentielle Koh sion und funktionale Koh sion geht von einer Bindung durch Operationen aus Die Typ Koh sion zerlegbare Koh sion mehrschichtige Koh sion nicht delegierte Koh sion und verbor gene Koh sion bewertet die Bindung der Objekte innerhalb einer Klasse Die Vererbungskoh sion folgt der Definition der Hierarchien unter den Typen und Klassen Im Rahmen der Forschungen zur Gruppenarbeit CSCW Computer supported cooperative work wurden Dialage nach unterschiedlichen Eigenschaften charakterisiert Charakterisierung nach Raum und Zeit Je nach Ort und Zeit sind unterschiedliche Dialoge m glich Gleicher Ort Anderer Ort Gleiche Zeitpunkte Elektronische Besprechung Videokonferenz Elektronisches Brett Konversationsunterst tzung Gemeinsamer Bildschirm Kooperatives Design Brainstorming Gruppeneditoren Zuh rerreaktion Verschiedene Zeitpunkte Gemeinsam genutzte Dateien Strukturierter Arbeitsflu8 Designwerkzeuge Elektrononische Post Nachrichtenbrett See ve 0 x 685 0 d is E 0 See 1 ee nn x
130. aum eine Kollaborationsunterst tzung oder auch Ar beitsspeicher bereitstellen Die Kollaborationsunterst tzung basiert auf einer Architektur zur Unterst tzung der Kollaboration Die Kollaboration erfordert ggf auch langlebige Transaktionen und auch das Anlegen von tempor ren Klassen sowohl beim Benutzer als auch beim Server Die Kollaboration kann ber unterschiedliche Kan le erfolgen Leistung Werkzeuge stellen Funktionalit t in einer bestimmten Qualit t und mit einer be stimmten Kompetenz zur Verf gung Die Spezifikation der minimalen Qualit tsanforde 228 225 x 02 00 4 48 0 c ee ne gt i ne da 2 2 pb s s lo INFORMATIONSSYSTEM ENTWICKLUNG IM Co DESIGN ZUGANG 8 139 Layout Das Benutzungsinterface soll dem Akteur ein einfaches Agieren zur Bew ltigung seiner Aufga ben gestatten Es kann in allgemeiner Form die Art des Benutzerinterfaces durch einen Layout Guide vorgegeben werden Layout Guides k nnen sich an die corporate identity des Betriebes anlehnen k nnen unterschiedlichen Gestaltungsrichtlinien folgen und auch durch entsprechende Regelwerke an den Kontext und die Benutzung adaptiert werden Die Gestaltung von Schnittstellen sollte den oben dargestellten Prinzipien der Ergonomie und der Psychologie folgen Dazu geh ren auch Prinzipien der visuellen Gestaltung Das Layout wird durch eine Spezifikation folgender Parameter vorgegeben Metapher Ein System soll sich dem Benutz
131. be von Gestaltungsrahmen werden sich auch st rker Typen von Interfacewerkzeugen heraussch len wenn sich durch XML allgemeine Standards wie z B SVG zur Graphikdarstel lung durchsetzen Der Typ von Interfacewerkzeugen wird durch eine Darstellung folgender Parameter spezifiziert Funktion Die Werkzeuge k nnen einfache Funktionen zur Verf gung stellen z B wie HTML mit einer Reihe von Um gebungen e komplexe Funktionen bereitstellen mit denen z B auch ein Playout von Simulationen analoge und digitale Video und Audio Dateien oder Kodierung Fehlerbehandlung etc unterst tzt werden Kommunikations Kooperations und Koordinationsfunktionen sowie Austauschfor mate unterst tzen e Bindungsfunktionen mit denen Informationen und Content Suiten eingebunden wer den k nnen besitzen und e Verwaltungsfunktionen zur Verwaltung und Weiterf hrung von Sitzungen und Ar beitsr umen anbieten Aufgabenklasse Durch die Werkzeuge werden bestimmte Aufgaben unterst tzt und ggf auch nicht unterst tzt Es sind die Aufgabenklassen zu charakterisieren die durch die Werkzeuge unterst tzt werden Paradigma der Darstellung Die einzelnen Funktionen der Werkzeuge erlauben unterschiedliche Darstellungen wie z B ereignisorientierte objektorientierte oder zustandsorientierte Dar stellung der Funktionsabarbeitung Kollaboration Die Funktionalit t der Werkzeuge kann ggf auch einem Benutzer seinen Schreib tisch einer Gruppe einen Arbeitsr
132. bge legt Deshalb sind hier auch Probleme zu l sen die f r die Sichtenintegration typisch sind Ein schwieriges Problem ist z B die Behandlung und Interpretation von Nullwerten Mit der Entwicklung der Akquisitionskomponente sind verschiedene Probleme zu l sen Eigentlich kann die Akquisition einfach beschrieben werden Man w hlt die ben tigten Daten aus l dt sie und integriert sie in das Datenbank Warenhaus Damit sind die unterschiedlichen Quellen zu mischen die Daten zu s ubern und zu standardisieren Die Datenextraktion schlie t das Streichen oder Gewinnen von Daten von einer Quelle mit ein Dazu ist auch eine Informationsverarbeitung notwendig Damit wird auch eine entsprechende Prozessorleistung notwendig Die Datens uberung basiert auf einer Qualit tskontrolle der Daten und schlie t die Identifikation zu s ubernder Daten mit ein Alle Typen von Datenproblemen die sonst f r Nullwertproble me blich sind treten auf inkonsistente fehlende unlesbare falsche tempor r unerreichbare partiell falsche Daten sowie einfache Schreibfehler Die Datenformatierung ist notwendig weil oft weder die Formate noch die unterlegten Datenty pen noch die Anordnung der einzelnen Elemente den Anforderungen entsprechen Man verglei che die Vielfalt von Darstellungen f r Kalenderdaten Das Mischen von Daten ist zur Verminderung der Redundanz im Warenhaus notwendig Dabei treten z T jedoch erhebliche Integrationsprobleme auf Die Sc
133. bjekt relationalen DBMS angewandt Die Repr sentation erfolgt auf der Grundlage von Sichten die im Kapitel 6 ausf hrlich dargestellt werden OLAP Zug nge verwenden oft den zweiten Zugang Die zweite Methode wird auch bei XML DBMS angewandt Die Redundanz Beherrschung ist nach wie vor f r beliebige Objektmengen wichtig Deshalb ist der erste Zugang vorzuziehen Wir unterst tzen diesen Zugang durch Einf hrung einer Sichten Suite INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG Motivations schicht Gesch ftsproze schicht Aktions schicht konzeptionelle Schicht Implementations schicht Bild 25 Die Arbeitsprodukte im Abstraktionsschichtenmodell f r die Strukturierung onzeptlandkarte Vorstudie Skizzierung Skizze Feinstudie Darstellung Ske Entwurf Entwurf Schema Implementation Transformation py 6 Lastenheft Daten R Pflichtenheft Daten Konzept Grober Typ R Anvendungstyp Anwendungsschema nn ER Schema logisches Schema T yP logischer Typ 53 54 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 5 FUNKTIONALIT T 5 Sprachen zur Darstellung der Funktionalit t Ein Mann der recht zu wirken denkt Mu auf das beste Werkzeug halten Bedenkt Ihr habt weiches Holz zu spalten Und seht nur hin f r wen Ihr schreibt Goethe Faust Vorspiel auf dem Theater Direktor Die Herang
134. bung der Sichten und der Verteilung PV Die Sichtenskizze beschreibt die einzelnen Sichtweisen der Anwender auf das Produkt in allgemeiner Form Die Elemente der Sich tenskizze sind allgemeine Konzepte aus der Anwendung die wir als ontologische Einheiten bezeichnen Die Verteilung wird durch den Vertragsraum grob skizziert und mit einer Dar 22 a d A e oo onu xd 2 r d Az di s ul 178 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 9 DOKUMENTATION Erganzende Festlegungen PW Es k nnen Festlegungen zum Prasentationsstil und der Benut zungsoberfl che Bildschirmlayout Drucklayout Tastaturbelegung Dialogstruktur Uber gabeformate und zur Qualit tszielbestimmung Kriterien G te Katalog getroffen wer den Vorteilhaft ist die Festlegung von globalen Testszenario und von Testf llen mit einer Darstellung des Verhaltens f r jeden einzelnen Testfall Au erdem kann die Entwicklungs umgebung Software Hardware Orgware und Entwicklungsschnittstellen festgeschrieben werden Erg nzungen betreffen auch Installationsbedingungen Schulungen Wartungspro bleme Normen Vorschriften Patente Lizenzen und das Benutzerhandbuch mit Anwen dungsszenarien und Anwendungsbeispielen Als Anhang zum Pflichtenheft sind Definitionen der Fachbegriffe auf der Grundlage eines Glossar bzw Begriffslexikons blich Die Fachabteilungen des Anwenders sind hierbei meist involviert Dokume
135. d Aktionen vornehmen und dazu Daten vom Format der Aktionssichten Suite verwenden Zwischen Story und Szenarien existiert ein Unterschied Die Geschichte ist das eigentliche Ge schehen Die Szenario bestimmen die Auswahl von Szenen und Szenenfolgen Jede einzelne Szene stellt ein Thema der Anwendung dar Im Falle unserer Beispielanwendung sind Themen Anga be von Vorschl gen zu Lehrveranstaltungen Zusammenstellung eines Stundenplanes bersicht ber ein Institutsprofil Die Szenario stellen einen verfeinerten Ablauf einer einzelnen Story dar Dabei wird es oft vorkommen da nicht eine einzelne Story zur Darstellung aller m glichen Szenario ausreicht sondern eine Menge von Stories die die Abl ufe in der Anwendung beschreibt In diesen Fall entwickeln wir den Raum der Stories den Story Raum Dieser Story Raum kann auch auf andere Art durchlaufen werden als in den angegebenen Szenario In diesem Fall entdecken wir L cken in der Darstellung der Anwendung Die Stories werden durch einen Plot in diesem Entwurfsschritt a a Bu 1 ee no Tees CLT ae TL x Oe ROPE 0 en RE x Lan 108 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 7 INTERAKTIVITAT Film Drama Erz hlung Musik wird oft nur eine einzelne Story zur Grundlage genommen In der Architektur sind Plots nichtlinear Plots umfassen e die Raumplanung und die Raumordnung fiir die Stories d h die Planung und den Ablauf der Szenen e den allgem
136. d design for database applicati ons Prentice Hall Upper Saddle River 1998 M H Brackett Data sharing Using a common data architecture John Wiley amp Sons 1994 L Brown Integration models Templates for business transformation SAMS Publishing New York 2000 J Barwise and J Seligman The logic of distributed systems Cambridge University Press Cam bridge 1997 E B rger and R Stark Abstract state machines A method for high level system design and analysis Springer Berlin 2003 S Ceri and G Pelagatti Distributed databases Principles and systems McGraw Hill New York 1984 P Dadam Verteilte Datenbanken und Client ServerSysteme Springer Berlin 1996 S Dustdar H Gall and M Hauswirth Software Architekturen f r verteilte Systeme Springer 2003 H Dre ler Datenstrukturentwurf Vom Faktenchaos zur Anwenderdatenbank Oldenbourg Verlag Miinchen 1995 A D sterh ft and B Thalheim Linguisitc based search facilities in snowflake like database sche mes Data amp Knowledge Engineering 48 1 177 198 2004 NV TU si 0 d ua n 1 s i q Ti om M d FP dd a a INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 8 183 Elm92 Emb98 00 Fer95 FS95 FvH89 Gil90 G1096 GR9A Gur00 Hal95 Hau00 Haw90 Hor99 HP97 IZG97 Kas03 KE96 KE01 KK93 KMOo3 KT95 Kun92 Leo92 LFe LL99 LLO3
137. d die Koordination Facetten der Kollaboration Eine andere Dimension von Facetten ist auch Verteilung und Interaktion Auch f r die Abstraktion k nnen wir unterschiedliche Facet ten unterscheiden Facetten des wie Modellierung Abbildung Verfeinerung und Facetten des wodurch Approximation konservative Approximation Die Strukturierung besitzt die Zachman Aspekte womit materialisiert Speicher Struktur Repr sentationsstruktur und abstrakte Strukturen wodurch repr sentiert direkte Darstellung und kodierte Darstellung wie konstruiert Basis Typen Konstruktor Arten und Abschlu bedingungen Je nach Wahl erhalten wir unterschiedliche Sprachen bzw Modelle wie das relationale oder auch objekt relationale Modelle Erzeugungsregeln und Materialisierungssprachen Diese vier Prinzipien werden in Zweigen der Informatik unterschiedlich akzentuiert So konzen triert sich der klassische Datenbankentwurf auf die Strukturierung verwendet eine Art der Abstrakti on die konservative Abstraktion und integriert die Kollaboration implizit im Schema Komponenten Diese Vorstellung haben wir leider bislang nicht in der Literatur nachweisen k nnen obwohl sie zur Folklore geh rt A PER a Gee 031 YT TT 1 4 as INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 7 werden innerhalb eines Schemas verschmolzen und sind dann Bestandteil einer gro en Strukturein heit Gegebenenfalls werden Aspekte der Verteil
138. d m glich e ConTracts sind komplexere Modelle und geeignet f r die Gruppierung von Transaktionen in eine Multitransaktionsaktivit t Menge von ACID Aktionen Schritte mit explizit spe zifiziertem Ausf hrungsplan Skript wobei die Ausf hrung Vorw rts Recoverable sein mu abgeschw chte atomicity e Langlebige Aktivit ten Long running activities basieren auf einem erweiterten ECA Mo dell Sie verwenden eine Menge von Ausf hrungsschritten die rekursiv andere Transak tionen enthalten und Kontroll und Datenflu Skripte Es wird eine explizite Kompensati on f r Transaktionen vorgegeben Das Konzept wird durch eine Kommunikation zwischen den Ausf hrungsschritten unterst tzt Es werden au erdem die Abfrage des Status einer Aktivit t und explizite Ausnahmebehandlung unterst tzt Es k nnen Korrektheits und Koordinierungsbedingungen angegeben werden Daraus werden Aufgabenflu modelle f r Multiaktivit ten abgeleitet Damit umfa t die Spezifikation eines Workflows die Aufgaben bzw Proze spezifikation als spezifische Art eines Prozesses bei Spezifikation der Struk tur wobei e die Menge von extern sichtbaren Ausf hrungszust nden e die Menge von legalen Transitionen dieser Zust nde und e Bedingungen die die Ausf hrung der Transitionen erlauben f r die Darstellung durch Zustandstransitionsdiagramme benutzt werden Jeder Proze hat eine interne Struktur und ist damit abh ngig vom Input und dem Zustand des l
139. de Programme terminieren exklusive Auswahl M bei der genau ein Programm zur Ausf hrung nichtdetermistisch aus gew hlt werden kann Synchronisation f 4 die eine parallele Ausf hrung mit einer Synchronisationsbedingung zul t und einfaches Mischen bei dem zwei alternative Programme verbunden werden k nnen Erweiterte Verzweigungs und Synchronisationsanweisungen sind mehrfache Auswahl bei der verschiedene Ausf hrungspfade gew hlt werden k nnen mehrfaches Mischen bei dem verschiedene Ausf hrungspfade gemischt werden k nnen Diskriminator bei dem verschiedene Ausf hrungspfade ohne Synchronisation gemischt werden k nnen wobei Teilprogramme nur einmal ausgef hrt werden n out of m Verbund bei dem verschiedene Ausf hrungspfade mit partieller Synchronisation ge mischt werden k nnen wobei Teilprogramme nur einmal ausgef hrt werden und synchronisierter Verbund bei dem verschiedene Ausf hrungspfade mit vollst ndiger Synchro nisation gemischt werden k nnen wobei Teilprogramme nur einmal ausgef hrt werden Strukturelle Steueranweisungen sind Wiederholung bei der Programme beliebig oft ausgef hrt werden k nnen und implizite Termination die eine Beendigung des Programmes hervorruft Datenabh ngige Steueranweisungen sind statische Steueranweisungen deren Steuerung mit Bedingungen erfolgt die bereits zur Compi lezeit gepr ft werden k nnen statische Steueranweisungen deren Steuerung
140. der ggf auch weltweit die gleiche Semantik besitzen m ssen Der Benutzer kann nur entsprechend sei nen Erfahrungen fehlende Teile antizipieren Er soll vom Motiv auf die Absicht und von der Absicht auf das Ziel schlie en k nnen Sind wesentliche Teile unverst ndlich dann kann er keine Schlu folgerungen ziehen Der Benutzer will Informationen die er noch nicht kennt d h es werden neue Informationen geliefert die sich anhand des Allgemeinwissens einordnen lassen Bei der Vermittlung von z T komplexen und tiefgr ndigen Inhalten ist 5 ot x d ee HE ERS o A t M a o 00 DER a zi xu a INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 8 109 Plausibilit t Ein Szenario mu plausibel sein und sollte sich an die gewohnten Arbeitswei sen anlehnen Der Stellenwert der Plausibilit t und des Realismus ist dabei umgekehrt proportional zum Auffassungsverm gen und Ausbildungsgrad Identifikation Mit einem Szenario mu auch das Interesse der Akteure geweckt und wach gehalten werden F r die Akteure mu eine enge Verflechtung zwischen dem Inhalt den Prozessen und den Dialogen einerseits und der Arbeitsweise anderseits erreicht werden Ein Benutzer soll sich mit seinem System identifizieren k nnen Die Identifikation hat eine ganze Reihe von erw nschten Auswirkungen und ist ein wesentlicher Grund f r die Akzeptanz eines Systemes F r das Szenario bewerten wir abschlie end seine Q
141. dere Objekte integrierbar In unserem Hauptbeispiel sollte z B die bernahme von Kursbeschreibungen m glich sein Integration in den eigenen Arbeitsraum Es k nnen Sichten auf das Content Objekt und die Sit zung in den eigenen Arbeitsraum des Benutzers eingelagert werden Weitergabe von bearbeiteten Objekten an andere Akteure Eine Weitergabefunktion von Arbeits resultaten kann in analoger Form wie die Druckfunktion realisiert sein In analoger Form k nnen auch Importfunktionen bereitgestellt werden Sie unterst tzen den Akteur in den entsprechenden Dialogschritten und basieren auf folgenden Funktionen bernahme von Objekten in die Datenbank Eine Eingabe sollte nicht nur textuell erfolgen son dern durch Funktionen zur bernahme von Dokumenten oder Mengen von Objekten un do A L ER x gt gt ae Se RA Le 313 A S na An 42 Zen Ay 90 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 6 SICHTENSUITE Integration in das Content Objekt Das Content Objekt kann Parameter haben die durch eine Eingabe von Daten oder Objekten instantiiert werden k nnen Damit ist auch eine Erwei terung des aktuellen Content Objektes der aktuellen Sitzung m glich Integration in den eigenen Arbeitsraum Es k nnen in vorher vereinbarten Formaten durch ent sprechende Importfunktionen auch entsprechende Content Objekte des Benutzers benutzt und in den Arbeitsraum eingebracht werden Integration in die Arbeitssichten De
142. des Namens einer Person der Baum in Bild 18 zeigt Diese hierarchische Struktur erm glicht auch Elemente auszuzeichnen z B mit der Eigenschaft Element eines Schl ssels zu sein So kann z B zum Schl ssel das Teilattribut Name Vornamen Familienname Geburtsname hinzugenommen werden wobei wir als Abk rzungsregel benutzen da mit dem Nennen eines Bezeichners auch der damit verbundene Teilbaum mit bernommen wird z B f r Vornamen auch die gesamte Teilstruktur Vornamen lt Vorname varstring15 Benutzung stringl gt IM iz MEERES EHEN OR an 41 60 INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 45 Name EN 1 Familienname Geburtsname f Zu gt varstring30 varstring30 Titel wor 1 Benutzung 1 Familientitel string AkademischeTitel varstring10 varstring15 varstring10 Bild 18 Semi strukturiertes Attribut Name Entity Typ Eine Seiendenklasse Objektklasse Entity Klasse im weiteren wird durch einen Entity Typ dargestellt Ein Entity Typ besteht aus einer nichtleeren Folge von Attributen und einer Menge von statischen Integrit tsbedingungen Der Prim rschl ssel wird direkt durch Unterstreichen der Attribute angegeben Ist die Menge der statischen Integrit tsbe dingungen leer dann kann sie auch weggelassen werden Eine Klasse von der Struktur des Entity Typs ist g ltig falls alle Integrit tsbedingungen gelten Wir folgen der klassisc
143. deutet zugleich auch eine Herausforderung an die derzeitige Tech nologie und bedarf einer Unterlegung durch entsprechende Spezifikationsmethoden wobei im wesentlichen vier Aspekte genauer untersetzt werden m ssen Portabilit t Da zu unterschiedlichen Zeiten unterschiedliche Plattformen verwendet werden kann durch eine entsprechende Portabilit t ein Gleichklang der Anwendung erreicht wer den Freiz gigkeit und Offenheit Das verteilte System ist erweiter und reduzierbar ohne Einbu en der Qualit t hinnehmen zu m ssen Die Schnittstellen enthalten keine verborgene Funk tionalit t und sind voll ver ffentlicht Erreichbarkeit Anwendungen sollen zu jeder Zeit von jedem Ort durch jeden zugelassenen Benutzer zu den besten Bedingungen mit ad quatem Content erreichbar sein Beweglichkeit Ein Benutzer kann sich mit seiner Plattform innerhalb eines Netzes fortbewe gen ohne Einbu en bei der Dienstqualit t hinnehmen zu m ssen Einem Benutzer ist das Andocken an einen Dienst ohne Einschr nkungen durch den Dienst erlaubt Sicherheit Klassische Sicherheitanforderungen sind e Vertraulichkeit Schutz gegen Offenlegung gegen ber nicht berechtigten Benutzern Ak teuren oder Systemen e Integrit t Schutz gegen Ver nderung oder Besch digung und e Verf gbarkeit Schutz gegen St rungen der Bearbeitung Neben diesen Anforderungen treten in verteilten Anwendungen aufgrund der Unsicherheit des Kommunikationsmediums zwei weitere
144. dies ein Parameter Aufruf choose Person Name Login Pa wort or Mitglied Name Login Pa wort Arbeitsgruppe or Akteur Name Login Pa wort Rolle or Anonymit t Damit werden die entsprechenden Sichten und Funktionen freigeschaltet Gleichzeitig wird die Konsistenz in der Benutzung entsprechend der gew hlten Kooperationsbeziehungen gewahrt Damit wird ein Benutzer auf unterschiedliche Art unterst tzt Person als zentraler Einwahlpunkt in den Arbeitsplatz In diesem Fall werden unter Ber cksichtigung der Rollen Rechte und des Portfolios der Arbeitslatz mit den Containern und Content Objekten d INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 101 Mitglied einer Arbeitsgruppe mit einer Einwahl in die Arbeitsgruppe den f r die Arbeitsgruppe frei gegebenen Arbeitspl tzen den entsprechenden Containern und den aktuellen Arbeitstreffen Akteur mit einer Einwahl ber die Person und die Rolle dem Freischalten von entsprechenden Teilen des Content Objektes zur Bearbeitung von Daten etc Anonyme Benutzung der freigegebenen Nachrichten Content Objekte und allgemeinen bersichten Das Content Objekt SO Arbeitsplatz Akteur Bernhard Thalheim thalheim x x xe Arbeitsgruppenleiter generiert dann z B die Content Objekte Container und Schreibtische die der Autor auf seinen Ar beitsplatz als Arbeitsgruppenleiter besitzt Auf analoge Art k nnen der Content Typ Pers nlicher Arbeitsraum und der Sitzungs Typ S Pe
145. dig innerhalb des globalen Schemas integriert Die Integrit tspflege ist einfacher als beim GAV Ansatz Es wird allerdings eine vollst ndige Integrierbarkeit vorausgesetzt die in der Praxis selten gegeben ist Der Berechnungsaufwand zum Abgleich ist erheblich Es m ssen spezielle Kollaborationsvertr ge realisiert werden die auch den unterschiedlichen Semantikauffassungen der lokalen Anwendungen Rechnung tragen m ssen Damit entstehen Systeme die in der Komplexit t gr er sind als Systeme der K nst lichen Intelligenz Anfragebearbeitung setzt Logikkomponenten voraus Au erdem m ssen die lokalen Schemata meist restrukturiert werden womit eine Reprogrammierung erforderlich wird Global and Local A s View Integration GLAV Es werden sowohl eine globale Datenbank als auch die lokalen Datenbanken gepflegt Dieser Zugang stellt einen allgemeineren Zugang dar 2 a osa ee AY 168 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 8 VERTEILUNG Die strukturelle Integration ist als Tripel I G G M bestehend aus einem globalen Datenbank schema G iiber einer Sprache Ag einer Kollektion G von lokalen Datenbankschemata S iiber einer Sprache As und einer Abbildung zwischen G und definiert Die Architektur von Systemen die ber strukturelle Integration realisiert werden ist in Bild 69 dargestellt Lokales Lokales Lokales externes externes externes Schema 1 Schema 2 Schema n Gl
146. dings gestrichen werden Insertformen unterst tzen das Einf gen von Daten des exportierenden Systemes in Daten des impor tierenden Systemes Die Struktur S Ys und die Funktionalit t der Sich ten des exportierenden Systemes wird dabei in die Struktur S Sgr und die Functionalitat O So des importierenden Systemes eingebettet Kann eine Modifikation im importieren den System auf den importierten Daten vorgenommen werden dann wird die Funktionalit t o rsert So um entsprechende Versionierungsfunktionen erg nzt Verteilte Datenbank Systeme in der Data Warehouse Architektur Viele Unternehmen haben Unmengen an Daten ohne daraus ausreichend Informationen und Wis sen f r kritische Entscheidungsaufgaben ableiten zu k nnen Die Zusammenf hrung Integration und Verdichtung Aggregation von Daten aus mehreren i Allg heterogenen Quellen in einer zentraler Datenbank ist deshalb von gro em Nutzen Damit kann eine schnelle Reaktion auf sich ndernde Marktanforderungen erfolgen Zugleich entstehen damit komplexe mehrdimensionale Aggregations aufgaben bei denen auch unterschiedliche Zeitpunkte der Datenerhebung des Einbringens und Va lidierens zu ber cksichtigen sind Die umfangreichen Anfragen und Datenmengen k nnen meist nur mit parallelen DBS bew ltigt werden Ein Data Warehouse oft auch als Daten Warenhaus bezeichnet stellt die n chste Entwicklungs etappe f r breit benutzbare Datenbanksysteme dar Im Pr
147. dlichen Facetten k nnen gleichzeitig und in unterschiedliche Symmetrierichtungen wirken und sich komplement r erg nzen wie in den Beziehungen Fachmann Laie und Mitarbeiter Vorgesetzter Neben den semiotischen Aspekten erfordert auch eine Spezifikationsmethodik eine explizite Wi derspiegelung des Pragmatismus Der Pragmatismus ist die Lehre nach der sich das Handeln und Denken am praktischen Leben orientiert und diesem dient Durch den Pragmatismus werden pragma tische Annahmen determiniert bliche pragmatische Annahmen sind die Auswahl der Sprache die Selbst Beschr nkung bei der Benutzung der Sprache die Wahl der Begriffe und ihrer Assoziationen sowie die Wahl der Darstellungsmittel im Falle einer Auswahlm glichkeit Typische pragmatische und nicht dokumentierte Annahmen sind die Art der Attributdarstellung die Auswahl der Wertebereiche FAS Ss E O i EEEE h PE E SE ia A E R 4 gt s 207 es Se ae ENEE eee 6 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 1 EINFUHRUNG Normalform die nur atomare Attribute zul t wobei der Begriff des Atoms je nach Modellierungs urteil auch variieren kann Postleitzahlen werden oft als Atom zugelassen obwohl sie bereits aus Komponenten wie Zustellbereich und Zustellbezirk zusammengesetzt sind Pragmatische Annahmen bilden Tatsachen Handlungsweisen Erfahrungen M glichkeiten Potenzen und auch Fertigkeiten aus dem Anwendungsgebiet entsprechend de
148. dule schicht Programme Transaktionen red Procedurds Datenbank Maschine Bild 26 Die Arbeitsprodukte im Abstraktionsschichtenmodell f r die Funktionalit t 56 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 5 FUNKTIONALIT T Die Abstraktionsschichten werden in Bild 26 illustriert Es existieren viele Modelle zur Darstellung der Prozesse und wenige Modelle zur Darstellung der dynamischen Semantik Formular orientierte Sprachen erlauben die Modellierung von Folgen von zusammenh ngenden Akti vit ten Mit Ablaufmodellen kann der Lebenszyklus eines Datenbank Objektes dargestellt wer den In einer Form Definition Component werden die Objekte selbst beschrieben Mit der Do cument Flow Component wird der Datenflu beschrieben Die Document Transformation Com ponent erlaubt die programmiersprachliche Beschreibung der Aktivit ten Aktivit ten k nnen selbst zu Gruppen zusammengefa t werden Verschiedene parallele Berechnungen sind m glich Flu orientierte Sprachen modellieren formale Handlungen als Fl sse von Objekten und Mitteilungen Aktivit tengraphen bzw Vorgangskettendiagramme Proze modelle und Beschreibungen von Lebenszyklen erlauben die Beschreibung von komplexem Verhalten Wir w hlen hier einen ereignis orientierten Zugang Der Zusammenhang von Entities und Ereignissen wird durch Ereignisdiagramme in Petri Netz Darstellung Ereignisse und Sichten mit Input Output in Eventknoten dargestellt Knoten sind Ereigni
149. e Ein und Ausgabe Eine Sicht entspricht dann einer oder mehreren Aktionen Damit wird f r die Szenarien auch die Darstellung von Motiv Absicht und Ziel weiter verfeinert Ein Motiv kann zu einer Absicht f hren Einer Absicht liegt gew hnlich ein Wunsch zugrunde ein bestimmtes Ziel zu erreichen Jede Aktion f hrt zu einem meist erw nschten Ergebnis Hinter jeder Absicht steckt ein Ziel Keine Aktion erfolgt ohne Grund Das Motiv ist die Ursache der Aktion Zwischen Ursache und Wirkung besteht eine direkte Verbindung Absichten haben verschiedene Eigenschaften sind direkt indirekt bewu t unbewu t freiwillig unfreiwillig offensichtlich oder versteckt Kann eine Absicht nicht verwirklicht werden entsteht ein Konflikt oder evt auch nur ein Gegensatz Das Ziel orientiert auf ein in der Zukunft liegendes Ereignis das durch eine Absicht herbeigef hrt werden soll Beide Kategorien k nnen beliebig weit auseinander liegen Zwischen den Aktionen gibt es Verkn pfungspunkte Absichten k nnen auch von einer Gruppe von Akteuren bzw von Akteuren mit verschiedenen Rollen gleichzeitig getragen werden Ein Szenario mu auch akzeptabel sein Damit werden Benutzerbed rfnisse anhand der Spezi fikation des Szenarios gepr ft Dabei konzentrieren wir uns auf folgende Probleme Verst ndlichkeit Jedes Szenario und jede Szene mu verstanden werden Deshalb ist Klar heit und Verst ndlichkeit oberstes Gebot wobei die Inhalte f r alle Anwen
150. e 134 Kollaborationsrahmen Kollaboration Art des Zusammenwirkens Arbeitsplatz Form Rollenl Formie Raum Ver Bezie Arten Diskurs Ak Gruppe Rechte Port Organi rung Zeit trag hungen typ teure folio sation wird nun aufgesplei t in drei Kollaborationsrahmen die unterschiedliche Facetten der Kollaborati on des Zusammenwirkens und des Arbeitsplatzes darstellen Wir k nnen dieses Aufsplei en in einer Tabelle oder wie auf Seite 157 durch ein Arbeitsblatt darstellen Da die Darstellung als Arbeitsblatt kondensiert ist wenden wir uns zuerst der Darstellung durch Tabellen zu und untersuchen die Fa cetten der Kollaboration einzeln Mit der Vereinheitlichung und den einzelnen Kollaborationsrahmen erkennen wir au erdem welche Aspekte eine genauere Untersetzung bei der Spezifikation erfordern Der Kommunikationsrahmen stellt die Austauschformen zur Verf gung Wir k nnen hierbei auf der ORB Architektur aufsetzen Durch die Object Management Group OMG wurde die in Bild 59 und Bild 60 dargestellte Object Management Architecture OMA verabschiedet Sie gestattet eine h here Interoperabilit t durch standardisierte Zugriffsschnittstellen Die Schnittstellenbeschreibung erfolgt durch IDL Interface Definition Language Der Object Request Broker ist der Vermittler in der Client Server Kooperation zwischen Objekten Ein Aufruf besteht aus dem Tripel Operations
151. e Attribute ist die Lookup Notation look R Ri n m quivalent zur verallgemeinerten Kardinalit tsabh ngigkeit card R R R n m In unserem Beispiel gilt z B die Einschr nkung da erst dann ein Eintrag in die Klasse legtab gef hrt wird wenn der Student eine Vorlesung erfolgreich abgelegt hat Die Lookup Bedingung look legtab Ablageform 0 2 stellt dar da nur Pr fung und Schein bzw Schein und Praktikum bzw Pr fung und Praktikum absolviert werden m ssen Diese Bedingung ist quivalent zu card legtab Student Vorlesung 0 2 Eine Kardinalit tsbeschr nkung card R R 0 1 ist aquivalent zur funktionalen Abh ngigkeit R Ri gt R Eine Lookup Kardinalit tsbeschr nkung look R 0 1 ist quivalent zur funktiona len Abh ngigkeit R R Ri gt R Weiterhin k nnen wir z B fordern da nur solche Vorlesungen als gehalten gelten die auch zu studentischer Beteiligung gef hrt haben Dies wird durch card legtab Vorlesung 1 n dargestellt Eine strengere Bedingung ist da dies auch f r das Semester gelten mu Dann k nnen wir spezifizieren look legtab Student 1 n bzw card legtab Vorlesung Semester 1 n F r Relationship Typen mit eigenen Attributen ist die Lookup Notation in verschiedenen Formen definiert DBIV S82002 9 DBI WS2002 3 Compiler SS2002 PB Schein Pr fung Praktikum Informatik II WS2002 BvB Informatik III WS2003 8 Antje B rb
152. e Gesamtheit der Dinge wird unter Ber cksichtigung der Beziehungen untereinander model liert e Aussonderung Separation Spezialisierung e Verallgemeinerung Generalisierung von Gemeinsamkeiten und e Aggregation zur Darstellung komplexerer Daten mit entsprechenden Operationen Die Spezifikation der statischen Semantik d h durch einschr nkende Bedingungen f r wirk lichkeitsgetreue Nachbildung der Anwendung wie e die eindeutige Bestimmung aller Objekte durch Schl sselbedingungen e die Hierarchie der Objekte Aussonderungsbedingungen specialization IsA Verallgemei nerungsbedingungen partition constraints uniqueness constraints e und Bedingungen f r Beziehungsklassen wie die folgenden e Darstellung eines funktionalen Zusammenhangs viele eins Bedingung e Bedingungen zur Assoziation mit Komponentenobjekten Seinsbedingung existence constraint und e Verweisbedingungen auf Objekte der Komponentenklassen sowie e allgemeine Bedingungen inh rente Bedingungen des Modells wie die folgenden e Gesamtheitsregel universe of discourse d Torm en n zen l INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 43 Sichten und abgeleitete Begriffe sind erschlie bare Objekte und werden durch Anwendung von Spezifikationen aus den Objekten der Datenbank erzeugt Das allgemeine Vorgehen der statischen Datenbankmodellierungssprachen l t sich somit wie folgt charakterisieren e Typen sind ber ihre Typausdr c
153. e Pr fmechanismen sind Pr fsum men der Kodierungstheorie und Hilfssichten die zur Modifikationsf higkeit von Sichten bei nicht modifizierbaren Sichten verwendet werden Maskierung von Fehlern Fehler k nnen durch erh hte Funktionsredundanz wiederholte Ausf hrung oder bertragung oder Datenredundanz RAID Speicherung abgeschw cht werden Tolerierung von Fehlern Die Akzeptanz von Fehlern durch die Benutzer oder durch die Systeme ist ein Ausweg aus dem Entstehen von Fehlern Wiederherstellung nach Fehlern Die Wiederherstellung eines korrekten Systemzustandes ist f r DBMS hinreichend gel st Der Hauptmechanismus zur Behebung von Fehlern sind Mehrphasen Commit Protokolle und kompensierende Transaktionen die bereits als Elemente der Funktionalit t von Informations systemen vorgestellt wurden Sicherheitsmodell Die Sicherheit kann durch entsprechende Datenbanktechniken unterst tzt werden Sicherungssichten Die Benutzer arbeiten grunds tzlich nur auf Sichten nicht aber auf den Ba sisdaten Integrit tspflege Die Integrit tsbedingungen werden zusammen mit den Pflegestrategien spezifi ziert und durch entsprechende Prozeduren unterst tzt So kann z B eine Zusammenfassung von Funktionen in stored procedures eine Pflege der Integrit t unterst tzen Datenbankmonitor Es wird durch einen Monitor ein Abzug des Systemzustandes visualisiert Gleichzeitg werden entsprechende Eingriffsroutinen bereitgestellt Diese Verfah
154. e Unterst tzung f r die Zusammenarbeit in Arbeitsgruppen erfolgen Damit soll ein Content Typ Arbeitsplatz auch die Zusammenarbeit in Arbeitsgruppen und die Publikation der Resultate der Zusammenarbeit gew hrleistet werden Wir unterscheiden aktive Content Objekte aktivierte Content Objekte und passive Content Objekte und entwickeln Kooperationsvertr ge zwi schen den Objekten Prozesse und Dialoge der Content Objekte k nnen sich auch gegenseitig bedingen blockieren abweisen und starten Wir unterscheiden verschiedene Arten von Kopplungsmechanismen die auch im Kombination verwendet werden k nnen e Bei einer Kopplung im Story Raum werden die gleichen Daten interaktiv verwendet Die Ope rationen sind durch Interaktion gekoppelt Dazu existieren verschiedene Kopplungsmethoden interne Kopplung globale Kopplung externe Kopplung Kontrollflu kopplung Wanderdaten kopplung und Parameterkopplung e Die Container Kopplung erlaubt nur ein Zusammenspiel der Content Objekte unterschiedlicher Container Es k nnen verschiedene Grade der Kopplung unterschieden werden versteckte Kopp lung verstreute Kopplung und spezifizierte Kopplung e Die Kopplung durch Kooperation der Content Objekte im Sinne der Sichtenkooperation folgt der hierarchischen Struktur der Typen des Schemas Je nach Erzwingungsmechanismus un terscheiden wir nderungskopplung Signatur nderungskopplung bzw Implementations nde rungskopplung Verfeinerungskopplung Sign
155. e Zugriffsmengen zu berstehen empfiehlt sich eine gr ere Verteilung und eine mehr stufige Sichtenarchitektur F r die Zugriffskomponente sind eine Reihe von schwierigen Problemen zu l sen Der Zugriff ist unterschiedlich Er entspricht den Anforderungen einfacher zuf lliger Benutzer und auch denen von Profis Damit sind eine Reihe unterschiedlicher Zugriffskomponenten je nach Anwendungsfall vorzusehen Einfache Ad Hoc Schnittstellen wie die traditionellen Anfragemanager QBE QBF QMF MS Query und Anfragemanager anderer Produkte Excel sowie die Reportgenerato ren von verschiedenen Datenbanktools Auf das Warenhaus zugeschnittene Zugriffsmethoden zur einfachen Arbeit mit dem Wa renhaus Ausgekl gelte Auswertungsprogramme zur Visualisierung von Zusammenh ngen zur stati stischen Analyse zum Surfen in Querverweisen etc mit Methoden der k nstlichen Intelli Es xas Rn 48 4 1 174 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 8 VERTEILUNG Autonome externe Anwendungen wie z B Gesch ftsanwendungen Durch R ckkopplungskomponenten kann auch auf die Ursprungssysteme bei auftretenden Pro blemen durchgegriffen werden Einfache Ad Hoc Schnittstellen sind f r den schnellen intuitiven Zugriff auf die Datenbest nde ein absolutes Mu Ausgekl gelte Programmpakete die bereits f r statistische Anwendungen und zur Visualisierung existieren sollten integrierbar sein Einfache Schnupperan
156. e zur Darstellung der Interaktivit t sollen eine Beschreibung der Anwendung aus der Sicht der Benutzer erm glichen Deshalb wird die Interaktivit t als Raum von Handlungsabl ufe der Benutzer oder ihrer Abstraktionen als Akteure d h als Story Raum beschrieben Dieser Story Raum fu t auf Szenen zur Beschreibung eines generellen Schrittes der Anwendung und auf Dialogschritten zur Beschreibung der einzelnen Aktionen Produkte zur Darstellung der Unterst tzung der Verteilung sind im Rahmen von Anwen dungen der Informationssysteme Sichten auf die Datenbanksysteme Dienste zur Bereitstellung der erweiterten Sichten und deren Austauschrahmen Wir wollen diese Entwicklungsresultate auf unterschiedlichem Abstraktionsniveau darstellen Wir k nnen jeweils die Resultate mit der Abstraktionsschicht verbinden Dann sind die Abstraktions schichten mit folgenden Entwicklungsresultaten verbunden Motivationsschicht mit dem Lastenheft Gesch ftsproze schicht mit dem Pflichtenheft Aktionsschicht mit der Aktionsspezifikation und den vier Aspekten Anwendungsschema Nutzer Maschine Storyboard und Aktionssichten Suite Konzeptionelle Schicht auf Grundlage der konzeptionellen Spezifikation und der Beschreibung der vier Aspekte durch ER Schema Workflow Maschine Drehbuch und Sichten Suite Implementationsschicht auf Grundlage der logischen Spezifikation und einer Beschreibung der vier Aspekte durch logisches Schema Datenbank Maschine Inszenierung und
157. ehensweise zur Spezifikation der Funktionalit t Wir gehen von einer Einheit von statischen Gesichtspunkten grundlegende Seiende und Bezie hungen und dynamischen Gesichtspunkten aus Dynamische Gesichtspunkte der Anwendung lassen sich spezifizieren durch Operationen bzw Handlungen zur Darstellung des dynamischen Verhaltens wie e nderungsoperationen zur Ver nderung der Daten in der Datenbank e Retrievaloperationen zur Erschlie ung des Wissens aus der Datenbank ohne Ver nderung der Datenbank e einer Sprache zur Generierung von Programmen und e Rollenver nderungen von dargestellten Objekten dynamische Semantik auf der Grundlage von dynamischen Integrit tsbedingungen zur Darstellung von zugelassenen erwarteten und verbotenen Handlungsfolgen und Verpflichtungen innerhalb einer Rolle beschreiben welches Wissen zug nglich ist Sichten und welche Handlungsfolgen ausgef hrt werden m ssen evt unter Ber cksichtung von Ursachen aktive Elemente bzw d rfen evt unter Ber cksichtung von Voraussetzungen sowie Mitteilungen an einen oder den anderen Empf nger die sie ihrerseits verstehen und verarbeiten k nnen Ver nderungen im Wissen m ssen stets zu einer statischen Gesichtspunkten gen genden Aufz hlung f hren Somit m ssen Handlungen stets statisch abbildbar sein Das Seiende ist etwas das wirklich existiert Es kann seine Existenz unabh ngig von anderen beginnen und beenden Damit werden formale Handlungen des
158. ei nen Rollen mit seinen Rechten bei der Aufgabenl sung dargestellt werden Das Akteurmodel fa t folgende Eigenschaften zusammen Profil des Akteurs Arbeitsziele des Akteurs Sicherheitsprofil des Akteurs und Portfolio des Akteurs Wir trennen davon jedoch im Gegensatz zu Use Case die Beziehungen der Dialoge zu den Daten und zu den Funktionen Diese Trennung entspricht der klassischen Vorgehensweise und verhindert ein berladen der Konstrukte Damit sind au erdem auch die dort geforderten Ressourcenmodelle Or ganigramme Firmenstrategiemodelle etc nicht mehr notwendig Mit der Verbindung zu den Sichten erhalten wir eine Seiteninhaltsbeschreibung Der Story Raum Szenen Dialogschritte und Szenario Wir unterscheiden zwischen dem Teil eines Systemes der f r den Benutzer sichtbar ist und dem in ternen Teil eines Systemes der f r den Benutzer nicht sichtbar gemacht werden mu Nach Wegner s Theorie der interaktiven Maschinen werden damit unterschiedliche Aspekte erfa t Interaktive Ma schinen stellen die Interaktion eines Benutzers dar Sie unterliegen anderen Paradigmen als klassische Berechnungssysteme Input Output Str me Ein Benutzer reagiert auf den Output eines Systemes mit seiner Antwort Beobachtungen Glauben Bed rfnisse Intentionen und Aufgaben eines Akteurs bestimmen die Inter pretation des beobachteten Output des Systemes mit e Damit besitzt die Antwort des Akteurs auf den beobachteten Output eine intens
159. ein XML oder auch HTML Buch ersetzen Dieser Buchmarkt ist un bersichtlich und strotzt vor vorgespiegelter Einfachheit Unter den soliden Einf hrungen sticht KM03 hervor Zum Storyboarding gibt es leider auch meist nur Erz hlliteratur von Autoren denen eine sehr kleine Website als Illustration und Erfahrungshintergrund dient Zur Spezifikationstheorie verteilter Systeme auf logischer Sicht kann am besten ALSS03 DGH03 heran gezogen werden Auf h herem Abstraktionsniveau existiert unserer Beobachtung nach keine einzige Literaturquelle 9Die Bibliographie in Tha00 ist bereits l nger als 50 Seiten Slee a IE 2 a 1 X r 0 s me nr T2 T rz r 1 no a i Ya reso 1 r PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 1 EINF HRUNG B THALHEIM 18 usd AQUATIC PU eWIOTBSUSNPDIS FUNNIJ19A PUN 7D710174DLAIUT Lap BUNZINISLIJUN UazING UIazYIUG Toy SNOqIY q mp 33 rys un USINsINy yur umey A10I4g pun uSAAL IUSYUON IDPALIYDASJUT GunsayjJapopy U9I9P usyuauodwoyy pun m y qry ry rur soutoysAG m ff A s p CWAG BunjrazuaA sap Bumda q poyy u dun3urp qs eqrs ur yy q srureu 4p pun 98892014 oJloseq yy IPMTDUOHYUNnT sap Bund nq poyy u dun3urp qs ye rd qur HH oystyeys pun MPMYS SYIOISeq YA B nd nq poyy suro4sAg ZUR
160. einen Ablauf der Themen e Prinzipien zur Szenographie und zum Aktionsraum e die Aktionen der Darsteller und Akteure e Prinzipien der Komposition und des Klangbildes die als Qualit tsparameter dargestellt werden k nnen und e Prinzipien der Akzeptanz und Aufnahme in der Dramaturgie der Musik Melodie und Rhythmus Es ist offensichtlich da nicht alle Plots in der gleichen Form dargestellt werden k nnen Die Plots werden f r die Ausarbeitung der Szenario aufbereitet Das vorhandene Material wird auf eine einfache und klare Handlungsfolge reduziert Die Story wird damit konkretisiert bzw verfeinert In der Story sind keine detailliert ausgearbeiteten Szenen enthalten dies trifft auch f r das Szenario zu Es enth lt die Szenenabfolge und alle Dialoge In das Szenario flie t bereits die gesamte Informationsf lle ein Sobald wir uns f r eine bestimmte Auswahl entschieden haben kommen neue Informationen hinzu Sie ergeben sich aus dem bisher Betrachteten Damit entwickelt sich das Szenario selbst Es werden auch Unzul nglichkeiten und Fehler sichtbar Die einzelnen Szenen kann man sich durch berlappende Bl cke darstellen Da eine Information und eine Aktion noch nachwirken kann bzw antizipiert wird sind die Szenen nicht vollst ndig trennbar Mit der Szenenentwicklung betten wir auch die Dialoge in die Handlungen und die Daten ein Handlungen sind Folgen von Aktionen Aktionen ben tigen Daten als benutztes Wissen f r di
161. eitet werden Bekannt ist z B nach KT95 das Fremdbild wie in Bild 40 stabil A hawild stark introvertiert triebhaft extravertiert aggressiv gesellig Y labil Bild 40 Das Fremdbild des Bayern hnliche Profile sind auch f r andere Gruppen bekannt Mit diesen Profilen k nnen Portfolios f r die einzelnen Benutzergruppen erstellt werden Hinzu kommen dabei auch noch Morphologien Ein Oberfl chen Portfolio setzt sich dabei aus mehreren ebenen Profilen zusammen wie Funktion Semantik Pr gnanz Expressivit t Zum Pers nlichkeitsprofil geh rt auch das subjektive Informationsbed rfnis das wiederum abh ngig von der intuitiven Erkenntnis ist da die vorhandene Information zur L sung einer Aufgabe nicht ausreicht da das Wissen zu gering ist da die Information aus vorhandenen Wissen und Infor mationen nicht oder nicht so schnell generiert werden kann da die Unsicherheit Unbestimmtheit Unsch rfe oder die Widerspr che nicht anders aufgel st werden k nnen Wir unterscheiden den Infor mationsbedarf vom Informationsbed rfnis Das Informationsbed rfnis ist abstrakt ein Wunsch nach besserer Information Der Informationsbedarf wird f r das Portfolio ben tigt Bei der Entwicklung von Informationssystemen sind unterschiedliche Informationsbed rfnisse ent sprechend dem Profil zu beachten Damit kann ein Informationssystem nur dann von Bestand sein wenn es ein B ndel von Informationsdi
162. el Cornell Doris Emil Fjodor Bild 23 Beziehungen der Objekte im Vorlesungsbeispiel Wir betrachten in diesem Beispiel in Bild 23 eine kleine Klasse mit 14 Objekten Z B hat B rbel sowohl die Informatik II WS2002 BvB als auch DBIV SS2002 3 mit Pr fung und Schein abgelegt Emil dagegen nur Scheine in Informatik IIT VVS2002 BvB und DBI VV92002 6 Kardinalit tsbeschr nkungen sind mitunter nicht erf llbar in nicht leeren endlichen Klas sen Fin Beispiel einer solchen nicht erf llbaren Menge von Integrit tsbedingungen ist das Paar card Voraussetzung setzt Voraus 0 2 card Voraussetzung vorausgesetzt 3 4 Dagegen ist FREE ee m TEEN ed da EHI LE f T x INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 l card Voraussetzung vorausgesetzt 3 4 erf llbar und impliziert card Voraussetzung setzt Voraus 3 3 card Voraussetzung vorausgesetzt 3 3 Mehrwertige Abh ngigkeiten stellen im Entwurf i a die Separation von Gesichtpunkten bzw Aspekten dar Sie werden oft weggelassen da ihre mathematische Notation schwierig nach zuvollziehen ist Eine mehrwertige Abh ngigkeit X 2 wird f r einen R Ur p mit Teilmengen X Y C Up und Z Up Y UX definiert und gilt in einer Klasse Relation ber R dargestellt durch R X YZ falls f r alle o o RC die den gleichen Wert f r die X Elemente von R haben ein Objekt o in R existiert da
163. elationship Typen Folge an der jeweils da runterliegenden Schale angeh ngt werden In diesem Fall wird ein Stern Schema er zeugt Meist wird jedoch eine vollst ndige hierarchische Strukturierung nicht m glich sein Dann erhalten wir ein Schneeflocken Schema Ein Beispiel einer Adh sionsmatrix f r das Schema in Bild 34 ist mit folgender Matrix gegeben Archivsicht T To Ts Ta Ts Te Ty Ta T Verantwortlicher 0 2 0 4 4 2 5 11 T Professor 1 0 1 4 6 4 4 7 gehaltene Lehrveranstaltung 2 1 0 2 4 1 3 5 T4 Semester 5 4 2 0 1 3 6 9 Ts Bezeichnung 6 6 4 1 0 4 7 10 T Kurs 4 3 0 38 3 0 2 5 Studiengang 5 3 2 5 7 2 0 11 Tg Typus 6 2 1 7 9 1 3 0 Eine Adh sionsmatrix kann auch per Default besetzt werden Wir verwenden dazu den Abstand in der Typen Definition Die Beispielmatrix erlaubt z B eine Separation der Typen in Bild 34 f r den Typ Kurs in die Schalen QR d RT Se 0 2 94 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 6 SICHTENSUITE Kurs gehaltene Lehrveranstaltung Studiengang Kurs gehaltene Lehrveranstaltung Studiengang Professor Kurs gehaltene Lehrveranstaltung Studiengang Professor Semester Bezeichnung Verant wortlicher und die gesamte Sicht Die Schalen k nnen auch noch gegenseitig durch die Adh sion der hinzukommenden Typen der n chsten Schale separiert werden Dadurch k nnen wir sogar eine hierar chische Charakterisierung vornehmen In den selten
164. en sind Damit k nnen wir f r alle Typen 7 in G die Gleichung T f 2 T und f r alle Typen T in OY die Gleichung T fa T zur Gleichungstheorie hinzuf gen Falls wir an einer vollst ndigen Integration interessiert sind dann k nnen die Gleichungen durch Term Ersetzungsregeln der Form T fij T oder fij T x T ersetzt werden Diese Ersetzungsre geln m ssen auch dem induktiven Aufbau der Typen folgen Deshalb wird auch ein Ableitungssystem ben tigt Wir nutzen dazu die folgenden Inferenzregeln E U TT TL en EUIT TI EU T S gU 17 8 U T S1 Tm Sm EU S T Vrus U T S f r Substitution von r s in Zwei Sichtenschemata sind integrierbar wenn Schema Morphismen existieren die alle Typen der Schemata paarweise miteinander assoziieren Wir k nnen die Sichtenintegration auch durch Definition entsprechender Anfragemengen definie ren Diese Definition ist der obigen quivalent 104 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 7 INTERAKTIVIT T 7 Sprachen zur Darstellung der Interaktivit t Greift nur hinein ins volle Menschenleben Ein jeder lebts nicht vielen ists bekannt Und wo Ihrs packt da ists interessant In bunten Bildern wenig Klarheit So wird der beste Trunk gebraut Der alle Welt erquickt und auferbaut Goethe Faust Erster Teil Vorspiel auf dem Theater Lustige Person Der Interaktionsraum zur Darstellung der Interaktivit t Die Interak
165. en E eine Gleichungstheorie und S eine Sitzung Wir unterscheiden strikt zwischen Typen die der Spezifikation dienen und Klassen von Objekten eines Typs Klassen eines Typs werden mit einer hochgestellten Annotation bezeichnet z B ist R eine Klasse von Typ R Anzumerken ist au erdem da wir hier den Notationen des ER Modelles und der Datenbankliteratur folgen wollen In der Informatik wird unterschieden zwischen unterlegter Theorie Spezifikationssprache und Programm In der Datenbankliteratur ist eine Theorie durch eine meist implizit angenommene Mengensemantik und Pr dikatenlogik gegeben Das ER Modell ist eine Spezifikationssprache Das Datenbank Schema ist ein Ausdruck dieser Spezifikation und ein Analogon zum Programm Alle maskulinen Personen in diesem Skript sind Abstrakta Sie gelten f r feminine Personen mit Ein Ausnahme ist das im Universit tsverbund entwickelte Werkzeug RADD sein AABT 98 Es wurden mit DB bzw ID weit mehr als 5000 gro e Projekte mit mitunter mehr als 1000 Entity und Relationship Typen durchgef hrt deren Ergebnisse und deren Entwurfs und Weiterentwicklungsgeschichte dem Aut hor vorliegen 2 e TT 1 da M ai 2 A o did A a at pe 227 lt cae INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 3 1 Einf hrung Ich bin nicht ihr bester Freund Ich bin ihr einziger Freund Danny DeVito in Das Geld anderer Leute Datenbank u
166. en Inkonsistenz und update Anomalien vermieden Mitunter ist eine Pflege so aufwendig da kein System diese leisten kann Durch Systemunabh ngigkeit wird eine Portierbarkeit erleichtert Durch eine ad quate Sichtenunterst tzung kann jede Sicht eines Benutzers auf einfache Weise unterst tzt werden 3 F r die Anwendung Bei Vollst ndigkeit werden alle Aspekte der Anwendung die notwendig sind repr sentiert Durch Flexibilit t bedingen nderungen in der Anwendung nicht sofort nderungen aller Teil schemata Werden relevante Dinge repr sentiert und nicht alle m glichen Situationen dann kann ein Sche z Re 12 1 2 00 1 INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 13 Betriebliche Modelle dienen der Repr sentation betrieblicher Einschr nkungen operationale Be schr nkungen Gesetze Regulierungen Planung Kontrolle etc Daraus k nnen Prinzipien des Entwurfes abgeleitet werden Was wird modelliert In einer korrekten Repr sentation verk rpert jeder dargestellte Typ Ob jekte einer bestimmten Klasse in der realen Welt und jede relevante Klasse wird aufgezeigt Der Grad der Detailliertheit wird nur soweit vorangetrieben da Anfragen und Updates in ei ner einfachen Form m glich sind aber zugleich soweit da die Entwicklung von Anwendungen unterst tzt wird Prinzipiell werden nur stabile Strukturen repr sentiert Teiltypenhierarchi en k nnen ansonsten bis ins letzte Deta
167. en Schema beruhen und die ber Exportschemata miteinander zusammenarbeiten Eine Weiterentwicklung von multiplen F derationen sind sprachlich gekoppelte Multi DBMS Dazu wird jedoch erst geforscht so da hier f r den Entwurf nur f derative DBMS betrachtet werden Der Entwurf einer f derativen Datenbank kann dabei von folgender Referenzarchitektur ausgehen Lokale Schemata sind die Schemata der einzelnen Netzknoten Komponentenschemata sind die lokalen Schemata in einer f r die Koordinierung aufbereiteten Form Das Datenbankmodell kann verschieden vom Datenbankmodell des lokalen Schemas sein Exportschemata beschreiben die netzweit zug nglichen Daten die den Teilnehmern einer F dera tion zug nglich gemacht werden m ssen F derative Schemata fassen die Exportschemata analog zur Sichtenintegration wie oben beschrie ben zu einem allgemeinen Schema zusammen Weiterhin werden Ans tze zur Aufl sung von Modellierungskonflikten statische Daten zur Optimierung zur Verteilung Partitionierung Re plikation etc erfa t Transformationsprozessoren erlauben eine Abbildung der lokalen Schemata auf die Komponen tenschemata Filterprozessoren filtern aus den Komponentenschemata die Daten f r die Exportschemata heraus Konstruktionsprozessoren dienen zur Einbindung der Exportschemata in die oder das f derative INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG 8 163 Interface zum f derativen Schema Konstru
168. en des Wertebe reiches Diese Klassifikation kann einfach oder mehrfach hierarchisch analytisch oder d 05852 xu 010 x a e CAEN 3 OS et 4 o o o Bo 44 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 4 STRUKTURIERUNG e Datentypen k nnen ber unterschiedliche Pr sentationsformen verf gen Das Format umfa t L nge und Gr e e Datentypen k nnen auf unterschiedliche Art abgespeichert werden e Datentypen verf gen ber eigenst ndige Default und Nullwerte e Datentypen k nnen durch Casting Funktionen aufeinander abgebildet werden e Datentypen sind bestimmten Anwendungen und Arbeitsgebieten zugeordnet e Die Funktionen und Pr dikate lassen unterschiedliche Berechnungen zu die sich auf die Erfassung Berechnung Algorithmen etc auswirken e Bestimmte Funktionen wie z B der Durchschnitt sind evt anders oder gar nicht definiert e Datentypen sind oft mit Ma einheiten ausgewiesen womit auch Berechnungen unter legt werden m ssen Basis Datentypen sind meist auch in einem Typenverband geordnet Neben den Basis Datentypen des DBMS kann auch eine Anwendung ber eigene Basis Datentypen verf gen Wir k nnen z B den Typ varnumbersequence20 zur Darstellung von Telefonnummern mit einer angepa ten Ordnungsbeziehung und ohne Unterdr ckung f hrender Nullen einf hren Analog kann ein Typ EmailTyp oder URL eingef hrt werden Attribut Typen werden ber einem Basis Datentypen
169. en generellen Rahmen der Szenen durch eine Abfolge der Szenen und durch didaktische Regeln bei der Erschlie ung des Story Raumes allgemein dargestellt Didaktische Regeln fassen sowohl die Redundanz der Kollaboration als auch die Erwartungskonformit t Ebenso wie f r die Realisierung von Barrierefreiheit eine Unterst tzung durch nicht visuelle Kommunikation erforderlich Ber cksichtigung der Gestaltungsgesetze des Bildschirmes Ein Bildschirm ist eine zweidimensio nale Oberfl che mit dem evt auch dreidimensionale Effekte erzielt werden k nnen Die Gestaltung der Bildschirmoberfl che mu Gestaltungsprinzipien wie e dem Prinzip der visuellen Kollaboration in Abh ngigkeit von den Arbeitsaufgaben der Story und der Einfachkeit der Vermittlung e dem Prinzip der visuellen Wahrnehmung basierend auf einer Abstimmung von Anord nung Wirkung und Gliederung und e dem Prinzip der visuellen Gestaltung unter Ber cksichtigung der Optik der hnlich keit der Geschlossenheit der Symmetrie der Pr gnanz und des Aufnahmeflusses angemessen ber cksichtigen Akteure sind Gruppen von Benutzern Die generelle Spezifikation der Akteure wurde bereits in diesem Kapitel dargestellt F r den Gestaltungsrahmen nehmen wir eine Kategorisierung der Akteure vor nach Einordnung in Zielgruppen Polarit ten Profil insbesondere das psychographischen Profil und nach Adaption an rT f l 140 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 7 INTERA
170. end seine Qualit t d h insbesondere die folgenden xY OR EA On Se EE E Cer cee eee INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 111 Benutzerf hrung Die Akteure ben tigen neben einer angepa ten Hilfe auch eine F hrung durch komplexe Prozesse Differenzierung Es werden die unterschiedlichen Kategorien von Akteuren unterst tzt Medienmiz Die Medienauswahl erfolgt an den Inhalt angepa t Hypermediale Struktur Es werden die Aktionen Informationen und Dialoge in einer benut zergerechten Form geboten die ein Verlieren im Cyberspace verhindert Verbindung von Arbeit und Vergn gen Da eine multimediale Darstellung auch eine Emo tionalisierung der Darstellung erlaubt ist der Einsatz dieser Mittel zu konzipieren Konsistenz Jede Szene mu an sich und auch in ihrem Kontext konsistent sein Erwartungskonformit t Die Erwartungen der Akteure sind f r unterschiedliche Szenen ver schieden Dabei sind auch verschiedene Kategorien von Akteuren zu beachten F r die Inszenierung wird die Form der Dialoge und damit der Pr sentationsraum bestimmt Wir entwickeln in dieser Schicht die Arbeitsoberfl chen f r jeden Dialogschritt im einzelnen Ebenso wie das Storyboard den Handlungsrahmen nicht ver ndert wird durch die Inszenierung das Drehbuch nicht ver ndert Es werden die einzelnen Szenen und Dialogschritte des Szenenraumes ausgeschm ckt Die Spezifikation der Dialogschritte im Drehbuch basiert bereits auf
171. enge von Entwurfseinheiten der folgenden Schicht direkt zugeordnet werden Wir merken an da wir ber zwei unterschiedliche Methoden zur Darstellung Repr sentation Verarbeitung und Speicherung von Objekten verf gen Klassen Separation Die Menge aller Objekte wird durch ein ER Schema dargestellt Jedes Objekt wird genau einer Klasse zugeordnet und in beliebig vielen anderen Klassen auf der Grundlage des ER Schemas verwendet Die Verwendung kann ber einen Surrogat Schl ssel eine Markierung oder Werte zum ausgew hlten Schl ssel des Objektes erfolgen Wir nennen diese Form der Behandlung von Objektmengen klassen separierte Darstellung Ein Objekt ist dann mit dem erweiterten ER Modell als Schneeflocke mit einer Wurzel darstellbar Objekt Entfaltung Die Menge aller Objekte bildet unter Einbeziehung der Beziehungen der Objekte untereinander einen Objektmengen Graphen Wir k nnen ber diesem Graphen beliebige ber deckungen U bilden d h Mengen von Teilgraphen die zusammen den Objektmengen Graphen ergeben Fin Teilgraph besitzt evt ein Wurzel Objekt d h es gibt ein Objekt das rekursiv auf alle anderen Objekte des Teilgraphen verweist Besitzt jeder dieser Teilgraphen ein Wurzelob jekt dann hei t U Objekt Gesellschaft Damit ist in Objekt Gesellschaften jedes Objekt ein volles Objekt mit allen Eigenschaften Ein Beispiel f r eine Objekt Entfaltung zum Schema in Bild 20 ist folgendes XML Dokument lt Lehrveranstaltung ID 1202
172. ensten aus den folgenden Kategorien bereitstellt Informationsdienste im allgemeinen Interesse orientieren sich insbesondere analog zu Zeitungen auf die Bereitstellung von Informationen des t glichen Alltags Beispiele sind Wetterdienste Veranstal tungskalender Regionalinformationen Sportinformationen und Nachrichtendienste Informationsdienste zur Gestaltung der Freizeit orientieren sich z Z noch am Computerspielmarkt wer den aber auch immer st rker Aufgaben der Kommunikation wie auch Email bernehmen und sich zunehmend in eine st rkere Konkurrenz mit Printmedien wie Nachschlagewerke Verzeich nisse wie Adre b cher begeben Informationsdienste zur Erf llung von Arbeitsaufgaben werden zuerst als allgemeine Betriebsinforma Cen ee f 2 8x EY xo xX981 x s55 208 82825605 5 555 5210 20934 nn o Y nu 28 116 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 7 INTERAKTIVIT T heute vorrangig entwickelten Wirtschaftsinformationsdienste ist die Aktualit t der angebote nen Information Jede Gruppe von Benutzern besitzt auch Spezifika Diese erg nzen das allgemeine Profil um folgende Informationen positive Arbeitserfahrungen f r die Anwendung wie praktizierte Kenntnisse L sungsstrategien und Fertigkeiten bei der Anwendung des eigenen Wissens negative Arbeitserfahrungen i a Fehlersuche Fehlerbeseitigung Arbeitsplanung Arbeitsschrittentschei dungen Bewertung des Arbei
173. ent py 6 Professor Semester ire Voraus set Student Professor Semester Raum Kurs Bild 19 HERM Diagramme mit und ohne Relationship Typen h herer Ordnung Kurs Semester Studiengang Vorschla Typus Vorlesung 2 Zeitrahmen Professor Person Zeit Vorschlag Nebenbeding Bild 20 HERM Diagramm zu unserem Hauptbeispiel 47 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 4 STRUKTURIERUNG der Relationship Typ bzw Entity Typ als sein Element diesen identifiziert Rollen werden oft durch einen generischen Typ mit der Bezeichnung IsA dargestellt Da die relationalen Schemata auch ohne diesen Typ auskommen bevorzugen wir die Darstellung als Rolle mit un ren Relationship Typen oder ggf auch mehrstelligen Relationship Typen falls die Rolle durch eine Beziehung zu anderen Typen ausgezeichnet ist Damit sind wir in der Lage zwischen Generalisierung und Spezialisierung zu unterscheiden Rollen die exklusiv bzw hierarchisch sind lassen sich auch anstelle einer HERM Rau tenstruktur durch hierarchische Strukturen abbilden wie in Bild 21 dargestellt Welche Darstellungsform gew hlt wird h ngt vom erforderlichen Detaillierungsgrad ab Sollen At tribute mit dargestellt werden wird das hierarchische ER Modell sehr schnell zu un
174. eorie erweiterte Sichten und kleine logische Theo erweiterte Begriffs Funktionalit t rien verb nde Spezifikationsresultat erweitertes ER Schema Konzeptfelder Begriffslandkarte Die Assoziation zwischen Content Konzepten und Begriffen kann erfolgen durch spezielle Ab bildungen Im Rahmen unserer Entwicklung hat es sich als ausreichend erwiesen dabei wenige aus drucksstarke Verbindungen der unterschiedlichen Aspekte der Assoziation zu verwenden von zu Content Konzepte Begriffe Content Integration Aufbereitung Annotation allgemeine Assoziation Konzepte Spezialisierung Komposition Verbalisierung allge meine Assoziation Begriffe allgemeine Assoziation Untermauerung Komposition Content kann z B durch eine Datenbankspezifikation wie der folgenden gegeben sein create table Benutzer BenutzerID smallint not null FirmaID numeric 18 0 not null Vorname varchar 20 null Name varchar 20 null Tel varchar 20 null Zugriff tinyint null go create table BProfile BPID numeric 18 0 identity 1 1 not null BPName char 100 null BenutzerID smallint null TY LL Su JASAN an NI 22 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 2 SPRACHEN go create view SysusersBenutzer as select S1 Name as Login S2 Name as Gruppe BP Name as Profil BP Rechte B Name B Vorname B Tel B Funk B FirmalD S1 GID S1 UID from Sysusers S1 inner join Sysusers S2 on S1 UID l
175. er a wir e Tempus zur zeitlichen Relativierung Pr senz Perfekt Plusquamperfekt etc e Modus zur Bewertung der Modalit t Indikativ als Feststellung z B durch Teilklasse Imperativ 1 1 bzw 1 n Konjunktiv I zur Darstellung der allgemeinen M glichkeit bzw Wunsches Konjunktiv II zur Abgrenzung einer spekulativen M glichkeit und e Genus verbi zur Darstellung der Beziehungsform aktiv bzw passiv oder Komparation zur Darstellung von Steigerungsformen e Positiv bzw einfach positiv e Komparativ bzw Vergleichstufe bzw H herstufe und e Superlativ als H chststufe sowie e Elativ als absoluter Superlativ und Auspr gungen des Wortes Da wir die Theorie der Wortfelder Kun92 zu Konzeptfeldern DT04 bzw Konzeptrahmen erwei tern wird f r ein Konzeptfeld eine Kontextualisierung oder Konjugation durch Instantiierung der Parameter Akteursprofile und portfolio Wiederholungsprofil Zeitprofil deontischer Modus mit imperativen konjunktiven und indikativen Auspr gungen und Aktionsform und Handlungsrichtung zur Darstellung der Beziehung zwischen Akteur und Handlungs TN VIER nd INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 75 erreicht Damit werden insbesondere die Parameter der Stammform des Konzeptfeldes durch entspre chende Werte angepa t Ein Konzeptfeld ist ein generisches Konzept aus dem ein Konzept durch Instantiierung einer Reihe von Merkmalen abgeleitet wi
176. er in einer einheitlichen Form pr sentieren wobei die allgemeine Arbeitsumgebung ebenso wie eine bevorzugte Form der Darstellung mit einbe zogen wird In unserem Beispiel kann z B die Raumplanung mit einer Reiter Darstellung die Vorlesungs bersicht durch hierarchische Strukturen unterst tzt werden die dem Stu dienplan und der Lehrstuhl bersicht folgen unterst tzt werden Screen Layout f r Funktion und Interaktion Funktionen und insbesondere Interaktionsfunktio nen sind als besondere Gestaltungselemente durch eine entsprechende Typisierung ein heitlich und schnell erkennbar gestaltet Umsetzung der Prinzipien der visuellen Wahrnehmung Schnittstellen sollen einfach leicht zu berschauen und auch so zu bedienen sein da die bersicht nicht verloren geht Da zu sind Parameter der visuellen Wahrnehmung wie Ordnung und insbesondere Hierarchie Wirkung auf bestimmte Akteure und auch der Schrittfolge durch eine entsprechende Struk tur zu unterst tzen Daraus kann sowohl die vertikale als auch funktionale Navigation abgeleitet werden Da auch multimediale Elemente eingebracht werden k nnen spielt neben der visuellen Kommunikation auch die audio basierte Kommunikation sowie auch andere Arten eine Rol le Insbesondere f r barrierefreie Systeme wird auf die anderen Kommunikationsm glich keiten zur ckgegriffen Umsetzung der Prinzipien der visuellen Kollaboration Die unterschiedlichen Facetten der Kol laboration werden durch ein
177. er nicht sichtbar Wir unterscheiden dabei verschiedene Arten von Sichtbarkeit Je nach Verteilung der einzelnen Komponenten unterscheiden wir Einfachknoten Berechnung und Einfachknoten Datenhaltung Einfachknoten Berechnung und Mehrfachknoten Datenhaltung Mehrfachknoten Berechnung und Einfachknoten Datenhaltung und Mehrfachknoten Berechnung und Mehrfachknoten Datenhaltung Die Mehrfachknoten Berechnung und Einfachknoten Datenhaltung entspricht im Wesentlichen der Client Server Architektur der Workstation basierten DBMS Wir k nnen auf verschiedene Rechner bei Vorhandensein eines Netzes verschiedene Ressourcen verteilen 16 Wir verwenden hier den Begriff Partition In der Literatur wird neben dem Begriff Partition der Begriff Fragment benutzt Da wir jedoch auf eine disjunkte Uberdeckung des Datenbankinhaltes orientieren ist das Wort Partition eher INFORMATIONSSYSTEM ENTWICKLUNG IM Co DESIGN ZUGANG BY 8 159 Daten Daten k nnen auf verschiedenen Rechnern abgelegt und auf Anfrage bzw Abforderung ande ren Rechnern zug nglich gemacht werden Prozesse Prozesse k nnen auf verschiedenen Rechnern ausgef hrt und ber ein Netz zusammen gef hrt werden Steuerung Die Bearbeitung kann durch verteilte Steuerung der einzelnen Prozesse und des Daten austausches erleichtert werden Dabei kann die Organisation der Verteilung nach Proze charakteristika und Proze wissen unter schieden werden Umfang des Sha
178. erter Entwurf nicht m glich ist Wird aber eine konkrete Anwendung betrachtet dann erscheint auch in vielen F llen eine Kombinierbar keit der unterschiedlichen Aspekte der Anwendung gegeben Wir pflegen deshalb das Wissen um die Integration der Daten direkt im Sichtenintegrationsschema Wir unterscheiden Sichten f r strukturelle Aspekte und Sichten f r funktionale Aspekte Diese unterschiedlichen Begriffe wollen wir im weiteren auseinanderhalten Ein sichtenorientierter struktureller Entwurf ist am einfachsten in der Top Down Strategie in tegrierbar In diesem Fall wird zur Darstellung der strukturellen Zusammenh nge ein Skelett benutzt Es dient zur expliziten Spezifikation der Abbildungen von einzelnen Konstrukten der Sichten untereinander Jeder neue Entwurfsschritt der sich auf eine andere Sicht aufgrund dieses Skeletts auswirken kann zieht eine Entwurfsobligation nach sich Entwurfsobligationen k nnen sofort nach einem Schritt betrachtet werden oder im deferred Modus auch zu einem sp teren Zeitpunkt bearbeitet werden Der sp teste praktikable Zeitpunkt ist das Entstehen weiterer Obligationen aus diesen Obligationen In diesem Fall treten typische Probleme der EAS 84 20 0 0 88 3 6 1421 LEHRE Aare SMe Bei A DDR INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 81 Ein sichtenzentrierter funktionaler Entwurf orientiert sich an den Hauptprozessen und den Dialogen Es wird f r jeden Proze bzw Dialog ei
179. erwendet werden Die Koh sion kann analog zur Koh sion auf Seite 98 durch die Bindung zwischen den einzelnen kooperierenden Objekten beschrieben werden Der Gestaltungsrahmen Durch die Spezifikation eines Gestaltungsrahmens kann in allgemeiner Form die Darstellung der gesamten Arbeitsoberfl chen Suite und des Pr sentationsraumes in einheitlicher Form und auch mit der XML Technologie erfolgen Zur Gestaltung von Software und insbesondere von Dialogen nach ergonomischen Kriterien stellt die DIN Norm 66234 Teil 8 folgende Kriterien auf Erwartungskonformit t Ein Dialog ist erwartungskonform wenn sich die Erwartungen Erfahrungen und bisherigen Handlungen der Benutzer im Dialog widerspiegeln Steuerbarkeit Ein Dialog ist steuerbar wenn er sich dem augenblicklichen Arbeitsstil der Geschwin digkeit und der Wahl der Arbeitsmittel anpassen l t Aufgabenangemessenheit Ein Dialog ist aufgabenangemessen wenn er die Erledigung der Arbeitsauf gaben unterst tzt ohne zus tzlich zu belasten Selbstbeschreibungsf higkeit Ein Dialog ist selbstbeschreibungsf hig wenn er entweder direkt oder indirekt z B ber ad quate Hilfen verst ndlich ist Fehlerrobustheit Ein Dialog ist fehlerrobust wenn trotz erkennbarer Fehler ein richtiges Resultat erzeugt wird Bei der Bewertung von Benutzungsoberfl chen k nnen eine Reihe von Parametern betrachtet werden Robustheit Ein System darf durch eine falsche Handlung nicht in seinen wese
180. erzu ein vereinfachtes Diagramm in Bild 22 gehaltene Vorlesung Ablage form 0 Resultat setztVoraus vorausgesetzt 3 4 3 4 0 n Student Bild 22 Kardinalit tsbeschr nkungen im Vorlesungsbeispiel Eine Kardinalit tsbeschr nkung card R R n m gilt in einer Klasse RC falls jedes Objekt o von R in R mindestens n mal und h chstens m mal vorkommt Eine Kardinalit tsbeschr nkung in der Lookup Notation look R R n m gilt in einer Klasse RC mit k Elementen falls zu jeder Kombination von Objekten oj von RE j 41 1 lt j x k mindestens n und h chstens m entsprechende Objekte o aus RE in der Klasse R vorkommen Im Fall bin rer Relationship Typen kann man damit einem Objekt o von R mindestens n und h chstens m Objekte aus RF zuordnen d h das Objekt sieht vermittels R h chstens s d x ax a 1 es B esa B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 4 STRUKTURIERUNG Die Lookup Notation ist f r bin re Relationship Typen ohne eigene Attribute quivalent zur Partizipation Notation Sie wird jedoch am anderen Element angetragen Im Beispiel nehmen an da card Voraussetzung setzt Voraus 0 2 look Voraussetzung setzt Voraus 3 4 card Voraussetzung vorausgesetzt 3 4 look Voraussetzung vorausgesetzt 0 2 gilt Damit haben wir quivalente Formen F r n re Relationship Typen ohne eigen
181. esen Rahmen f r die Definition der logischen Sichten Im allgemeinen ben tigen wir jedoch in Anwendungen komplexere Unterst tzung Spezifkation einer Sichten Suite Zur Begleitung der unterschiedlichen Arbeitsschritte sind auch un terschiedliche zusammenh ngende Sichten zu definieren Spezifikation einer Funktionalit t f r die Sichten Suite Es sollte m glich sein eine Anwendung soweit wie m glich durch entsprechende Funktionen und Prozesse zu unterst tzen Dazu ben tigt ein Benutzer eine Reihe von Funktionen Spezifikation der Anpassung an den aktuellen oder potentiellen Benutzer Jeder Akteur oder jeder ak tuelle Benutzer sollte ggf auch mit seiner Oberfl che arbeiten k nnen ggf seine Daten auch f r sich selbst modifizieren k nnen und auch durch eine explizite Beschreibung der Pr sentati onsart eine Anpassung vornehmen k nnen Die aktuell verf gbare Datenbank Technologie unterst tzt diese Forderungen bereits in breitem Ma e wenn Sichten Suite Modifikation ber stored procedures abefangen wird Sichten Suiten k nnen auch durch logische Sichtenanfragemengen unterst tzt werden Die Funktionen sind mit einem all gemeinen Funktionsrahmen allgemein darstellbar und dann an die konkrete Sichten Suite anpa bar Die XML Technologie eignet sich besonders f r unterschiedliche Arten des Ausspielens Au erdem kann einem Benutzer auch ein Sitzungsobjekt zugeordnet werden so da entsprechende Einstellun gen automatisc
182. etzterEintrag B eschreibung 5 Art Eigenschaft Dituri Wane Priorit t R Bildungs d einrichtung Gegenstand Status Spezialisierung Beschreibung Bild 8 Das Person Konzept mit obligatorischen allgemeinen und optionalen Bestandteilen Rollenkonzepte A Interne Rolle o Externe Rolle Kontakt Partner Adre konzepte adresse adresse Lieferant Kunde Angestellter Beauftragter Privatperson Personenkonzepte Bild 9 Die Kombination von Konzepten Person Rolle und Adresse INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 25 Eine Spezialisierungsbeziehung zwischen dem Person Konzept und dem Content erfolgt dann durch Instantiierung der Parameter Dadurch pa t die Sicht zu Person Content auch zum Person Konzept Ein Beispiel ist die Spezialisierung des Parameters familie oder des Parameters _name T Geburtname Vater Mutter familie oder T Geburtname Kind T Vornamen lt Vorname use gt FamName GebName Titel AkadTitel U FamTitel name oder T Vorname Familienname Spitzname Begriffe sind i a nicht so stark durch Merkmale oder Eigenschaften unterlegt besitzen h ufig eine hohe Ambiguit t und sind oft in einer ellipsenartigen Form gegeben Au erdem werden sie oft metaphorisch verwendet Begriffe k nnen als Funktionen verstanden werden die Dinge im weitesten Sinne meh
183. eutet keinesfalls die weitestgehende Unabh ngigkeit der einzelnen Oberfl chen voneinander aufzu geben Verbindungen zwischen den einzelnen Oberfl chen sind explizit darzustellen bzw durch globale Techniken wie Zwischenablagen und dynamischen Datenaustausch zu unterst tzen Kontextsensitive Oberfl chen insbesondere solche die von mehreren anderen abh ngen sollten vermieden werden oder nur mit einer hierarchischen Strukturierung angewandt werden Eine Darstellung von Informationen sollte so einfach sein wie es die Informationsf lle zul t Die Information ist bersichtlich zu gestalten Durch geschickte Vernetzung von Oberfl chen kann eine bersichtlichkeit geschaffen werden die weit ber die M glichkeiten von Printmedien hinausgeht Durch verschiedene bergreifende Verzeichnisse kann eine Transparenz geschaffen werden die eine umfassende und aktuelle Recherche in einfacher Form erm glicht Einfachheit impliziert auch Eleganz Der Stil ordnet sich hier unter Die Repr sentation und das Aussehen folgen auf dieser Grundlage Einfache Oberfl chen bedeuten auch minimale Wege sowohl f r die Bedienung als auch f r das Auge Mengen von Oberfl chen werden umso eher angenommen umso mehr sie einer einheitlichen Strukturierung unterliegen Die Verteilung der Funktionalit t sollte einheitlich sein Die Eingabeober fl chen ben tigen eine einfache und bersichtliche Gestaltung Sind aufgrund einer Informationsviel falt mehrere Oberfl chen
184. folge kann man zwischen Mikro Daten der Datenbank und den Makrodaten des Warenhauses unterscheiden 176 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 9 DOKUMENTATION 9 Die Dokumentation der Spezifikation Nicht Kunst und Wissenschaft allein Geduld will bei dem Werke sein Goethe Faust Erster Teil Hexenk che Mephistopheles Entwicklungsdokumente In unserem Vorgehensmodell werden folgende Dokumente schrittweise erarbeitet verfeinert bzw dienen als Basis f r die Entwicklung anderer Dokumente Lastenheft L Zur Dokumentation verwenden wir ein erweitertes Lastenheft Bestimmung der Ziele und des Produkteinsatzes LZ Es werden die Ziele der Produktentwick lung beschrieben Die Aufgaben und Einsatzfelder des Informationssystemes werden kurz beschrieben Wesentliche Charakteristika des Produkt Einsatzes wie z B Anwendungsbe reiche Zielgruppen und Betriebsbedingungen phys Umgebung Betriebsumgebung und Betriebszeit werden ebenso festgelegt wie auch die Produkt Umgebung mit einer Be schr nkung f r Software Betriebssysteme Laufzeitsysteme Fenstersysteme einsetzbare DBMS Compiler bzw Interpreter die einsetzbare Hardware CPU Peripherie Drucker die angestrebte Orgware Netze Infrastruktur und die Produkt Schnittstellen Beschreibung der Produktdaten LD Es werden die wesentlichen Gruppen von Datentypen so wie deren Einsatz und Gewinnung kurz beschrieben Produktdaten werden in Konzepten zu
185. formationen beruhen in der Inszenierung auf Selektion Es werden bestimmte Szenen herausgehoben oder auch nur angedeutet Jede Information zieht auch weitere Informationen nach sich Voraussetzung f r die richtige Informationsaus wahl ist daher die Kenntnis aller Fakten ber den Dialogablauf und die zugrundegelegten Funktionen und Daten Es k nnen zu wenig zu viel oder die korrekte Anzahl von wichti gen Fakten in den Entwurf eingehen Dies trifft insbesondere auch auf die Darstellung der Begleitinformation zu Zugleich werden die Vorkenntnisse der Benutzer mitber cksichtigt Der Informationspflicht am Anfang eines Szenarios mu in st rkerem Ma nachgekommen werden Man kann auch Informationen die sp ter ben tigt werden vorher sien Die Verteilung der Informationen unterliegt ebenso wie die Verteilung von Wissen und Nichtwissen komplizierten Gesetzm igkeiten und verst rkt die Wichtigkeit der Informa tionsvermittlung Durch eine ungeschickte Verteilung k nnen auch Mi verst ndnisse her ee eh a 1122 INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 113 Die Inszenierung bietet mit einer multimedialen Ausgestaltung des Drehbuches eine Vielfalt von M glichkeiten die gerade weil sie existieren danach verlangen genutzt zu werden Damit wer den jedoch neue Hindernisse aufget rmt die die erfolgreiche Nutzung erschweren Es ist nicht m glich das gesamte Hintergrundwissen und den common sense in die Au
186. g Deshalb ver wenden wir das Diensteverwaltungssystem mit den entsprechenden Schnittstellen und Protokollen auf dem Implementationsniveau Zur Spezifikation der Verteilung abstrahieren und verallgemeinern 2385 556 205k ee Ly INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG ienstnehmer IDienstnehmercode Stummel Ger st Parameter 29 lenstgeber Dienstgebercod unktions eintritt erpacken Parameter Funktions aufruf k Auspacken Ergebnis Verpacken Ergebnis 4 Funktions Bild 13 Entfernter Funktionsaufruf mit einer Schichtung ALSS03 Die Verteilung ist gegeben durch eine Spezifikation der Dienste des Kollaborationsrahmens und der Architektur Dienste setzen auf Sichten Suiten auf Der Kollaborationsrahmen fa t die Kommu nikation die Koordination und die Kooperation zusammen Die Architektur stellt den Zusam menhang der Komponenten dar Dienste S T F s sind gegeben durch die Informationseinheiten durch das Dienstverhalten und durch den Dienstvertrag insbesondere die Qualit tsparameter Informationseinheiten Z V M z7 bestehen aus Content Typen der Sichten Suite einem Informationseinheit Manager und einer Menge von Regeln zur Darstellung der Kompetenz Das Dienstverhalten wird e innerhalb der Aktionsschicht durch Vereinbarungen zur Dienstg te e innerhalb der konzeptionellen Schicht durch konzeptione
187. g A B B B Die verwendeten Zug nge kann man klassifizieren wie in Bild 68 dargestellt Mehrrechnersysteme Externspeicher a gemeinsam partitioniert zuordnung Topologisch Verteilung lokal lokal ortsverteilt eng nahe lose nahe lose lose Shared l A everything Shared disk Shared nothing Bild 68 Zug nge f r Mehrrechnersysteme Parallele Datenbanksysteme k nnen in analoger Art und Weise unterschieden werden in Shared everything Architektur Mit einem Hochgeschwindigkeitsnetzwerk sind sowohl die Prozessoren als auch die Speicher und die Datenbanken miteinander verbunden Damit kann eine hohe Universalit t durch symmetrisches Multiprocessing erreicht werden Zugleich sind diese Systeme sehr komplex schlecht erweiterbar und wenig robust Shared disk Architektur Durch ein Hochgeschwindigkeitsnetzwerk werden die Datenbanken und die Einzelrechner miteinander verbunden Die Einzelrechner benutzen gemeinsam die Datenbanken sind aber in ihrer Steuerung und Berechnung isoliert Shared nothing Architektur Die Rechner verf gen ber ihre lokalen Datenbanken Prozessoren etc Sie sind ber ein Hochgeschwindigkeitsnetz miteinander verbunden da RO pee ERS a s GREENS D 0 eh eR en 57 rare Walk fais Can ANDERE az 166 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 8 VERTEILUNG Kriterium Shared nothing Shared disk Leistungsfa statische Datenpartitionier
188. g besteht in der Realisierung eines integrierenden und homogenisierenden globalen Sche mas Deshalb sind die Verteilung der Daten inklusive der Kopienhaltung d h der Partitionierung und Allokation ebenso wie die strukturellen und semantischen Heterogenit ten mittels Schema transformation bzw integration zu verstecken Aus Performanz und Sicherheitsgr nden werden dabei dieselben Daten an verschiedenen Knoten redundant gespeichert redundante Allokation In formationen des gleichen Typs werden ggf an verschiedenen Knoten verschieden dargestellt z B anders strukturiert strukturelle Heterogenit t bzw mit anderen Bedeutungsinhalten semantische Heterogenit t Eine andere L sung ist die Partitionierung globaler Relationen indem logisch an sich zusammengeh rende Daten in homogener Form an verschiedenen Knoten gespeichert werden Mit dieser Funktionalit t kann ein verteiltes DBMS e eine Anfrage entgegennehmen e diese analysieren pr fen und zerlegen e diese Teile den einzelnen Komponenten zuordnen e auf verschiedene I O Operationen zur ckf hren e die entsprechenden Daten suchen lokalisieren lesen und validieren e auf dieser Grundlage die Konsistenz Sicherheit und Integrit t pr fen e die Daten entsprechend der urspr nglichen Dekomposition validieren und e am Ende die gewonnenen Daten entsprechend der Anfrage dem Benutzer zur Verf gung zu stellen Diese Aktivit ten sind aber f r dem Benutz
189. gar mit einer Verallgemeinerung zur Arch Architektur noch nicht durchgesetzt Vorstellbar ist nach Sch96 auch eine Erweiterung der Pr sentationskomponente zu einem Dialogmanagementsystem Die Arbeiten der DBIS Arbeitsgruppe haben zu der hier ver wendeten verallgemeinerten Architektur gef hrt Die Trennung zwischen Client und Server ist eine der m glichen Separation innerhalb einer Anwen dung Vorstellbar sind weitere Trennungen wie z B die Trennung f r verteilte Informationssysteme die Trennung f r Web Informationssysteme mit relativ einfachen Client oder auch Applet basierte Clients Das DBIS Modell ist auf keine der Trennlinien angewiesen und erlaubt eine sp tere Entschei dung f r eine Plattform Typische weitere Trennungen sind meist als Multi Tier Architekturen z B als 3 Tier Architekturen spezifiziert Die Spezifikation des Interaktionsraumes wird in folgenden Entwurfsdokumenten niedergelegt Drehbuch Der Ablauf der Interaktion die Akteure die Stories der Anwendung werden im Drehbuch zusammengefa t Content Typen Das Systeminterface wird als Container Objekt bereitgestellt mit dem ein Akteur sowohl die aktuellen und spezifischen Sichtweisen auf die Datenbank erh lt als auch die ent sprechende Funktionalit t zum Agieren mit dem Informationssystem Der Interaktionsraum wird um Soft Bestandteile erweitert Kollaborationsrahmen Die Interaktion basiert auf der Existenz mehrerer Parteien die in unterschied
190. ge Alte gespeicherte D ten vergangener Semester Darstellung das Kurse f r Kurse Bild 52 Szene zur kollaborativen Planung eines Lehrveranstaltungsangebotes eines Lehrstuhles e Die assoziative Suche geht dagegen von assoziierten Begriffen aus So kann z B eine Hotelsuche mit einer Suche nach Hotels in der N he von einer Sehensw rdigkeit oder eines Transportmittels beginnen wobei die N he selbst durch Fuzzy Funktionen unterst tzt wird e Eine Suche kann auch f r Schn ppchensucher von Sonderangeboten angeboten werden Die Suche ist ein hochgradig iterativer Proze mit einer schrittweisen Verfeinerung Abschlie end kann eine Buchung erfolgen Die Suchszene kann zu jeder Zeit ohne weitere Schritte verlassen werden In Bild 53 wird eine Suchszene dargestellt die diese Aspekte umfa t Diese Gestaltung der Suchszene hat sich bei der Gestaltung von Websites bew hrt Mit dieser Gestaltung verwenden wir Techniken der aspekt orientierten und generativen Programmierung Gleichzeitig kann dieser Zugang als eine Variante der subjekt orientierten Programmierung verstehen Suchszene f r Veranstaltungen individuelle Anfrage Anfangs schritt esultat amp erfeinerungs schritt Buchungs schritt Bild 53 Dialogschritte innerhalb eines Suchszene Neben den hier dargestellten Suchschritten gibt es noch weitere Varianten f r Dialogschritte z
191. gebote sollen zur Benutzung des Warenhauses verleiten Die Akzeptanz des Warenhauses kann dadurch verbessert werden Schnittstellen zu bereits existierenden Systemen die einen Datenstrom des Warenhauses verarbei ten sollen sind zu entwickeln Die Aktualit t der Daten ist auszuweisen Daten unterliegen ebenso wie Produkte einem Verfallspro ze Eventuell will ein Benutzer erst ber die Aktualit t von Daten eine Information erhalten ehe er diese Daten anfordert Ein variabler benutzerabh ngiger Arbeitsraum erleichtert einem Benutzer zu seinen letzten Re cherchen zur ckzukehren und auch evt die stattgefundenen Ver nderungen seit seiner letzten Recherche zu erkennen Durch einen entsprechenden Arbeitsraum und seine Verwaltung entsteht ein zus tzlicher Overhead Datentypen besitzen oft eine eigenst ndige Dimensionierung Mit dieser Dimensionierung sind Aggre gationsfunktionen anders anzuwenden sowie ggf auch nicht sinnvoll anwendbar Die unterschiedliche Granularit t bei der Aggregation f hrt auch zu Operationen wie Drill down feinere Dimensionen Roll up gr bere Dimensionen Slice Selektion und Dice Projektion bzw Umordnung Im Einzelnen kann man folgende Dimensionen unterscheiden R umliche Dimension Daten k nnen eine geografische oder geometrische Verteilung in entprechenden R umen besitzen z B Ort Region Bundesland Land Zeitliche Dimension Daten werden zu unterschiedlichen Zeiten
192. gen e der Rollen der Akteure und e Sichtentypen Das Ubergabefeld erlaubt den bergang von Objekten einer Sicht eines Akteurs auf Objekte einer Sicht eines anderen Akteurs Zus tzlich kann der Kontext und auch der Vertrag des berganges spezifiziert werden Das Arbeitsfeld erlaubt die Bearbeitung von Daten ber den Sichtentypen und deren Versand an andere Akteure bzw deren Einbringen in das System Neben diesen Basisfeldern k nnen wir auch Konstruktionsfelder spezifizieren mit denen Felder kom biniert werden k nnen Das Verzweigungsfeld unterst tzt eine Verzweigung von Workflows in synchronisierte Workflows die parallel unter Einhaltung der Synchronisationsbedingungen ablaufen k nnen Das Wiederholungsfeld stellt den Rahmen f r eine wiederholte Ausf hrung eines Workflows TE n CEF a PU sandal x b b 08 22 sSs 80 05 icy ON Ne 3 ush 2 2 INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 77 Wir haben diese Theorie der Workflow Felder mit den Kompositionsoperationen f r Workflows harmo nisiert damit wird eine entsprechende Entfaltung der komplexen Workflow Felder vornehmen k nnen Generische Workflows und entfaltbare Workflows Workflow Felder erlauben oft eine einfache Darstellung durch entsprechende Ausdr cke K nnen Workflow Felder durch eine Stammform spezifiziert werden dann nennen wir diese Stammform gene rischer Workflow Generische Workflows stellen
193. gen kann F r die Beschreibung von Containern unterscheiden wir zwischen allgemeiner Containerfunktionalit t mit der Beschreibung allgemeiner Container Funktionen zur Ent und Beladung und spezifischer Containerfunktionalit t die durch die Content Objekte mit denen ein Container be laden wurde gepr gt wird Ein Beispiel eines Content Typen Als Beispiel f r ein Content Objekt betrachten wir einen Archivierungstyp Dieser Typ soll in unserem Hauptbeispiel benutzt werden um aus der Datenbank zur Stundenplanung heraus eine Da tenbank zur Ablage der relevanten Informationen zu gehaltenen Vorlesungen integriert mit entstehen zu lassen Diese Datenbank dient der Verwaltung von Studentendaten insbesondere f r Informatio nen zu den erworbenen Scheinen Die Funktionalit t dieser Sicht ist stark eingeschr nkt Es k nnen unterschiedliche Pr sentationstil Optionen zur Laufzeit gew hlt werden Dieses Content Objekt ist als Sicht ber der Struktur in Bild 20 darstellbar Die Archivsicht ist ein Ausschnitt der Daten Die Daten die nur f r die Planung im laufenden oder kommenden Semester von Bedeutung sind werden nicht archiviert Mithilfe der archivierten Daten k nnen zu einem sp teren Zeitpunkt die Daten zu Lehrveranstal 14 ama b b 3 0 50 a 0 94 oy 86 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 6 SICHTENSUITE haben Lehrveranstaltungen d
194. gen kurz and allgemein dargestellt Dazu kann sowohl ein hierarchisches ER Modell herangezogen werden als auch eine allgemeine Beschreibung mit Mindmap Techniken Die Strukturierung des Informationssystems wird in einer Skizze die auch grobe Typen umfa t dargestellt Beschreibung der Funktionalit t PF Es wird die Funktionalit t durch Arbeitsschritte unter legt Darauf aufbauend werden die Gesch ftsprozesse beschrieben die funktionale Anforde rungen die Leistungsanforderungen die Entwurfsrestriktionen und die Produkt Leistungen sowohl zeitbezogen als auch umfangsbezogen Die Beschreibung der Funktionalit t beruht auf Gesch ftprozessen und den Arbeitsschritten Beschreibung des Handlungsrahmens PS Es werden die Hauptszenario der Anwendung zu ei ner allgemeinen Beschreibung des Story Raumes verdichtet Jedes Szenario l t sich da durch als ein Durchlauf durch den Story Raum darstellen Die Grobdarstellung des Story Raumes durch einen Handlungsrahmen umfa t die Beschreibung von Szenen Dialogschrit ten und die Assoziierung jeder Szene mit einer Sicht und der erforderlichen Funktionalit t Die Beschreibung der Funktionalit t erfolgt aus der Benutzungssicht Benutzer werden zu Gruppen von Benutzern mit einem Benutzertyp zusammengefa t und allgemein mit ihren Aufgaben Rechten Rollen und Verantwortlichkeiten beschrieben Die Beschreibung des Handlungsrahmens f hrt zu einer Darstellung der Stories und der Freig nisse Beschrei
195. gen modelliert Die Prozesse veranlassen legale Transitionen von Zust nden Darauf aufbauend k nnen die Integrit tsbedingungen durch Bedingungen zur Ausf hrung und durch Nachbedingun gen f r Prozesse dargestellt werden Integrit tsbedingungen die durch Transitionsbedingungen nicht darstellbar sind werden f r Pflegeroutinen aufbereitet Mit der Proze definition kann die Definition der Semantik abgeleitet werden Je nach Proze modell wird eine axiomatische parallele kausale etc Semantik benutzt Wir benutzen ein Zustandstransitionsdiagramm zur Darstellung Die Aufgaben und Proze koordination folgt den Zusammenh ngen in den Gesch ftprozessen Wir unterscheiden f r die Prozesse Retrievaldaten die als Input f r die Prozesse aus der Daten bank dienen Inputdaten der Akteure Outputdaten zum Zur ckschreiben in die Datenbank Display daten zur Darstellung in den Dialogen und Begleitdaten die aus vorhergehenden Prozessen stammen und zur Darstellung der Informationen w hrend der Dialogschritte dienen Damit k nnen Prozesse auch einander beeinflussen und sind nicht nebenwirkungsfrei Damit werden f r die Prozesse auch Interaktionsdiagramme und Koh sionsbeziehungen entwickelt Damit erhalten wir ein allgemeines Workflow Modell Die drei R s von Workflow Modellen sind Routen Szenario durch einen Ablaufgraph Regeln zur Darstellung der verarbeiteten Information und Rollen mit einer Zuordnung zu den handelnden Personen Akteuren D
196. genit t der Plattformen verursacht durch unterschiedliche Betriebssysteme Hardware Datenbank Management Systeme bzw Programmiersprachen Heterogenit t durch unterschiedliche Programmiermethodiken Heterogenit t der Datenbankschemata Heterogenit t der Funktionalit t der Informationssysteme und Heterogenit t der Story R ume Nicht alle Spielarten der Heterogenit t k nnen durch entsprechende Kollaborationssysteme berwunden werden Hauptmechanismen zur berwindung der Heterogenit t sind entsprechen de Abbildungen bzw Mediatoren Konsistenz Objekt Suiten d rfen keine Konflikte der unterschiedlichen Komponenten der Kollabora tion untereinander besitzen Die Konsistenz wird durch die L sung einer Reihe von Problemen unterst tzt Herausfiltern potentieller Konflikte Die Konsistenz von Objekt Suiten kann berechnet werden solange Objekt Suiten hierarchisch strukturiert sind und die Integrit tsbedingungen stra tifizierbar sind In vielen F llen ist ein Herausfiltern von Konflikten m glich Das Auffinden von Inkonsistenzen kann durch die Modellierung der Inkonsistenz und Konfliktbedingun gen einfacher werden Beweis von Eigenschaften Der Nachweis von Spezifikationskonflikten ist an die Axiomatisier barkeit bzw Entscheidbarkeit von Klassen von Integrit tsbedingungen gebunden Deshalb k nnen nur einfache Eigenschaften gepr ft werden Pflege der Konsistenz bei Modifikation Eine Modifikation der Datenbank kann auc
197. gnisse die zum Schritt f hren sowie die agierenden Akteure der Szene Formal k nnen wir diese Begriffe von SiteLang wie folgt einf hren Der Story Raum ist ein gerichteter bewerteter Graph bestehend aus Szenen und den Transitionen zwischen den Szenen d h Story Raum Szene E A k E C Szene x Szene A Szene SzeneBeschreibung ko E TransitionBeschreibung TransitionBeschreibung C Ereignisse U Aktivit ten x Akteure x Vorbedingung x Nachbedingung x Priorit t x H ufigkeit x Wiederholrate Eine Szene besteht aus Dialogausdr cken dem Content einer Darstellung der Akteure einer Re pr sentation und dem Kontext d h Szene SzenelD DialogueSchrittAusdruck Content Suite Akteure AkteurlD Rechte Aufgaben Zuordnung Rolle Repr sentation Stil Defaultwerte Betonung Kontext Hardware Software Kanal Intention Datenbank Unterst tzung f r den Story Raum Es sind verschiedene Repr sentationen f r Szenen und Dialogschritte m glich F r komplexere Anwendungen ist eine Datenbankablage der Elemente von SiteLang w nschenswert Dies kann durch eine Struktur wie in Bild 45 erfolgen Damit sind dann auch in einfacher Form einzelne Schritte eines Szenario abwandelbar ohne im Detail alle Strukturen Oberfl chen und Prozesse durchmustern zu m ssen Der Vorteil dieser Abbildung des Story Raumes liegt auf der Hand Es k nnen nderungen jeder Ra 2 0
198. granularit t Die Abstraktion der verschiedenen Typen ist unterschiedlich Zum Bei spiel sind Vorlesung und Kurs in unserem Beispiel nicht auf gleichem Abstraktionsniveau Verschiedene Zeitma e und Wertebereiche Die Repr sentation und die Wertemengen von Attribut Typen k nnen einander entsprechen ohne da dies direkt ersichtlich ist Fehlende Typen Da Sichten eine eingeschr nkte Welt repr sentieren sind sie unvollst ndig Semantische Unterschiede Die Bedeutung bzw Semantik der Konzepte ist unterschiedlich Unterschiede im G ltigkeitsbereich Es gelten weder Inklusions noch Exklusions noch die ne gierten Inklusions noch die negierten Exklusionsabh ngigkeiten Wertesemantik Die Bedeutung der Werte umfa t zus tzliche Werte wie z B die Matrikelnum mer die das Immatrikulationsjahr mit einschlie t Verschiedene Konstruktoren bei Synonymen Verschiedene Konstruktoren f r quivalente Men gen f hren zu relativ komplexen Integrit tsbedingungen die in den Sichten fehlen Verschiedene Operationen Auf den Typen sind unterschiedliche Operationen definiert die nicht inte grierbar sind Verschiedene Wertebereiche Synonyme Typen besitzen verschiedene Wertebereiche Wir k nnen jedoch mit dem ER Modell Mechanismen bereitstellen die eine Kooperation von Sichten unterst tzen Gegeben seien die Sichtenschemata und Gz und entsprechende Datenbanken GF und 65 he nn San s da Z lb E A See 102 B T
199. h die Konsi stenz zerst ren Mit Transaktionsmodellen kann dem entgegengewirkt werden Konsistenzinseln erlauben auch die Benutzung von global inkonsistenten Datenbanken Sie m ssen explizit formuliert werden Dauerhaftigkeit Die Persistenz von Ver nderungen erfordert eine Abspeicherungsstrategie f r erfolgte Ver nderungen bzw eine Zur ckf hrungsstrategie Die Dauerhaftigkeit wird durch die klassische Datenbanktechnologie unterst tzt Robustheit von Systemen erfordert Fehlertoleranz Es treten unterschiedliche Arten von Fehlern auf Benutzerfehler werden durch eine falsche Benutzung der Dienste durch autorisierte Benutzer verursacht Durch eine gute Gestaltung des Story Raumes k nnen diese Fehler vermieden werden Ihre Behebung ist deshalb nicht Teil der Spezifikationsanforderungen f r verteilte Systeme Systemfehler k nnen in verteilten Systemen in unterschiedlicher Form auftreten e Diensteverweigerungs und Auslassungsfehler entstehen durch Nichtausf hrung eines Befehles durch den Kollaborationsdienst oder den Kommunikationskanal Da ein all gemeines Fehlererkennungsmodell nicht existieren kann ist eine Spezifikation zur Be aa ba asa olmas 0 0 Aa b 150 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 8 VERTEILUNG e Zuf llige Fehler oder byzantinische Fehler sind alle Fehler die nicht eindeutig zuge ordnet werden k nnen bzw die eine Beliebigkeit aufweisen e Timing Fehler treten beim Vorh
200. h ein Sitzung Container zur Verfiigung gestellt In diesem Container werden die Sitzungen mitprotokolliert Damit ist dann auch eine Weiterf hrung eines bereits partiell durchlaufenen Workflows m glich Funktionen der Sitzungsverwaltung sind insbesondere Funktionen zum ffnen Protokollieren und Schlie en von Sitzungen mit denen ein Arbeitsstand gespeichert werden kann die Erhaltung pers nlicher Daten gew hrleistet wird mit denen Nebensitzungen und Gruppensitzungen unterst tzt werden Absicherungsfunktionen zur Absicherung der Sitzungsinformation und der Workspace Information vor unberechtigtem Zugriff oder unberechtigter Modifikation Weitergabefunktionen mit denen Sitzungsinformationen an andere Benutzer oder Funktionen weitergegeben bzw andere Benutzer kontaktiert werden k nnen und L schfunktionen mit denen ltere Sitzungen gel scht werden k nnen Eine einfache Form der Sitzungsverwaltung stellen Cookies dar Neben diesen Funktionen k nnen auch Funktionen f r Gruppensitzungen zur Verf gung gestellt werden Diese Funktionen unterst tzen eine effiziente Arbeit von Gruppen wie z B Gremien eT o o bo ud a 2 db x s 4 9 j ASi CEO E I si PON OL INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 91 Funktionen zur Darstellung der Arbeit der Gruppen mit variabler Sichtbarkeit der Tagesordnun gen Dokumente und Nachrichten je nach Freigabe Funktionen zur Ver ffentlichung
201. h von der Umgangssprache her und die sprachlich ein fach ist Vertrautheit und Nutzbarkeit Ein Benutzer soll die Form der Benutzung und insbesondere die Szenario nicht erst erlernen sondern sollte aufgrund seiner Erfahrungen das System einfach handhaben einfach erlernen und schnell die Arbeit an beliebiger Unterbrechungsstelle wieder aufnehmen k nnen Diese Merkmale k nnen mit entsprechenden Metriken unterlegt werden Diese Forderungen wurden in der Cottbuser Arbeitsgruppe unter dem Begriff omasicher zu sammengefa t e Ein Informationssystem sollte ohne zus tzliche Ausbildung in einfacher Art aufgrund von offensichtlichen Optionen f r jedermann innerhalb des Erwartungshorizontes des Benut zers mit kontextsensitiver Hilfe mit entsprechender Wortwahl mit einfachen Dialogen und Teilaufgaben benutzt werden k nnen e Es sollte stets der aktuelle von Benutzer auch real angeforderte Inhalt in dem Moment pr sentiert werden in dem ihn der Benutzer auch ben tigt e Es sollten dem Benutzer keine nicht nachvollziehbaren Wartezeiten zugemutet werden e Das System sollte einfach benutzbar sein Fehler des Benutzers tolerieren solange diese aufgel st werden k nnen und von hoher Benutzbarkeit sein Wir fassen diese vier Forderungen unter dem Stichwort HOME zusammen High quality content Often updated Minimal download time und Ease of use Die Dimensionen des Gestaltungsrahmens Wir k nnen den Gestaltungsrahmen um
202. h weitergef hrt werden k nnen Sitzungsobjekte k nnen direkt realisiert werden oder mit einem Verpackungsumschlag in das verpackte Content Objekt integriert werden Funktionen wie Markierungsfunktionen sind durch Sichten die ber materialisierten Sichten entstehen darstellbar Deshalb ist keine Neuentwicklung notwendig sondern nur ein Spezifikationsrahmen zur Verf gung zu stellen Dieser Rahmen kann zu folgendem Rahmen verallgemeinert werden generate MAPPING VARS AUSGABESTRUKTUR from DATENBANKTYPEN where AUSWAHLBEDINGUNG represent using ALLGEMEINER PRASENTATIONSSTIL amp ABSTRAKTION GRANULARITAT MASSEINHEIT PRAZISION amp ORDNUNGEN DER PRASENTATION amp HIERARCHISCHE DARSTELLUNGEN amp SICHTWEISEN amp SEPARATION browsing definition BEDINGUNG amp NAVIGATION functions SUCHFUNKTIONEN amp EXPORTFUNKTIONEN amp EINGABEFUNKTIONEN amp SITZUNGSVERWALTUNG amp MARKIERUNGSFUNKTIONEN INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 85 Damit k nnen wir f r die Sichten Suite in einem Vierschritt Verfahren die Spezifikation erstellen Das Resultat dieses Spezifikationsprozesses nennen wir Content Typ Eine Instanz eines Content Typs nennen wir Content Objekt Eine Content Klasse enth lt demzufolge Content Objekte des gleichen Content Typs Die Spezifikation eines Content Typs erfolgt durch schrittweise Erweiterung Wir unterscheiden drei Gesichtspunkte Content Objekte werden den Akteuren zur Verfiigung gestel
203. harts Addison Wesley Harlow 1999 L J Heinrich and G Pomberger Theorie und Praxis der Wirtschaftinformatik 9 1997 W H Inmon J A Zachman and J G Geiger Data stores data warehousing and the Zachman framework McGraw Hill New York 1997 R Kaschek Konzeptionelle Modellierung Habilitationsschrift Universit t Klagenfurt 2003 A Kemper and A Eikler Datenbanksysteme Oldenbourg Verlag M nchen 1996 A Kemper and A Eikler Datenbanksysteme Oldenbourg Verlag M nchen 2001 P Kandzia and H J Klein Theoretische Grundlagen relationaler Datenbanksysteme Bibliogra phisches Institut Darmstadt 1993 M Klettke and H Meyer XML amp Datenbanken Konzepte Sprachen und Systeme dpunkt verlag Heidelberg 2003 E K the and M Thun Marketing mit Bildern Management mit Trend Tableaus Mood Charts Storyboards Fotomontagen und Collagen DuMont K ln 1995 J Kunze Generating verb fields In Proc KONVENS Informatik Aktuell pages 268 277 Sprin ger 1992 in German M Leonard Database design theory MacMillan Houndsmills 1992 C L ckenhoff D Fensel and R Studer eds CommonKADS Proc 3rd KADS meeting M Levene and G Loizou A guided tour of relational databases and beyond Springer Berlin 1999 M Levene and G Loizou Why is the snowflake schema a good data warehouse design Information Systems 28 3 225 240 2003 P C Lockemann and H C Mayr Computer based information systems
204. hen Notation bei der ein Entity Typ mit einer Definitionsgleichung dargestellt wird Zum Bei spiel ist ein Person Typ spezifiziert durch Person Name Adresse Kontakt GebDatum PersNr StudNr U MitarNr 0 mit einer Folge von Attributen Markierungen sind als solche ausgewiesen Ein Entity Typ wird durch ein Rechteck graphisch reprasentiert Eine Entity Klasse besteht aus einer Menge von Objekten vom Entity Typ die die statischen Integrit tsbedingungen des Entity Typen erf llt Zum Beispiel ist das folgende Objekt mit dem Identifikator 8 0 lt Karl z Bernhard r gt Thalheim Prof Dr rer nat habil Dipl Math BTU Cottbus 49 355 692700 49 355 692397 49 355 824054 thalheim informatik tu cottbus de 10 3 52 637861 vom Entity Typ Person wobei mit z der Zusatzname und mit r der Rufname bezeichnet wird Einfacher Relationship Typ Ein Relationship Typ erster Ordnung besteht aus einer nicht leeren Folge von Entity Typen einer Menge von Attributen und einer Menge von statischen Inte grit tsbedingungen Eine Menge von der Struktur des Relationship Typen ist eine g ltige Menge wenn sie den statischen Integrit tsbedingungen gen gt Elemente k nnen markiert sein Ein Beispiel sind die Relationship Typen InGruppe Person Gruppe Zeit Von Bis Funktion 0 Direkt Voraussetz setztVoraus Kurs vorausges Kurs 0 0 Professor Person Berufungsgebiet E
205. hreibweise bzw die Art der Abk rzungen ist f r Texte zu vereinheitlichen Die Schl sselanpassung ist notwendig um gleichartige Information herauszufinden um eine In formationsverarbeitung und Verweise auf analoge Informationen zu erm glichen Die Proze reinigung ist ebenso wie die Datenreinigung erforderlich Dabei h ngt viel von der Qua lit t der Dokumentation ab Die Allokation der gewonnenen Daten und Prozesse im Warenhaus ist so vorzunehmen da diese Daten und Prozesse durch die Benutzer auch effizient und mit minimalem Aufwand be 5 INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 173 Die Herkunftskennzeichnung dient sp ter im Updateproze als Information zur Identifikation der zu ver ndernden Daten Diese Prozesse k nnen nicht innerhalb nur eines Schrittes durchgef hrt werden wie einige Firmen heute glauben machen Die Speicherkomponente ist f r sehr gro e Datenbanken auszulegen Damit ergeben sich eine Reihe von Eigenschaften Extrem gro e Tabellen Die Tabellen bertreffen in ihrer Gr e und auch Komplexit t oft die derzeitigen M glichkeiten Hohe Verflechtung der Daten Die Daten sind oft hochgradig ineinander verwoben Oft werden auch Makrodaten Daten die aus den Mikrodaten der Datenbanken gewonnen werden neben Mikrodaten verwaltet Ad hoc Zugriff berwiegt In Datenbank Warenhaus Anwendungen berwiegt der Ad Hoc Zugriff auf die Daten Zugleich sind jedoch die Benutze
206. htbar Allen verteilten Datenbanksystemen ist die Verteilung der Daten auf verschiedene Knoten und die lokale Verarbeitung von Anfragen durch die lokalen Komponenten gemeinsam Mitunter werden auch verteilte Dateisysteme als verteilte Datenbanksysteme bezeichnet Obwohl Dateisysteme als Datenbanksysteme der ersten Generation aufgefa t werden k nnen haben sie wenig gemeinsam mit Datenbanksystemen Die Funktionalit t von verteilten Datenbanksystemen kann nach der folgenden Tabelle unterschieden werden Merkmale verteilter Homogene Interope F de Offene Datenbanksysteme eng integr rable rierte Multi DB Physische Verteilung der Daten Logische Sicht als eine Datenbank Nichtsichtbarkeit der Verteilung Gemischter DB Zugang glob lok Zerlegung glob Anfragen durch DBMS Lokale Ausf hrung von Teilanfragen Globales Transaktionskonzept 162 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 8 VERTEILUNG Das verteilte System ist von au en als ein homogenes System sichtbar Es besitzt ein integriertes Schema Die lokalen Systeme sind nicht autonom Das Transaktionskonzept ist global Damit werden Leistungsanforderungen wie im Falle zentraler Datenbanksysteme anwendbar Dar aus resultiert auch die Anwendungsbreite e Hochleistungsdatenbanksysteme durch Nutzung der Parallelverarbeitung e Fehlertolerante Datenbanksysteme durch Nutzung der kontrollierten
207. hungen der Anwender und die Beziehungen des Benutzers mit dem System k nnen durch Beziehungsstrukturen dargestellt werden Diese Beziehungsstrukturen k nnen Ethik regeln unterliegen oder explizit formuliert sein Wir k nnen wie im Falle der aspekt orientierten Programmierung auch auf allgemeine Beziehungsstrukturen zur ckgreifen oder explizit die Einhaltung der allgemeinen Gesch ftsbedingungen postulieren Arten der Aktivit t werden durch Verbgruppen mit Verben der Handlungen wie kaufen lernen und informieren ergative Verben wie fliehen Proze verben wie einschlafen ingressive Prozesse und verbl hen egressive Prozesse und Verben zur Beschreibung eines Zustandes wie schlafen oder haben relativ gut charakterisiert Wir sind f r Informationssysteme an der ersten und der letzten Verbgruppen st rker interessiert In diesen beiden Gruppen unterscheiden wir e Verben des Geschehens e Verben des Zunehmens Verben der bereinstimmung Verschiedenheit Verben des Mitteilung Verben des Argumentation Verben der Zustimmung Verben der Leitung Verben des Zusammentreffens Verben der sinnlichen Wahrnehmung Verben der Nahrungsaufnahme und Verben des Reinigens Die ersten acht Gruppen sind f r Informationssysteme relevant und k nnen zu speziellen Kooperationsrahmen verwendet werden Diskurstypen in der Zusammenarbeit k nnen nach der Konversationstheorie unterschieden wer den in Handlungen Es wird der Partner zu einer Hand
208. iablen weitere Informationen z B zu den Autoren und zu Klassifikation f r das Content Objekte Angaben zur Funktionalit t des Content Objektes d h e zu Durchmusterungsfunktionen e zu Integrationsfunktionen e zu Markierungsfunktionen und e zu Funktionen zur Sitzungsverwaltung Prozeduren und Programmme zur Anpassung des Content Objektes an den aktuellen Benutzer d h e zur Anwendung von Abstraktionen azala A aa a a 46 s INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 95 e zur Anpassung an den inhaltsbasierten Repr sentationsstil Ein Content Objekt wird e gef von einem Akteur mehrfach benutzt e ggf von einem Akteur mit entsprechenden Anmerkungen unter Benutzung der Markierungs funktionen versehen und e erfordert eine Aufzeichnung der Benutzungsgeschichte Diese Aufzeichnung wird mit einem Anh nger dem Content Objekt zugeordnet Verpackungsum schl ge Kuvert envelops docket dienen als Anh nger Sie enthalten 1 eine allgemeine Inhalts Information in der e die Sourcen der Provider die Autoren und die Benutzungsinformation mitgef hrt werden e der Inhalt und die unterst tzten Aufgaben die Eignung und die Art der Erzeugung dar gestellt werden und e die Qualit tsbewertungen f r das Content Objekt angegeben werden 2 eine Anwendungsanleitung f r das Content Objekt die auch Anmerkungen zu folgenden Dingen umfa t e Vertrauensw rdig
209. iche Mitteilungen sein ffentliche Dokumente werden in Wandzeitungen etc ver ffentlicht Dokumente k nnen verpackt und entpackt editiert oder auch nur gelesen werden Es werden den Mitgliedern eigene Arbeitsr ume z B Schreibti sche und pers nliche Speicher zur Verf gung gestellt Der Zeitrahmen wird durch die Zusammenarbeit der Arbeitsgruppe vorgegeben Kooperation Vollst ndiges Dokument eyi Intention Aufgaben Mitglied Deadline Leiter Rollen Verantwortlichkeit Zeitbeschr nkung Ablauf Moderator Phase Arbeitsgruppenmitglied Zeitintervall Gemeinsame we a a ruppendokumente Wandzeitung ffentliche Art 77 Existenz Lebensspanne Schreibtisch Privat Pers nlicher Speicher Funktionalit t Content Editieren ERU mustern Meinung nt Verpacken Antwor 4 R ume hi Arbeitsresultate Protokoll u TC 000 Y Report Programm Bild 49 Der Spezifikationsrahmen f r Arbeitsgruppen Sites Der Spezifikationsrahmen f r einen Beitrag eines Arbeitsgruppenmitgliedes wird in Bild 50 vor gestellt Die Akteure sind diesmal Mitglieder einer Redaktionskommission Sie erstellen kommentieren und lesen gemeinsame Beitr ge Der Story Raum umfa t z B den Dialogschritt einer Beitragserstellung Die Content Objekte sind Beitr ge Sie werden mit der blichen Funktionalit t wie bei Textedi tiersystemen unterst tzt Die Beitr ge k nnen abgelegt zwischengespeichert oder auch gel scht werden Der Zeitrahme
210. ichen nur die Entwicklung von Information innerhalb eines Informations systemes und weniger die Entwicklung von Systemen selbst Die Abstraktion wird ebenfalls nur in als konservative Abstraktion behandelt Wir nutzen die Modellierung und konzentrieren uns weniger auf Abbildungen und Verfeinerungsmechanismen Aus diesen vier Prinzipien leiten wir deshalb die vier Modellierungsaufgaben ab Modellierung der Strukturierung Modellierung der Funktionalit t Modellierung der Verteilung und Modellierung der Interaktivit t Im Abstraktionsproze kann man unterschiedliche Aspekte betrachten e Wir unterscheiden drei Abstraktionsarten e Die Komponentenabstraktion kann aufgrund unterschiedlicher Konstruktoren unterschied liche Auspr gungen besitzen e Die Klassenabstraktion orientiert sich auf die Unterscheidung von Instantiierung und Klassifizierung e Die Konstruktorabstraktion orientiert sich an der Benutzung der im Datenbankmodell vorhandenen Konstruktoren Daraus resultieren Operationen wie die Aggregation und die Dekomposition e Die Beziehungen zwischen Klassen k nnen explizit modelliert sein Durch Teiltypenhierarchien werden die Generalisierung und Spezialisierung von Klassen dargestellt Die Konstruktionsbeziehungen folgen meist der Definitionsbeziehung Abbildungsbeziehungen werden f r Datenbanken auf die Sichtenmodellierung redu ziert e Die Lokalisierungsabstraktion orientiert auf eine Verallgemeinerung ohne Bezug zur k
211. icht der Geschichte Es k nnen damit auch Informationen vermittelt werden Informationsquellen Jede Oberfl che jeder Dialogschritt vermittelt Informationen Damit wird eine Oberfl che zur Informationsquelle Die Vielfalt der Informationen kann auch durch die Kombination verst rkt abgeschw cht oder auch beigeordnet werden Durch eine neue Information kann auch eine Ver nderung implizit angezeigt werden Wird die In formation komplexer dann ist die Wiederholung ein n tzliches und angebrachtes Mittel Verdopplung kann verwendet werden um Daten die ben tigt aber evt vergessen werden wieder in Erinnerung zu bringen Typische Verdopplungsfunktionen sind Statusleisten Sie sind jedoch mit Vorsicht zum richtigen Zeitpunkt mit der richtigen Information anzuwen den Die Vielfalt an zu vermittelnder Information ist in geschickter Anordnung Arrange ment Koordination dem Akteur zu vermitteln Dabei ist auch die semantische Konsistenz zu beachten Widerspr che deuten auf Fehler hin Informationsquellen d rfen nicht mit Symbolismus verwechselt werden der eher eine un geeignete Art der Bildkonzeption ist Bildauswertung und Bildkomposition Jede Szene in der Inszenierung und jede Oberfl che besteht aus kleinen Einheiten die wiederum aus kleinen Einheiten zusammengef gt sein k nnen Sie setzen sich zu einer Einstellung zusammen die sich auch je nach Betrach tungspunkt ver ndern kann Das Blickfeld selbst ist begrenzt Es wird nur ein re
212. ie Prozesse werden damit ber diese Einbindung in das Schema auch f r die Sichten benutzbar Damit erhalten wir ein Entwurfsviereck bestehend aus der Datenspezifi kation der Funktionsspezifikation der Verteilungsspezifikation und der Dialogspezifikation Das Zachman Modell zur Separation von Aspekten Durch Zachman wurden Ende der achtziger Jahre allgemeine Modellierungsregeln eingef hrt die mit dem Abstraktionsschichtenmodell verallgemeinert werden e Es werden verschiedene Dimensionen der Entwicklung unterschieden e Die Dimension der statischen Aspekte stellt Strukturierung der Daten und die Sichten dar e Die Dimension der dynamischen Aspekte soll die Funktionalit t und die Interaktivit t der Anwendung repr sentieren e In der Verteilungsdimension wird die Lokalit t der Strukturen und Prozesse dargestellt e Die Benutzerdimension dient der Darstellung des Systemes aus Benutzersicht einschlie lich der Organisationsmodelle e In der Zeitdimension wird die Entwicklung der Anwendung dargestellt e Mit der Motivationsdimension erfolgt eine explizite Darstellung der Umst nde Ziele und Motive f r die einzelnen Aspekte der Anwendung e Jede der Dimensionen verf gt ber ein einfaches und eindeutiges Basismodell e Jede der Dimensionen repr sentiert genau eine Sichtweise auf die Anwendung e Jedes abstrakte Objekt wird nur einmal repr sentiert e Entwurfsprodukte sind aufgrund ihrer Architektur und Entwurfsgeschichte rekur
213. ie auf dem Niveau der Interaktivit t keine Rolle spielen Deshalb sind Workflows berladen e Handlungsabl ufe der Realit t m ssen sich nicht zwingend im Workflow widerspiegeln Dem zufolge werden Workflows funktional unvollst ndig e Handlungsabl ufe auf Systemniveau und auf Interaktionsniveau unterscheiden sich im Abstrak tionsniveau Deshalb besitzen sie eine unterschiedliche Granularit t e Handlungsabl ufe auf Interaktionsniveau stellen auch die Zusammenarbeit von Akteuren dar die sich nicht zwingend im System widerspiegeln mu Demzufolge sind Workflows organisato risch unvollst ndig e Workflows zur Spezifikation der Funktionalit t sollten den konkreten Handlungsablauf nicht in Beziehung zum Kontext setzen In klassischen Herangehensweisen werden aber die unter schiedlichsten Varianten des gleichen Workflows je nach Kontext als eigenst ndiger Workflow dargestellt Es entsteht eine Workflow Lawine deren Beherrschung und berschaubarkeit nicht mehr gegeben ist Wir bevorzugen dagegen eine Trennung von dynamischen Gesichtspunkten in Stories zur Darstellung der Handlungsabl ufe auf Interaktionsniveau und Workflows zur Darstellung der Handlungsabl ufe auf Systemniveau Workflow Klassen Workflows und Workflow Felder Die Beschreibung der Handlungsabl ufe lehnen wir dabei an die Formenlehre an In der Morpho Wan ine h Bed TER a I COs eR Di 7 0 5 See TL nn co 2410 her EEE 0z 74 B THALHEIM PRE
214. ie drei P s von Workflow Modellen sind Prozesse als das Kernst ck der Spezifikation k A x 0 nd een eae 64 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 5 FUNKTIONALIT T Praktiken der Anwendung die spezifische Seiten zum Ausdruck bringen F r die Verhaltensmodellierung ergeben sich neue Modellierungsforderungen e Erweiterte und abgeschw chte Transaktionsmodelle k nnen verwendet werden Dazu stehen als Al ternativen Konzepte des Transaktionsbaumes genesteter Transaktionen offene genestete Trans aktionen und kompensierende Teiltransaktionen zur Verf gung Das erweiterte ER Modell verf gt ber diese Mechanismen Es wird eine Transaktion allgemein mit einem Definitionsrahmen der Form transaction identifier parameter list 01 02 Om end angegeben Die Operationen o sind HERM Operationen Sie k nnen parametrisiert sein Weiterhin sind geschachtelte Transaktionen P P2 P zugelassen die ihrerseits wiederum aus Folgen von Komponenten Transaktionen bestehen Die Semantik der geschachtelten Transak tionen basiert auf einem schrittweisen Abschlu der Komponenten Transaktionen F hrt eine der Komponenten Transaktionen zu einem Fehler dann wird die gesamte geschachtelte Trans aktionen abgebrochen Au erdem sind zugelassen e kompensierende Transaktionen compensated_by P bei denen bei einem Auftreten eines Fehlers die Transaktion zu einer Kompensation des Fehlers ben
215. ie stattfanden in denen aber Studenten keine Abschliisse erreichten werden ebenfalls gespeichert Sie sind jedoch fiir die Archivsicht nicht mehr von Interesse Die Archivsicht wird ber dem Schema in Bild 20 als allgemeiner parametrischer Ausdruck Archiv SemesterBezeichnung mit obigem Rahmen spezifiziert Sie wird instantiiert mit Archiv SS01 02 Der erste Teil der Sichtendefinition lautet somit generate t Person gt Person tkurs Kurs tgehalteneLv gt gehalteneLehrveranstaltung t Studiengang Studiengang t Typus Typus t Professor Professor from tKurs gehalteneLV Kurs t Person gehalteneLV geplanteLV angeboteneLV Verantwortlicher4LV Person Studiengang Typus 1 Professor tgehalteneLV gehalteneLV geplanteLV angeboteneLV Kurs Studiengang Dozent Professor Verantwortlicher4LV Person Typus where Bezeichnung SemesterBezeichnung Sie ist mit einem Parameter Semester als materialisierte Read Only Sicht in Bild 34 dargestellt Mit dieser Sicht ist eine Modifikation der Daten nicht mehr erlaubt Sie kann nur als Anfragesicht verwendet werden Bezeichnung SS01 02 e Person 2 Kurs Semester l L retrieve _ slice sort _ retrieve Studiengang retrieve Typus retrieve Bild 34 Content Typen zur Archivsicht auf gehaltene Lehrveranstaltungen Darstellung von Sich
216. ierungskonzepte Die Partitionierungstiefe kann bei einer Partitionierung von keine Partitionierung bis zu einer Par titionierung auf Attribut bzw Objektniveau reichen u u a E El ten 4 9 nn Sn EEEL OO See Tech A AEE i EEE E EE E A P E INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 161 Vollst ndigkeit In Analogie zur Eigenschaft der verlustlosen Dekomposition bei der Normalisierung k nnen Klassen in mehrere Teilklassen oder anhand von Teilstrukturen in Partitionen zerlegt werden Eine Eigenschaft eines Objektes kann dabei einmalig oder mehrmalig repr sentiert sein Rekonstruierbarkeit Je nach Zerlegung bzw Partitionierung existiert eine Funktion V zur Wieder herstellung der urspr nglichen Klassen Disjunktheit Die Partitionen sind entweder disjunkt oder es existiert ein Algorithmus mit dessen Hil fe gleiche Eigenschaften eines Objektes in verschiedenen Partitionen gepflegt werden k nnen Meist kann ein solcher Algorithmus ber Identifikationsmechanismen definiert werden Sobald eine Datenbank partitioniert ist mu eine Allokation der verschiedenen Partitionen zu den Knoten des Netzes erfolgen Die Partitionierung und Allokation werden ebenso wie im Falle zentraler DBS in einem Datenbank Katalog data dictionary DD verwaltet Ein zugeordnetes Datum kann dabei repliziert oder einmalig einem Knoten zugeordnet sein Es k nnen Prozesse f r Daten in zwei Extremen unterst tzt werden
217. ige Abh ngigkeit 51 Mengen Operationen 61 Metapher 137 Metaphorikrahmen 144 Mockup 109 Modallogik 71 Modellierungswelt 149 Modifikation von Objekten 61 Motivationschicht 34 Multiple choice Workflow 77 Notwendig giiltig 71 Objekt 43 Objekt Gesellschaft 52 Ontologische Einheit 81 177 Open world assumption 5 Parallelisierter Workflow 77 Partitionierung 159 Partizipation Notation 49 Pers nlichkeitsprofil 114 Pflegeschicht 35 Pflichtenheft 37 Plot 107 Polarit tenprofil 114 Portabilit t 148 Portfolio 98 Potenzmenge 62 Pr dikat 60 Pr ferenz 116 Pr sentationsraum 111 Pragmatik 5 Pragmatische Annahme 5 Pragmatisches Axiom 5 Pragmatismus 5 Prinzipien der Informatik 6 Produktdaten 81 176 Produktdatenskizze 81 176 Produktfunktion 176 Produktfunktionalit t 176 Profil 114 Programme 68 Projektion 61 Proze 36 Rechtetyp 119 Relationship Klasse 45 Relationship Typ 45 Se 241 4 190 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 INDEX Rolle 119 Schachtelung 61 Schema 3 36 51 Schema Morphismus 101 Schliissel 49 Schnappschuf 71 Schneeflocken Schema 93 Selektion 61 Semantik 5 Semiotik 5 Sicherheit 148 Sicherheitsoption 117 Sicherheitsprofil 116 Sicht 37 Sichten des Lastenheftes 81 Sichten des Pflichtenheftes 81 Sichtenintegration 101 Sichtenkooperation 101 Sichtenskizze 81 177 Sitzungs Objekt 100 Sitzungs Sche
218. il aufgesplei t werden so da jede nderung in der Anwendung eine andere Hierarchie bringt Die Darstellung semantisch sinnvoller Einheiten ist so einfach wie m glich zu gestalten Damit ist die Bedeutung einfach herauslesbar Jede semantische Einheit besitzt eine einfach erkl rbare Bedeutung Jeder Fakt wird nur einmal repr sentiert wodurch Anomalien vermieden werden Jede Asso ziation erscheint nur einmal Zerlegbare Fakten sollten in Abh ngigkeit von den updates auch zerlegt dargestellt werden Beispiele eines ung nstigen Entwurfes sind solche die eine update Anomalie besitzen Surrogat Attribute werden demzufolge erst auf logischen Niveau wirksam Durch Sicherung der Identifizierbarkeit jeden Faktes wird auch eine Modifikation einzelner Fakten erm glicht Durch eine saubere Unterscheidung der Nullwerte unbekannt nicht anwendbar etc kann auch eine entsprechende Funktionalit t unterst tzt werden Nicht anwendbare Werte deuten auf un saubere Modellierung Eine bessere Modellierung ist die Darstellung durch Teiltypen Schwie rigkeiten bei Anfrageauswertung und formulierung k nnen so umgangen werden Es gibt struk turelle Nullwerte und Ausnahmenullwerte Wir ben tigen klare Regeln f r die Zuordnung zu den Konzepten Attribut oder Entity Typ oder Relationship Typ Mitunter mu auch f r Konzepte die eigentlich durch Attribute dargestellt werden ein Entitytyp eingef hrt werden Attributnamen dienen einer intuitiv ve
219. ile durch Individuen im Modellierungskontext und das Dilemma der Modellierung 22 ee daa aa ha a ana 16 Integrierte Entwicklung von Strukturierung Funktionalit t Interaktivit t und Verteilung 19 Semiotik Darstellung von Content Konzepten und Begriffen 21 Die Mindmap Strukturierung der Spezifikation von Konzepten 23 Das Person Konzept mit obligatorischen allgemeinen und optionalen Bestandteilen 24 Die Kombination von Konzepten Person Rolle und Adresse 24 Konzept und begriffsbasierte Anfrageschnittstellen von Informationssystemen 26 Die Infrastruktur f r die integrierte Entwicklung von Informationssystemen 27 Die Unterst tzung von Informationssystem durch Datenbanksysteme und Content Typen 27 Entfernter Funktionsaufruf mit einer Schichtung ALSS08 1 29 Entwurfseinheiten auf verschiedenen Abstraktionsebenen 33 Entwicklungsdimensionen f r dei Entwurfsdokumente 34 Das Abstraktionsschichtenmodell des Informationssystem Entwicklungsprozesses 35 Schritte in unserem Vorgehensmodell 40 Semi strukturiertes Attribut Name 45 HERM Diagramme mit und ohne Relationship Typen h herer Ordnung 47 HERM Diagramm zu unserem Hauptbeispiel 2 47 Hierarchisches ER Diagramm versus HERM Diagramm 48 Kardinalit tsbeschr nkungen im Vorlesungsbeispiel
220. in Relationship Typ wird mit einer Raute graphisch repr sentiert Wir erlauben auch optionale Komponenten von Relationship Typen solange eine Identifikation ber die ob ligatorischen Elemente definiert ist Ein Objekt eines Relationship Typs ist ein Tupel das zu den jeweiligen Elementen auf die entsprechenden Objekte der Klasse der Elemente durch Angabe von identifizierenden Werten Identifikator bzw Prim rschl ssel bzw anderer Schl ssel verweist und Werte f r die Attribute des Relationship Typs besitzt a a N EEN h E io S A o A rl er a Os WS SE Sn gt 845 3 ok EE EE B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 4 STRUKTURIERUNG Integrit tsbedingungen gen gen z B sind Objekte der Typen Professor InGruppe und Direkt Voraussetz Prof 637861 Datenbank und Informationssysteme Senator3 637861 Senat 1995 1998 Dekan Senator5 637861 Senat 2000 Vorsitzender VorausDBIVHaupt DBIV DBI Cluster Typ Eine disjunkte Vereinigung von bereits konstruierten Typen wird als Cluster Typ bezeichnet Ein Cluster Typ wird mit einem amp Zeichen graphisch repr sentiert Beispiele sind durch folgende Typen gegeben JuristischePerson Person U Betrieb U Vereinigung Gruppe Senat U Arbeitsgruppe U Vereinigung die den Typ JuristischePerson bzw Gruppe als disjunkte Vereinigung von anderen Typen einf hren Cluster Typen k nnen weitere Attribute besitzen In diesem F
221. ine Neu bersetzung und ausf hrung mit aktualisierten Daten wie z B im System R vorgenommen wird Anforderungen an die Namensvergabe sind damit o eindeutige Bezeichner f r globale Objekte Relationen Sichten Indexe usw o Stabilit t gegen ber Datenumverteilungen Migration o Unterst tzung von Verteilungstransparenz und o lokale Namensvergabe Die Struktur des Namensraums kann entweder global unter Einsatz von Namensservern oder Na menskonventionen konzipiert sein woduch allerdings ein weiteres Zuverl ssigkeitsproblem entsteht oder hierarchisch sein wodurch die Knotenautonomie gew hrleistet wird die Netzwerk Partitionierung FT EEE d OL o a Laz od xo t n ULU aa s FORE mehr RE BE 164 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 8 VERTEILUNG Zur Namensvergabe kann eine dreiteilige Objektbezeichnung lt node id gt lt user id gt lt object id gt gew hlt werden Damit wird eine lokale Namenswahl durch Benutzer wie in zentralisierten Systemen unterst tzt Verschiedene Benutzer k nnen die gleichen Objektnamen verwenden Die Referenzie rung lokaler Objekte erfolgt wie im zentralen Fall Diese L sung erfordert jedoch die Verwendung von lt node id gt f r externe Objekte Damit wird die Ortstransparenz verletzt Eine nderung der Datenallokation erfordert auch Programm nderungen Es existieren eine Reihe Abhilfem glichkeiten Durch die Verwaltung von Synonymen Aliase
222. ine explizite Trans ferkomponente an Datenbank Farmsysteme wurden in YTST99 eingef hrt Sie nutzen die Mechanismen von Sichten Suiten aus Informationseinheiten sind verallgemeinerte Sichten Diese Sichten werden mit einer Funktionalit t ausgestattet die sowohl Retrieval als auch Modifikation von Daten als auch die Arbeit mit den Daten unterst tzt Container unterst tzen den Export und den Import von Daten Die Container k nnen je nach Bedarf ent und beladen werden Das globale Kollaborations und Farmsystem stellt entsprechende Dienste auf der Grundlage des Kol laborationsvertrages zur Verf gung Datenbank Farmen erfordern einen Entwurfsschritt mehr Wir k nnen mit der vorgeschlagenen i A ee SR Re AO OSS CO b ae 22 d Sees eo ng eer SENTEN OME En 215 x SU Bi INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG 8 169 Lokaler Benutzer von A Globale Benutzer Lokale Benutzer von B System A Benutzungs System B schnittstellen Benutzungs Benutzer schnittstelle schnittstelle Farm Farm container container system Globales system Kollaborations Lokale und Farme Lokale Anwendungen system Anwendungen Filter und Filter und 11105 2 7 Lokales system system Lokale DBS DBS Bild 70
223. inheiten auf verschiedenen Abstraktionsebenen Gleichzeitig beobachten wir da drei Dimensionen in der Modellierung auseinander gehalten Pena eRe 34 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 3 ABSTRAKTIONSSCHICHTENMODELL Abstraktionsschicht Die Schichtung sollte hierarchisch wie in Bild 14 erfolgen damit die Entwurfsdo kumente zueinander einfach in Beziehung gesetzt werden k nnen Architektur der Komponenten K nnen die Komponenten der Anwendung separiert werden dann kann auch eine Architektur der Komponenten mit expliziter Darstellung ihrer Zusammenh nge er folgen Versionen der Entwicklungsresultate Jedes Entwurfsdokument kann im Verlaufe der Entwicklung re vidiert werden Deshalb sollte man eine explizite Pflege von Versionen in den Entwurfsproze integrieren Diese drei Dimensionen spannen einen Entwicklungsraum wie in Bild 15 auf Abstraktionsschicht Version Architekturkomponente Bild 15 Entwicklungsdimensionen f r dei Entwurfsdokumente Das Abstraktionsschichtenmodell zur integrierten und abgestuften Entwicklung Wir betrachten explizit unterschiedliche Abstraktionsschichten und integrieren die Darstellung der Architektur der Anwendung und die Versionierung explizit in die einzelnen Entwurfsschritte Damit unterscheiden wir folgende Schichten die Motivationsschicht zur Spezifikation der Ziele der Aufgaben und der Motivation der Informations systemanwendung
224. inzip kann man sich Farmen von Daten banksystemen vorstellen die durch eine Art Warenhausverwaltung den Bed rfnissen von Kunden angepa t und konfektioniert verkauft werden Dabei wird nicht nur eine Datenbank an sich vermark tet sondern ein Datenbanksystem mit einer entsprechenden Funktionalit t Die bereits entwickelte Technologie f r benutzerfreundliche Oberfl chen kann dabei angewandt werden Insbesondere sind dabei Methoden von executive information systems EIS on line analy tical processing OLAP decision support systems DSS anwendbar In erster N herung ist dabei ein Datenbank Warenhaus eine Farm von Datenbanken die durch data mining Werkzeuge einem Be nutzer die Auswertung vorhandener Daten erm glicht Damit ergibt sich die in Bild 72 dargestellte Architektur Schleuse Workspace Akquisition Speicher Zugriff DB 7 Dat i Client atens Datenbank Inp import xtraktorenl i DB Export verwaltungs 5 m Werkzeuge system mining W Data Warehouse Bild 72 Die drei Komponenten eines Datenbank Warenhauses Das Input Interface kann auch als Legacy Interface bezeichnet werden Es werden sehr unterschied Ze i eer du 0222 dt ig 0 nn 1 O o 2 Ps 2 0 U o a a ERBE 172 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 8 VERTEILUNG und auf anderer technologischer Grundlage basiere
225. ion anforderungen Prozesse J globale Datenbank gt Prozesse schema bereitgestellte Aspektkategorien statische Aspekte dynamische Aspekte Bild 11 Die Infrastruktur f r die integrierte Entwicklung von Informationssystemen A A A Informations Systemi Content Inter Typen aktions Story Daten raum Raum bank system Bild 12 Die Unterst tzung von Informationssystemen durch Datenbanksysteme und Content Typen 28 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 2 SPRACHEN unterstiitzt Meist basiert diese Architektur auf einer Trennung der Datenverwaltung und des Datenaustausches bzw der Daten bertragung Dienste werden charakterisiert durch eine Dienstleistungsvereinbarung als verbindliche Regelung des Dienstverh ltnisses eine Sammlung von Funktionen die zur Erf llung des Dienstes abgerufen werden k nnen und Dienstmerkmalen zur Darstellung der Qualit tsparameter Die Funktionalit t des Dienstes und die Dienstmerkmale werden oft als Diensteigenschaften zusammengefa t Verteilte Datenbanksysteme setzen auf Datenbanksystemen auf erlauben eine Verteilung der Daten durch Partitionierung der Daten Allokation der Partitionen zu Knoten und eine verteilte Be arbeitung von Daten auf der Grundlage von erweiterten Protokollen f r den Abschlu von Transaktionen Eine klassische Darstellung der Verteilung wird oft anhand von drei Modellen dargestellt Das Ko
226. ionale Logik e Ein Akteur stellt die Beobachtung zu den Aufgaben in Beziehung die er gerade l sen m chte e Der Output wird mit einer Umgebung bzw einen Kontext im allgemeinen in Beziehung gesetzt Damit wird durch den Akteur eine andere Beziehung eingegangen als dies bei der Modellierung von algorithmischen Systemen blich ist Mensch Maschinen Schnittstellen erfordern deshalb eine explizite Ber cksichtigung folgender Parameter Beobachtetes Verhalten Die Beobachtungen bestimmen die Sicht des Akteurs auf das System Interpretiertes Verhalten Ein Akteur interpretiert das Verhalten des Systemes Nichtalgorithmisches Verhalten des Akteurs Das Verhalten eines Akteurs ist meist nicht al s d a a AE b L INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 121 ip Benutzer A Benutzer A 0 il _ _ IO _ IO A nyyeridi 2 2 Inter Benutzer A Inter stem Inter Benutzer B face face gt gt Benutzer A gt gt gt gt Benutzer A gt gt Algorithmische Sequentielle 7 7 konkurrierende Berechnung Interaktion Interaktion Bild 43 Algorithmisches Verhalten versus Mensch Maschine Verhaltes eines oder mehrerer Akteure In Bild 43 vergleichen wir das algorithmische Verhalten eines Systemes in der klassischen Vor stellung mit der sequentiellen Interaktion bei
227. ionelle Repr sentation des Handlungsablaufes aller Facetten der Anwendung Das Drehbuch basiert auf Szenen die miteinander durch explizite berg nge verbunden sind Die Szenen selbst realisieren entsprechende Aktionen von Akteuren die durch Dialogschritte dargestellt werden Diese Aktionen k nnen durch kurze pr gnante Beschreibungen charakteri siert werden Wir streben dazu auch eine Kurzcharakterisierung an Dazu benutzen wir Verben oder auch Substantive Diese Worte werden als Wortfelder dargestellt Eine Szene ist dann ein algebraischer Ausdruck von Dialogschritten Die Algebra mu dazu auch die Parallelit t von Schritten ber cksichtigen Einer Szene sind Akteure mit entsprechen den Rollen und Aufgaben zugeordnet Eine Szene nutzt ein Medien Objekt Ein Dialogschritt wird unter Beteiligung einiger Akteure die in die Szene involviert sind ausgef hrt Dabei wer den die Akteure einem Kontext zugeordnet Dieser Kontext stellt insbesondere die technischen Rahmenbedingungen der Benutzung dar Wir ber cksichtigen f r das Drehbuch auch Eigenschaften und Wirkungen auf den Benutzer Damit wird das Drehbuch im wesentlichen von drei Faktoren bestimmt von der Form den Aktionen der Story und den Besonderheiten der Arbeitsweise der Endbenutzer Wir k nnen damit im einzelnen Folgearbeitspakete herausstellen Kategorisierung der Endbenutzer Aktionen und Dialoge existieren nicht unabh ngig von den Akteuren Es k nnen die Akteure kategorisier
228. ionskomponente und die entsprechenden Sichten Dieser Zugang wird im Software Engineering pr feriert entspricht aber selten den Gegebenheiten der Entwicklung von Informationssystemen Interaktionsraum determinierte Entwicklung Es werden zuerst die Stories und Szenarien der Anwen dung abgenommen Auf dieser Grundlage werden die entsprechenden Medientypen konzipiert Damit sind die Anforderungen f r die Strukturierung und die Funktionalit t bekannt so da eine Entwicklung dieser Aspekte integriert erfolgen kann Diese Vorgehensweise entspricht der Entwicklungsmethodik von informationsintensiven Websites Sie bedingt jedoch eine weitestge hende Erfassung aller Szenarien der Anwendung Sichtenorientierte Entwicklung Es wird ein Skelett oder eine Architektur der Anwendung entwickelt Die einzelnen Sichten werden schrittweise und an ihren Schnittstellen integriert entwickelt Dar auf aufbauend k nnen die Strukturierung der Story Raum und die Funktionalit t entwickelt werden Diese Vorgehensweise eignet sich besonders f r gut strukturierte Anwendungsgebiete mit separierbaren Datenbest nden Sie bedingt jedoch eine h here Disziplin und Koordinierung bei der integrierten Entwicklung Schichtenbasierte Entwicklung Es werden zuerst alle Aspekte auf der Motivationsschicht danach auf der Gesch ftsproze schicht dann auf der Aktionsschicht und abschlie end die Aspekte auf der konzeptionellen Schicht entwickelt Nach Abschlu des konzeptionellen
229. ir in Bild 4 in vereinfachter Form zusammen gefa t Realit t Ausschnitt der Realit t Dinge der Beobachtete 5g Realit t 5577 Pradikator Urteils Kontext k A Theorie Schema als Resultat und Ausschnitt Y eines Entwicklungs a Referenz Modalit t prozesses Individuum modellierung Gewi heit Sch rfe Bild 4 Modellierungsurteile durch Individuen im Modellierungskontext und das Dilemma der Mo dellierung Mit der Darstellung in Bild 4 wird gleichzeitig auch das Dilemma der Modellierung sichtbar Sind nach der Modellierung nur noch die Modellierungsurteile verf gbar dann sind nicht mehr die impliziten Annahmen die theoretischen Grundlagen die Beobachtung der Realit t und oft auch die Spezifika des Entwicklers nachvollziehbar Damit entstehen Schemata die der Nachwelt nicht mehr verst ndlich erscheinen die zu einer Doppelentwicklung innerhalb von gro en Anwendungen wie z B bei SAP R 3 f hren und neben Redundanz auch erhebliche Konsistenzprobleme besitzen Redundanz kann eine sinnvolle Eigenschaft sein sollte aber explizit erfa t und gepflegt werden Inkonsistenz ist selten sinnvoll Vollst ndigkeit ist eines der Hauptkriterien bei der Beurteilung der Qualit t neben diesen Kriterien Ein wichtiger Problemkreis vor Einf hrung eines Informationssystemes ist das Abw gen ob dieser Einsa
230. irkens und der Arbeitsplatz werden mit ber cksich tigt Wir ber cksichtigen neben den bereits diskutierten Eigenschaften von Oberfl chen die folgenden Gestaltungsm glichkeiten Multimediale Darstellung Einziger Zweck der Oberfl che ist es etwas mitzuteilen Sie ist niemals Selbstzweck sondern steht im Dienste der Arbeit mit den Informationen Durch die Einengung auf den Bildschirm wird die Vermittlung einer Botschaft auch eingeschr nkt Eine Folge von Bildschirmen soll weder erm den noch von der eigentlichen Arbeit ablenken Zugleich kann eine Oberfl che mehr Informationen vermitteln als ein einfaches Foto Es werden Aktionen und Objekte in der Wechselwirkung sichtbar Die Dekoration ist jede Art von Hintergrund Die Requisite kann entweder zur Dekoration oder zum Akteur geh ren Lichtwechsel und das Aussehen von Requisiten dienen der Gestaltung von Oberfl chen Eine multimediale Arbeitsumgebung schlie t die Verwendung von T nen ein T ne sind 11 7 o N k Ola e E EATE 10 0 DEERE 50 3 13 SEN I N B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 7 INTERAKTIVIT T Akteur Er ist die bei weitem einfachste Form der Fakten bermittlung Er sollte jedoch nur dann angewandt werden wenn andere Ausdrucksm glichkeiten voll ausgesch pft sind Demgegen ber kann jede Aktion von bestimmten Ger uschen begleitet sein Hintergrund musik ist ein Bestandteil der Tonebene jedoch i a n
231. it t Verteilung und Sichten Suiten als Verallgemeinerung des Sichtenbe griffes darstellen Mit SiteLang k nnen wir alle Aspekte der Interaktivit t und der Einbettung von Datenbanksystemen in interaktive Systeme darstellen SiteLang umfa t neben der Darstellung von Interaktion und Stories auch die entsprechenden Kontextbedingungen zu denen insbesondere der Gestaltungsrahmen der Kommunikationsrahmen und der Arbeitsrahmen geh ren DistrLang stellt die Dienste und die Kollaboration f r die Verteilung dar Die unterschiedlichen Elemente unseres Modellierungsansatzes sind auf Seite 18 zusammengefa t Modellieren ist das Herstellen Modifizieren Analysieren und Nutzen von Modellen zur Herstellung von Vorstellungen zu Dingen der Realit t Der Modellbegriff basiert auf drei Abstraktionsmerkmalen e Abbildungsmerkmal Ein Modell stellt einen Ausschnitt der Realit t dar Es werden somit Ob jekte Dingen der Realit t zugeordnet e Verkiirzungsmerkmal Ein Modell abstrahiert von den Eigenschaften der Realit t Es werden nur einige relevante bzw wichtige Eigenschaften dargestellt e Pragmatisches Merkmal Ein Modell wird nicht ein f r alle mal bestimmt sondern h ngt von den Zeitpunkten dem Anwendungskontext und den Auffassungen der beteiligten Individuen ab Diese k nnen sich jederzeit ndern Damit werden in der Modellierung Urteile durch den Modellierer gef llt welche Dinge der Realit t f r welchen Ausschnitt mit welchen
232. it tenprofil mit einer ordinalen Bewertungsskala zur Darstellung der Ausgepr gtheit der Eigenschaften erstellt werden Perspektiven der Mensch Computer Interaktion Traditionell werden vier verschiedene Perspektiven der Interaktion unterschieden Maschinenperspektive Der Computer wird bei den Betrachtungen in den Mittelpunkt gestellt Der Mensch wird als Maschinenbediener wahrgenommen Systemperspektive Mensch und Computer werden als gleichberechtigte Partner eines Systemes aufgefa t Kommunikationsperspektive Programme und Benutzer unterhalten sich gleichberechtigt in einer Dialogsprache Werkzeugperspektive Der Computer unterst tzt den Benutzer bei der Erf llung seiner Aufgaben Auf der Grundlage dieser Perspektiven k nnen wir vier Methoden zur Entwicklung von Ober fl chen ableiten Die empirische Methode orientiert sich an den aktuellen Herangehensweisen verallgemeinert diese und gestattet die Entwicklung in einem trial and error Proze Die kognitive Methode untersucht zuerst das Verhalten des Menschen ergr ndet sein mentales Modell und nutzt diese Erkenntnisse zur Entwicklung von benutzungsfreundlichen und intuitiv ver st ndlichen Oberfl chen Die prediktive funktionsorientierte Methode leitet aus den Zielen der Anwendung den Aufgaben und den technischen M glichkeiten eine L sung f r die Gestaltung des Arbeitsprozesses und der entsprechenden Oberfl chen ab Die anthropomorphe Methode bildet die Kommunika
233. it einer Darstellung der Spezifika der Akteure und in Erg nzung zum Ausbil dungsprofil und das Pers nlichkeitsprofil zur Darstellung der Eigenschaften von Gruppen Das Ausbildungsprofil stellt f r eine Gruppe von Benutzern das gesamte Spektrum der Ausbildung die die Benutzer e ben tigen e mitbringen und ggf auch e nicht besitzen sollen dar Die letzte Kategorie dient auch der Charakterisierung von Wissens Fertigkeiten und F higkeitsl cken Diese Kategorie erlaubt auch eine Ableitung von Content der f r die Bew ltigung der Arbeitsaufgabe durch das Informationssystem bereitgestellt werden mu Die erste Kategorie dient der Darstellung des Bildungsweges der auch in grober Form dargestellt werden kann Die Darstellung des Bildungsweges wird meist in analoger Form wie in Stellenanzeigen oder Stellenprofilen eines Arbeitsplatzes erfolgen Wir ben tigen diese Kategorie zur Ableitung der pragmatischen Annahmen die eine Vereinfachung des Systemes bedingen Die zweite Kategorie kennzeichnet das Bildungsspektrum der Benutzer Wird das Spektrum nicht ber cksichtigt dann verleitet ein System relativ schnell zum Mi brauch oder wird abgelehnt obwohl es gerade zur Bew ltigung der Arbeitsaufgabe ad quat erscheint Das Arbeitsprofil ist analog zur KADS Charakterisierung LFel auf eine Klassifikation der Akteure nach Eigenschaften ausgerichtet e F higkeiten die Akteure zur Bew ltigung der Arbeitsaufgaben besitzen sollen Fer
234. ite P read P write P einer Transaktion sind alle elementaren Lese und Schreiboperationen der Transaktion P Eine read Operation ist eine objekt basierte Operation ebenso wie eine write Operation Zwei Transaktion P und P sind Konkurrenten falls read P O urite P oder read P2 Nwrite P oder write P2 Nwrite P 0 Parallele Ausf hrung von Transaktionen ist immer m glich wenn diese keine Konkurrenten sind In diesem Fall ist der Effekt der parallelen Ausf hrung quivalent zu P P2 ER oder zu Ps P ER f r die Datenbank ER Sind Transaktionen Konkurrenten dann kann ein Steuerprogramm die Korrektheit der paral lelen Ausf hrung gew hrleisten Neben diesen Modellen k nnen wir auch erweiterte Konzepte aus der Literatur verwenden Sagas basieren auf einer Menge von ACID Subtransaktionen mit vordefinierter Ausf hrungs ordnung und einer Menge dazu assoziierter kompensierender Teiltransaktionen e Split and join Transaktionen wurden f r den Ressourcentransfer zu parallel verlaufenden Transaktionen entwickelt e Flexible Transaktionen sind Polytransaktionen deren Konsistenzforderungen durch Kol lektion von Datenabh ngigkeitsdeskriptoren realisiert werden e Transaktionen k nnen mit dem ACTA Metamodell erweitert werden F r unsere Belange erscheinen jedoch diese HERM TA Formen ausreichend e Es wurden unterschiedliche Modelle zur Ausf hrung und Steuerung von Gesch ftsprozessen Hand lu
235. ke definiert Den freien Variablen werden wiederum Typen zugeordnet e Die Zuordnungsvorschrift f r Typausdr cke kann sowohl hierarchisch als auch zyklisch sein W hlt man eine zyklische Struktur dann sind meist nur Topoi Semantiken geeig net W hlt man hierarchische Strukturen dann kann meist eine Mengensemantik noch garantiert werden e Typen haben eine assoziierte statische Semantik e Typen haben Operationen zu ihrer Manipulation und Ver nderung Man kann diese Ope rationen generisch definieren wenn die Typenstruktur hierarchisch aufgebaut ist Einige Operationen k nnen auch Pr dikate sein e Klassen sind Typen zugeordnet e Sie stellen Container f r die Objekte des jeweiligen Typs dar Die assoziierte statische Semantik der Typen mu zu jedem Zeitpunkt f r eine Klasse erf llt sein e Die Operationen der Typen werden auf Klassen ausgef hrt Wir bezeichnen Typen mit ihrem Namen z B T und die zugeh rigen Klassen mit einer Anno tation zum Typennamen z B T C steht f r Klasse Es sind verschiedene Modelle m glich Jedes Modell ist durch eine Menge von inh renten Bedin gungen gekennzeichnet Jeder benutzte Typ hat neben Konstruktor Selektoren f r Retrieval und Updatefunktionen Korrektheitskriterien default Regeln auch eine Benutzerrepr sentation und eine physische Repr sentation G nstig ist eine graphische Repr sentation Eines der popul rsten Modelle ist das Entity Relationship Modell
236. keit dem Umfang der bereitgestellten Information der Benutzungsrech te Sicherheitskriterien und den Gesch ftsbedingungen e assoziierten Content Objekten f r unterschiedliche Benutzergruppen und e Annotationen Anmerkungen zu Zugriffsmodellen spezifischen Annotationen zum Res sourcentypen und formaten sowie zur verwendeten Sprache 3 die Benutzungsgeschichte des Content Objektes die mit Parametern erfa t und angepa t wer den kann die schrittweise zu einer Erweiterung des Umschlags fiihren 4 allgemeine Zeitinformation insbesondere e zu Versionen Ausgaben und Benutzungsprofilen e zu Erneuerungsstrategien anwendbaren Verbindungsprofilen zur Erneuerung und die Art der Verbindung und e Signaturen Beglaubigungshinweisen und Angaben zur wiederholten Benutzung Wir fiigen diesen Verpackungsinformationen dem Content Objekt hinzu indem durch Variable Werte Paare eine erweiterbare Attribut Information mitgefiihrt wird Container fiir die Auslieferung von Content Objekten Content Objekte sollen dem Benutzer zur Verfiigung stehen Dabei wollen wir eine m glichst gro e Unabh ngigkeit von der aktuellen Web Technologie erreichen Eine Auslieferung von Content Objekten kann sowohl ber der Internet als auch das Extranet oder Intranet erfolgen Weiterhin kann ein Benutzer die Daten mit einem komfortablen System wie z B einem Browser einem weniger komfortablen System wie z B einen text basierten Browser einem eingeschr
237. ktions prozessor Exportschema Filter prozessor Komponentenschema Transformations prozessor Lokales DB Schema Lokales DBMS Bild 65 Die Architektur von f derativen Datenbanksystemen Ein Katalog fiihrt die Metadaten fiir die DB Verarbeitung Im Katalog werden die Namen und Adressen externer Knoten und der DBS Angaben zur Datenverteilung und Angaben zu Relationen Sichten Attribute Integrit tsbedingungen Benutzern Zugriffsrechten Indexstrukturen Statistiken etc gef hrt Jeder Knoten f hrt f r die lokalen Objekte die Katalogdaten Alternativen f r die Realisierung eines globalen Kataloges Verteilungsinformationen Angaben zu nicht lokalen Objekten und Benutzern sind o zentralisierter Katalog vollst ndig replizierter Katalog Mehrfachkataloge Kombination aus den beiden ersten Ans tzen und partitionierter Katalog D 0O O Eine weitere Variante ist die Verwendung eines partitionierten Kataloges und die Pufferung Caching von entfernten Katalogdaten Die beiden wesentlichen Alternativen zur Behandlung veralteter Katalogangaben sind e entweder eine Verlinkung der Daten so da sich der Besitzerknoten vermerkt an welcher Stelle Katalogdaten gepuffert sind und invalidiert diese bei einer Anderung oder e die Verwendung von Zeitstempeln so da bei der Ausf hrung einer Operation festgestellt wird ob veraltete Katalogdaten verwendet wurden und ggf e
238. levanter bzw wichtiger Ausschnitt gezeigt d h die informationstr chtigen Elemente die zur glei chen Aktion geh ren werden als Elemente einer Einstellung zusammengefa t Eine gute Einstellung h lt mit den Aktionen und ihren Zielen Schritt Mitunter ist die Reaktion wichtiger als die Aktion Wir unterscheiden dabei verschiedene Einstellungstypen Gro Nah halbtotale etc Einstellung Jede Einstellung kann auf unterschiedliche Weise in formationsvermittelnden Fakten entsprechen Eine Einstellung kann auch dynamisch sein und tr gt damit u a der Verlagerung des Interesses Rechnung Ein Einstellungswechsel darf nicht zu kra sein Die Szenarien sollen durch eine nahtlose Verbindung von Einstellungen zusammenh ngen Mittel der Abgrenzung wie Auf und Abblende sind deshalb in den Entwurf mit einzubinden Einzelszenen Die Einzelszenen k nnen auch aus mehreren Einstellungen bestehen In diesem Fall sind auch mehrere Sichten auf die Datenbank zu integrieren Freignisse sind in den Szenen selbst enthalten Einzelszenen sind durch ihren Ort ihre Zeit Zeitpunkt Laufzeit L nge mitbestimmt Eine kunstvolle Zusammenstellung von Elementen verbessert nicht unbedingt die Qualit t der Inszenierung es kann dadurch die Aufmerksamkeit der Arbeit entzogen werden Damit wird die Exposition von Ort und Zeit zum Entwurfsproblem Auswahl der Informationen Ein Szenario wird durch den Akteur als eine Folge von Einze linformationen beobachtet Alle In
239. leware Systemen als auch mit JavaBeans oder auch direkt mit Perl PHP bzw anderen Skriptsprachen realisieren k nnen Diese Definition des Containers wird auch bei der Entwicklung von benutzereigenen Arbeitsr um en verwendet Container k nnen verfeinert werden e durch Instantiierung oder Adaption der Parameter e Vergr erung und Verkleinerung der Kapazit t e Hinzuf gen von Integrit tsbedingungen und e Verfeinerung folgender Operationen e der Vergleichsfunktion bzw der Mustermenge e der Auswertungsfunktion eval e der Inspektionsfunktion inspect und e der Auswahlfunktionen e sowie durch Verbesserung der Darstellung von e Abstrakten als Zusammenfassungen des Inhaltes der Content Objekte und la nn dar Wera amr im ET aan dan hatranhtan 98 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 6 SICHTENSUITE Die Verfeinerung f hrt aufgrund des generischen Charakters der Funktionen zu einer Ver nderung des Verhaltens der vier Hauptfunktionen nicht aber zur Ver nderung der Funktionen Der Content Typ Benutzer Arbeitsplatz Ein Informationssystem soll einen Benutzer effizient und effektiv in seiner Arbeit unterst tzen Das Portfolio haupts chlich bestehend aus dem Aufgabenmodell und dem Rollen und Rechtemodellen des Akteurs und das Benutzerprofil werden zur Generierung des Playout und des Layout der Content Typen herangezogen Portfolio und Profile behandeln wir im Abschnitt 7 ausf hrlich Weiterhin mu ein
240. lgen Ein typisches Beispiel wird in Bild 8 vorgestellt Konzepte sollen durch Content unterlegt werden k nnen wobei der Content und seine Struktur variabel sein k nnen solange sie miteinander verbunden werden k nnen Wir schr nken diese Ver bindung durch die Forderung einer Spezialisierungsbeziehung ein Die Spezifikation des Content stellt eine Verfeinerung der Spezifikation der zugeh rigen Konzepte dar Konzepte k nnen miteinander kombiniert werden So kann z B wie in Bild 9 das Konzept Person mit dem Konzept Rolle und dem Konzept Adresse verbunden werden wobei z B nur der Angestellte eine interne Kontaktadresse und eine externe Partneradresse besitzt Diese Verbindung wird allgemein durch Filter oder Theta Operatoren sichergestellt Wir k nnen dies durch die Algebra unterst tzen und erhalten Adressen Xe a Personen Rollen Eine Algebra zur Verbindung wird aus der HERM Algebra abgeleitet Wir verwenden dabei die HERM Operationen td rn A 5 Een ya taten 24 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 2 SPRACHEN Beschreibung Charakterisierung Intervall A Organi Pee sation Fahigkeiten N ame profil Kommentar Familienname Rufname AnzJahreBerufserfahrung Ab Person A lt gt Bis Vornamen Titel nrede Profil Geburtsdaten Biometriedaten i Geschlecht Familiengeschichte K I 1 ommentar CV Pa Charakterisierung Bildungs Ist Von profi L
241. llaborationsmodell oder Interaktionsmodell dient der Spezifikation der kommunizierenden Pro zesse ihrer Kommunikation und ihrer Koordination Es wird meist ein Zeitmodell unterlegt das auch erlaubt die Verz gerung der Kollaboration darzustellen Das Fehlermodell definiert und klassifiziert die auftretenden Fehler die Behebungsm glichkeiten und die Ausf hrung der Kompensation Das Sicherheitsmodell klassifiziert und definiert die Form mit der Angriffen und Systemgef hrdungen begegnet werden kann Die Kollaboration f hrt oft zu einer Einschr nkung der Leistung von Systemen Au erdem kann rela tiv selten ein globales Zeitkonzept realisiert werden Deshalb unterscheiden wir auch verteilte Systeme in asynchrone und synchrone Systeme Die Kollaboration kann oft durch Interaktionsdiagramme die die Abfolge der Kollaborationsereignisse darstellen unterst tzt werden Typische Modelle zur Dar stellung sind dann Weg Zeit Diagramme Im Datenbank und Informationssystementwurf ist jedoch eine gr ere Vielfalt von Anwendun gen darzustellen So sind z B e Business Anwendungen mit den Methoden der OSI Schichtung mit einfachen Diensten und auf der Grundlage von einfachen Austauschprotokollen nur partiell darstell bar Deshalb wird versucht ber mehrdimensionale Strukturierung wie z B in ALSS03 mit den Dimensionen Daten bertragungssystem und Datenverwaltungssystem und den klassischen Schich ten des OSI Modelles Bit bertragung Sicherung
242. lle Eigenschaften und e innerhalb der Implementationsschicht durch Dienstg teeigenschaften der Implementa tion angegeben Der Dienstvertrag legt die Rahmenbedingungen des Dienstes fest Das Vertragsschema stellt die Bedingungen des Vertrages dar Insbesondere werden Pa rameter wie e das Benutzungsmodell mit den Akteuren ihren Beziehungen Rollen und Rech ten e das Zeitmodell e der Vertragskontext und e die vertraglich vereinbarte Qualit t spezifiziert Qualit tsparameter der Dienste sind je nach Abstraktionsniveau e innerhalb der Aktionsschicht Eigenschaften wie Allgegenwart ubiquity und Si cherheit e innerhalb der konzeptionellen Schicht Eigenschaften wie Bedeutungstreue und Kon sistenz und e innerhalb der Implementationsschicht Eigenschaften wie Dauerhaftigkeit Perfor manz Robustheit und Skalierbarkeit Der Kollaborationsrahmen ist durch die Darstellung der verschiedenen Facetten der Kollaboration spezifiziert Der Kommunikationsrahmen legt die Art der Kommunikation und die benutzten Austauschme EN on ak Mo es 2 30 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 2 SPRACHEN Der Kooperationsrahmen bestimmt die Art des Zusammenwirkens der unterschiedlichen Akteu re und Komponenten im Rahmen des Portfolios bzw der Arbeitsprozesse Der Koordinationsrahmen bestimmt die Synchronisation der Kollaboration die Organisation und die Aufgabenverteilung Die Facetten der Kollaboration werden durch jeweils
243. llen und der Implementationsschicht auf der Grundlage von Verteilungskonzepten entwickelt Sie werden dort mit betrachtet Die Spezifikation der Sichten kann auch in die Spezifikation der Schemata mit eingebettet werden Da f r die Akteure Daten nur im Rahmen der Dialoge von Interesse sind und diese Dialoge auch spezifisch aufbereitete Daten erfordern ist eine explizite Modellierung der Sichten angebracht Wir wollen au erdem eine Spezifikation der Anwendung auf der Grundlage eines sichtenorientier ten Zuganges unterst tzen Deshalb ben tigen wir explizite Konzepte zur Darstellung des Zusam menhanges von Sichten Dieses Konzept der Sichtenkooperation wird deshalb in diesem Abschnitt ebenfalls eingef hrt Der sichtenorientierte Entwurf konzentriert sich st rker auf die Spezifikation der Aspekte der Anwendung die mehr den Anwender betreffen Es wird angenommen da eine Integrati on der einzelnen Sichten so wie dies f r die Anwendung eigentlich der Fall ist eine l sbare Aufgabe ist Das steht im Widerspruch zu theoretischen Resultaten Die Sichtenintegration ist eine algorith misch unl sbare Aufgabe Es existiert kein Algorithmus der entscheidet ob zwei Sichten integriert werden k nnen Das Sichtenintegrationsproblem ist auch nicht semientscheidbar d h es existiert auch kein Algorithmus der f r Sichten die integriert werden k nnen die integrierende Sicht berechnet Aus diesen Resultaten kann man schlie en da ein sichtenorienti
244. llierte Redundanz partiell ber winden Transparenz wird in der Informatik als das Verbergen der einzelnen Komponenten vom Benutzer des verteilten Systems verstanden Wir unterscheiden unterschiedliche Formen der Transparenz Zugriffstransparenz unterst tzt den Zugriff auf Dienste unabh ngig von deren Ort mit den glei chen Funktionen Ortstransparenz unterst tzt den Zugriff trotz der Unkenntnis vom Ort des Dienstes Nebenl ufigkeitstransparenz erlaubt mehrere Prozesse gleichzeitig zu fahren ohne da sich diese gegenseitig beeinflussen Replikationstransparenz erlaubt die Benutzung von Kopien ohne da ein Benutzer dies wahr nimmt Fehlertransparenz wird durch das Verbergen von Fehlern vor dem Benutzer unterst tzt Mobilit tstransparenz erlaubt das Verschieben von Diensten und insbesondere von Ressourcen Leistungstransparenz erlaubt eine Selbstreorganisation des Systems ohne Beeintr chtigung des Benutzers Skalierungstransparenz erlaubt eine Ver nderung der Systemgr e ohne Beeintr chtigung der anderen Funktionen Vertr ge zur Verteilung Der Vertragsraum besteht aus einer Darstellung der Dienste aus dem Kollaborationsvertrag und dem Qualit tsvertrag Im einzelnen werden die folgenden Elemente dargestellt Das Dienstmodell was basiert auf einer allgemeinen Darstellung der Dienste mit den Sichtenskiz zen und den Kompetenzen der Dienste TB m 0000000 ra s 7 ae a nenn Me nn 7 Fi T u T 1
245. llung der Retrieval Sichten der bereitgestellten Funktionen einer Einschr nkung der involvierten Akteure auf ak tive Akteure und einer Steuerspezifikation mit Ereignissen die zum Aufsuchen dieses Dialogschritts f hren Bedingungen unter denen der Dialogschritt ausgef hrt werden kann und Beendigungsbedingungen mit denen eine explizite Kontrolle realisiert werden kann so da ein Dialogschritt erst beendet werden kann wenn eine bestimmte Konsistenz erreicht ist Szenario Der Story Raum erlaubt eine Vielzahl von Durchl ufen Da in einer Anwendung nur einige Durchl ufe von Interesse sind spezifizieren wir die Hauptdurchl ufe durch Szenario Szenario sind i a adaptierbar an die Benutzung an die direkten Benutzer deren Anwendungskontext und deren Benutzungshistorie Dies wird durch eine Parametrisierung erreicht Szenarium Jedes Szenario enth lt aufgrund der Parametrisierung eine Vielzahl von Durchl ufen Ein konkreter Durchlauf wird durch eine Wertezuweisung an alle Parameter zu einem Szenarium Diese Direktspezifikation wird insbesondere f r Informationssysteme angewandt deren Pr sentati n d 2 sox ke 0 LT x kuru x 1 8 a aaz r b ee Weiz bane eee ea ines ix 5 OMENS mee 0 d 124 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 7 INTERAKTIVIT T Pr sentationsmaschine Container Generator Content Objekt Generator Sichten Generator Datenbanksystem DBMS
246. ls auch in der Lehre ihren Niederschlag findet In der Lehre wurde diese Methodik aller vier Semester in mehr als einem Dutzend Jahren erprobt Es haben dabei viele Studenten mit kritischen Hinterfragungen auch zu einer Verfeinerung der Methode beigetragen Die Co Design Methode ist mit den Mitgliedern der Arbeitsgruppe von Klaus Dieter Schewe Mas sey University Palmerston North weiter verfeinert worden Ihm und Roland Kaschek m chte ich extra danken Die Co Design Methode hat ihre praktische Erprobung mit ID bereits seit l ngerer Zeit erfahren Ich danke meinen Studenten und Kollegen aus Kuwait Oman und Jordanien f r die Unterst tzung die Anregungen und vor allem f r die Herausforderungen Mit der Vielzahl von Anwendungen in Ara bien habe ich zu den Anforderungen zu den Tricks und kleinen Br cken die jede Methode erfordert und zu gro en Anwendungen sehr viel gelernt Das DB System wurde zum RADD System durch die Mitglieder meiner Rostocker und Cottbu ser Arbeitsgruppen erweitert Die Entwicklungsarbeiten meiner Studenten und Promoventen insbe sondere von Margita Altus Antje D sterh ft und Meike Klettke haben zu einem ausgereiften System gef hrt dessen Kernideen in das System ID bernommen wurden Die Co Design Methode hat auch viele Anwendungen zur Entwicklung von informationsintensiven Websites gefunden Das Cottbuser InfoTeam hat mehr als 35 gro e Websites entwickelt Im wesent lichen wurde die Co Design Methode verwe
247. ls f r alle i 1 lt i lt n A lt Bi gilt A A A B falls Aj x B gilt Die Vereinigung Y Ux Z der Durchschnitt Y Mx Z und die Differenz Y x Z sind dann f r Strukturen X und deren Teilstrukturen Y Z wie folgt induktiv definiert falls Y lt Z gilt auch Y Ux Z 2 sowie Y fix 2 Y Z xX Z und Z xY falls A B A C 2 A D dann gilt auch Y ox 2 A C og D f r o u n falls X A B Y A C Z A D Z ZY dann gilt auch Z x Y A D op X falls X A A1 An Y A B Ba Z Ci Cy dann gilt auch A By OA Cires Ba OA Ca f r o TELL Die Struktur X wird als Kontext f r die Operationen ben tigt Pr dikate Gegeben sei ein Typ X Ein Basispr dikat a vom Typ X ist ein Ausdruck der Form YOa oder der Form Y o C f r Y lt X aedom Y o C C dom Y und alle Vergleichspr dikate die ber Y definiert sind F r viele Typen sind dies 4 lt gt lt gt Ein Objekt vom Typ X erf llt YOa falls a oly f r die Einschr nkung von o auf Y gilt Ein Objekt o vom Typ X erf llt Y o C falls oly o C f r die Einschr nkung von o auf Y gilt Pr dikate sind induktiv definiert e Basispr dikate sind Pr dikate Sind a and 6 Pr dikate dann sind es auch aA a V Bund 7a Ein Objekt o erf llt das Pr dikat a falls dies entsprechend der Definition von a gilt Damit definieren wir o falls o das Pr dikat a erf llt A
248. lt Sie enthalten die Spezifikation der Strukturierung der dem Akteur zur Verfiigung gestellten Daten und die Darstellung der Funk tionalit t Damit wird folgendes dargestellt Daten innerhalb von Content Objekten sind in eine Reihe von Kategorien klassifizierbar Retrievaldaten die aus einer Datenbank gewonnen werden und als Inputdaten f r den ablaufenden Proze bzw Dialogschritt dienen Inputdaten des Akteurs die ggf auch als Insert oder Update Daten in Dialogschritten fungieren Outputdaten die in die Datenbank zur ckgeschrieben werden Displaydaten die als Output w hrend des Dialoges dargestellt werden und Begleitdaten die aus vorherigen Prozessen stammen und der Darstellung der Informa tionen w hrend des Dialogschrittes dienen Bei Prozessen mit denen ein Akteur Handlungen und Aktionen mit dem Informationssystem ausf hren kann unterscheiden wir Unterst tzende Prozesse f r die Aktionen und Manipulationsanforderungen an das Informationssystem die zur Ver nderung der Daten f hren k nnen Wir fassen die Daten in Klassen zusammen Ein Content Typ spezifiziert eine solche Klasse und basiert auf einem Sichtenschema das auch um die erforderliche Funktionalit t angereichert wurde Container werden benutzt um die Sichten den Akteuren bereitzustellen Sie umfassen auch Parameter zur Beschreibung des Benutzungskontextes so da mit einer Auslieferung des Containers an den aktuellen Benutzer eine Adaption erfol
249. lt dann ist eine Vielfalt von Sichten zur Unterst tzung unterschiedlicher Benutzungsarten zu entwickeln Au erdem verlangt eine Sicht oft auch eine eigenst ndige Funk tionalit t Diese Vielfalt ist sp testens bei einer Modifikation nicht mehr zu berschauen Workflow Bruch Gesch ftsprozesse k nnen analog zu langandauernden Transaktionen im Ablauf un terbrochen werden auf anderen Gesch ftsprozessen basieren und unterschiedliche Granularit t besitzen Damit entsteht ein komplexes Ausf hrungsmodell das von einem Normalentwickler nicht mehr berschaut wird CASE Tool Bruch Die meisten Entwicklungsumgebungen erlauben wenn sie ber reine Malprogram me hinausgehen nur eine Einbahnstra e in der Entwicklung Nach der Erzeugung des logischen Modelles aus dem Entwurfsmodell ist es in der Regel unm glich oder zumindest sehr schwer beide Modelle miteinander konsistent zu halten Es ist deshalb eine harte Kopplung der kon zeptionellen externen und internen Modelle erforderlich Jede Modifikation eines Schemas zieht ansonsten schwierige Reorganisationen der Datenbank nach sich Diese Br che entstehen durch unterschiedliche Ziele im Verlaufe des Entwicklungsprozesses wie z B e Konzentration auf einen Aspekt ohne Ber cksichtigung anderer Aspekte oder e Verf gbarkeit einer bestimmten zumeist unvollst ndigen Entwicklungsumgebung oder einer bestimmten Entwicklungsmethodik und resultieren in e unterschiedlichen Spezifikatio
250. ltungsangebot gemeinsam Dabei existieren zwei Einwahlstr nge die parallel ablaufen die Planung von Vorlesungen mit den bungen etc und die Erarbeitung eines Seminarvorschlages Bei der Pla nung von Vorlesungen kann man ausw hlen ob eine Anforderung bearbeitet wird oder ob ein neuer Kurs erarbeitet wird Bei der Eingabe von Daten kann man auch auf alte historische Daten zur ckgreifen Analog kann auch ein Mitarbeiter eines Lehrstuhles seine Arbeitsaufgaben diskutieren Am Ende werden die Daten durch den Lehrstuhlleiter eingereicht Eine analoge Szene k nnen wir auch generisch entwickeln Eine Suchszene in einer Webseite mu unterschiedliche Facetten der Suche darstellen e Die eigenschaftsbasierte Suche orientiert sich auf Haupteigenschaften die auch als solche f r den Content spezifiziert sein m ssen z B durch Angabe von Schalen eines Sterntyps Die eigen schaftsbasierte Suche mu robust sein Wir wenden deshalb daf r SoundEx Algorithmen an INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 129 Szene zur kollaborativen Semesterplanung Einreichung der Daten durch ehrstuhlleitet Akzeptierung eiher Zuweisung von Kursen Mitarbeit Best tigung Login gt Generierung Anpassung Best tigung durch den neuer Kurse der Daten der Kurszuweisung als Vorschl ge r einen Kurs duxch Mitarbeiter Lehrstuhl ormulierung von Neben bedingun
251. lung aufgefordert Kl rung Es erfolgt mit dem Partner eine Kl rung Entscheidung Es wird mit dem Partner eine Entscheidung getroffen Orientierung Es wird dem Partner eine Orientierung f r dessen T tigkeiten gegeben Wir k nnen mit dieser Klassifikation der Arten des Zusammenwirkens in Erweiterung der Klas sifikation Wer 2 Wem 2 steht f r to mit mit einem Muster der Form Provider des Inhaltes 2 Kunde der Aktivit t charakterisieren Daraus ergibt sich f r die Gestaltung von Websites eine Klassifikation in E Business Sites B usiness 0 2V erwaltung un B 2B BP2K unde Ffen Vi nformation 2K kauten K 2 K kaufen bzw C ustomer kaufen Lern Sites BW issen gg lernen KW 2 Klemen Information Sites B2 f ormation 2G as ren Vi2QGinformieren KTyginformieren Arbeitsgruppen Sites A rbeitsgruppe 2A Sieren A 2 informieren agieren Corporate ldentity Sites P rovider 7 2G 5chauen Unterhaltungs Sites BY rterhaltung agieren GU Gagieren Arbeitsplatz Der Content Typ Arbeitsplatz soll die Kollaboration unterst tzen Er mu deshalb auch die Aspekte der Kollaboration ber cksichtigen Zur Darstellung benutzen und verfeinern wir die Kern Typen des Content Typs Arbeitsplatz Akteure werden mit ihren Kollaborationsbeziehungen dargestellt Sie umfassen Kooperationsbeziehungen X5 1 x5 58 8 95 8 5 x kasa 134 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003
252. lvierte Akteure Oft wird eine vollst ndige Beschreibung schwierig Deshalb k nnen wir eine Beschreibung gliedern in obligatorische Bestandteile deren Spezifikation unbedingt erforderlich ist weitere sinnvoll Bestandteile good practice deren Spezifikation der weiteren Bearbeitung zu gute kommt und die in einer Spezifikation nicht fehlen sollten optionale Bestandteile die eine Beschreibung sinnvoll erg nzen aber die nicht f r den Abschlu der Spezifikation erforderlich sind und n tzliche Bestandteile die eine Einordnung und eine Beschreibung des Kontextes erlauben Diese Untergliederung erscheint auf dem ersten Blick als berfrachtet Da in der Praxis Entwicklungs gruppen sehr h ufig innerhalb kurzer Zeitr ume wechseln bzw je nach Projektetappe nur f r eine kurze Zeit existieren ist eine gute alle Aspekte umfassende Dokumentation erforderlich Eine Beschreibung der Dialogszenen in denen diese Untergliederung vorgenommen ist wird im folgenden Arbeitsblatt angegeben 128 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 7 INTERAKTIVITAT Szene header Inhalt Name Entwickler copyright Problemgebiet Motivation Source L sung Intention auch bekannt als siehe auch Variante Anwendungsgebiet Anwendung Anwendbarkeit Konsequenzen der Anwen Beispieleinsatz angewandt in Anwendun dung gen Benutzbarkeitsprofil Erfahrun
253. m yy I9IS G 9SSIZOLI SOYPSISOT upps solloygg pun myppmags OSSTUSIOIO u uonyuni uouorgyuny yuequeyeq NLIOJLIM UI 2SAS HOMN uojouy ssunpuomuy my uodAT yq OSSTUSIOIO uoyloyuro SS Z y fqo yeyosor syeypsery suoryestuesig oa osyeyosey o1rdsyyeyosoxy S Tev s r JOzUsog ISSTUZTO LO u r qur SS Z syeyoses suoryestuesi0 9410 oidsyeyosex n qepsayeq s r tzydnef 10 1 psyeyosesydney H ssery SS TY J Uejd oyyadsy oyyadsy oydstyegs 110110 INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 33 Mit dieser Verallgemeinerung wird die Mitwirkung unterschiedlicher Personen zu unterschiedlichen Zeiten im Entwicklungsproze sichtbar Planer in der Motivationsschicht Durch den Systemplaner wird eine Analyse des gegebenen Zustandes und eine Zielbestimmung f r die gesamte Anwendungsentwicklung vorgenommen Besitzer in der Motivationsschicht Durch den Besitzer werden die Randbedingungen f r die Entwick lung vorgegeben Entwerfer in der konzeptionellen Schicht Ein Entwerfer ist hauptverantwortlich in der konzeptionellen Schicht zugleich allerdings Partner der anderen Personen in allen anderen Schichten Programmierer und Anwendungsentwickler in der Implementationsschicht verwenden die Entwurfsdoku mente zum Erstellen der Programme nderungen der
254. m besteht aus Szenen und markierten Transitionen zwischen diesen Szenen Eine Story stellt einen Handlungsstrom mit allen seinen Varianten dar Ein Szenarium ist ein Durchlauf durch eine Story d h ein Objekt einer Story wenn wir die Story sn ual 1236 h ara 122 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 7 INTERAKTIVITAT Szenario stellen ein B ndel oder einen Pfad von Durchl ufen dar Szenario k nnen zu einer Story zusammengefa t werden Innerhalb eines Story Raumes k nnen viele Stories realisiert werden Neben den Stories k nnen auch Nebenstories und Hauptstories spezifiziert werden Eine Story besteht aus Szenen in denen Akteuren ihre Content Suite in ihrem Repr sentationstil und in Abh ngigkeit von ihrem Kontext dargestellt wird Der Akteur stellt eine Gruppe von Benutzern in abstrakter Form dar Eine Szene besteht aus Dialogschritten in denen die zugelassenen Akteure bestimmte Aktionen un ternehmen Die Markierung von Szenen wird beschrieben durch Ereignisse oder Aktivit ten f r den bergang von einer Szene zur n chsten durch die involvierten Akteuere durch Vor und Nachbedingungen f r die Nutzung der Szene durch die Priorit t der Transition durch die H ufigkeit und durch die Anzahl der Wiederholungen Dialogschritte sind beschrieben durch die Sichten auf die Content Objekte die Manipulationsanfor derungen die zugelassenen Operationen die Vorbedingung eine Abschlu bedingung und die Frei
255. m praktischen Nutzen ab Sie dienen damit dem Ziel einer m glichst effektiven Abbildung des Anwendungsgebietes Die Informatik hat bislang nicht allzu viele Prinzipien hervorgebracht Die Mathematik kann man auf die Triade reduzieren Strukturierung Topologie und Symmetrie bzw Erzeugung In der Kristal lographie unterscheidet man drei Grundbegriffsarten wie in Bild 1 Diese drei Prinzipien sind analog zu den Prinzipien der Quantenphysik Dieses Modell kehrt auch in den Gesellschaftswissenschaften wieder In analoger Form kann auch die Strukturtheorie der Mathematik verstanden werden Topologie Gesellschaft Topologie Kristallographie Gesellschaft senschaft Strukturierung i r Mathematik Geometrie Symmetrie Individuum Entwicklung Algebra Ordnung Bild 1 Die drei Prinzipien der Kristallographie der Gesellschaftswissenschaft und der Mathematik Die Informatik f gt diesen drei Prinzipien ein weiteres Prinzip hinzu die Abstraktion Das Ab straktionsprinzip ist bereits in den Ans tzen der Quantenphysik implizit enthalten und ist bei den Prinzipien der Gesellschaftswissenschaften verwirklicht Gleichzeitig erfahren diese Prinzipien viele Auspr gungen Kommunikation Qo O O Zustand Zei tliche Entwicklung ulu Struktur Entwicklung feo 7 Modellierung Komponentenabstraktion Bild 2 Die vier Prinzipien der Informatik Jedes der vier Prinzipien besitzt unterschiedliche Facetten So sind die Kooperation die Kom munikation un
256. ma 100 Skalierbarkeit 150 Skizze 177 SPICE 179 Statische Integrit tsbedingung 42 Stern Schema 93 Steuerspezifikation 66 Story 107 177 Story Raum 121 Storyboard 107 Strategieschicht 34 Streichen von Objekten 61 Struktur 42 Strukturelle Rekursion 60 Strukturierung 3 Subjekt orientierte Programmierung 129 Suite 81 Syntax 5 System Gesichtspunkt 104 Szenario 107 123 Szenarium 123 128 Szene 37 109 Teilstruktur 60 Temporale Formel 72 Temporale Klasse 71 Thema 107 Theorienwelt 149 Transaktion 64 Transitionsbedingung 72 Transparenz 150 Typ 37 43 I ill Py 2 Umschlag 95 Update 61 Vereinigung 61 Verpackungsumschlag 95 Verteilte Datenbank 157 Vertrag 132 Vor und Nachbedingung 72 Weiche Integrit tsbedingung 72 Wertebereichsabh ngigkeit 51 Wissensprofil 118 Workflow 36 Workflow Impedance Mismatch 73 Workflow Maschine 70 Wortfeld 74 109 Zachman Modell 32 38 Zeitrahmen 71 Zielstruktur 117
257. meist verteilt auf Struktureinheiten auf unterschiedliche Orte und auf die Infrastruktur Die Verteilung des Datenbanksystemes war von untergeordnetem In teresse solange eine verteilte Verarbeitung keine Effizienzvorteile brachte Mit der Entwicklung der Vernetzung und der effektiven Unterst tzung hat sich dies grundlegend ge ndert Akteure wer Mit der Entwicklung der k nstlichen Intelligenz wurde auch das Mensch Maschine Interface komfortabler Spezielle Schnittstellen f r unterschiedliche Benutzer je auch F higkei ten Fertigkeiten Wissen Arbeitsaufgaben Arbeitsumfeld Rollen und Rechte k nnen mittler weile durch DBMS unterst tzt werden Demzufolge sind die Akteure als Gruppen von Benutzern mit zu modellieren Zeitpunkte wann Daten altern auf unterschiedliche Art und Weise je nach der Benutzung der Sichtweise der Benutzer der Erneuerungsstrategie und der zur Verf gung stehenden Infra struktur und Systeme Der Alterungs und Erneuerungsproze kann durch Modellierung der Zeitaspekte beherrscht werden Motivation warum Die Akzeptanz der Systeme wird stark durch die Motivation der Akteure mit bestimmt Wir verallgemeinern die Motivationsschicht zur allgemeinen Benutzbarkeitsschicht Metaaspekte werden im Zachman Modell bis auf die Motivation nicht betrachtet Beispiele solcher Kategorien sind Qualit tskategorien wie Allgegenwart Sicherheit Konsistenz Bedeutungstreue Robustheit Skalierbarkeit und Dauerhaftigkeit
258. menh nge in einem Integrationsschema der Sichten Die Koh sion zwischen den Sichten ist ein wichtiger Hin weis f r eine sp tere Sichtenintegration Damit wird eine Bereinigung von Integrationskonflikten sp ter vereinfacht und algorithmisch beherrschbar Aktionssichten Suite Fine Suite besteht aus einer Menge von Elementen einem Integrations bzw Zusammenhangsschema zur Pflege des Zusammenhanges und Obligationen Die Aktionssich ten stellen die Strukturierung der Daten in einer Form dar wie sie der Benutzer sehen wird Dazu werden die Kerntypen dargestellt Aus den Kerntypen k nnen wir alle Sichtenskelette zusammenstellen Damit werden durch die Sichtenskelette alle Typen repr sentiert die f r den Anwender eine Bedeutung haben Die Typen stellen eine Verfeinerung der Typen des Pflichten hefts dar oder sind neu eingef hrt Die Aktionssichten Suite besteht aus den Sichtenskeletten mit den Kerntypen und aus dem weiterentwickelten Integrationsschema Die Sichtenskelette werden in bereinstimmung mit dem Storyboard und dem Anwendungs schema entwickelt Eine Spezifikation der einzelnen Sicht kann eine vollst ndige Erfassung aller Pa RR di Ks ER ME x 0 6 a i ee To ah eae ee ne BEE nn 82 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 6 SICHTENSUITE Anwendungsschemas gefiihrt werden kann Falls ein Anwendungsschema vorliegt dann sollte jede Sicht auch als Anfrage ber dem Anwendungsschema formuliert
259. ment und die ausgearbeite Story Ein solches schrittweises Vorgehen bringt betr chtliche Vorteile durch die schrittweise Beseitigung von Unsicherheitsfaktoren und das Hinzuf gen von zus tzlichem Material mit sich Jede Szene kann damit ihren richtigen Platz in der Story erhal ten Spr nge werden vermieden Der langsame Aufbau gew hrleistet auch Detailtreue Eine Story baut auf Ereignissen auf in denen Akteure in Arbeitsschritten ontologische Ein heiten benutzen Deshalb wird hier auch eine enge Integration der Dialogentwicklung mit der Entwicklung der Sichten und der Funktionen vorgenommen Das Resultat dieses Schrittes ist als Handlungsrahmen Bestandteil des Pflichtenheftes Die Spezifikation des Storyboards wird auf der Grundlage der entwickelten Story durch Auswahl von m glichen Auspr gungen und Verfeinerung entwickelt Die Story besteht aus Szenen die nun in einer Form ausgepr gt werden die dem tats chlichen Ablauf der Handlung entspricht Wir nutzen dazu eine Aufnahme der m glichen Szenario Ein Szenario ist ein genereller Ablauf aus der Sicht der Akteure Dieser Auflauf oder Durchlauf soll dem aktuellen Geschehen in der Anwendung entsprechen Die einzelnen Szenario k nnen wir schrittweise miteinander verkn pfen und diese integrieren Mit einer derartigen Integration entsteht eine Verfeinerung der Story Die einzelnen Szenen werden nun durch entsprechende Dialogschritte untersetzt in denen die Akteure entsprechende Handlungen un
260. merziellen Systeme befriedigt z B ist das Kriterium 10 bei einigen Firmen im Interesse der Firmenpolitik nie unterst tzt worden Die meisten dieser Regeln f hren direkt zu heterogenen DBMS Die meisten kommerziellen DBS unterst tzen eine Teilfunktionalit t von verteilten DBS Beispiele kommerzieller Systeme sind Tandem NonStop SQL CA Ingres Star CA DB STAR Oracle Infor mix Star Sybase Replication Server IBM DRDA DB2 DB2 2 DB2 6000 SQL DS Cincom Supra Empress UDS D und Sesam DCN Fr he Prototypen sind z B die Systeme R IBM SDD 1 CCA Distributed Ingres VDN POREL DDM DDTS Sirius Delta und Polypheme 148 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 8 VERTEILUNG Facetten der Verteilungsqualit t Die Qualit t der Verteilung wird aus unterschiedlichen Gesichtswinkeln beurteilt Die Bandbreite der Anforderungen ist sehr hoch Wir k nnen dies an einer Reihe von Dimensionen feststellen Allgegenwart Ubiquity Daten haben je nach Anforderungen eine unterschiedliche Aktualit t Typi sche entgegengesetzte Anwendungen sind nomadische Informationssysteme bei denen Datenbest nde der einzelnen Knoten ggf auch zu einem sp teren Zeitpunkt aktualisiert und abgeglichen werden und fest miteinander kooperierende Informationssysteme in denen Kopien von Objekt Suiten ber Re plikationsmechanismen miteinander verbunden sind und die alle gleichzeitig die gleiche Aktualit t haben Mobilit t der Rechner be
261. mit Bedingungen erfolgt die erst zur Laufzeit gepr ft werden k nnen Steueranweisungen mit A priori Laufzeitannahmen erlauben eine Voreinstellung durch Erzeugung von einer beschr nkten Menge von Wiederholungen und Steueranweisungen mit Synchronisationsbedingen bei denen beliebig viele Alternativen parallel ausgef hrt werden k nnen und eine Synchronisation bei Abschlu erfolgt Zustandsbasierte Steueranweisungen sind die verz gerte Auswahl bei der alle Alternativen ausgef hrt werden und eine Auswahl der Al ternative erst nach Ausf hrung erfolgt die verbundene parallele Ausf hrung bei der die Alternativen in zuf lliger Reihenfolge sequenti ell ausgef hrt werden und die meilenstein basierte Steuerung bei der eine Aktivit t ausgef hrt wird bis ein Meilenstein erreicht ist Abbruchanweisungen sind Abbruchaktion bei der eine Aktion abgebrochen wird und Fallabbruch bei der ein Fall abgebrochen wird Diese Algebra kann durch die Algebra der Workflow Maschine ausgedr ckt werden Wir verstehen sie deshalb eher als syntaktischen Zucker der die Spezifikation von Workflow Programmen vereinfacht Mit dieser Algebra f hren wir eine rigide Klammerung ein Damit sind nicht mehr alle Ausdr cke 2 A hi hy MEN Pe EOP ORO N Eh ct nh i ke rR Sa ES e 5 EL 2 7752185 S a b 20 Sd INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 79 WF WR W Fs W F
262. mleistung mit Me kriterien wie Durchlaufzeit Kosten Fehlerquote etc ermittelt Die Untersuchung beruht auf einer Reihe von Qualit tsparametern e Allgemeine Aspekte wie der Output des Produktes Abnehmer H ufigkeit der zuk nftigen nderungen e Zeitaspekte wie L nge Liegezeit Bearbeitungszeit Transportzeit termingerechter Ab schlu Qualitatsaspekte und Zufriedenheit wie Arbeitszufriedenheit Anforderungen der Kun den Beanstandungen iterative Fehlerreparaturen weitere Anpassungen des Prozesses Struktur und Mengendaten z B die Anzahl der Teilnehmer H ufigkeit parallele Prozesse Rollen Organisationseinheiten Anzahl der Aktivit ten parallele Aktivit ten Adressaten Inputinformationen Koordinierungsaktivit ten Verantwortlichkeit ben tigte Sachmittel Aufwand und Ertrag versus Kosten Nutzen z B Materialkosten Informatikkosten Per sonalkosten Gemeinkosten Globale Strukturierung und Selektion eines zu ver ndernden Prozesses Es wird eine Migrations strategie vom abzul senden System hin zum neuen System erarbeitet Formulierung der definitiven Ziele Es werden die Ziele an den notwendigen Verbesserungen orien tiert und je nach Bedeutung f r zuk nftige Prozesse gruppiert und geordnet Dadurch entsteht ein Zielportfolio mit einer Konzentration auf zentrale Ziele Ermittlung von organisatorischen Ma nahmen Zum Erreichen des Zieles werden Ma nahmen anhand der vorher herau
263. mp gozo1g yfazoud MOY uodunf assozoidsyyeyaser qe ryeuouyunnusup uornd zuoy pueH mopom yemp MOJOM 014 mp MOPYIOA mor syLoy soJouU soyJouy EWOUS YI ewsysssdunpusmuy s p Treyusyeq usIse sep Treyusgeq WII J101Yusse1del dAyssunpuem dAL qd zuoy uorydozuoy uy q mp dAyusyeq ueqors q mp dAyueyeq ypanp dAyusyeq dhizuazog eu q s eur n ssaunp reypuend zuoy 4 2 uomuy 9ZZINS ymp euroyps q mp eu q s uond zuoy JYDIYDSSUOIIYV YoIYDSgazoudsyeyose5 TYDIYDSSUOIJEAIIO INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 39 Ein Vorgehensmodell Wir k nnen mit dem Abstraktionsschichtenmodell zur Entwicklung von Informationssystemen eine Reihe verschiedener Entwicklungsmodelle unterst tzen In der Strukturierungsorientierten Entwicklung wird zuerst die Datenbank Struktur weitestgehend ent wickelt Darauf aufbauend werden die Prozesse und die Sichten und abschlie end die Pr sen tationskomponente entworfen und implementiert Diese Vorgehensweise entspricht dem klas sischen Entwicklungsansatz hat aber den Nachteil einer hohen Modifikationsrate aller vorher erstellten Dokumente In der proze orientierte Entwicklung wird zuerst die Funktionalit t der Anwendung entworfen und prototypisch realisiert Danach werden die entsprechenden Datenstrukturen entwickelt und ab schlie end die Pr sentat
264. n Mitglieder eines Lehrstuhles wirken koordiniert zusammen indem ein Mitglied die Rolle des Koordinators bernimmt und die einzelnen Mitglieder schrittweise ihre Obligationen erf llen Ein anderes Beispiel der Koordination ist das Zusammenwirken eines Programmkomitees Dieses Komitee wird durch einen virtuellen Koordinator zur Erf llung von Aufgaben Erstellung von Gut achten zu Arbeiten z B angehalten ggf auch durch entsprechende Nachrichten ermahnt und durch Nachrichten ber den Fortschritt der Kollaboration informiert Wir k nnen deshalb den folgenden Koordinationsrahmen zur Spezifikation verwenden Koordinationsform Aufgabenverwaltung Koordinator Form Rolle Formie Syn Feh Auf Zu Dis Part Gruppe Dien Port Na rung chro ler gabe ord kurs ner ste folio mens nisa mo nung typ raum tion dell INFORMATIONSSYSTEM ENTWICKLUNG IM Co DESIGN ZUGANG BY 8 155 Die unterschiedlichen Bestandteile von Kommunikation Kooperation und Koordination k nnen f r das Arbeitsblatt zum Austauschrahmen zusammengefa t werden der aus drei Dimensionen besteht Architektur Die Architektur stellt einen Zusammenhang der verwendeten Dienste und Komponen ten her Kollaborationsstil Der Kollaborationsstil stellt die Modelle zur Unterst tzung Zugriff zur Imple mentation der Kollaboration und den Kollaborationsdiskurs dar Kollaborationsform
265. n Wir modellieren deshalb die Akteure in dieser Etappe mit ihren Rollen Rechten Aufgaben und Zielen im Groben Der Handlungsrahmen ist mit der Darstellung der Motive und Ziele im vorigen Schritt bereits skizziert BE en a ek ay oer 6 A LP s a a l Fa ee PRONE R d 6 Tutub AR H 26 106 B THALHEIM Motivations schicht Gesch ftsproze schicht Aktions schicht konzeptionelle Schicht Implementations schicht PREPRINT BTU INFORMATIK I 15 2003 Vorstudie Story Entwurf Stories Feinstudie Szenenentwicklung Plot Entwurf Szenenbeschreibung m Szenenraum g Implementation Szenenausschm ck n nwendungsgebiet Lastenheft Diskurs 7 flichtenheft Handlungsrahmen 75 Storyboard Drehbuch a Inszenierung Pr sentations raum KAPITEL 7 INTERAKTIVIT T Anwendungsschritt Ereignis Thema Dialogschritt Arbeits oberfl che Bild 39 Die Arbeitsprodukte im Abstraktionsschichtenmodell f r den Story Raum Dialogaspekte INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 107 worin die Geschichte besteht In der Geschichte werden die Hauptdialoge mit ihren Zielen und Absichten dargestellt Nicht alle Einzelszenen m ssen enthalten sein Es existiert eine Vielfalt von m glichen Stories Trotzdem gibt es Regeln zur Beschreibung von Geschichten Jede Geschichte wird durch
266. n bis hin zu Datenbanksystemen der ersten Ge neration Der Speicher dient der Ablage dieser Daten auf einheitlicher technologischer Plattform Wahrend der Entwicklung eines Datenbank Warenhauses sind unterschiedliche Akquisitionspro bleme die bereits f r f derative Systeme in Ans tzen auftreten zu l sen Gleiche Information in verschiedenen Datenbanken Sind Daten in mehreren Systemen vor handen dann treten sowohl Konsistenzprobleme als auch Integrations und Beschreibungs probleme auf Historische Information Daten sind meist ohne einen Hinweis auf den letzten update oder auch ihre G ltigkeit abgelegt Beim Vergleich von Datenbest nden ist aber eine Information ber das Alter von Daten sinnvoll Korrektheit der Ausgangsdaten Unterschiedliche Systeme k nnen sehr unterschiedlichen Quali t tsanspr chen gen gen Unterschiedliche Vollst ndigkeit der Ausgangsdaten In den verschiedenen Systemen k nnen zum gleichen Themenkreis Daten in verschiedenem Umfang existieren Unterschiedliche Funktionalit t der Ausgangssysteme Information kann sowohl in den Da ten der Ausgangssysteme vorhanden sein als auch durch die Funktionalit t der Ausgangssysteme extrahierbar sein Unterschiedliche Semantikintegration der Ausgangssysteme Da auch die Ausgangssysteme mit unterschiedlichen Modellierungsmethoden entwickelt wurden ist auch die Semantik des Anwendungsgebietes auf unterschiedliche Art und mit unterschiedlicher Vollst ndigkeit a
267. n s gestaltet werden Schaltfl chen dienen zum Ausl sen von Funktionen Die Eingabemaske eignet sich am besten zur Eingabe von Informationen ber eine semantische Einheit Sie sind weniger f r die Modifikation von Daten geeignet Dazu ist eine Men struktur eher geeignet Arbeitssicht Eine Arbeitssicht auch Arbeitsbereich in der Literatur definiert alle Informationen die f r eine bestimmte Aufgabe ben tigt werden Layout Durch das Layout wird die Darstellung der Informationen der einzelnen Arbeitsschritte be schrieben Proze sicht Durch die Proze sicht wird der Arbeitsablauf bzw der Gesch ftsproze der Anwendung spezifiziert Diese ergonomischen Prinzipien die allgemein f r Softwareprodukte entwickelt wurden k nnen zu Gestaltungsprinzipien weiterentwickelt werden bzw von produktspezifischen Forderungen kann ab gesehen werden Wir f hren als allgemeines Rahmenwerk Gestaltungsrahmen ein Die Gestaltung von Schnittstellen besitzt eine Reihe von Analoga mit der Gestaltung von Werbe material Aus Optimierungsgr nden sind jedoch kaum dessen gestalterische M glichkeiten aussch pf bar Insbesondere sind die Effizienz und die bersichtlichkeit zu beachten Hinzu kommen aber auch zus tzliche M glichkeiten Werkzeuge die z Z im Entstehen sind werden auch Sprache Gestik in telligente Agenten und integrierte Multimedia Panmedia ist ein besserer Begriff einschlie en Graphiken von Web Oberfl chen werden immer noch
268. n und Rollen zugeordnet Diese Rollen erlauben einem Akteur das Agieren mit dem Informations system Eine direkte Interaktion mit entsprechenden Funktionen ber entsprechende Sichten oder das Schema direkt ist nach wie vor auch m glich In diesem Fall wird jedoch nicht eine entsprechende Oberfl chenmodellierung vorgenommen Da solche Interaktionen in ihrer Vielfalt kaum zu behandeln sind modellieren wir sie nicht gesondert sondern benutzen die Dienste der logischen Schicht lay ob 20 60 du 4 70 en ko nN 2 x q ae E E E ee 114 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 7 INTERAKTIVIT T Dieses Akteurmodell verallgemeinert das Use Case Modell Wir streben eine m glichst abstrakte Beschreibung am Anfang an und gehen erst dann ins Detail wenn der Endanwender nicht mehr in volviert ist Beziehungen zwischen den Akteuren werden nur durch entsprechende Dialoge aufgebaut Die Beziehung zwischen Akteur und System findet hier jedoch nur durch entsprechende Dialoge statt Ein Akteur aktiviert einen Dialog und erh lt Daten aus dem Dialog modifiziert Daten im Dialog oder stellt dem System Daten im Dialog zur Verf gung Damit ist das hier angewandte Modell viel allge meiner und zugleich praktikabler als das Use Case Modell Einem Akteur wird ein Profil zugeordnet Es umfa t das Ausbildungsprofil mit einer allgemeinen Darstellung der erforderlichen Kenntnisse F higkeiten und Fertigkeiten das Arbeitsprofil m
269. n Parametern aktueller Arbeitssichten k nnen auch entspre chende Content Objekte zugewiesen werden so da mit einer Importfunktion auch das aktuelle Content Objekt ver ndert wird Sowohl Import als auch Exportfunktionen k nnen auf der sogenannten Wrapper Technologie aufsetzen Wir verwenden zur einfacheren Integration die unten dargestellten Mechanismen der Sichtenkooperation In unserer Anwendung kann z B die Archivsicht um Funktionen zum Druck wie folgt erweitert werden extend Archivsicht by functions EXPORTFUNKTIONEN Profil bersichtPDF Professor Name Dokument Vorlesungsprofil Professor Name LV Ubersicht Markierungsfunktionen erlauben dem Benutzer mit den dargestellten Daten so umzugehen wie mit Daten auf seinem Schreibtisch Es kann dem Akteur eine sehr breite Palette zur Verfiigung gestellt werden Oft verwendet werden Funktionen wie Kopierfunktionen zum Kopieren von Daten in den eigenen Arbeitsraum Farbungsfunktionen zum Markieren von Daten mit unterschiedlichen Beschriftungen wie z B Farben Beschriftungsfunktionen zur Annotation zum Einbringen von Kommentaren und zum Anbrin gen von Variationen Markierungsfunktionen k nnen durch einen benutzereigenen Container unterst tzt werden Container werden auf Seite 96 eingefiihrt Funktionen zur Sitzungsverwaltung erlauben einem Benutzer auch die Wiederaufnahme der Arbeit an der entsprechenden Stelle Jedem Benutzer wird in seinem Arbeitsraum auc
270. n Strukturentwurf dominiert Der Datenbankentwurf ist Bestandteil jedes Datenbankkurses Zwischen 30 und 50 des Umfan ges von Datenbankb chern werden diesem Teil gewidmet Oft wird z B in der folgenden Reihenfolge vorgegangen Struktur des Entwurfsprozesses Anforderungsanalyse Modellierung mit dem Entity Relationship Modell relationale Modellierung und Normalisierung objekt orientierte Modellierung Sichtenentwurf bersetzung in logische Datenmodelle physischer Entwurf verteilte Datenbanken Tuning und Optimierung Eine Methodologie f r den Datenbankentwurf ist damit jedoch nicht gege ben Eine Methodik wird allerdings durch die Reihenfolge der Kapitel vorgegeben Diese oft empfohlene aber den Entwerfer grausam berfordernde Methodik bedeutet f r jeden Schritt ein anderes Modell zu verwenden f r die Anforderungsanalyse ein Fragment der nat rli chen Sprache f r den Strukturentwurf das Entity Relationship Modell f r den Semantikentwurf das Eine Methodik die auf der strukturellen Rekursion aufsetzt besteht i a aus drei Bestandteilen einer Sprache zur Darstellung der Urteile Entwurfsurteile einer Menge von Regeln zur Konstruktion neuer Urteile und einer Menge von Konsistenzregeln mit denen falsche Konstruktionen ausgesondert werden k nnen Eine Entwurfsentscheidung geht q ae ee a ee Ce 12 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 1 EINFUHRUNG relationale Modell fiir den operationalen Entwurf ei
271. n des Schemas an Ist ein Schema nicht zusammenh ngend und ist keine Adh sion unter den Elementen der nicht zusam menh ngenden Teilschemata definiert dann nehmen wir AM T 72 an Eine Adh sionsmatrix ist konservativ falls AM T 72 lt M T1 T3 f r Typen T T von types G und Teiltypen Tj 72 von jeweils 71 To Eine Adh sionsmatrix mu nicht symmetrisch sein Teiltypen 71 75 eines Typen T k nnen dem Typen T unterschiedlich nahe stehen Durch eine Adh sionsmatrix k nnen wir f r jeden Typen T von types G Schalen definieren durch Shell T types G i T types G AM T T xi Die Schalen erlauben eine automatische Separation insbesondere im Falle eines nicht ausreichenden Darstellungsraumes auf dem Bildschirm Mit der Adh sionsmatrix wird dargestellt welche Typen und Teiltypen gemeinsam auf dem Bildschirm erscheinen m ssen und welche nicht unbedingt im Zusammenhang mit einem Typ dargestellt werden m ssen Wir k nnen die Schalen und deren Beziehungen als Hypergraphen wie in Bild 35 dar stellen Ein Hypergraph besteht aus Knoten V und Hyperkanten H C 2 In unserem Modell sind die Hyperkanten hierarchisch Es existiert eine lexikographische Nummerierung E j i der Kanten in H so da Ez genau dann gilt wenn 7 der Beginn von 7 ist Die Wurzel ist der Knoten Eine andere Darstellung kann auch analog zu Bild 21 mit dem erweiterten ER Modell angegeben werden indem die Rauten als R
272. n und die Funktionalit t wie in diesem Abschnitt dar gestellt zur Verf gung Abstrakte zu Content Objekten sind zusammenfassende Beschreibungen des Inhaltes Sie k nnen auch leer sein Kuverts erlauben die F hrung von Begleit und Benutzungsinformation zu Content Objekten Operationen opse sollen die Verwaltung der drei Zustandsr ume unterst tzen Deshalb unterscheiden wir Auswertungsfunktionen zur Einlagerung von Content Objekten in den Container Operationen zum Ver ndern des Zustandes des Containers Operationen zum Anfordern von Content Objekten aus dem Container Beschr nkungen Xe zum Container selbst sollen insbesondere darstellen das Vergleichsverm gen des Containers auf der Grundlage von Vergleichsmustern die Beladungskapazit t eines Containers und die Entladungsbeschr nkungen f r den Benutzungskontext Die R ume des Containers realisieren einen Tupel Raum Jedes Element hat die Form Variable Wert Die R ume enthalten Multimengen von Elementen d h T ifil M th th Eine Unterscheidung von Elementen erfolgt durch eine Mustererkennung der Variablen Sind Elemente mehrfach in einem Container enthalten dann mu eine intelligente Mustererkennung eine Separation erlauben Variable sind Worte eines Alphabetes Alph Variable k nnen auch die Kuverts und Abstrakte aufnehmen Werte sind Content Objekte Ein Container ist konsistent beladen falls seine Tupel Variablen eindeutig sind Wir fordern jedoch keine Ko
273. n wird durch den Aufgabenbereich der Redaktionsgruppe diktiert Dokumente die keine Endfassung darstellen werden nach der Redaktionsperiode gel scht oder ggf archiviert Unterst tzung der Arbeitsgruppe Ejnreichen Intention gabe Mitglied Rollen Verantwortlichkeiten Einreichen eines Beitrages 7 n cadline Zeitbeschrankungen Ablauf hase Erstelle Beitrag I Redaktionskommissionsmitglied Redaktionsperiode Gemeinsame IT Beitr ge anderer B itrag Art Existenz G ltigkeit Beitr ge zum Durchmustern ee Funktionalit t Content Schreiben inreichen evidieren Downlgad der letzten Version Raum Arbeitsresultate iskupsion der Bei Tage Beitra Durchmustern vorhandener Beitr ge Diskussionsraum 6 ENIA EN Mor Sa Fa lz Esya Bs Bin lt mn anodoan INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 127 Der Spezifikationsrahmen ist eine Verallgemeinerung der Theorie der Wortfelder Die detaillierte Spezifikation der Dialogschritte und Dialogszenen Eine vollst ndige Beschreibung der Dialogschritte kann mit dem Arbeitsblatt erstellt werden Dialogschritt header Name Layout Titel Container Inhalt Text multimedia object Graphik Bild Video Audio Funktionalit t Operationen algorithmisches Objekt Anpassungsstil Einordnung in Hierarchien Adh sion Adaptation Interaktionsstil Steuerungstil invo
274. nalit t erweitert wurden Der Story Raum und die Content Objekte werden im Interaktionsraum zusammengefa t Diese vier Aspekte m ssen gemeinsam bei der Entwicklung eines Informationssystemes betrachtet werden Wir sprechen deshalb vom integrierten Entwurf von Strukturierung Funktionalit t Verteilung und Interaktivit t eines Informationssystemes bzw vom integrierten Entwurf von Strukturierung und d r EEE Rn o en OEY 7 16 EENES 4 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 1 EINF HRUNG Der Entwurfsproze ist ein Proze des Abstrahierens und des Konstruierens Wir k nnen deshalb die unterschiedlichen Abstraktionsarten und Konstruktionsarten miteinander vergleichen Mit dem Zachman Zugang IZG97 k nnen wir beim Konstruieren unterschiedliche Aspekte von Informationssystemen unterscheiden Strukturierung was Die Strukturierung der Anwendung wird durch Datenbankmodelle angegeben Datenbanklehrb cher konzentrieren sich meist auf diesen Aspekt Funktionalit t wie Funktionen und Prozesse die f r die Manipulation und das Retrieval ben tigt werden werden meist erst mit der Entwicklung der Funktionalit t der Anwendung auf dem Ni veau der Implementierung betrachtet Da aber die Optimierung des Verhaltens der Anwendung eine dedizierte Unterst tzung durch die Strukturierung erfahren mu sollte die Spezifikation der Funktionalit t und der Strukturierung abgestimmt erfolgen Lokalisierung wo Anwendungen sind
275. nbanksysteme angese hen werden Architekturen f derierter Systeme von Datenbank Farmen und inkrementellen Datenbanksystem Suiten basieren auf einer Trennung in lokale und globale Komponenten und auf der expliziten Spezifikation der Austauschbeziehungen zumindest f r die Strukturierung von Objekt Suiten mitunter auch die Funktionalit t von Objekt Suiten Architekturen k nnen durch entsprechende Austauscharbeitspl tze unterst tzt werden Unsere konzeptionelle Darstellung kann auf die logische und physische Ebene abgebildet werden durch Abbildungsregeln zur Transformation von Sichten Abbildungsregeln zur Erzeugung der Architektur Abbildungsregeln zur Erzeugung des Kollaborationsmodelles Abbildungsregeln zur Erzeugung des Fehlermodelles und Abbildungsregeln zur Erzeugung des Sicherheitsmodelles INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 31 3 Das Abstraktionsschichtenmodell Gebraucht der Zeit sie geht so schnell von hinnenl Doch Ordnung lehrt Euch Zeit gewinnen Mein teurer Freund ich rat euch drum Zuerst Collegium Logicum J W Goethe Faust Erster Teil Studierzimmer Mephisto pheles Wir erhalten aus Anforderungen der vorigen Kapitels die Aufgabe Strukturierung Funktionalit t Dialoge Verteilung und Sichten auf eine Datenbank im Zusammenhang zu entwerfen Vereinfachend ist dabei da die Dialoge auf den Sichten und den Prozessen aufsetzen und da die Sichten in das Schema einbindbar sein sollen D
276. nd A Netke editors Proc Process Modelling pages 256 275 Springer Berlin 1999 N Rishe Database design fundamentals Prentice Hall Englewood Cliffs 1988 O Rauh and E Stickel Konzeptuelle Datenmodellierung Teubner Stuttgart 1997 B Schewe Kooperative Softwareentwicklung Ein objektorientierter Ansatz Deutscher Univer sit ts Verlag Wiesbaden 1996 G Simsion Data modeling essentials Analysis design and innovation Van Nonstrand Reinhold New York 1994 T J Teorey Database modeling and design The entity relationship approach Morgan Kaufmann San Mateo 1989 B Thalheim Dependencies in relational databases Teubner Leipzig 1991 B Thalheim Entity relationship modeling Foundations of database technology Springer Berlin 2000 See also http www informatik tu cottbus de thalheim HERM htm B Thalheim Abstraction layers in database structuring The star snowflake and hierar chical structuring Technical Report Preprint 1 13 2001 Brandenburg University of Techno logy at Cottbus Institute of Computer Science 2001 See also http www informatik tu cottbus de thalheim slides htm B Thalheim Component construction of database schemes In Proc ER 02 volume 2503 of LNCS pages 20 34 Springer Berlin 2002 B Thalheim Visual sql an er based introduction into database programming Technical Report 08 03 Brandenburg University of Technology at Cottbus Insitute of Computer Science
277. nd Informationssysteme sind heute integrierte eingebettete oder selbst ndige An wendungen und integraler Bestandteil der Infrastruktur von vielen Betrieben Meist wird zwischen die sen Systemtypen nicht unterschieden Wir wollen im weiteren jedoch Datenbanksysteme als die Haupt komponente von Informationssystemen auffassen Informationssysteme verf gen au erdem ber eine Reihe von Anwendungsschnittstellen im Rahmen von Pr sentationssystemen Ein Datenbanksystem umfa t wiederum ein Datenbank Management System DBMS und eine Reihe von Datenbanken Information umfa t immer eine Deutung von Daten Information ist aus unserer Sicht nicht einfach Mikro Wissen oder eine Menge von Daten Wir unterschieden zwischen dem Datum als Folge von Symbolen Nachrichten als bermittelte Daten dem Wissen als validierter wahrer Glaube bzw zusammengefa te kondensierte Fakten Daten und Regeln und Informationen als gedeutete Nachrichten Daten oder Mitteilungen die ein Empf nger mit be stimmten Regeln intuitiv oder explizit ausw hlt innerhalb eines Konterxtes verarbeitet und in seinen Informations Daten bzw Wissensbestand integriert Die Entwicklung eines Informationssystemes mu deshalb alle Aspekte einer Anwendung umfas sen Strukturierung Die Struktur eines Informationssystemes und die statischen Integrit tsbedingun gen werden im Datenbank Schema zusammengefa t das die Strukturierung einer Datenbank beschreibt Funktionalit
278. ndardisierung das Erlernen der Benutzung Die Effizienz und Aspekte der Sicherheit sollten durch das Dialogmangementsystem oder falls kein System existiert dann sind diese Probleme beim Entwurf der Oberfl chen mit zu betrachten Av _ 11 8 Ya u 1 Ca ay jep 19 1 a ee ae a INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 137 optimierbar sein Die Gestaltung von Oberfl chen erfordert die Einbeziehung so unterschiedlicher Disziplinen wie Wahrnehmungspsychologie Ergonomie Soziologie Informatik Grafikdesign und Marketing in die Datenbankprogrammierung In der ersten N herung k nnen die Gestaltungselemente Typographie Symbole und Piktogramme Farbe sowie Proportion und Aufbau des Bildschirms betrachtet wer den Hinzu kommen die Betrachtung der Eleganz und der Einfachheit der Organisation und visuellen Zuordnung von Widget Typen Sichten Suite Fenster Funktionalitat Men Operationsauswahl Strukturierung Konstantenfeld Datenfeld Gruppe Einfach Mehrfachauswahl Liste Tabelle Parameterfestlegung tandardwerte Strukturierung Schemata Repr sentationstypen Name Typ Wertebereich Fenster Men Gruppe Vorbelegungen Konstantenfelder Datenfelder Operationsauswahl Liste Tabelle Standardwerte Benutzerpr ferenzen Umgebungsbeschreibung Stileigenschaften o Abb abstrakter Content Typen Wechselwirkung zwischen auf Zielsystem A
279. nderen Sche mas verkn pft Diese Verkn pfung erlaubt eine Verbindung von Sichten wie in Bild 37 bei Angabe der Funktionen fi und fo Sind die Typen der Sichten entweder ber Schema Morphismen total verbunden oder paarweise verschieden dann sprechen wir von der Sichtenintegration Eine Sichtenintegration k nnen wir damit formal definieren Meist wird eine Sichtenintegration nur pauschal und informal in der Literatur eingef hrt Mit dem Schema Morphismus k nnen wir die Sichtenintegration auch formal fassen In diesem Fall gelten fi2 Gi1 Go und fei Ga Gu Sind zwei Typen total verbunden wird einer der Typen der Schemata zur Weiterf hrung im integrierten Schema ausgew hlt und der nicht verwendete Typ ber eine Sichtendefinition an den eo TEE mi x bo ban INFORMATIONSSYSTEM ENTWICKLUNG IM Co DESIGN ZUGANG BY 8 103 Die Assoziierbarkeit von Typen der Schemata wird durch die Wertebereiche der Typen der Sich tenschemat begrenzt Typen T in G und 75 in z sind wertebereichsvertr glich falls dom T dom T gilt Es ist anzumerken da die Wertebereichsvertr glichkeit nicht auf eine Teiltypen Eigenschaft G11 N f r S r und in G2 N fi2 Giz f r die Morphismen der Sichtenkooperation reduzierbar ist Die beiden Schema Morphismen 12 fG und 121 fK definieren eine Gleichungstheorie Wir k nnen vereinfachend annehmen da alle Typen Namen in den Schemata 6 und G verschied
280. ndet was auch gleichzeitig zu Herausforderungen an der Methodik f hrte Die Bewertung der Methodik nach dem SPICE 2 0 Framework wurde durch die Gruppe um H Jaakkola in Pori dankenswerterweise 2003 durchgef hrt Diese Zusammenschrift ist w hrend meines Sabbaticals im Sommersemester 2003 entstanden Ich danke insbesondere meinen ungarischen Freun den Gyula Katona und Janos Demetrovics f r die jahrelange Unterst tzung und f r das Refugium in der letzten Phase des Zusammenschreibens Ein besonderer Dank geb hrt dem guten Geist des Lehrstuhles Karla Kersten Bitte Diese Arbeit wird nicht endg ltig fertig gestellt sein Jedem der kritische Bemerkungen und auch Verbesserungsvorschl ge hat m chte ich bitten mir diese nicht vorzuenthalten sondern unter thalheim is informatik uni kiel de zukommen zu lassen Weiterentwicklung Die Co Design Methode ist durch eine detaillierte Entwicklungsmethodik unterlegt worden In einer weiteren Arbeit wird diese Entwicklungsmethodik des schrittweisen Entwurfes vertiefend behandelt werden 186 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 BILDVERZEICHNIS Verzeichnis der Illustrationen 1 Die drei Prinzipien der Kristallographie der Gesellschaftswissenschaft und der Ma Scat m b sb vu gi a bon s Sa m s s b ls l 6 Die vier Prinzipien der Informatik 6 Modellierung Verfeinerung Verifikation und Validierung 14 Modellierungsurte
281. ne Methodik der Softwaretechnologie fiir den physischen Entwurf verschiedene Datenstrukturen fiir das Tuning ein operationales Modell etc Die Beschr nkung ist nicht nur da kaum jemand alle diese Modelle im Detail beherrscht und filigran anwenden kann sondern das damit verbundene Abbildungs und Konsistenzproblem Man entwirft mit einem Modell setzt diesen Entwurf im anderen Modell fort und mu die bisherigen Resultate in das andere Modell transformieren Dabei geht meist bereits entwickeltes Entwurfswissen verloren und mu neu entwickelt werden Hier verwenden wir dagegen durchgehend ein erweitertes Entity Relationship Modell das es gestattet das vollst ndige Entwurfswissen in nur einem Modell darzu stellen Die Transformation auf die logischen und physischen Modelle ist bereits seit l ngerer Zeit vollst ndig erforscht Diese Transformation kann uns ein Entwurfswerkzeug vollst ndig abnehmen Wenige ge bte Datenbankentwerfer sind in der Lage beim Strukturentwurf auch die Funktio nalit t die Benutzbarkeit und die Effizienz in Einklang zu bringen Diese Genialit t wird jedoch nur in jahrelangem Training erworben und ist sp testens bei einer Modifikation der Anwendung die bereits meist nach kurzer Einf hrungszeit erfolgt zum Scheitern verurteilt Deshalb ben tigen wir eine Entwurfsmethodik die Struktur Funktionalit t Benutzbarkeit und Effizienz in gleichem ber cksichtigt Die Qualit t von Schemata wird bestimmt
282. ne entsprechende Sicht erzeugt die die Ver arbeitung der Daten erm glicht Daten k nnen unterschieden werden in Retrievaldaten die mit einer Retrievalanweisung anhand der Datenbank gewonnen werden in Inputdaten die ein Benutzer in eine Datenbank einf gt Outputdaten die einem anderen Proze z B einem Out putproze bermittelt werden und Begleitdaten die in einem Proze als Zusatzinformation dienen bzw von anderen Prozessen stammen Diese Daten k nnen zus tzlich Displaydaten sein F r die Entwicklung von Informationssystemen konzentrieren wir uns auf eine Datenbankl sung Deshalb hat der strukturelle Entwurf einen h heren Stellenwert als der funktionale Entwurf Die Unterscheidung der Daten aus dem funktionalen Entwurf behalten wir jedoch bei Sichten im Abstraktionsschichtenmodell Wir k nnen wie in Bild 33 dargestellt auch f r die Sichtenspezifikation das Abstraktionsschichten modell verwenden Da die Sichten aber eine Hilfskonstruktion sind und in engem Zusammenhang zum Schema und zu den Dialogen stehen ist eine isolierte Modellierung der Sichten nicht sinnvoll Im einzelnen verwenden wir die folgenden Schritte Sichten des Lastenhefts Mit der strategischen Informationsanalyse erhalten wir Informationen zu den unterschiedlichen Ansichten der Akteure zur Datenbank Diese Ansichten k nnen im Nachgang zum Struktur Funktions und Dialogentwurf zur Entwicklung einer Vorstellung zu den ein zelnen Sichten genutzt werden E
283. nen browsing zapping n by n object by object mit denen Objektmengen schrittweise b ndelweise im Schnelldurchgang oder auch mit einem Browser durchmustert werden k nnen Kontexterschlie ungsfunktionen mit denen die assoziierten Objekte zu einer Objektmenge erfa t und dann mit den Objekten der Objektmenge verbunden werden k nnen berblicksfunktionen die anhand von Klassifikationskriterien die Erstellung einer Datenland karte unterst tzen und Assoziationsfunktionen mit denen Objekte aufgrund von Assoziationsbeziehungen schrittweise 2 5 8 8 n c s su usb 0 INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 89 In der Archivsicht k nnen wir folgende Funktionen einf hren extend Archivsicht by functions SUCHFUNKTIONEN Lehrveranstaltungs bersicht Von Bis Kurs Name Verantwortliche Semester Bezeichnung stored procedure Lehrveranstaltungen der Architektur Kurs Name stored procedure by functions NAVIGATIONSFUNKTIONEN Semester bersicht Semester Bezeichnung browse by Studiengang Typus by functions ASSOZIATIONSFUNKTIONEN Vorlesungsprofil Professor Name LV Ubersicht view defined as Die Suchfunktionen sollen eine vereinfachte Suche unterstiitzen Die Navigationsfunktionen wer den f r eine begleitende Navigation f r die Oberfl chen der Benutzer erstellt Die Assoziations funktion erlaubt die Erstellung eines Profils mit einer neuen Sicht
284. nformationen das Layout abgeleitet Es orientiert sich an e der Art des Content e dem Inhalt des Content und e dem Anliegen der Benutzung e sowie den technischen M glichkeiten der Umgebung In der kombinierten Dimension der Benutzer Prozesse wird die Story benutzt um die Layout und die Playout Gestaltung abzuleiten Parallel zu den Dimensionen kann der Grad der Auspr gung bestimmt werden mit dem Kategorien wie e kraftvolle Gestaltung e angereicherte wertebasierte Gestaltung e erweiterte Gestaltung um Aspekte von e Verspieltheit Romantik Leidenschaft Kreativit t mit einer Neuheit und berraschenden Effekten e erfrischende Gestaltung mit Momenten einer Leichtigkeit und Transparenz Beruhigung durch Momente der Harmonie und der Ausgegleichenheit und e Anregung durch exotische und magische Elemente e nat rliche Gestaltung mit einem Bezug auf das Umfeld des Benutzers und e dynamische Gestaltung mit einer internen Bewegung und Spannung benutzt werden um eine Verst rkung oder Abschw chung zu erreichen Der Gestaltungsrahmen orientiert sich deshalb zentral auf das Layout der Daten unter Ber cksichtigung der technischen M glichkeiten das Playout der Prozesse unter Ber cksichtigung der technischen Umgebung des Benutzers Metaphern zur Informationsdarstellung und Metaphern zur Story Darstellung und Funktionsunterst tzung und mittelbar auf a en POOE E e E S ps SEE INFORMATIONSSYSTEM ENT
285. ngeben Klassifizieren Einordnen sonstige Angaben erfassen Nebenbedingungen eingeben 2 Kontrolle Beauftragter und Mitglieder des Lehrstuhles Informationsvergleich von Anforderungen Angaben und weiteren Daten 3 Beendigung Beauftragter des Lehrstuhles Ablegen am Lehrstuhl Absenden an auffordernde Einrichtung In analoger Form kann das Verhalten f r Einzelobjekte durch eine Lebenszyklusspezifikation mit einem verallgemeinerten Petri Netz Modell Pr dikaten Transitionsnetz oder einem Automatengra phen beschrieben werden Menge von Zust nden 5 f r jedes Objekt in der Datenbank Menge von Aktivit ten To f r jedes Objekt in der Datenbank Diagramm D SoxTo U To x So Vor und Nachbedingungen zu Aktivit ten V s t f r s t S x Ty als Vorbedingung f r eine Ak tivit t und N t s f r t s S x To als Nachbedingung f r eine Aktivit t Damit kann eine Darstellung durch eine Hoare Logik VtN verwendet werden ne ee ft 799 TT AHA 58 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 5 FUNKTIONALIT T Nachteilig ist da dieser Zugang nur f r Einzelobjekte geeignet ist Durch komplexe Bedingungen kann auch Verkn pfung von Lebenszyklen beschrieben werden Mitunter kann das Zusammenwirken von Objekten eine Komposition des Verhaltens verschiedener Objekte erfordern Der Moment eines Lebenszyklus sind alle Eigenschaften des Objektes im Zustand s Die Spezifikation der Nu
286. ngen und Workflows entwickelt Das einfachste Modell ist das Modell der Job Control Language JCL Dieses Modell wurde f r Skriptsprachen erweitert Fine Transaktion kann ebenso wie ein Modul als abstraktes Programm mit einem Namen und formalen Parametern f r den Input d n Laz WER iv o ME 2 0 ii 82 b 66 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 5 FUNKTIONALIT T Jedem abstrakten Programm sind Parameter Werte Paare zugeordnet die entweder zur Aufruf spezifikation oder zur Steuerungsspezifikation herangezogen werden Diese Parameter sind ent weder ereignisbasiert oder wertebasiert Wir verwenden solche Ereignisse oder Werteparameter in der konzeptionellen Schicht um einen allgemeinen Rahmen f r die Implementationsschicht schaffen zu k nnen Zu solchen Parametern geh ren e allgemeine Aufrufparameter onLoad onSelect onSubmit onUnload onWait onUnWait getData instantiateSession presentationMode presentationStyle typeGlobeSelect onBlur onCancel e allgemeine Priorisierungsparameter wie onFocus changePriority unFocus emphasisMode e allgemeine Steuerparameter wie onReset onRecovery onChange onUserReaction changeToSlave changeToMaster waitUntil securityLevel changeStatus openSatelliteWindow closeSatelliteWindow hook nProcess separateFromProcess defaultSet onScroll deliveryRestriction deliveryMode securityLevel garbageCollector hideMode e Fehlerparameter wie
287. nicht angegeben werden Weiterhin k nnen diese allgemeineren Typen auch f r die Spezifikation der Funktionen verwendet werden Anreicherung der Sichtenschemata um Funktionen Eine Funktion ist allgemein mit einem Definitionsrahmen der folgenden Form spezifiziert Signatur der Funktion Name Input Parameter Output Parameter Basiert auf Sichtenschema Deklaration der Funktion Dieser Definitionsrahmen kann f r jede Art von Funktionsdefinition verwendet werden In vereinfach ter Form kann auch der folgende Definitionsrahmen verwendet werden extend Sichtenname by functions KATEGORIE DER FUNKTIONEN Name der Funktion Input Parameter Output Parameter Deklaration der Funktion In diesem Fall wird die Erweiterung der Sichtendefinition hinzugef gt Wir ben tigen in internet basierten Anwendungen eine ganze Reihe unterschiedlicher Funktionen die wir wie folgt klassifizieren k nnen Durchmusterungsfunktionen erlauben die Erschlie ung von gr eren Datenmengen ohne Verlust der Orientierung Dazu geh ren Suchfunktionen mit denen die Sichten und deren Objekte durchsucht werden k nnen Generalisierungs und Spezialisierungsfunktionen zooming out zooming in mit denen eine Men g ge von Objekten zu einer abstrakten Menge zusammengefa t sowie diese Zusammenfas sungen wieder aufgehoben werden k nnen Umordnungsfunktionen mit denen eine Menge von Objekten auch in einer anderen Ordnung dargestellt werden kann Navigationsfunktio
288. niitzen Goethe Faust Erster Teil Nacht Faust Eine Sprache zur Beschreibung der Strukturierung von Datenbank Anwendungen verf gt ber Konstrukte zur Darstellung der Struktur einer Anwendung Falls diese Sprache nicht zyklisch und induktiv aufgebaut ist ist damit auch eine Einbettung in die Sprache der Pr dikatenlogik der ersten Stufe gegeben Deshalb lassen sich dann statische Integritatsbedingungen als Formeln der Pr dika tenlogik mit einer Standardinterpretation angeben Mit der Sprachkonstruktion und mit Annahmen aus dem Umfeld werden implizite Integrit tsbedingungen aufgenommen Die Sprache zur Beschrei bung der Strukturierung von Datenbanksystemen wird genutzt um diese mit einem sogenannten Datenbank Schema zu beschreiben Inhalte eines statischen Modelles sind daher Strukturen einer Anwendung Statische Integrit tsbedingungen einer Anwendung meist f r die zus tzliche Beschr nkung evt in einer Anwendung vorkommender Daten und Common sense Annahmen ber das Modell die Modellierungsart ber die Interpretation der Daten etc Damit wird das Wissen ber die statischen Gesichtspunkte einer Anwendung modelliert durch Die Spezifikation der Struktur in Abh ngigkeit vom Typensystem mit der Spezifikation des Sei enden entity der Beziehungen relationship und der Eigenschaften Attribute Dinge stehen in Beziehung bzw besitzen Figenschaften die klassifiziert werden durch eine Rolle oder durch Klassenbildung Di
289. nsistenz a priori Ein Container verf gt ber eine Muster Vergleichsfunktion e mit der Elemente verglichen werden k nnen Der Mustervergleich h ngt von den Mustern M ab die ein Container vergleichen kann Die ser Mustervergleich wird benutzt um die Annahme von Content Objekten zu verweigern oder auch dem Benutzer f r seine Spezifikation ein passendes Content Objekt auszugeben Ein Vergleich von Elementen eines Containers nutzt ein Muster m unter Einbeziehung eines der Muster des Containers wobei dann der Durchschnitt der beiden Muster zur Erkennung genutzt werden kann und wird g ltig f r Elemente falls keine Ungleichheit erkannt werden kann Et true falls dm M v v Sm Anm A w w VwHl Vw L v w xen v w e INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 97 Mit diesem allgemeinen Vergleich kann ein Container sowohl alle Elemente als nicht unterscheidbar betrachten M 0 als auch alle Elemente genau unterscheiden M Alpht Wir k nnen nun die Operationen des Containers als parallel ablaufende Operationen zur Zu standver nderung behandeln Diese Funktionen basieren auf folgenden Elementaroperationen des Containers e eval t ist eine Auswertungsfunktion des Containers mit folgenden Eigenschaften e eval t kann ggf die Aufnahme von Content Objekten blockieren In diesem Fall ist das Resultat eine leere Multimenge e Die Auswertung eines Content Objektes kann auch zur Dekomposition dieses
290. nssprachen und unterschiedlicher Semantik und Bedeutung der einzelnen Sprachkonstrukte Au erdem implizieren sie eine Nichtber cksichtigung der Bed rfnisse des Endbenutzers Im Datenbankentwurf wird die Struktur Funktionalit t und Semantik einer Datenbankanwendung so spezifiziert da die infragekommende Anwendung auf einer Plattform bzw einem Datenbankverwal tungssystem DBMS effizient verwaltet und bearbeitet sowie in benutzerfreundlicher Form dargestellt werden kann Damit ist neben der Speicherkomplexit t und der Verarbeitungskomplexit t auch die Einfachheit der Benutzung zu optimieren Diese Aufgabe ist sehr komplex Aufgrund dieser Komple xit t tendieren viele Entwurfsmethodiken zu einem Teilentwurf oder einem partiellen Entwurf Oft wird nur die Struktur einer Anwendung entworfen Die Semantik wird z T als intuitiv erkl rt vorausgesetzt Es wird dann angenommen da auf der Grundlage der aus der Struktur ableitba ren generischen Operationen und Transaktionen jede Funktion auch in einfacher Form dargestellt und entwickelt werden kann Da 4GL Sprachen eine benutzerfreundliche Notation nachgesagt und deshalb eine Benutzeroberfl che nicht entwickelt wird ist ein Datenbanksystem nach wie vor extrem benutzerunfreundlich Viele DBMS erlauben deshalb die Erstellung von sichtenbasierten Formularen bzw Men s Aufgrund dieser Vorgehensweise wird durch die Struktur einer Anwendung die gesamte Funktionalit t und Benutzbarkeit durch de
291. ntationstechniken wird ein Entwurf intuitiv auch in seiner Ent wurfsgeschichte verst ndlich Au erdem mu eine entsprechende Transformationstechnik existieren mit der ein Prototyping z B in relationalen DBMS erleichtert wird In diesem Skript wird eine Methodik vorgestellt die sich ein Entwerfer selbst ver ndern kann Wir gehen davon aus da jeder Entwerfer seine eigene Methodik verwendet Es gibt zwar Gemein samkeiten aber die Wahl der Methodik h ngt nicht nur von den Kenntnissen und Erfahrungen des Entwerfers ab sondern wird auch durch das Anwendungsgebiet und durch die Projektpartner mit bestimmt Deshalb wird im Skript auch dargestellt wie man die Methodik die im Hauptteil des Co Design Buches vorgestellt wird durch eine eigene Methodik ersetzen kann Unsere Methodik hat sich in den mehr als 100 DB Anwendergruppen als eine der am h ufigsten und am weit verbreiteten Methodiken erwiesen Neben dieser Methodik existieren viele verschiedene andere Methodiken Die Modellierung wird immer von der Verfeinerung begleitet Verifikation und Validierung dienen der Kontrolle der Resultate wie in Bild 3 dargestellt Realit t A Modellierung Validierung was wie wo wer wann 1 Wird das richtige Produkt erstellt Modell A Verfeinerung Verifikation Qualitatsforderungen Wird das Produkt richtig erstellt Y Implementation Bild 3 Modellierung Verfeinerung Verifikation und Validierung Ob
292. nte der Aktionsschicht A sind das Anwendungsschema als Skelett AD mit einer Spezifikation der Anwendungstypen die Nutzer Maschine AF mit einer Darstellung der Handlungen und der entsprechenden Ak tionen die Aktionssichten Suite AC mit den Sichtenskeletten und den entsprechenden Kerntypen das Storyboard mit Szenario Aufgaben und Benutzergruppen AS zur Darstellung der Inter aktivit t wobei der Repr sentant eines Benutzertyps Akteur mit einem Profil und Portfolio beschrieben wird mit seinen Daten und Proze anforderungen angegeben sowie seinem Polarit tenprofil spezifiziert wird und das kollaborative System mit Diensten Kollaborationsrahmen und Qualit tsanforderungen AV des Kollaborationsraumes Die Dokumentation der konzeptionellen Schicht K basiert auf dem dem ER Schema KD mit den ER Typen der Workflow Maschine KF mit den Workflows bzw Workflow Feldern und Programmen und den unterlegten Prozessen dem Drehbuch KS mit dem Szenenraum und den einzelnen Dialogschritten die Content Typen KC der Sichtenschemata mit entsprechenden Typen und den Dienste und Kollaborationsraum KV des verteilten Systemes die auf entsprechenden Content Typen beruhen eine Darstellung der Architektur und auch die Qualit tskontroll mechanismen einschlie t Die Dokumentation der Implementationsschicht I sollte aus den vorhandenen konzeptionellen Sche mata generiert werden Sie umfa t die logischen Schemata mit
293. nteraktionsm glichkeiten vorzusehen Offene Systeme Ein Informationssystem wird in immer st rkerem Ma e mit anderen Sy stemen in integrierter Form verwendet Deshalb ist der Output f r einige Standards mit aufzubereiten Erweiterbarkeit Ein Informationssystem beginnt aufgrund der nderungen in der Anwen dung selbst in den Profilen der Akteure und durch Hinzunahme von Funktionalit t bald nach der Erstellung zu leben Die m glichen Erweiterungen sollten antizipiert werden Auswahl der multimedialen Medien Ein Akteur sollte entsprechend seinem Benutzerpro fil die Interaktion und die benutzten multimedialen Formen selbst und evt auch dynamisch ausw hlen k nnen Benutzer und Akteursmodelle Wie bereits dargestellt unterscheiden wir zwischen einem Benutzer und einem Akteur Ein Benutzer ist eine Repr sentation der aktuell agierenden Person z B durch die Login Daten und die pers nlichen Daten sowie die Benutzungsgeschichte Benutzer werden im allgemeinen kategorisiert oder gruppiert Benutzer k nnen nach ihren Eigenschaften gruppiert und mit einem Typkonzept dargestellt wer den Ein Akteur ist ein abstrakter Benutzer Typ der eine Gruppe von Benutzern abstrakt darstellt Damit werden die allgemeinen Charakteristiken von Benutzern beschrieben In der konzeptionellen Modellierung sind wir mehr an einer Darstellung von Akteuren orientiert Akteure sind den einzelnen Dialogschritten und damit den Szenen mit entsprechenden Rechte
294. ntextraumes Umst nde allgemeiner Art kennzeichnen insbesondere Beschr nkungen der Benutzung Einspie len von Hilfsmitteln etc Das Benutzungsmodell der Akteure h ngt von einer Reihe von Parametern ab wie die Bezahlung das Organisationsmodell zur Benutzung die daraus resultierenden Rechte und die darauf aufbauenden Rollen Das Portfolio der Akteure wird bestimmt durch die durch die durch die durch die durch die Aufgaben spezifischen Rechte spezifischen Rollen Umst nde der Benutzung und Ziele Technische Einschr nkungen allgemeiner Art erweitern oder schr nken die Benutzung ein Sie sind gegeben durch die Umgebung der Benutzung wie z B Hardware Server Software Client Software und den Kanal sowie durch die Verteilung auf unterschiedliche Knoten Der konkrete Benutzungskontext basiert auf einer Beschreibung der Assoziationen wobei auch eine entsprechende Bindung Umordnung zur sequentiellen Repr sentation ber cksichtigt wird und der Ort und die Zeit der Benutzung zu Ver nderungen f hren kann Der Benutzungskontext ist determiniert durch die Einbettung in den Story Raum insbesondere unter Ber cksichtigung des benutzten Content je nach angeforderter INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 131 Navigation u a Funktionalit t sowie dem Sicherheitsprofil die Anpassung an den Benutzer wobei auch Ort Zeit und Benutzungsgeschichte variieren k nnen die Auslieferung v
295. ntlichen Parametern Benutzbarkeit Durchlauf etc beeinflu t werden Benutzbarkeit Die Benutzbarkeit bzw Brauchbarkeit kann durch verschiedene Parameter bewertet INFORMATIONSSYSTEM ENTWICKLUNG IM Co DESIGN ZUGANG BY 8 135 Analytische Me methoden werden z B beim Vollst ndigkeitstest herangezogen Damit kann er mittelt werden ob alle ben tigten Informationen auch dargestellt werden Leistungsparameter sind z B die ben tigte Arbeitszeit die Fehlerrobustheit und die Zeiterspar nis Die kognitive Beanspruchung stellt die geistige Anstrengung des Benutzers dar Stimmen das mentale Modell des Benutzers und die Reaktionen am Bildschirm berein dann ist sie gew hnlich gering Die Benutzerzufriedenheit ber cksichtigt die N tzlichkeit des Systemes f r den Anwendungs bereich und auch den Lernaufwand zur Bedienung des Systemes Die Modellierung von Benutzungsoberfl chen umfa t die Spezifikation verschiedener Bereiche Dialogmethoden erf llen unterschiedliche Zwecke Wir k nnen verschiedene Zug nge in realen Syste men finden Eingabemasken entsprechen Formularen Damit ist auch die Arbeitsweise determiniert Befehle und Aufforderungen an den Benutzer werden zum Abruf von Daten benutzt Dabei kann die Struktur durch meist deterministische Ablaufdiagramme dargestellt werden Men s k nnen mehrere Optionen oder Funktionen aus denen der Benutzer ausw hlen kann darstellen Men s k nnen auch als Popup oder Klappme
296. ntwicklungsproze Niveau 2 Beherrschung des Entwicklungsprozesses Der Entwicklungsproze selbst ist beherrsch bar berschaubar verwaltbar und geplant Es sind alle Ziele erfa t Es werden die Ziele und deren Erf llung in Einzelschritte planbar und kontrollierbar Risiken und pragmatische Annah men werden mit erfa t Die Verantwortlichkeit ist klar geregelt Die Parteien des Entwicklungs prozesses sind bekannt Deren Rollen und Rechte werden mit verwaltet Die Ressourcen und die Schnittstellen werden mit verwaltet Niveau 3 Standardisierung des Entwicklungsprozesses Es sind Standards Referenzmodelle Strate gien der Entwicklung Festlegungen f r das F llen von Entwicklungsurteilen wohl definiert und auch durch entsprechende Anwendungen unterlegt Der Entwicklungsproze ist standardisiert besitzt eine Audit und Controlling Methode ist als Proze etabliert umfa t die Aufgabezu ordnung f r alle Beteiligten hat klare Anforderungen an die zu nutzende Infrastruktur verf gt ber die entsprechenden theoretischen Grundlagen f r die Ausbildung von Beteiligten und kann ber eine Verwaltung auch L sungen integrieren Niveau 4 Vorherschaubarkeit des Entwicklungsprozesses Der Aufwand f r die einzelnen Entwick lungsschritte ist quantitativ erfa bar und durch Metriken berechenbar Die Qualit t des Pro duktes und des Produktfortschrittes kann gemessen werden Niveau 5 Optimierbarkeit des Entwicklungsprozesses Der gesamte
297. obales konzeptionelles Schema Globales Verteilungsschema Lokales Lokales Lokales kanzeptionelles kanzeptionelles kdnzeptionelles Schema 1 Schema 2 Schema n Lokales Lokales Lokales ternes ternes ternes ge ema 1 ge ema 2 Se hema n Lokales Lokales Lokales DBS 1 DBS 2 DBS n Bild 69 Verallgemeinerung der Dreiebenen Architektur zu einem verteilten Schema Offene Mehrdatenbanksysteme sind eine Variante von lose gekoppelten verteilten Systemen mit einem Verteilungsschema das weder Integrations noch Abstimmungsforderungen erhebt Alle Daten m ssen jedoch identifizierbar sein ber ihre Datenbank Im allgemeinen erfordern jedoch verteilte Systeme eine Integration lokaler Schemata Die Ent wicklung des Verteilungsschemas erfordert zus tzliches Wissen ber die Anwendungen Da die Inte grierbarkeit unentscheidbar ist mu das Integrationswissen im Entwicklungsproze extra eingebracht und erfa t werden Wir stellen au erdem fest da die Integration auf der Grundlage der Sichtenkooperation um ein vielfaches einfacher ist Sie wird durch Konzentration auf Stern und Schneeflockenschemata weiter vereinfacht wenn entsprechende B cken oder Scharnierkompositionsoperationen eingesetzt werden Die Integration setzt oftmals auf f derierten Architekturen in Analogie zur Architektur in Bild 70 auf Das Containersystem von Datenbank Farmsystemen bietet au erdem noch e
298. okalen Systemes Er ndert den Zustand und produziert einen Output abh ngig von verschiedenen Systemcha rakteristika abh ngig von Figenschaften der Operationen z B analoge Ausf hrung serielle Ordnung Idempotenz von Operationen g nstig f r Kompensation z B setze x to c die Aufgaben bzw Proze koordination durch verschiedene Scheduling Pre Conditions statisch durch Definition des Zustandes vor Start des Prozesses Ausf hrungszust nde anderer Prozesse Output Werte anderer Prozesse Werte externer Variable oder dynamisch durch Spezifikation der Abh ngigkeiten w hrend der Proze ausf hrung die Korrektheitsbedingungen f r Ausf hrung und Versagen mit Failure atomicity Bedingungen Bei Ausf hrungsproblemen kann anstatt des vorgegebenen Pro zesses ein anderer ausgef hrt werden um einen akzeptablen Endzustand zu erreichen oder Execution atomicity Bedingungen zur Darstellung der Zerlegbarkeit von Transaktionen bei Se rialisierung Die Ausf hrung eines Workflows h ngt von verschiedenen Interproze Abh ngigkeiten ab Damit spe zifizieren wir zwei Bestandteile den Scheduler zur Ausf hrung der Prozesse durch Planung der n chsten Schritte mit einem Monito 20000 a TEES SAD OAT ESTE 27 WDR eee BEFREIEN TER en un a a A 1 a s 21 7 5x c k 1 0 VERBIETEN 68 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 5 FUNKTIONALITAT den Proze Agenten zur Ausf hrungskontrolle eines
299. on kreten Umgebung e Die Wiederholung von Konzepten Parametrisierung von Konzepten orientiert auf der Grundlage einer Anwendungsabstraktion auf analoge Konzepte und Hierarchien artgleicher Konzepte Der Entwurf von Einheiten kann auf verschiedene Abstraktions b ES 20 R Ex 8 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 1 EINFUHRUNG e Durch Sharing von Konzepten ad quate Namensgebung Variablenkonzepte und Ver binden kann ein Muster von Konzepten wiederholt werden e Die Wiederholung von Funktionen kann sowohl f r unterschiedliche Strukturen als auch unterschiedliche Teile der Anwendung sinnvoll sein e Die Verteilungsabstraktion auf der Grundlage eines Namensgebungs und Verbindungs konzeptes verbessert die Einsichtigkeit und Nachvollziehbarkeit von Konzepten Durch Implementationsabstraktion oder Modularisierung von Struktur Semantik und Ope rationalit t auf der Grundlage von Verkapselung und Scoping kann die Konzeptunabh ngig keit verbessert werden Wichtige Methoden sind e das Verstecken von Konzepten Sichtenbildung private Gruppen und Weltkonzepte und e Abbildungsmechanismen f r Sichten e Wir unterscheiden im Informationssystementwurfsproze Konstruktionsarten Allgemeine Hilfs mittel zur Darstellung der einzelnen abstrakten Konstrukte sind in Anlehnung an Konstruktor konzepte die folgenden Elemente e Elementare Einheiten zur Darstellung von Basiskonzepten e Konstruktionsregeln
300. on Content in Containern deren Typ variieren kann und die auch an die verpackten Content Objekte anpa bar sein m ssen durch das aktuelle Szenarium und die unterst tzenden Session Objekte das konkrete Benutzungsmodell die aktuelle Umgebung wie z B den Kanal mit seiner aktuellen bertragungskapazit t und seiner Sicherheit sowie die aktuell gew hlte Verschl sselung Die Spielarten von Kontext k nnen einer Abh ngigkeitsstruktur unterliegen Wenn wir z B vor aussetzen e da der syntaktische Kontext der durch den Content bestimmt ist und der Zusatzkontext der durch die Hilfsmittel bestimmt ist unabh ngig voneinander sind und e da sich die Spielarten schichten lassen aufgrund der Abh ngigkeitsbeziehung dann kann ein Ausspiel des Content in der Form erfolgen wie in Bild 54 Pragmatischer Kontext Situation physische Umgebung Sozial Strategie Zeit Website Kontext Provider SW HW Lieferant Expliziter Kontext Story Raum Syntaktischer Extra syntaktischer verbaler Kontext Zusatzkontext Content Suite Akteure Profile Meta Information Bezahlung Potentielle Umgebung Informationssystem Szenen Aufgaben Rollen Intention Themen Umst nde Mission Anliegen Aktuelles Szenario Historie aktuelle Umgebung Benutzer Ziel Umst nde Kultur Bild 54 Das Zwiebelprinzip zum Einbringen von Kontext Der Kollaborationsrahmen Wir unterscheiden zwischen Koo
301. on Intervallen von IN und einer bin ren Relation W ber T S Wir bezeichnen mit maxTS den maximalen Zeitpunkt von TS und mit minT S den minimalen Zeitpunkt Der einfachste Zeitrahmen ist das Intervall TS 0 maxTS betrachtet Die bin re Relation W stellt eine Erreichbarkeit von Intervallen untereinander her Wir sind damit in der Lage Zeitr ume zu betrachten und ggf auch voneinander zu separieren e Die G ltigkeit von a in einem Schnappschu S i R Ir ist induktiv wie f r statische Inte grit tsbedingungen definiert und wird mit RC Ir i a notiert Die Formel a is notwendig g ltig in RC Ir zu einem Zeitpunkt i I 7 TS und f r einen Zeitrahmen ZR falls RC Ip a f r alle Intervalle 7 I mit 7 7 W und alle Zeitpunkte IUT Wir notieren dies mit R lr i ZR Da bzw RC 15 I ZR Oa Die Formel ist g ltig in jedem Zeitpunkt des Intervalls J dem angeh rt und in jedem Zeit punkt der durch W aus J erreicht werden kann In der Modallogik wird zwischen der G ltigkeit von a in und zu jedem Nachfolgeintervall unterschieden Wir ben tigen diese strikte Unter scheidung nicht Wir k nnen mit R lp I ZR Da die G ltigkeit ab einer Phase I f r alle Folgephasen J modellieren Eine Formel a ist notwendig g ltig in RC Ir und ZR ab I bis zu Is f r h TS falls RC Ip i a f r alle Intervalle 7 mit 1 7 W
302. on in der Datenbank sich auf die Sicht auswirkt Diese Materialisierung nutzt dann das folgende Schema extend Sichtenschema by MODIFIKATIONSMODUS store ABLAGE SCHEMA Wir werden im weiteren diesen Spezifikationsrahmen erweitern um eine Steuerbedingung accept on ABSCHLUSSBEDINGUNG mit der eine Kontrolle der Integrit t dynamisch erfolgen kann Eine derartige Kontrolle verbessert die bersichtlichkeit erfordert aber eine rigidere Behandlung der Konsistenz aller Integrit tsbedin gungen F r den Modifikationsmodus erstellen wir uns parametrische aktive Datenbank Trigger Diese parametrischen Trigger besitzen einen Namen sind f r Modifikationsoperationen ber der Daten bank spezifiziert k nnen bei G ltigkeit einer Bedingung aktiviert werden und f hren Aktionen zur Ver nderung einer materialisierten Sicht aus Der Modifikationsmodus besteht aus einem Modifikationsschema und einem Zeitschema Das Mo difikationsschema kann durch entsprechende Triggeroperationen in der logischen Sichten Suite unter legt werden in der Form on Modify on Datenbank Schema Typ if Sichten des Sichtenschemas XY betroffen do Modify XY Modify steht f r Insert Delete bzw Update Das Zeitschema diktiert wann eine Modifikation der Sichten erfolgt Default Wert kann z B Immediate sein Mitunter ist auch Aktionen DeferUntilNoUserActive sinnvoll Das Ablage Schema kann sowohl eine einzelne URL bzw URI als auch eine Menge zulassen falls eine redundante Speiche
303. onen neh muni schirml Infor Funk gruppe rit t tion lung ration mung kation ma tiona tion lit t In dieser Tabelle f hren wir die Information zum Akteur zur direkten Assoziation mit Sie dient eher der direkten Bezugnahme und bestimmt nicht den Gestaltungsrahmen Die Qualit tsparameter SUR Bo PONIES i A ES 144 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 7 INTERAKTIVIT T Dieser Gestaltungsrahmen kann dann den Arbeitsoberfl chen im speziellen oder dem Pr sentati onsraum im allgemeinen zugeordnet werden Wie bereits betont kann dieser Gestaltungsrahmen verwendet werden um Metaphern zu gewin nen Die Spezifikation von Metaphern kann mit folgenden Metaphorikrahmen erfolgen Name der Metapher Die Darstellung der Eigenschaften assoziiert Eigenschaften der Metapher mit dem Anwendungsge biet Die Intensit t und die Dominanz der Eigenschaften kann mit erfa t werden Klasse der Metapher personalisierte allegorische symbolische Bedeutung f r unterschiedliche Benutzergruppen in unterschiedlichen kulturellen Kontexten Repr sentation der Metapher durch entsprechende Formen und Farben Kontrast und Rhythmus Struk tur und Komposition Die Zuordnung von Metaphern zum Gestaltungsrahmen und zu den Content Suiten sowie zur Funk tionalit t erfolgt explizit durch Angabe der Suiten Content Suiten Funktionen Container
304. onen innerhalb des Sichtenschemas Zur Unterst tzung der Suche und der Navi gation innerhalb des Content Objektes kann man das Wissen zu den verwendeten Datentypen einbringen Jeder Basis Datentyp kann auch in vergr berter Form dargestellt werden Diese Vergr berung vererbt sich ber das Konstruktionsschema bis hin zum Sichtenschema Damit sind wir in der Lage e die Granularit t e die verwendeten Ma einheiten und e die Prazision der Darstellung anzupassen Diese Anpassung wird in Spreadsheet Zug ngen bereits breit praktiziert und ist relativ einfach mit dem Content Typ verbindbar Pr sentationsstil Der Datentyp des Sichtenschemas ist durch die verwendeten Datentypen gegeben Wir k nnen damit f r einen allgemeinen Datentyp eine Menge von Pr sentationsformaten ent wickeln und mit dem Content Objekt verkn pfen Allgemeiner Repr sentationsstil Im Rahmen der Entwicklungen zu Benutzungsschnittstellen sind allgemeine Gestaltungsraster f r die Pr sentation entwickelt worden Dazu geh rt das Screen Layout die Typographie die Integration von Metaphern in die Gestaltung nach allgemeinen Prinzipien e Das Prinzip der visuellen Wahrnehmung orientiert sich an Ordnungsbeziehungen in nerhalb des Content Typen an Wirkungen der Darstellung und Hilfsmitteln zur Vi n 1 92 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 6 SICHTENSUITE e Das Prinzip der visuellen Kommunikation orientiert auf eine klare
305. onierung Der Benutzer mu sowohl die Lokalisierung als auch die Partitionierung angeben Nichtsichtbarkeit der Transaktionen Die Benutzer kennen die Verteilung von Transaktionen nicht Durch remote Anforderungen k nnen Daten auch von anderen Knoten z T auch unabh ngig und parallel geholt werden Es wird durch einige Systeme auch eine verteilte Steuerung erm g licht Mit einem Zweiphasen Commit Protokoll wird der Abschlu der Transaktion auch ber verschiedene Knoten kontrolliert Nichtsichtbarkeit des Ausfalls einzelner Komponenten Solange ein Ausfall nicht das Funktionieren be einflu t erfahren die Benutzer nichts vom Ausfall einzelner Komponenten Nichtsichtbarkeit des Funktionierens Das System hat nach au en das gleiche Verhalten wie ein zen tralisiertes System Nichtsichtbarkeit der Heterogenit t Das System ist in der Lage die verschiedenen heterogenen Be standteile dem Benutzer wie ein einheitliches auf einem globalen konzeptionellen Schema be ruhendes System erscheinen zu lassen d d n 0 0 1 50 oh Ak 5 ne A En de s2x28 160 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 8 VERTEILUNG Horizontale Partitionierung Daten werden horizontal zerlegt d h eine Tabelle oder Relation wird tu pelweise in verschiedene Teilrelationen zerlegt und verschiedenen Medien zugeordnet In Bild 64 wird die Relation R durch Anwendung von Selektionsoperationen in drei Teilrelationen zer legt wobei geforde
306. onsdienstemodell in Bild 57 Dieses Modell verallgemeinert und erweitert das Dienstemodell in Bild 13 Komponente eines verteilten Systemes Kommunikation Kooperation Koordination asynchron x synchron Aufgaben 2 walt p Sender Arbeitsproze verwatung mitglie b Empf nger manager ren c g 1 Organisations Komponente tumme manager des i ualit tspara verteilten 7 1 Arbeitsraum 7 5 Systems Dienstevervvaltungssystem Content Typen Informationseinheitmanager Kompetenzregeln Bild 57 Die Implementationsschicht eines verteilten Systems Die Verteilung unterst tzt die Kollaboration Die bliche Form ist die Kollaboration von Syste men Eine spezifische Form der Kollaboration ist die Zusammenarbeit von Gruppen CSCW compu ter supported cooperative work Gruppenarbeit ist die Summe aller aufgabenbezogenen T tigkeiten die von Gruppenmitgliedern ausgef hrt werden um zielbezogene Aufgaben zu erf llen und somit das Gruppenziel zu erreichen Der Kollaborationsdienst wird im Rahmen der Implementierung durch einen konkreten Kollabo rationsrahmen unterlegt Dieser Kollaborationsrahmen setzt auf einer verf gbaren Kollaborationsar chitektur einem Kollaborationsstil und einem Kollaborationsmuster auf d AOR SENDE el Ah s o 2 2812 WEHT Kh Seren A Y s ri oy OAN o B
307. onsrahmen Logische Spezifikation von Informationssystemen 6005 7 relationales Schema Stored procedures tunsesvatem Pienste und Kollaborations ML Schema Transaktionen verwaltungssystem Schema Programme Trigger Oberfl chen Verteilung Protokolle Qualit t Bild 5 Integrierte Entwicklung von Strukturierung Funktionalit t Interaktivit t und Verteilung EHE d 00 EB n n a x ee a ak nL te gil au En En T Ome co 20 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 2 SPRACHEN fiir eine Spezifikation eines Informationssystemes auch eine Beschreibung der Datenbank Maschine und eine Beschreibung der Content Objekte und des Story Raumes sowie des Diensteraumes notwen dig Die konzeptionelle Beschreibung umfa t auch der Beschreibung der Funktionsweise eines im plementierten Informationssystemes d h auch die Beschreibung der Content Typen und des Story Raumes Gew hnlich wird dieser Teil dem Pr sentationssystem zugeordnet und erst sp ter entwickelt Damit werden Performanzengp sse von Anfang an mit ausgel st Wir f hren hier erstmals eine allgemeine Theorie der Content Objekte und Content Typen ein Content ist ein derzeit h ufig berladener Begriff Man verlangt heute von einem Content Management System CMS da folgende Teilsysteme und L sungen eingeschlossen werden e Portal Verwaltung Enterprise Content Management e Content Anlieferung Agentur L sungen Content
308. peration Koordination und Kommunikation Diese drei Formen der Kollaboration werden im n chsten Abschnitt im Detail behandelt Kollaboration zwischen Akteuren wird im Rahmen der Spezifikation des Story Raumes und im Rahmen der Spezifikation der Verteilung dargestellt Es werden unterschiedliche Aspekte f r den Story Raum dargestellt Hier sind die allge meinen Aspekte von Bedeutung F r die Spezifikation der Verteilung werden diese Aspekte verfeinert und im Detail angegeben Der Kooperationsrahmen soll bei der Inszenierung eine automatische Generierung der Oberfl chen f r die einzelnen Dialogschritte unterst tzen Im einzelnen ist der Kooperationsrahmen spezifiziert la 132 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 7 INTERAKTIVITAT Koordination bzw Kooperation Wir unterscheiden zwischen Koordination und Kooperation Charakterisierung nach Koordinationsformen Eine Koordination von Akteuren erfolgt fiir die Be waltigung von Arbeitsaufgaben Diese Aufgaben werden mit einer Reihen von Koordina tionstypen verbunden Typische Koordinationstypen sind z B die Broker bzw Trader Customer Koordination die Client Dispatcher Koordination oder die Publisher Subscriber Koordination Sie stellen allgemeine entfaltbare Workflows dar bei denen der Ablauf der Koordination durch entsprechende verfeinerbare Dialogschritte gekennzeichnet wird Die se Koordinationstypen werden im weiteren zum Austauschrahmen zur Spezifika
309. r nicht in der Lage ihre spezifischen Anfragen in einer abstrakten Notation zu formulieren Deshalb mu eine Variantenvielfalt von Anfragen vorgehalten werden Es gibt jedoch bereits auf dem Markt einige Umformer von nat rlichspra chigen Anfragen Gleichzeitiger Zugriff auf viele Tabellen Obwohl der Verbund von Tabellen bei zentralen Da tenbanksystemen ad quat unterst tzt wird ist der Verbund von heterogenen und verteilten Tabellen nach wie vor ein schwieriges Problem Benutzer greifen im read only Modus zu Im Warenhaus berwiegt der Lesezugriff Damit wird die Transaktionsverwaltung wesentlich vereinfacht Daten werden aus unterschiedlichen Quellen periodisch modifiziert Mit einer periodischen Modifikation kann eine Konsistenz von Daten aus unterschiedlichen Quellen nicht ohne weitere Funktionen unterst tzt werden Damit ist allerdings ein entsprechendes Schichtenkonzept neben den Kollaborationskonzepten zu entwickeln Daten sind abh ngig von ihrer Geschichte Daten werden in unterschiedlichen Quellen in un terschiedlicher G ltigkeit gehalten Au erdem ist es oft nicht m glich Daten unterschiedlicher Quellen mit einem G ltigkeitsabgleich zu versehen Gro er Zugriffsumfang Mit Datenbank Warenhaus Anwendungen entstehen f r bestimmte Da ten Zugriffslawinen Typische Beispiele daf r sind Daten die aktuellen Anforderungen z B in Informationsdiensten gen gen m ssen wie z B dem Samstagsknick bei Fu balldaten Um gr er
310. r oder weniger abbilden So wird meist ein Begriff mit einer Menge von Beispielen ver bunden die explizit oder auch abstrakt definiert sein k nnen Begriffe sind sprachabh ngig meist jedoch nicht reduzierbar auf die Gebrauchsregeln von denen sie erzeugt werden Das begriffliche Klassifikationssystem das eine Sprache unterlegt ist in hohem Ma e Ergebnis eines adaptiven und anwendungskontextgepr gten Sprachwandels Begriffe k nnen determiniert werden in der Art und Weise wie ihre Extension determiniert wird Sie k nnen scharf begrenzt sein im Sinne Fregescher Begriffe Wir bevorzugen diese Form In der Alltagspraxis werden Begriffe nicht so scharf eingegrenzt Es ist jedoch Aufgabe der Modellierung Begriffe so exakt wie m glich Extensionen Content und Konzepten zuzuordnen Begriffe k nnen auch prototypische Begriffe sein oder Familien hnlichkeitsbegriffe Ein Beispiel ist das Adre Konzept Wir k nnen mit diesem Konzept unterschiedliche Begriffe verbinden e Hauptwohnsitz Nebenwohnsitz e Zustelladresse e Anschrift oder Email Nicht verbindbar sind dagegen der Begriff Gliickwunschschreiben der Begriff Speicheradresse oder auch der Begriff Eingabe schriftliche Kundgebung Analog stellen wir f r das Person Konzept fest da Begriffe wie Mensch assoziierbar sind nicht aber Figur Akteur oder abstrakte Person ich f r meine Person Wir werden im weiteren uns nicht mehr mit Konzepten oder Begriffen auseinanderse
311. r ti en rufen werden Mit diesen allgemeinen Transitionen k nnen wir auch komplexere Programme zusammenstellen Diese Programme basieren auf einer parallelen Ausf hrung Das folgende Beispiel stellt die Alternativen zur Eingabe der Hauptdaten zu einem Lehrveranstaltungsangebot vor Danach k nnen alle erforderlichen sonstigen Daten bereitgestellt werden wie z B Raumforderungen oder auch optionale Informationen wie z B Angaben zu bungen und Praktika Raumdaten Studiengangsdaten Angaben zu Neben bedingungen und die Klassifikation der Lehrveranstaltung werden nicht neu erstellt sondern aus der Datenbank abgefragt und zugeordnet D0 Vorlesung Klassifikation ehooseKl DO Vorlesung Studiengang chooseSG_ true DO Vorlesung Praktika inputPr IF Praktika D0 Skip DO Vorlesung Hauptdaten inputHD TIS DO Vorlesung bung input b false po Skip DO Vorlesung Nebenbedingung chooseNB J 20 Vorlesung Raumforderung chooseRF Abstrakte Semantik von Datenbank Transitionen Das Datenbank Schema definiert die Strukturierung der Datenbank Ein Zustand der Datenbank kann durch eine Modifikation partiell ge ndert werden Anderungsoperationen T s n t vom Teiltyp T von T basieren auf Anfragen Sie sind auf einem Objekt einer Klasse T definiert falls ler 1
312. racht Wir k nnen aber einen Sprachmix verwenden der sich mit jeder weiteren Schicht immer st rker auf die formalen Teile orientiert Vorstellbar und praktikabel ist ein Sprachmix aus nat rlichsprachigen u erungen Formu lartechniken und formalen Darstellungsmitteln wie Diagrammen zur Darstellung der Datenstrukturen hen re y ey f r EE ee x d a x nr 3 a Re Se ess Cera x SM 0 05 2 sen e C EN Sn re FA 36 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 3 ABSTRAKTIONSSCHICHTENMODELL die Implementationsschicht ben tigen wir eine formale Darstellung mit exakt definierter Semantik f r die konzeptionelle Schicht ist dies ebenso notwendig Wenn wir uns f r einen Sprachmix entscheiden dann sollten wir in jedem Fall die Abbildbarkeit der Konstrukte von Schicht zu Schicht garantieren k nnen Auf die nat rliche Sprache sollte schon aufgrund des ihr innewohnenden Potentials keinesfalls verzichtet werden Formulartechniken sind eine Vorstufe der formalen Darstellung Formale Techniken wie ER Modelle oder CSP Modelle sind f r den direkten Anwender weniger geeignet sind aber mit einer entsprechenden Semantik versehen sehr gut zur Darstellung in der konzeptionellen Schicht geeignet Wir werden im weiteren zuerst einmal die einzelnen Spezifikationsteile im Abstraktionsschichten modell untersuchen Dabei k nnen wir auf die Erkenntnisse die in den vorangegangenen Kapiteln dargestellt sind zur ckgreifen
313. raus entstehender Obligationen entwickelt Interaktionszentrierter Entwurf Es wird zuerst der Interaktionsraum oder der Storyraum modelliert und daraus werden dann Anforderungen an die Strukturierung und Funktionalit t abgeleitet Diese Anforderungen f hren zur Ableitung des Anwendungssystemes Weitere Strategien sind m glich wie z B parallele Entwicklung verschiedener Konzepte bzw Teil konzepte Orthogonal dazu sind verschiedene Unabh ngigkeitskonzepte m glich Unabh ngigkeit des Endnutzers von spezifischer konzeptioneller Repr sentation und INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 9 Diese Unabh ngigkeitskonzepte sind an der Vorgehensweise zur Implementation und der 3 Ebenen Architektur Endnutzerebene Konzeptionelle Ebene Implementationsebene orientiert In der Softwaretechnik und der Wirtschaftsinformatik wird oft eine Herangehensweise im Rahmen eines Software Entwicklungsprozesses pr feriert HP97 I Definition des Gestaltungsbereiches Die bisherigen Prozesse werden rudiment r analysiert Damit kann eine Definition der Kerngesch ftsbereiche und der wichtigsten Prozesse erfolgen Formulierung der provisorischen Ziele Die Probleme und Schwachstellen des derzeitigen Systemes werden durch Interviews Fragebogen Beobachtungen und Experimente aufgefunden Analyse der bisherigen Prozesse Die aktuell vorhandenen Prozesse werden mit entsprechenden Aktivit ten verglichen Es wird die Syste
314. rbeitspl tzen innerhalb einer Gruppe globale Festlegungen gruppen bergreifend o Geometrie Position Ausrichtung o Konfiguration der Generierung nordnung Layout innerhalb einer Gruppe Priorit t gruppen bergreifend Anwendungssemantik Gestaltungsgesetze Bild 55 Die Vorgehensweise zur Zusammenstellung von Benutzungsoberfl chen Struktur der Anordnung und Bedienung der Bilder und der Repr sentation und Stilfragen Auf die ser Architektur kann auch die Vorgehensweise zur Generierung von Benutzungsschnittstellen wie in Bild 55 aufgesetzt werden Der Gestaltungsrahmen soll uns eine allgemeine Beschreibung der Gestaltung erlauben und auch eine automatische Adaptierung oder Adaption an die Eigenarten der Benutzer an die technische Umgebung und den Kontext im allgemeinen gestatten Es sind bereits eine Vielzahl von Regeln zur Gestaltung von Graphischen Benutzungsoberfl chen bekannt Diese Regeln werden jedoch selten im Zusammenhang betrachtet Mit der Spezifikation des Gestaltungsrahmens wollen wir jedoch auch den Zusammenhang in der Gestaltung betonen und zugleich auch eine Einheitlichkeit bei der Gestaltung realisieren Der Gestaltungsrahmen erlaubt auch eine allgemeine Kategorisierung der Gestaltung und zugleich auch eine Assoziation mit Metaphern die als gesamtheitliche Metaphern der gesamten Gestaltung unterlegt werden k nnen Wir kommen auf diese Anwendung am Ende des Abschnitt noch einmal zur ck
315. rch eine Content Objekt Suite bestimmt Die unterst tzende Funktionalit t f r die einzelnen Dialogschritte wird auf der Funktionalit t der Content Typen aufgesetzt Der Kontext der einzelnen Dialogschritte wird durch den Kontextraum determiniert Diese sechs Dimensionen k nnen in Zusammenhag mit dem Zachman Spezifikationsrahmen gestellt Zee 2 a ee ee ees en enh i Cae ee aa 1 3 4 am 2 One AT ey PORN INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 125 Dialogszene Steuerung Ereignis Vorbedingung Akzeptanzbedingung n chster Dialog schritt Content Objektsicht zugelassene Operation Manipulations operation 27 zugelassener Akteur Transition nach Dialogsschrittausdruck Dialog schritt 1 Akteure Rechte a Szenenabfolge Content Reprasentations Kontext Rolle Transition Object stil Aufgabe Bild 47 Sichtenstern f r eine Dialogszene mit entsprechenden SiteLang Elementen die zugelassenen Akteure des Dialogschrittes die Einbettung in den Story Raum die bereitgestellten Content Objekte und der Zeitrahmen f r die Absolvierung des Dialogschrittes Diese Hauptdimensionen sind in Bild 48 graphisch mit ihren Assoziationen skizziert Intention Aufgaben Rollen Verantwortlichkeiten Zeitbeschr nkungen Ablauf 5 Akteur Gemeinsame 155 gt bjekte Zeitrahmen
316. rd Dieser Zugang entspricht in der Theorie der Wortfelder der Komponentenanalyse Wir verwenden diese Ableitungsbeziehung analog zu den Erkenntnissen der Sprachwissenschaft Wir k nnen z B aus dem Konzeptfeld Lebewesen wie folgt Konzepte ableiten Lebewesen Belebtheit Kategorie Mensch Geschlecht weiblich Lebensalter Erwachsen Mann M dchen R de Welpe Analog kann auch eine generelle Klasse eingef hrt werden Diese Beobachtung f hrte V J Propps Pro72 zu seiner Spezifikation der M rchen Fr stellte z B f r das M rchen Die wilden Schw ne den Ausdruck iblalc Al B C Z SehiH Z lseh H Z VV L N V T SehiH Z R x3 auf Die Buchstaben werden jeweils f r eine Konzeptfeld verwandt z B J f r das Er ffnungsfeld a f r Ortsbewegungen b f r Verbote c f r Verletzungen der Verbote A f r Sch digungen C f r eine einsetzende Gegenhandlung und N f r Ortsver nderungen Sch f r Schenkungen H f r Reak tionen des Helden Z f r den Empfang eines Zaubermittels f r eine Parallelhandlung W f r eine Wegweisung L f r die Aufhebung des Ungl cks V f r die Verfolgung und R f r die Rettung Die einzelnen Schritte k nnen durch Annotation auch verfeinert oder negiert werden Au erdem kann eine Wiederholung angezeigt werden z B die dreimalige Wiederholung durch 3 Wir unterschieden in Anlehnung an die Theorie der Konzeptfelder zwischen Workflow
317. rem Portfolio Aufgaben Stel le Rolle Umst nde und Ziele gruppiert Diese Abstraktion wird durch die Einf hrung von Akteuren unterst tzt Arbeitgruppen Eine Zusammenarbeit findet in Arbeitsgruppen und zwischen Arbeitsgruppen statt Diese Interaktionsformen werden unterschieden Die Mitarbeit von Personen in einer Arbeitsgruppe und das Treffen von Arbeitsgruppen sind durch unterschiedliche Typen realisiert Zuordnung der Rechte zu Akteuren Akteure erhalten Rechte z B zur Ver ffentlichung der Re sultate Die Rechte an der Bearbeitung von Content Objekten k nnen analog erfa t wer den Portfolio Personen werden bei der Frledigung von Aufgaben unterst tzt Jede Person erh lt dazu ihr spezifisches Portfolio das in die Zusammenarbeit der Arbeitsgruppen einflie t Organisationsmodell Es wird ein einfaches Organisationsmodell benutzt bei dem einer Person Rollen zugeordnet werden die in der Firma blich sind Content Objekte und Container stehen den Benutzern zur Verf gung Sie befinden sich zu un terschiedlichen Zeitpunkten auf unterschiedlichen Arbeitspl tzen Mit einem Content Typ Arbeitsplatz k nnen sowohl Arbeitsgruppen als auch Benutzer auf ein fache Art in ihren Kooperationsbeziehungen unterst tzt werden e Je nach Art der Arbeitsaufgabe e je nach Portfolio oder Person e je nach Einwahl und Ausweis als Akteur je nach Gruppenzugeh rigkeit Pe Oe Eee EY os NEER SONU Dan sas L dr d Lo
318. ren k nnen mit expliziten Abwehrma nahmen und kryptographischen Verfahren 152 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 8 VERTEILUNG Diese Modelle werden zu Modellen erg nzt mit denen andere Qualit tsparameter garantiert wer den k nnen Der Qualit tsparameterpr fer kann diese Modelle ggf auch unterst tzen Innerhalb der Aktionsschicht wird Allgegenwart unterst tzt Dazu sind systemtechnisch entspre chende Voraussetzungen zu schaffen Innerhalb der konzeptionellen Schicht betrachten wird zwei weitere Qualit tsparameter e Bedeutungstreue wird durch eine Einbindung von Konzepten und Begriffen unterst tzt e Konsistenz wird mit dem Integrit tsmanagement verkn pft Die Qualit tsparameter der konzeptionellen Schicht werden auf entsprechende Funktionen der Imple mentationsschicht durch Instantiierung des Austauschrahmens abgebildet Au erdem k nnen je nach Bedarf folgende Qualit tsparameter unterst tzt werden e Dauerhaftigkeit e Performanz e Robustheit e Skalierbarkeit und e Transparenz Der Kollaborationsraum Bislang sind formale Methoden zur Spezifikation der Kollaboration nicht entwickelt worden Auf der Grundlage der vorangegangenen Uberlegungen sind wir jedoch in der Lage eine allgemeine Theorie des Kollaborationsraumes zu entwickeln Kollaboration spielt sich in den drei Facetten e Kommunikation e Kooperation und e Koordination ab Der Kollaborationsrahmen von Seit
319. riebsIS _aufgabenAkteur Wir k nnen die Parameter spezialisieren Eine m gliche Spezialisierung ist die folgende r beziehung _angestellter U partner xof qaza daa RE at en ee ee eee INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 23 Constraints Bedingungen Wort Regeln Optionalit t Umfeld Wortformen ye Assoziierte Null Konzepte u Default Kontext Syntax __ Parameter Valenz Historie Pragmatik Konzept Bindungsform Semantik Kem Semantische Anwendungs portfolio sips 5 R Modellwelt Bild 7 Die Mindmap Strukturierung der Spezifikation von Konzepten U familie U _weitereCharakt U profil Die Formeln zur Darstellung der Semantik k nnen unterschiedliche Bereiche der Anwendung ab decken So k nnen wir z B festlegen da Personen ihr Geburtsdatum nicht ver ndern Eine Person die geschieden ist war einmal verheiratet Wir erhalten damit Formeln der folgenden Form wobei wir uns der deontischen Quantoren F forbidden O obliged und P permitted bedienen F update Person _gebDaten Olugesehieden person m bast Y Beziehung Ist Partner _y Von Partner _person Ab Bis A Bis today In analoger Form k nnen wir Adressen spezifizieren Adresse _geograph Adr kontakt Adr _historie 5 M Adresse 277 _betriebsIS _aufgabenAkteur Die Darstellung der Konzepte kann auch in der Form von ER Modellen erfo
320. ring In verteilten Datenbanken kann sowohl kein Sharing an Informationen stattfin den als auch Sharing in verschiedenen Stufen Je gr er der Sharing Anteil umso kritischer wird die Pflege und umso besser wird die Zugriffszeit auf Fremddaten Verhalten von Zugriffsmustern Die Zugriffsmuster ber das Netz k nnen statisch oder auch dyna misch sein Statische Zugriffsmuster die sich nicht ver ndern sind relativ selten Dynamische Zugriffsmuster bedingen dagegen einen st ndigen Anpassungsproze Umfang des Wissens ber den verteilten Zugriff Die Information ber das Zugriffsverhalten kann voll st ndig ist jedoch meist nur partiell Je weniger Wissen vorhanden ist umso schlechter kann die verteilte Datenbank an die Anforderungen angepa t werden Grunds tzlich sollen in einer verteilten Datenbank die Benutzer nicht mit der Verteilung direkt konfrontiert sein Die Verteilung wird deshalb unsichtbar bleiben Nichtsichtbarkeit der Verteilung Die Benutzer wissen nicht welche Daten auf welche Knoten verteilt wurden Wir unterscheiden dabei verschiedene Niveaus von Nichtsichtbarkeit Nichtsichtbarkeit der Partitionierung Der Benutzer kennt weder die Partitionierung noch die Knoten sondern kann das System wie eine zentralisierte Datenbank benutzen Nichtsichtbarkeit der Lokalisierung bei sichtbarer Partitionierung Der Benutzer mu die Partiti on angeben nicht aber die Lokalisierung Sichtbarkeit der Lokalisierung und Partiti
321. rlauben Hierarchische Strukturierung als Darstellungshilfsmittel Eine besondere Pr sentationsform ist die hierarchische Darstellungsform Wir k nnen hierarchische Darstellungsformen einf hren e durch Verallgemeinerung von Zug ngen die f r OLAP Systeme entwickelt worden e durch Nutzung der Hierarchien die bereits mit einer Assoziierung wie z B Ver weisen gegeben ist und e durch Aufl sung geschachtelter Strukturen Die Aufl sung geschachtelter Strukturen ist bereits f r die HERM Algebra eingef hrt worden Einf hrung von parametrischen Ordnungen Bereits f r die Durchmusterung und die Suche in gr eren Content Objekten ist eine Unterst tzung durch entsprechende Funktionen entwickelt worden Wir k nnen diese Funktionen nutzen um eine Ordnungserweiterung des Content Typen vorzunehmen e Es werden die Ordnungsrelationen ord lt die f r Listen und Mengen bekannt sind genutzt e Es werden Mengen durch Listen ersetzt und damit einfach sequentiell durchmu sterbar Die Ordnungsrelationen sind von unterschiedlicher Gewichtung Einige Eigenschaften charakterisieren ein Objekt st rker als andere Deshalb k nnen wir die Gewichtung auch f r die Ordnung der Eigenschaften nutzen Das Ordnungsschema erlaubt eine Parametrisierung Diese Parameter k nnen zur Laufzeit durch entsprechende Ordnungen ersetzt werden Dabei k nnen auch bestimm te Ordnungen per Default zur Anwendung kommen In unserer Vorlesungsanwendung k nnen
322. rm spezifiziert Durch zus tzliche Einflu nahme kann ein Administrator auch Strukturen und Funktionen im internen Schema einer Daten bank ver ndern Damit kann der Zusammenhang mit dem konzeptionellen Schema vollst ndig zerst rt werden Struktur Semantikbruch Datenintensive Anwendungen zeichnen sich meist durch eine komplexe Struk tur aus Die statische Semantik wird entweder intuitiv durch die angewandten Konstruktoren verstanden oder erfordert wie im relationalen Fall tiefgr ndige Kenntnis der mathematischen Logik Damit wird aber die Konsistenz in der Spezifikation entweder willk rlich oder nicht mehr nachvollziehbar Funktions Verhaltensbruch Die Funktionen werden durch mehr oder weniger komplexe Prozesse und Operationen implementiert Das Verhalten dieser Prozesse kann auf der Grundlage einer kom positionellen Semantik in einigen Spezialf llen hergeleitet werden Damit ist aber nur ein Teil der dynamischen Semantik erfa t Sobald Prozesse zumindest in den Strukturen zyklisch wer den ist eine kompositionelle Semantik nur noch mit tiefgr ndigen Theorien darstellbar Noch schwieriger ist die Darstellung der Abh ngigkeiten zwischen Prozessen Oberfl chenbruch Verschiedene Anwender verlangen unterschiedliche Sichten auf die Datenbank und a es 6 x s 0 o OS a T Samen Zn y S A TE E OAR e EEEE 2166 INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 11 nachtr glich entwicke
323. rs nlicherArbeitsraum Parameter realisiert werden Damit steht eine allgemeine Technologie zur Realisierung beliebig komplexer Szenario zur Verf gung Diese Technologie erlaubt auch die Generierung entsprechender Begleitinformation das Aktua lisieren der entsprechenden Datenbest nde und kann durch Integration entsprechender allgemeiner und inhaltsbasierter Repr sentationsstile einschlie lich entsprechender Metaphern eine automatische Generierung von Arbeitsoberfl chen unterst tzen Sichtenkooperation und Integrationsschema Das Problem der Sichtenintegration ist ein unentscheidbares Problem Eine vollst ndige Sich tenintegration ist jedoch in der Praxis weder erforderlich noch erw nscht Oft sollen Datenbest nde auch lose gekoppelt bleiben Die Theorieeinsicht da eine Sichtenintegration unentscheidbar ist steht der Praxisbeobachtung gegen ber bei der Daten in unterschiedlichen Anwendungen relativ einfach miteinander in Beziehung stehen k nnen Die Anwendungen verwenden allerdings in der Praxis ein explizites oder implizites Integrationsschema Wir wollen diese Idee weiterverfolgen Eine Integration von Daten ist aus einer Vielzahl von Gr nden nicht m glich Die Sichtenintegra tion wird durch verschiedene Vereinbarkeitsprobleme und Konflikte erschwert Strukturelle Konflikte Die Strukturen entsprechen einander nicht Unterschiede in Schl sseln Es existieren nur verschiedene nicht integrierbare Schl ssel Abstraktions
324. rst ndlichen Charakterisierung von Objekten der Daten bank Hierarchische Strukturen sind meist einfacher zu behandeln Insbesondere wird die Pflege der Integrit tsbedingungen und die Generierung von Operationen einfacher Surrogate sollten im konzeptionellen Entwurf nur in Ausnahmef llen verwendet werden Modi fikationen werden ansonsten schwieriger Damit k nnen kritische Faktoren f r die Entwicklung einer Entwurfsstrategie abgeleitet werden 1 2 Ein schrittweiser Entwurf kann unterst tzt werden Rollen und Verantwortlichkeiten m ssen wohldefiniert sein Eine klare Unterscheidung zwischen allgemeinen und produktspezifischen Entwurfstechniken erleichtert die Migration zu anderen Werkzeugen Das Datenw rterbuch data dictionary sollte auch Versionen und weitergehende Informationen enthalten Der Entwurf basiert auf einem und nur einem Modell das mindestens die gesamte Funktionalit t 50 pi TR EOR Oe p EAE EA EOE SAREN S IEEE da 14 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 1 EINFUHRUNG 6 Durch die Darstellung der Entwurfsentscheidungen f r ein sp teres Reviewing und Einf hrung von Checkpoints denen sich Entwerfer unterwerfen miissen insbesondere zum Einholen von Kompetenz kann eine sp tere Modifikation und die Diskussion von Varianten vereinfacht wer den 7 Der Struktur Funktions und Semantikentwurf wird integriert durchgef hrt 8 Durch bersichtliche Repr se
325. rt wird da sich die Relation R aus den Teilrelationen durch Vereinigung dieser Teilrelationen wiederherstellen l t Damit m ssen die Bedingungen a 3 und y als Dis junktion den Wahrheitswert true ergeben Neben Selektionsoperationen k nnen auch andere Operationen der relationalen Algebra verwendet werden Es wird jedoch im Kontext verteilter DBS exklusiv die Selektion verwendet Vertikale Partitionierung Daten werden vertikal zerlegt d h eine Relation oder Tabelle wird attri butweise dekomponiert und auf verschiedene Medien verteilt In Bild 64 wurde die Relation R durch Projektion in zwei Teilrelationen zerlegt Der nat rliche Verbund dieser beiden Teilrela tionen mu wiederum die urspr ngliche relation R ergeben Gemischte Partitionierung Daten werden sowohl horizontal als auch vertikal zerlegt und auf verschie dene Knoten aufgeteilt Es werden schrittweise Selektion und Projektion zur Partitionierung angewandt A A A Aa A A Az A Relation Ra Relation R os R Relation R3 04 R 0 R horizontale Partitionierung 1 Rekonstruktion Dekompostion durch Selektion R RU R2 U R3 A A Relation R vertikale Partionierung 1 is Rekonstruktion Dekomposition durch Projektion R RI A A3 X RH A1 A A A Relation Relati RI A Aa A elation A1 Az As RUAL AD Bild 64 Partition
326. rung erforderlich ist F r die Archivsicht erhalten wir mit Darstellung durch den deontischen Operator F Verboten extend Archivsicht by MODIFIKATION F Insert F Delete F Update store ARCHIVSICHT Weiterhin wird ein Sichtenschema durch die Angabe aufbereitet ob die Objekte dieser Sicht nur Daten sind die dem Benutzer zu Ansicht zur Verf gung Retrievaldaten stehen oder auch zur Modifikation Modifikationsdaten benutzbar sind Objekte einer Bearbeitung mit Sichten enthalten in der obigen Klassifikation demzufolge e Input Daten die dem Benutzer in den einzelnen Arbeitsschritten zur Verf gung gestellt werden e Output Daten mit denen der Benutzer auch Daten wieder in das System zur ckschreiben oder einschreiben kann und Xa 0 pe nn ee Pi a SR 0 0 6 020 0 RER 0 Me rar Zn 88 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 6 SICHTENSUITE Au erdem k nnen Objekte einer Sicht sichtbar sein Displaydaten oder auch nicht dem Akteur sichtbar gemacht werden Insbesondere wollen wir damit die direkte Modifikation der Objekte der Datenbank unterst tzen ohne dem Benutzer auch die Identifikation der Daten bekannt zu machen Damit ist das Sichtenschema um die Angabe type for modification for retrieval used for input for output for escort only displayed with subtype erweitert Um die Identifizierbarkeit zu gew hrleisten verwenden wir dabei evt auch Typen die dem Benutzer
327. s f r jeden Benutzer wobei die automatische Abbildung auf vollen Objektnamen durch das DBS erfolgt kann die Allokation mitgef hrt werden Damit wird bei Datenmigration nur eine Anpassung der Synonymtabellen notwendig oder im urspr nglichem Knoten wird ein Vorw rtsverweis auf die neue Datenlokation gespeichert Ein Beispiel eine solchen L sung ist das System R Es verwendet als Syntax lt NAME gt lt user gt lt user_ node gt lt object_name gt birth_node Darauf werden Expansionsregeln fiir systemweite Namen aufgesetzt e Ein fehlender lt user gt wird durch die aktuelle USERID ersetzt e Ein fehlender lt user_node gt wird durch die aktuelle KNOTENID ersetzt e Ein fehlender lt birth node gt wird durch die aktuelle KNOTENID ersetzt Vorteile dieses Zuganges sind Knotenautonomie und die Auswirkungsfreiheit auf Namen und da mit bestehende Programme bei Migration eines Objektes Erkauft werden diese Vorteile mit einer umst ndlicheren Adressierung falls das Objekt nicht an Benutzerknoten gespeichert wird weil min destens ein Knotenname angegeben werden mu Durch Synonyme kann hier Abhilfe geschaffen wer den Das verteilte System wird um eine Routine zur Namensaufl sung wie in Bild 66 erweitert Betei ligte Rechner sind Geburtsknoten birth site meist im globalen Namen enthalten Katalogknoten catalog site und Speicherknoten store site Es wird die Replikation mehrere Speicherknoten damit
328. s aus der Faltung von o und o hervorgehen kann d h formal f r alle o o R mit o x of existiert ein Objekt o R mit o xuy o und xuz d Eine n tzliche allgemein bekannte Eigenschaft von mehrwertigen Abh ngigkeiten ist die Dekompositionseigenschaft Es gilt R X Y Z genau dann wenn sich R nach XUY und XUZ vertikal dekomponieren l t d h formal RC RC XUY x R XUZ Weniger bekannt ist dagegen da die G ltigkeit der mehrwertigen Abh ngigkeit zu einem neuen quivalenten Schema f hrt bei dem der Typ R durch die dekomponierten Typen wie in Bild 24 ersetzt wird Bild 24 Die Zerlegung von R in zwei Relationship Typen Weitere relationale Integrit tsbedingungen z B Wertebereichsabh ngigkeiten k nnen im erwei terten ER Modell verwendet werden So gilt in unserem Beispiel Semester Bezeichnung WS SS x x x 1 x 80 99 00 01 02 17 Andere wichtige Klassen von Abh ngigkeiten sind Exklusions und Inklusionsabh ngigkei ten e Ein Datenbank Schema ER besteht aus einer Menge von Typen 17 Uz r und globalen statischen Integrit tsbedingungen Xer Unsere Strukturierungssprache unterst tzt das Abstraktionsschichtenmodell Es kann die Struk turierung der Daten in jeder Schicht durch das Entity Relationship Modell repr sentiert werden Wir verwenden dazu Schemata unterschiedlicher Abstraktheit und Granularit t D
329. s wird eine Produktdatenskizze mit einer Grobstrukturierung der Produktdaten entwickelt Diese Produktdatenskizze ist mit der Konzeptlandkarte dem Dis kurs und der Produktfunktionalit t abzugleichen Zur Darstellung der Produktdaten wird ein allgemeines HERM Diagramm mit den Haupttypen entwickelt Sichten des Pflichtenhefts Es wird eine Sichtenskizze entwickelt Jede dieser Sichtenskizzen basiert auf Begriffen der Anwendung Wir nennen die Darstellung dieser Begriffe ontologische Einheit On tologien dienen bereits in breitem Ma e zur Darstellung der Realit t F r die Sichtenskizzen und die ontologischen Einheiten werden entsprechende Integrit tsbedingungen angegeben Die Ver feinerung des Lastenheftes findet durch Spezialisierung der Typen Dekomposition strukturelle Erweiterung semantische Einschr nkung Separation von Aspekten und durch Instantiierung statt Zus tzlich werden weitere Typen eingef hrt Die Sichtenskizze enth lt die Spezifikation der Darstellung der wichtigen Typen und eine grobe Vorstellung ber die Art der Benutzung der Sichten Es wird wiederum der Zusammenhang zur Darstellung der Strukturierung und der Funktionalit t im Pflichtenheft hergestellt Alle Ereig nisse des Handlungsrahmens werden durch entsprechende Teile der Sichtenskizze unterst tzt Auf der Grundlage des Zusammenhangs zu verschiedenen Elementen der Story werden auch Zu sammenh nge zwischen den einzelnen Sichten erkannt Wir spezifizieren die Zusam
330. sammengefa t und zu einer Konzeptlandkarte vereint Beschreibung der Produktfunktionen LF Es wird die Hauptfunktionalit t Kernfunktionen und Schnittstellen des Produktes mit den entsprechenden Anwendungsbereichen Zielgruppen und Adressaten beschrieben Beschreibung des Diskurs LS Es werden der Interaktionsraum kurz skizziert und die Benut zer allgemein beschrieben Au erdem werden sie im Zusammenhang mit den zu l senden Aufgaben charakterisiert Wir erfassen damit das Anwendungsgebiet und die Anwendungs schritte Beschreibung der Sichten und der Verteilung LV Es wird eine Grobbeschreibung von Sichten auf das Informationssystem mit der Verwendung durch den Benutzer und der Integration mit den Objekten des Datenbanksystems angegeben Die Sichten beschreiben die Daten in der Form in der die Benutzer mit den Daten arbeiten d h als Produktdaten und Produktdatenskizze Beschreibung der Produktleistungen und der Qualit tsanforderungen LQ Die Leistungsanforde rungen an Kerndatentypen und die Hauptfunktionalit t und allgemeine Anforderungen an die Produktqualit t wie Zuverl ssigkeit Benutzbarkeit Effizienz nderbarkeit bertrag barkeit Sicherheit Portierbarkeit und Erweiterbarkeit werden kurz angegeben Aufwands und Kostenabsch tzung LK Anhand der Strukturierung Funktionalit t der Pro duktdaten und der Diskurse wird eine Grobabsch tzung des Entwicklungs Installations und Pflegeaufwandes vorgenommen Wei
331. sberichte DBMS Beschreibung Strukturierung Funktionalit t Interaktivit t Kontext Struktur statische IC Operationen dynamische Story Raum Akteure Aufgaben Intention Ge IC Erzwingungsstrategien Content Objekte Re schichte Umgebung Ziele pr sentation Implementation Implementation Programmkode assoziierte Szenario assoziierte Szenen Kollaboration Integrationsstrategie obligatorisch good practice optional n tzlich Ein Szenario ist z B in Bild 51 beschrieben Haupt Story z B als Folge von Szenen Szenario Ausschnitt des Story Raumes mit ohne Seitenpfade gt SC3 Seitenpfad mit partieller Ver nderung des Szenariums SCI 5 2 gt SC4 SCB Bild 51 Szenario in einem Story Raum Fin Szenario ist durch eine Zuweisung von Werten an die Parameter konkretisiert Damit wird das Szenario f r einen Benutzer zu einem Szenarium das dieser durchl uft Mit der Zuordnung eines konkretisierten Szenario zu einem Benutzer wird damit auch der Akteur personalisiert Die Adaption der Elemente des Story Raumes an einen konkreten Durchlauf kann durch den Auf bau von Sitzungsobjekten in der folgenden Form erfolgen Sitzungsobjekte selbst verf gen wiederum ber eine Historie und erlauben damit eine Aufzeichnung der Historie der Benutzung durch einen Akteur Ein Beispiel einer Lernszene wird in Bild 52 dargestellt Ein Lehrstuhl erarbeitet das Lehrveran sta
332. sgearbeiteten Schwerpunktaufgaben abgeleitet Ermittlung von technischen Ma nahmen Darauf aufbauend wird die technische Infrastruktur abgeleitet Grobmodellierung der Gesch ftsprozesse Im ersten Entwicklungsschritt wird eine Grobstruktur des zuk nftigen Prozesses mit echten obligatorischen Aufgaben abgeleitet Dazu werden Dar stellungsmittel wie ereignisorientierte Proze ketten Information Control Nets Process Analysis and Design Method Petrinetze Role Activity Diagrams semantische Objektmodelle Trigger modellierung genutzt Einzelne Schritte sind dabei Modellierung des Gesch ftsvorfalles e Ablaufmodellierung e Organisationsmodellierung nach der Iststruktur e Informationsmodellierung e Definition objektbezogener Business Regeln und erandeatinnamradalaarne nach Anor GE Teri 10 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 1 EINFUHRUNG 9 Feinmodellierung des zuk nftigen Gesch ftsprozesses Es kann nun die Aufgabenverteilung f r die einzelnen Partner im Entwicklungsproze abgeleitet werden Diese analysieren den Daten und Dokumentenflu die Entscheidungsregeln die Gesch ftsfalldaten die Kompetenzregeln die Kooperationsregeln die Methodenregeln und die Zeitregeln Auf dieser Grundlage werden einzelne Komponenten des Systemes erstellt 10 Evaluierung der einzelnen Komponenten des Systemes Die erstellten Komponenten werden an hand der Ziele evaluiert Es werden au erdem
333. sgestaltung zu inte grieren Obwohl wir viele Ereignisse pr sentieren k nnen ist es schwierig sie klar und verst nd lich zu pr sentieren weil i a keine beschreibenden und erkl renden Manual Kurzgeschichten hinzugenommen werden sollten Abschlie end bewerten wir die Qualit t der Inszenierung Zieltechnik Die Zieltechnik beeinflu t in sehr starkem Ma e die Qualit t und auch die Im plementierbarkeit von einzelnen Szenen Einheitlichkeit Neben Standardinteraktionen besitzen wir auch aus dem Inhalt abgeleitete Interaktionen Eine Vereinheitlichung ist dabei angebracht Professionelles Design Ein System soll einen Akteur nicht unterfordern nicht berfluten und auch ein einfaches Wiedereinsteigen erm glichen Damit sind auch die Dialoge profes sionell zu gestalten Fehlerrobustheit Eine Fehlbedienung darf weder zum core dump noch zu unkontrollierbaren Zust nden f hren Ein Akteur mu selbst aus einer Fehlersituation wieder herausfinden Hierarchie der einzelnen Szenen Da die Szenen geordnet werden ist auch dem Akteur eine wiederholte Anwahl von einzelnen Szenen zu gestatten so da auch ein konsistentes nach und r ckverfolgbares Szenenmanagement einen Benutzer unterst tzen mu Farbauswahl Wie jedes andere Darstellungsmittel sind auch die Farben mit einer semanti schen Bedeutung zu versehen Darstellungsskalierung Je nach Akteur je nach vorhandenem Client oder Darstellungsme dium sind unterschiedliche I
334. siv oder itera tiv aufgebaut PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 3 ABSTRAKTIONSSCHICHTENMODELL B THALHEIM 32 USSIOMIUIIS Usp ff pours3unypyorAqun seq 1uE4 l l II Tf DOTV X 2u09 yo n0 u u uoduroy Sunqr s i us usuodwoy A S H P OTN T3oTouU T Joules pun s ynpolq s p unqr rq s gi 481911 uowo du a TPPoW wagsAg usgyersqe s p Sunqre1yoseq S TTopowsyyeypsery JINpoIg SVY 2115 a soumnelpetdg s p unqr rq s gi s uunery rds s p unqr rq s gi Jaueld 1 4 1912 H pouru q rq s uesnz pun u r g USP AU f poyy uceuuq ez seq Tepowsdun ynysny q poyy u quo1S wney A oys uog ued AT ued uomeyyrzeods u uon urn ormeu zs nu quoo Tm3 qens sZunIynjsny SUOTJESIUCZIO eyolly Z3 N assozoIg u m3ynns 8 sunsuIp s unuq s gi 1 41 pun m yy u ss Ip y 2014 uoyeq usIusuodwoy 9 LIOSSOTRIC ug 19 42IM U 9TeMJJog uouezg pun eyewauydag s3unpu muy 3urpog H zs suncunisny
335. sse oder Sichten bzw in einfachen F llen Teilschema ta Kanten verlaufen von Ereignissen nach Sichten bzw von Sichten nach Ereignissen Sichten werden aufgefa t als Input Output Generatoren Ein Mehrfachinput kann in and Form f r Ereignisse auf gefa t werden Ein Mehrfachinput an Sichten ist eine or Form zum Ansto en Damit ergibt sich eine Petri Netz Darstellung wie in Bild 27 als Aus ein Sender als Erstellung als l sung gedeutete gehende Sichten und bertragung von Empf nger von Mittei rein 2 Mitteilungen gedeutete anschlie enden lungen ermittelt gedeutete Transition Sichten 57 Information u No Bild 27 Petri Netz Darstellung von formalen Handlungen Spezifikation der Gesch ftsprozesse Auf der Grundlage der Darstellung in Bild 27 k nnen wir ein Aufgabenmodell entwickeln Wir wer den dieses Aufgabenmodell noch f r die Spezifikation der Interaktivit t durch Arbeitsvorg nge Akti vit ten und Aktivit tenfolgendiagramme erweitern Ein Arbeitsvorgang besitzt eine allgemeine Struk tur ein Resultat und semantische Rahmenbedingungen ba s a Ae 1 906 eee a ie ENAERE 26208 en dr AF INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 57 einen Namen einen Ausl ser der die Ausf hrung der im Arbeitsvorgang genannten T tigkeiten ausl st Zeitpunkte eingehende Daten Unterlagen eine organisatorische Einheit die eine Aufgabe durchf hrt eine T tigkeit der Ben
336. st i Allg nur bedingt erreichbar Die Prozessorfunktionalit t gestattet eine weitere Unterscheidung verteilter und Mehrrechner DBS Funktionale Gleichstellung Jeder Knoten besitzt die gleiche Funktionalit t bzgl DB Verarbeitung I Allg werden vollst ndige DBMS in jedem Knoten verwendet Die Funktionen werden repliziert Funktionale Spezialisierung Die Funktionen werden partitioniert separiert oder auch spezialisiert Ty pische Beispiele sind DB Maschinen mit Spezialprozessoren f r bestimmte DB Funktionen z B S e A Oe i ek an 30 2 et ce a nn 0 SR Rn 5 0 En INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 167 Ein spezielles Beipiel sind Workstation Server DBS Sie werden besonders bei Non Standard Anwendungen verwendet Damit kann eine DB gest tzte Verarbeitung gro er komplex struktu rierter Datenmengen in der Workstation unterst tzt werden insbesondere bei hoher Rereferenz Wahrscheinlichkeit bei den Daten und bei langen Transaktionen Sowohl die Workstations als auch der Server verarbeiten Daten besitzen eine Steuerfunktio nalit t und verarbeitende Funktionen Durch den Workstation Objektpuffer k nnen Kommuni kationsvorg nge eingespart werden Anfragen und Methoden werden ggf lokal ausgef hrt Auf dem Server werden globale Aufgaben ausgef hrt Logging Synchronisation Externspeicherver waltung etc Die Spezialisierung erschwert Lastbalancierung Erweiterbarkeit und Fehler
337. sten F llen wird jedoch eine solche Detailliertheit ben tigt Im Beispiel in Bild 35 kann die vierte Schale z B in die Per sonenangaben die Angabe der Verantwortlichkeit und die Semesterangaben separiert werden Verantwortlicher Kurs Semester gehaltene Studien Pro Bezeichnung Lehrver gang fessor Typus anstaltung Bild 35 Hierarchische Schalen des Typen Kurs in der Archivsicht Abstrakte und Verpackungsumschl ge von Content Objekten Content Objekte sind Objekte eines Content Typs die an den Akteur ausgeliefert werden und ihm zur Verf gung stehen Ein Content Objekt kann relativ gro werden Deshalb kann ein Content Objekt mit einer Beschreibung versehen werden die ber den Inhalt Auskunft gibt Diese Beschrei bung wird mit einer Extraktionsfunktion gewonnen Abstrakte dienen als verallgemeinerte Indizes und erlauben eine Vorausschau auf das Content Objekt Der Name des Content Objektes wird um den Abstrakt erweitert Abstrakte umfassen die Titel Information nach einem Benennungsschema mit einer Kurz Identifikation eine Kurzbeschreibung des Inhaltes des Content Objektes die Zusammenfassung des Inhaltes des Content Objektes die durch Anwendung entsprechender Ex traktionsfunktionen des Content Typen aus dem Content Objekt gewonnen werden k nnen allgemeine Beschreibungen des Inhaltes und der Strukturierung der Content Objekte einschlie lich der Var
338. t Wir verwenden jedoch die blichen Kurzdarstellungen Wir gehen davon aus da statische Integrit tsbedingungen einer Interpretation mit einer Nor mallogik unterliegen Mitunter wird auch im Entwurf eine Integrit tsbedingung mit einer schwachen deontischen Interpretation benutzt bei der ihre G ltigkeit f r die meisten Objekte einer Datenbank oder einer Klasse gefordert wird Mitunter wird auch eine strikte Form der In terpretation genutzt bei der z B obere bzw untere Schranken f r Kardinalit tsbeschr nkungen auch durch entsprechende Objektmengen genau erf llt sein m ssen Wir verwenden im weiteren folgende Klassen von Integrit tsbedingungen Schl ssel dienen der Darstellung der Identifizierbarkeit von Objektmengen insbesondere in FREE VII 55 TIRE sten 1 22 1 5 Tr ea en EIS WE x5 FT INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 49 Mengen sind Eine Teilmenge der Strukturelemente kann auch als Schl ssel dienen Gew hn lich hat jeder Typ mehr als einen Schl ssel Deshalb verwenden wir von vornherein Schl ssel mengen Der Prim rschl ssel eines Entity Typs wird direkt angegeben und kann in der Schl sselmenge weggelassen werden Wir nehmen z B f r das Diagramm in Bild 20 folgende Schl ssel an Key Person 1 1 PersNr Name Geburtsdatum Relationship Typen haben ggf auch eigene Attribute die auch Bestandteile eines Schl ssels sind Zum Beispiel nehmen
339. t gt S2 GID and S1 GID S2 U1D left outer join Benutzer B on S1 UID B BenutzerID left outer join BProfile BP on B BenutzerID BP BenutzerID where S1 UID between select typ_integer from tc_parameter where Name UserAnzeigenAb and 16380 go Im allgemeinen wird dies nicht ausreichen Wir verwenden deshalb erweiterte Sichten die in den n chsten Kapiteln ausf hrlich behandelt werden Sichten m ssen um Funktionen erweitert werden mit denen die Sichten ver ndert anders pr sentiert und f r das Portfolio des Benutzers aufbereitet werden k nnen Dazu benutzen wir den Definitionsrahmen generate MAPPING VARS temp OUTPUT STRUCTURE from DATABASE TYPES where SELECTION CONDITION represent using GENERAL PRESENTATION STYLE amp ABSTRACTION GRANULARITY MEASURE PRECISION amp ORDERS WITHIN THE PRESENTATION amp HIERARCHICAL REPRESENTATIONS amp POINTS OF VIEW amp SEPARATION browsing definition CONDITION amp NAVIGATION functions SEARCH FUNCTIONS amp EXPORT FUNCTIONS amp INPUT FUNCTIONS amp SESSION FUNCTIONS amp MARKING FUNCTIONS maintenance functions MAINTENANCE FRAME amp CONTROL OBLIGATIONS PERMISSIONS RESTRICTIONS Konzepte k nnen durch Konzeptnetze dargestellt werden Konzeptnetze widerspiegeln die drei semiotischen Aspekte Syntax Semantik und Pragmatik wobei die Syntax und die Pragmatik durch Kontexte verbunden werden Konzepte besitzen allgemeine Parameter die mit einer Wertebereich
340. t und mit Charakteristika versehen wer den Dabei interessieren nur solche Details die f r den Verlauf der Dialoge von Bedeutung sind d h wir erfassen einige Charakteristika und charakterisieren nicht etwa den Endan a 08 TARN ENA ET DEEE CO E D a ED a nee Os a s UR CSD a B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 7 INTERAKTIVIT T wie notwendig mit erfa t Die Kategorisierung sollte sich durch eine relative Best ndigkeit auszeichnen Aktionsphasen So wie ein Verb Aktion bzw Handlung verdeutlicht kann auch Aktion in den drei Zeitdimensionen dargestellt werden die untrennbar miteinander verbunden sind Eine f r die Zukunft geplante Aktion weist auf ein bevorstehendes Ereignis Ihr geht eine Absicht und damit ein Motiv voraus die sich einem allgemeinen Plan des Szenarios unterordnet Freignisse die in der Vergangenheit stattfanden sind in ihrem Zeitbezug auch darzustellen Aktive und inaktive Zust nde Szenen k nnen aber m ssen nicht zu einer Aktivierung f hren Deshalb kann auch ein Szenario vorsehen da einzelne Aktionen schlummern Wir k nnen diese Verz gerung durch lang andauernde Transaktionen darstellen Die Im plementierung wird damit jedoch komplexer Bei inaktiven Zust nden fehlt ein Motiv f r eine Aktion oder es liegt eine St rung vor Zur Spezifikation ziehen wir deshalb auch die Kategorisierung der Endbenutzer mit heran Wenden Benutzer Aktionen an ohne agieren zu
341. temes Das Dienste und Kollaborationsverwaltungssystem ist beschrieben durch die Implementation des verteilten Systemes Es werden insbesondere die Protokolle die Verteilung die unterst tzen den Programme und die Qualit tsverwaltung dargestellt Oft wird die Verteilung vor dem Benutzer verborgen Deshalb ist im Entwurf mitunter eine trans parente Spezifikation der Verteilung f r die Aktionsschicht angebracht Es ndert sich nur die Sicht der Benutzer auf das System Die Verteilung wird nach wie vor sowohl konzeptionell als auch im Pflichten und Lastenheft verankert Dem Benutzer erscheint das System als monolithisches System Ihm werden Dienste angeboten Der Kollaborationsrahmen kann als Arbeitsblatt dargestellt werden Ein typisches Arbeitsblatt 1 TR IT 83 Ka SE TE an Er en a Ba Re ae wa ER Er 2 FI IE IM I 5 156 Motivations schicht Gesch ftsproze schicht Aktions schicht konzeptionelle Schicht Implementations schicht B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 Vorstudie Skizzierung Vertragsraum Feinstudie Verfeinerung Kbllaborationsraum Entwurf Entwicklung Diensteraum Implementation Transformation Lastenheft Verteilung Pflichtenheft Verteilung Kollaboratives System ienste und Kollaborationssyste KAPITEL 8 nste ualit tsvertra Dienste Qualit t Content Typen
342. tenschemata Wir erweitern die Darstellung von ER Schemata wie bereits z T in Bild 34 verwendet Optionale Komponenten sind f r Relationship Typen von Sichten zugelassen Sie werden mit einer gestrichelten Linie angegeben Versteckte Komponenten sind in einer Sicht in der Definition vorhanden werden aber nicht angezeigt Sie werden mit einem gestrichelten Typ mit dem Auswahlpr dikat dargestellt Default Werte werden f r eine Sicht f r die Generierung der Sicht benutzt Sie k nnen jedoch im Dialog durch andere Werte ersetzt werden Es wird f r einen Typ der Default Wert mit der Ag cy oa xe EEE Zn INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 87 Wir merken an da sich mit einer Sichtendefinition auch die Integrit tsbedingungen f r die Typen einer Sicht ndern k nnen Wir verwenden das Sichtenschema um die Funktionalit t der einzelnen Typen mit anzugeben Damit wird ein schnellerer berblick gegeben Erstellung der Sichten Suite Es werden die Sichten als konzeptionelle Sichten in ihrem Zusammenhang mit einer Erweiterung um ggf andere Datenbest nde sowie um andere Datentypen wie z B den Basis Datentyp URL money und MAIL dargestellt Ein Sichtenschema wird als ER Schema dargestellt in dem jedem Typ eine Anfrage ber dem ER Schema und den Typenerweiterungen zugeordnet wird Ein Sichtenschema kann auch materialisiert abgelegt werden Dazu ist anzugeben auf welche Art eine Modifikati
343. tentiale erlauben Effekte oder schr nken diese stark ein Diese Gestaltungsdimensionen k nnen auch in kombinierter Art und Weise zur Gestaltung herange zogen werden In den kombinierten Dimensionen Benutzer Daten Datenrepr sentation werden Metaphern zur Informa tionsdarstellung mit denen ein Bezug auf die Benutzerwelten und die das Verst ndnis der Daten auf die Benutzer darstellen eingesetzt In den kombinierten Dimensionen der Benutzer Proze Repr sentation werden Metaphern der Bewegung wirksam In der kombinierten Dimension der Daten Benutzer Welt wird der Informationsgehalt der Wert der Es i REN 0 15 0 b 21 aaa i AITE ER x 142 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 7 INTERAKTIVITAT In der kombinierten Dimension der Daten Datenrepr sentation spielt die Bereitstellung der Daten als Content eine Rolle In der kombinierten Dimension der Prozesse Proze repr sentation wird aus der erforderlichen Funk tionalit t abgeleitet welche gestalterischen Mittel erforderlich werden In der kombinierten Dimension der Proze repr sentation Umgebung wird das Playout abgeleitet Es orientiert sich an e dem Anliegen der Darstellung und setzt Anforderungen der Darstellung der Prozesse um e der Story selbst und e den technischen M glichkeiten die durch die Umgebung gegeben sind In der kombinierten Dimension der Datenrepr sentation Umgebung wird aus den zur Verf gung ste henden I
344. tere Bestandteile LW beschreiben die Ber cksichtigung von Rechten Privatrecht Daten schutzrecht Pers nlichkeitsrecht Recht auf informationelle Selbstbestimmung Grund recht auf Datenschutz die Darstellung des angestrebten Softwareschutzes Vertragsrecht Urheberrecht auch bei Reengineering die Mitbestimmungsrechte Arbeitsverfassungsge setz Personalvertretungsgesetz Betriebsverfassungsgesetz den Verweis auf das Produkt haftungsgesetz insbesondere im Zusammenhang mit Qualit tsmangement die Instruk tionspflicht f r das Fehler Management das Vertragsrecht M ngelhaftung Erkl rungen zum Stand der Technik und die vertragliche Regelung der Software Hinterlegung z B 3 XY 2 ami as INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 177 Das Lastenheft sollte so detailliert sein da eine Vermarktungsabteilung aus dem Lastenheft eine Vermarktungsstrategie erarbeiten kann Architektur der Anwendung A In unserem Komponentenansatz erhalten Verteilungs und F derie rungsaspekte eine relativ einfache L sung Es wird die allgemeine Architektur der Anwendung als Komponenten Schema angegeben Es werden damit die Zusammenh nge der Komponenten dargestellt die Abgrenzung der Komponenten voneinander die Kooperationsbeziehungen der Komponenten unteinander und die Art der Vererbung und Steuerung von Strukturierung und Funktionalit t einer Komponente durch andere Komponenten Da wir eine Separation von
345. terst tzt werden Wir k nnen die einzelnen Schritte wie in Bild 33 darstellen INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 83 Motivations schicht Gesch ftsproze schicht Aktions schicht konzeptionelle Schicht Implementations schicht Produktdatenskizze Vorstudie Skizzierung Produktdaten Lastenheft Sicht en Sichtenskizze Feinstudie 7 Darstellung ontologische Einheit Pflichtenheft Sichten Sichtenskelette Entwurf Sichtenentwurf Keni typ Aktionssichten Suite ichtenschemata Implementation nn Transformation Typ Sichten Suite Sichten anfrage menge Sichtentyp anfrage logische Sichten Suite Bild 33 Die Arbeitsprodukte im Abstraktionsschichtenmodell fiir die Sichtenentwicklung 84 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 6 SICHTENSUITE Sichten und Content Typen Sichten werden klassischerweise durch Anfragen ber Datenbank Schemata definiert In diesem Fall benutzen wir als Rahmen select Projektionsausdruck from Datenbank Struktur where Auswahl Bedingung group by Zusammenfassungsausdruck zu Gruppe having Auswahl unter den Gruppen order by Lexikographische Ordnung unter Teilstruktur Dieser Rahmen erlaubt die Definition einfacher Sichten die auf einem Typ definiert sind Damit ist jedoch eine konzeptionelle Darstellung zusammengeh render Objekte f r die Ausgabe nicht m glich Wir nutzen di
346. tigkeiten die zur Benutzung des Systemes erforderlich sind e Wissen das zum Verst ndnis der Benutzung des Systemes erforderlich ist e Arbeitsumgebung die durch die Akteure toleriert bzw akzeptiert wird und e Systeme mit denen die Akteure bereits Arbeitsaufgaben bew ltigt haben Das Pers nlichkeitsprofil umfa t auch das Polarit tenprofil Typische Polarit tenprofile sind nach Anmutungscharakteren sachlich romantisch konventionell originell klassisch modisch traditionell avantgardistisch tough tender rustikal artifiziell und einfach wertvoll Im Einzelnen k nnen wir dazu dra d a x a 2 42 TE eet Bu aE 1 1 TOE cer Seen eres r G b 22 s INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 115 sachlich romantisch konventionell originell n chtern gef hlvoll blich ausgeflippt rational sensitiv bedeckt frisch berlegt sinnlich seri s ungew hnlich b rgerlich bohemehaft klassisch modisch traditionell avantgardistisch dezent laut alt jung zeitlos modern uni bunt ruhig unruhig ruhig erregend zur ckhaltend aufdringlich vertraut vertraut gewohnt poppig tough tender rustikal artifiziell herb s lich nat rlich k nstlich geometrisch blumig verspielt streng hart weich einfach komplex robust zart schwer leicht eckig rund grob grazil Daraus kann die Charakterisierung von Benutzergruppen abgel
347. tion der Verteilung erweitert Der Austauschrahmen umfa t die gesamte Kollaboration Charakterisierung nach Kooperationsformen Kooperation zwischen Akteuren basiert auf einer Darstellung des Arbeitsprozesses einer Angabe des Organisationsmodelles und einer Dar stellung des Arbeitsplatzes bzw Arbeitsraumes Die Kooperationsformen zum Frreichen der Ziele werden im Rahmen der Kooperation der Benutzer abgeglichen Es sind sowohl spezifische Formen der Interaktion als auch des Re viewing und der Kontrolle zu vereinbaren Die Rollen bei der Kooperation werden f r die einzelnen Benutzer im Detail festgelegt Charakterisierung der Formierung Wir unterscheiden unterschiedliche Arten der Formierung von Gruppen in inhaltsbezogene Formierung bei der der Kooperationsrahmen durch Ziel und Portfolio de terminiert wird arbeitsweise orientierte Formierung die eine Anpassung der Content Objekte an die z Z pr ferierte bzw im n chsten Schritt erwartete Arbeitsweise erm glicht und Formierung durch Selbstorganisation der Gruppe die eigenst ndig die Inhalte den Zeit punkt und den Arbeitsraum bestimmt Charakterisierung nach Raum und Zeit Wie bereits dargestellt k nnen wir bei einer Zusammen arbeit unterschiedliche Content Objekt Zuordnungen und Zeitr ume darstellen Gleiches Content Objekt und synchrone Zusammenarbeit Ein typische Form dieser Zusam menarbeit sind Brainstorming Sitzungen Gleiches Content Objekt und asynchrone Zusammen
348. tion von Mensch und Maschine in Form von Dia logen Dialogobjekten und Oberfl chen nach Meist wird eine Kombination dieser Methoden gew hlt Eine bevorzugte Variante ist die Kombination der prediktiven und der anthropomorphen Methoden Aus diesen Perspektiven sind zwei grunds tzliche Zug nge zur Gestaltung von Oberfl chen ab leitbar Der konstruktive Ingenieurzugang orientiert sich an den Entwicklern und den vorhandenen technischen M glichkeiten und damit an der Maschinenperspektive Systeme dieser Bauart k nnen einfach und elegant einfacher auch durch den Benutzer zu pflegen und f r den eingearbeiteten Benutzer auch durchschaubar sein Der Benutzer Aufgaben Zugang beruht auf eine Kombination der Werkzeug Kommunikations und der Systemperspektive Ausgehend von einem Aufgabenmodell und einem Interaktionsmodell wird der Computer zum Partner bei der L sung einer Arbeitsaufgabe Die einzelnen Arbeits schritte werden in Oberfl chen nachgebildet Der Vorteil dieses Zugangs ist die leichte Erlern barkeit Von Nachteil ist die Fixierung auf den aktuellen Zustand des Arbeitsprozesses der u U auch von bislang benutzten nicht ad quaten Werkzeugen und deren Funktionalit t gepr gt ist 146 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 8 VERTEILUNG 8 Sprachen zur Darstellung der Verteilung Entzwei und gebiete T chtig Wort Verein und leite Bessrer Hort Goethe Sprichw rtlich Allgemeine Architektur von Kollabor
349. tivit t kann unter zwei Gesichtspunkten dargestellt werden Der System Gesichtspunkt umfa t alle Input Output und Speicherprozesse und baut auf der Struk turierung der Daten auf den Sichten zur zusammenh ngenden Darstellung der Daten sowie auf dem technischen Workflow der wiederum auf Systemprozessen basiert auf Der Benutzer Gesichtspunkt basiert auf den Rollen und Aufgaben von Benutzergruppen deren Sicht weisen auf die dargestellten Daten und die ablaufenden Prozesse Diese Sichtweisen sind auch durch die Pragmatik der Benutzergruppen gepr gt Ein Informationssystem basiert auf einer Schichten Architektur die die klassische ANSI Sparc Architektur verallgemeinert Im folgenden vertiefen wir diesen Zugang Die Architektur ist in Bild 38 b skizziert Mit dieser Architektur wird nicht nur die klassische Seeheim Architektur in Bild 38 a verbessert sondern auch eine ganzheitliche Betrachtung von Anwendungen erm glicht Die Oberfl chenmodellierung wurde auch f r Datenbanken im wesentlichen auf der Grundlage des See heim Modelles nach Bild 38 a ohne Dialogmanagementsystem und Sichtengenerator vorgenom men Das klassische Seeheim Modell trennt wie in Client Server Architekturen die Pr sentation vom Anwendungssystem Diese Trennung hat sich f r eine Vielzahl von Anwendungen durchgesetzt Die Funktionalit t der Anwendungssysteme kann sich dabei weiter in die Clients verlagern F r Daten banksysteme hat sich diese Architektur so
350. toleranz Deshalb werden Mischformen aus horizontaler vertikaler Verteilung verwendet Zusammenfassend k nnen wir die Eigenschaften von Mehrrechnersystemen wie folgt vergleichen Parallele DBS Verteilte DBS F derative DBS Workst Server DBS Hohe Transaktionsraten o o Intra TA Parallelit t o o o Erweiterbarkeit o o o Verf gbarkeit o Verteilungstransparenz o 4 geographische Verteilung o Knotenautonomie DBS Heterogenit t Administration o Multi DBMS und Datenbank Farmen Verteilte Datenbanksysteme fu en auf lokalen Datenbanksystemen und folgen einer Integrations und Kollaborationstrategie Die Integration verwendet kooperierende Sichten in der einen oder ande ren Form Typische Formen der Integration sind Global A s View Integration GAV Das globale Schema besteht virtuell Es ist eine Sicht auf die einzelnen lokalen Schemata Es wird eine Client basierte Integration angestrebt und eine auf den Einzelsystemen basierende Entwicklung vorgenommen Anfragen k nnen damit durch An frageexpansion ber den lokalen Schemata realisiert werden Damit sind allerdings Integrations Semantik und Pragmatikkonflikte verbunden die die Praktikabilit t dieses Zuganges erheblich einschr nken Local A s View Integration GAV Die lokalen Schemata sind modifizierbare Sichten des globa len Schemas Die lokalen Schemata sind vollst n
351. tsfortschrittes Konstruktion der L sungen Umgang mit Abstrak tionstechniken Effektivit t Erweiterung f r bereits gefundene Teill sungen und Kooperati onsf higkeit und spezielle Kenntnisse wie Wissens Rep sentationstechniken Wissens Akquisition und andere Die Profile von Akteuren k nnen kategorisiert und damit einer Skalierung unterzogen werden Wir k nnen z B mit der folgenden Kategorisierung die Profile der Akteure zum Erstellen eines Lehr veranstaltungsvorschlages eines Lehrstuhles vornehmen Ausbildungsprofil Arbeitsprofil Pers nlichkeitsprofil Folgerung erfor vor nicht F hig Fertig Wissen Arbeits System Polarit f r Umge derlich han vorh keiten keiten umgebung tenprofil bung den Infor Infor Organi Java Program Infor Unix Work rigide 5 Kommandoi matik matik sations C mierung matik station sprache erfahrung ohne Sicherung Biiro PH Infor Organi kollabo allg PC minimal moderat Fehler Kauf Stu matik sator rativ Platz toleranz frau dium bersicht mann lichkeit Andere ableitbare Eigenschaften sind z B die erforderlich Hilfe die Art des Systemerlernens die Adaptivit t der Interfaces die Erweiterbarkeit exploratives Handeln selbst gesteuerte Nut zung Merkhilfen Aufgabenorientierung Routinetoleranz Technikerwartungen Zusatzaufwandtole ranz EDV Terminologie Toleranz
352. tz nicht zu h heren Kosten f hrt Der Nutzen von Informationssystemen besteht 1 in der gemeinsamen und parallelen Benutzung von Daten bei gleichzeitiger Benutzung unter schiedlicher Sichtweisen auf die Daten 2 in kontrollierter Redundanz von gleichen Datenbest nden 3 in der Unterst tzung von eingeschr nktem Benutzerzugriff die auch Sicherheitsmechanismen einschlie t 4 in der Bereitstellung verschiedener Schnittstellen f r unterschiedliche Benutzungsgruppen b ne SPL EEE gt nn Ah Zn iat SE ec bi INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 17 6 in der Bereitstellung von Mechanismen zur automatischen Integrit tserzwingung und 7 in einer Robustheit die einen Wiederanlauf auch nach Systemfehlern erlaubt Ein Einsatz von Datenbank Management Systemen DBMS ist besonders sinnvoll e zur Unterst tzung heterogener Benutzergruppen die eine gemeinsame Datenhaltung pr ferie ren e falls keine oder kontrollierte Redundanz gew nscht ist e falls eine Benutzerverwaltung und Authorisierung sinnvoll ist e falls unterschiedliche Schnittstellen f r unterschiedlich geschulte Benutzer bereitgestellt werden sollen e falls komplexe Daten oder komplexe Beziehungen zwischen den Daten vorliegen e falls Integrit tsmechanismen genutzt werden sollen e falls eine Fehlerbehandlung und Archivierung erforderlich ist und e falls eine geringe Entwicklungszeit f r sich ndernde Anwendungen bevorzugt
353. tzen da dies den Rahmen dieser Arbeit sprengen w rde F r die Spezifikation von Informationssystemen spielen Begriffe und Konzepte eine untergeordnete Rolle Wenn wir allerdings eine allgemeinere Architektur wie z B in Bild 10 anstreben dann kann eine essentielle Verbesserung der Kultur erfolgen Nor malerweise befindet sich ein Benutzer eines Informationssystemes in der SQL Falle Er mu sowohl das Schema kennen und verstehen als auch mit SQL seine Anfragen formulieren k nnen Einfacher und zugleich sinnvoller ist es dem Benutzer durch eine Assoziation seiner Begriffe mit Konzepten und durch eine Verbindung dieser Konzepte mit Anfrage und Antwortformen zu unterst tzen Die Anfrageformen k nnen mit dem Datenbankschema ebenso assoziiert werden wie die Antwortformen Damit erh lt ein Benutzer f r seine Frage die richtige Antwort aus dem System heraus Mit dieser L sung kann ein Content Management System dem Benutzer maximal entgegenkom men Die Modellierung von Strukturierung Funktionalit t und Verteilung wird nicht vollst ndig durch die vorhandene DBMS Welt unterst tzt Ein Hindernis ist das Sichtenupdate Problem Da mit der Er zeugung von Sichten ggf auch nicht jedes Sichtenobjekt einem Datenbankobjekt zugeordnet werden 05 612 a ody POET 2 a Mn en AR las 0 1 uza aa a en 22 ce hi F 26 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 2 SPRACHEN
354. tzer Maschine Die einzelnen Gesch ftsprozesse werden nun mit ihrem Verlauf im Detail dargestellt Sie k nnen durch Ablaufdiagramme dargestellt werden Handlungen sollen zu einer Ver nderung der Datenbank f hren oder dem Informationsgewinn der Akteure dienen Akteure sind Abstraktionen von Benut zergruppen wie z B der Beauftragten des Lehrstuhls Wir entwickeln damit allgemeine nderungs operationen Retrievaloperationen und Operationen zur Ver nderung von Rollen von Objekten mit entsprechenden dynamischen Integrit tsbedingungen Es werden zugelassene erw nschte verbotene und erzwungene Handlungen dargestellt F r die einzelnen Akteure gibt es Verpflichtungen Handlungen werden Arbeitsvorg ngen bzw T tigkeiten zugeordnet Ein Arbeitsvorgang ist wie bereits dargestellt durch einen Akteur oder eine Gruppe von Akteuren als Ausl ser mit Rollen und Rechten eine organisatorische Einheit einer Beschreibung der Aktionen in ihrer Abfolge eine Ordnung und ihren Beziehungen die verwendeten Hilfsmittel und Informationen und die Ablage der Resultate charakterisiert Aus der Beschreibung der Koordination der Handlungen werden dynamische Integrit tsbedin gungen abgeleitet Spezielle dynamische Integrit tsbedingungen sind Methodenregeln die Aussagen dar ber festhalten wie bestimmte Aktionen ausgef hrt werden und welche Umgebung Daten Ak teure Dialoge zu ihrer Ausf hrung notwendig ist Durch Zeitregeln Ausf hrungsh ufigkeiten und
355. u ur 2 en INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 99 Durch den Sprechakt wird die Interaktionsform beschrieben Im illokution ren Akt wird die kommunikative Funktion der menschlichen Kommu nikation nachgebildet z B pr positionaler Akt Typische Darstellungsformen sind Assertion Direktive Kommissive Deklarative und Expressive F r den perlokution ren Akt wird die Wirkung auf den Zuh rer bewertet Die Konversation ist eine Kombination einer Reihe von Sprechakten Wir unterscheiden dabei die die Konversation zur Handlung Aufforderung zu einer Handlung die Konversation zur Kl rung als Interaktion die Konversation zur Entscheidung ber M glichkeiten ber einen Handlungsver lauf und die Konversation zur Orientierung zur klareren Darstellung der Umgebung Die Charakterisierung nach Aktivit ten dient der Einbettung des Dialoges in die Spezifikation der Funktionalit t Ein Content Typ Benutzer Arbeitsplatz sollte die eine oder die andere Form unterst tzen Wir w hlen dazu einen Ansatz der sich relativ einfach realisieren l t sich gleichzeitig harmonisch mit den bisherigen Ans tzen verbindet und in Bild 36 skizziert ist Kern Typen des Content Typs Benutzer Arbeitsplatz sind die Typen Person Arbeitsgruppe und Arbeitsplatz Diesen Kern Typen werden unterschiedliche Typen auf der Grundlage folgen der Annahmen zugeordnet Gruppierung von Personen in Akteure Personen werden je nach ih
356. ualit t Vollst ndigkeit Alle Szenen sind vollst ndig und bis ins Detail ausgestaltet Bed rfnisgerecht Die Aktionen Informationen und Dialoge entsprechen den Bed rfnissen der Akteure Didaktisch aufbereitete Granulierung Informationen k nnen in der Granulierung auch einen Akteur berfordern was h ufig bei einer direkten bertragung von Darstellungen mit Printmedien vorkommt Inhaltliche Konsistenz Jede Aktion jede Information jeder Dialog besitzt einen lokalen und einen globalen Kontext In beiden sollten Widerspr che vermieden werden Resultat dieses Schrittes ist ein Storyboard mit einer detaillierten Beschreibung der Szenen Es werden die Stories aus dem Pflichtenheft mit den Freignissen durch Plots und Themen verfeinert Diese Szenen wiederum werden schrittweise untersetzt durch einzelne Aktionen der Akteure Das Storyboard zeigt die Anwendung aus der Sicht des Benutzers Oft werden da zu auch graphische Repr sentationen benutzt Eine solche Repr sentation wird bei Website Entwicklungen Mockup genannt Ein Mockup stellt eine Folge oder allgemein partiell geordnete Menge von Themen dar unter Einbezug der Gestaltungsmittel der visuellen Gestaltung F r das Drehbuch werden die Szenen des Storyboards weiterentwickelt Durch das Drehbuch wird die Art und Weise in der die Geschichte realisiert werden soll spezifiziert Ein Drehbuch spezifiziert eine Story bzw den gesamten Story Raum im Detail Das Drehbuch ist eine konzept
357. uch 0 andernfalls Erf llt ein Objekt o das Pr dikat a dann Ersetzungsfamilie Eine Ersetzungsfamilie y o R vom Typ R ist eine Menge bestehend aus ei nem Paar von Objekten und Klassen vom Typ R Eine Ersetzungsfamilie beschreibt fiir Objekte vom Typ R jeweils eine Klasse von Objekten durch die dieses Objekt ersetzt wird Definitionsrahmen der strukturellen Rekursion Durch strukturelle Rekursion wird ein allgemeiner Rah men zur Definition von Funktionen bereitgestellt Gegeben seien Typen T T Kollektionen T vom Typ T die Funktionen Ur verallgemeinerte Vereinigung Nr verallgemeinerter Durchschnitt und die leere Kollektion z von T Weiterhin seien f r einen Typ T ein Wert ho dom T und Funktionen hy T T T x T T gegeben Dann definieren wir 5TECho hi ha Pr ho STECho hi h si h ls f r einelementige Kollektionen s ha h Ur 77 falls T Nr T z Gew hnlich wird eine solche mathematische Definition weggelassen Wir sind jedoch an einer Datenbank entwicklung mit nachvollziehbaren Eigenschaften interessiert Die Algebra des erweiterten ER Modelles ist eine Verallgemeinerung und Erweiterung der rela l aaa li a 8 ne ARCHE Cee en cr DEREN RR oe a ee u 335 0 o o 6 03 0 N INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 61 e Typ erhaltende Operationen f
358. uch aufgrund der Komplexit t es PER 0 0 Ey by NON 382 S x o r aaz 27 URMU ua d lu o 40 66 0 9 xs d ann ee INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 15 Entwerfer umfangreiche und tiefgehende Kenntnisse Die Werkzeuge generieren meist nur eine von vielen m glichen Normalisierungen so da eine Korrektur per Hand oft erforderlich ist Aus diesem Grund hat sich das auf eine graphische Darstellung st tzende Entity Relationship Modell f r die ersten Entwurfsphasen durchgesetzt Es gibt heute fast kein Entwurfssystem das dieses Modell nicht in irgendeiner Form benutzt Wir folgen diesem Trend erweitern aber das Modell um auch die anderen Entwurfsphasen mit diesem Modell durchf hren zu k nnen Es gibt allerdings bislang keine Theorie der Modellierung von Informationssystemen In der Lite ratur finden sich nur einige Bestandteile einer solchen Theorie Theorie relationaler Schemata Theorie der Petri Netze Theorie von Workflows Wir ben tigen einen vollst ndigen Zugang der eine Modellie rung der Strukturierung Funktionalit t und Interaktivit t unterst tzt Au erdem sollten Aspekte der Verteilung dargestellt werden Unsere Theorie st tzt sich auf zwei Darstellungssprachen das erwei terte Entity Relationship Modell HERM und die Webseiten Beschreibungssprache SiteLang sowie der Verteilungssprache DistrLang Mit der ersteren k nnen wir alle datenbank basierten Aspekte wie Strukturierung Funktional
359. ung bestimmt lokale Erreichbarkeit aller Daten wodurch higkeit Ausfiihrungsort von DB Operationen gr ere M glichkeiten zur Lastbalancierung entstehen geringe M glichkeiten zur Lastbalancie Kommunikation f r Synchronisation und rung oder Einsparung von Kommunikations Koh renzkontrolle vorg ngen besonders problematisch dominierende nahe Kopplung kann zur Leistungssteige Transaktionstypen und DB Bereiche rung eingesetzt werden trotzdem h here Fle xibilit t zur Parallelisierung Erweiterbar neuer Rechner erfordert physische Neuauf keine physische Neu Aufteilung der keit teilung der Datenbank N N 1 besonders problematisch f r nicht direkte Plattenanbindung kann Rechner relationale DBS anzahl begrenzen nachrichtenbasierte I O Schnittstelle Verf gbarkeit Partition eines ausgefallenen Rechners gesamte DB bleibt nach Rechnerausfall er zun chst nicht mehr erreichbar reichbar bernahme Recovery der betroffenen Parti komplexe Crash Recovery tion durch anderen Rechner vorzusehen ggf berlastungsgefahr ortsverteilte Replikation erm glicht schnelle Erstellung einer globalen Log Datei Katastrophen Recovery Technische Bestimmung der physischen DB Synchronisation Probleme Partitionierung verteilte Anfrageverarbeitung globale Deadlock Behandlung parallele Anfrageverarbeitung Koh renzkontrolle Behandlung replizierter Datenbanken Logging
360. ung separat behandelt Die Entwicklung von Systemen wird dagegen gar nicht betrachtet Da die Approximation gar keine Rolle spielt wird sie im weiteren nicht betrachtet Programmiersprachen konzentrieren sich eher auf die Entwicklung von Regeln zur Zustandstrans formation Zust nde werden durch eine Struktur definiert Die abstrakten Zustandsmaschinen er lauben dar ber hinaus eine Abstraktion durch Einf hrung einer expliziten Verfeinerungsbeziehung Regeln k nnen sowohl sequentiell als auch konkurrierend als auch parallel angewandt werden Erst mals mit den abstrakten Zustandsmaschinen wurden auch Postulate aufgestellt Gur00 Postulat der sequentiellen Zeit Zustandstransformationen erfolgen schrittweise mit einer Zeit logik die sequentiell ist Postulat der abstrakten Zust nde Zust nde k nnen durch eine Struktur ber einer Signatur definiert werden wobei Zustandstransformationen nicht die Struktur ndern und invariant ge gen ber Strukturisomorphismen sind Postulat der beschr nkten Exploration Zustandstransformationen erfolgen f r eine beschr nk te bzw endliche Menge von Zust nden des gesamten Zustandsraumes Oft ist es sinnvoll die vier Prinzipien auf spezifische Art zu betrachten In unserem Anwendungs fall betrachten wir nicht die allgemeine Kollaboration sondern nur einige Aspekte Kollaboration im Rahmen der Verteilung und Interaktion von System und Akteuren anstelle von Agenten Wir betrachten auch im wesentl
361. ungsbereich an der BTU Cottbus und die Nichtweiterf hrung des Denda Projektes war eine entschei dende Ursache f r den Zusammenbruch des SFB s Im Denda Projekt wurde dagegen erreicht da trotz Einhaltung von Autorenrechten auf der Grundlage eines Kollaborationsvertrages eine umfassende Kollaboration durch gemeinsame AT a ee E A a en P 9 dz 170 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 8 VERTEILUNG Wir betrachten als Anwendung unserer Entwicklungstheorie Facility Management Systeme im Baubereich Die Objekte in diesem Bereich sind interessante Beispiele f r Stern Typen Objekte die in Typenschalen so wie f r Sichten Suiten dargestellt schrittweise erweitert werden Die Entwick lung der Typen in den einzelnen Datenbanksystemen folgt dabei einer Stern Architektur in der die Pflege der Daten mit Insert Delete und Update Formen auf der Grundlage von Trennschichten nach Tha01 erfolgt F r Facility Management Systeme ist keine Systematik bekannt Diese Systeme besitzen einige Phasen e In der Planungsphase werden die Daten zu Geb uden den Bestandteilen und ihren Assozia tionen entwickelt Es entsteht eine Kerndatenbank die sp ter nicht modifiziert sondern nur verfeinert wird Wird eine nderung in einer sp teren Phase erforderlich dann werden Kopien angelegt und verfeinert e W hrend der Architekturphase wird die Geb udearchitektur entwickelt Es entstehen
362. unterst tzt Die Trennung von Geburts und Speicherknoten erlaubt eine Stabilit t gegen ber Datenumverteilungen Der Katalogknoten kann mit dem Geburts oder Speicherknoten bereinstim men wodurch die Kommunikation verringert wird Geburtsknoten Birth site globaler Name Katalogknoten Catalog site Speicherknoten Speicherknoten Speicherknoten Store site Store site Store site Bild 66 Namensaufl sung In analoger Form findet die Namensaufl sung ber Synonyme statt Wie in Bild 67 illustriert werden Synonyme Alias Namen durch eine Abbildung benutzerspezifischer logischer Namen in voll qualifizierte globale Namen umgewandelt Die Verwaltung von Synonymtabellen wird durch DBS im lokalen Katalog vorgenommen Dieser Ansatz findet in vielen kommerziellen Systemen wie z B Tandem NonStop SQL DB2 Oracle etc Verwendung Der n chste Schritt sind interoperable f derative Informationssysteme wie in Bild 58 Diese Ent a 2 80 DA y E Sa Seen ik a 24 o INFORMATIONSSYSTEM ENTWICKLUNG IM Co DESIGN ZUGANG 8 165 logischer Objektname lokale Synonymtabelle ns Y globaler Objektname globale Katalogdaten Y physische Objektadresse Bild 67 Namensaufl sung ber Synonyme Verteilung DBMS Zentrale Verteilte Interoperable F derative Datenbankmodell A A B B Plattform A A A B Replikation Partitionierun
363. uordnung k nnen sich vom Vorschlag zum Plan und f r den Raum vom Plan zu den gehaltenen Lehrveranstaltungen ndern Ein Vorschlag f r eine Lehrveranstaltung wird durch Berechtigte eingetragen Eine Person ist f r die Lehrveranstaltung verantwortlich Eine Lehrveranstaltung kann f r mehrere Studieng nge angeboten werden Wir wollen hier nicht die vollst ndige Entfaltung von Objekten zu Typen h herer Ord nung fordern Deshalb erbt ein Relationship Typ h herer Ordnung nur die Identifikation seiner Elemente oder wenn wir an einer vollst ndigen Wertedarstellung interessiert sind nur die identifizierenden Werte der Objekte seiner Komponenten So k nnen z B Ob jekte vom Typ geplanteLehrveranstaltung in Bild 20 auch nur auf Objekte verweisen die Kurs Semester Professor bezeichnen wenn wir voraussetzen da ein Schl ssel des Typs angeboteneVorlesung aus Kurs Semester Professor besteht Ein Objekt vom Typ angeboteneVorlesung Kurs Semester Studieng nge Professor eingetragen Verantwortlicher4LV Raumwunsch Typus Zeit ist z B VorlesungDBIVSS02 DBIV SS2002 Informatik IMT 637861 KK 637861 SR1 Vorlesung bung Praktikum 2 2 2 Mo 1 DS Generalisierung versus Spezialisierung Ein Cluster Typ erlaubt die explizite Darstellung einer 23 89 2 0 e 012581 855k S125 Seren eee oo 5 lt 15 eto l x INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG Stud
364. ur Suche e Die antonymbasierte Suche beginnt mit einem Begriff den man nicht sucht der aber relativ s lan x Nm z r ER 03 130 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 7 INTERAKTIVIT T e Das Zappen erlaubt den Beginn an einer beliebigen Stelle und eine spezifische Form des Drill down e Das Roll up beginnt mit einem speziellen Begriff und hangelt sich ber die Gattung oder Kategorisierung zu den gew nschten Begriffen e Das Umschauen oder Kramen ist eine Suche mit einer Drill down Funktion zur Verfeinerung e Die Formulierung eines vollst ndigen Suchausdruckes z B mit einer SQL Anweisung ist eher die Ausnahme e Die Suche mit intelligenten sich durchfragenden Agenten ist eine Form des Auslegens von Fallen oder der Beauftragung von Suchhelfern In analoger Form kann auch die Navigation oder auch der Export Import in generischer Form dargestellt und mit konkreten Datenstrukturen unterlegt werden Der Kontext Raum Die Laufzeit Pr sentation wird durch Instantiierung des Kontextes technische Umgebung Aufgabe Geschichte Umst nde und durch Adaption an den Benutzer Profil Portfolio erzeugt Diese Infor mation mu deshalb im Entwurf mit erarbeitet werden Wir betrachten unterschiedliche Spielarten von Kontext Diese Spielarten k nnen mit dem Zwie belprinzip zum Ausspielen in die XML Dokumente eingebracht werden Allgemeiner Kontext dient zur Beschreibung des Ko
365. urchdachte Freignisstruktur ist Voraussetzung f r eine Akzeptanz der Dialoge Der Benutzer soll in der Lage sein die Distanz zum Frreichen des Ziels abzusch tzen wozu auch eine Umstellung der Szenen beitragen kann Eigenschaften der Darstellungsmedien Der Entwickler kann sich vieler Medien bedienen um alle Bestandteile einer Szene dem Akteur mitzuteilen Es m ssen Dialoge Ger usche Handlungen Dekorationen Darstellungsobjekte und Musik in konsistenter Form eingesetzt werden Damit ist das Verfassen ebenso wie alle anderen Schritte der Entwurfsschicht nicht nur zu eine sch pferischen T tigkeit sondern ist vor allem auch ein Handwerk das sich an Regeln der Handwerkskunst orientiert Am Ende entsteht auf der Grundlage des Szenarios der Story und der Ideen ein ausgereiftes Drehbuch Die Szenenfolge wird anschlie end auf Variation Ver nderung und Kontrast untersucht F r die einzelnen Szenen sind die Verbindungen explizit zu modellieren Deshalb werden evt zus tzliche Verbindungselemente aufgenommen Nicht alle Szenen sind miteinander gleich eng verbunden Es lassen sich Szenenbl cke Akte mit besonders starken Verbindungselementen bilden Nach der Fertigstellung des Drehbuches sollte man den Entwicklungsproze umkehren und eine Zusammenfassung des vorliegenden Drehbuches schreiben Diese Zusammenfassung ist dann mit dem Storyboard dem Story Raum und den Ideen und Motiven zu vergleichen F r das Drehbuch bewerten wir abschlie
366. utzer bzw einen Ablauf von T tigkeiten der Benutzer verwendete Hilfsmittel und Zusatzinformationen die diese T tigkeiten unterst tzen und einer Ablage und einem Adressaten in die oder an den Ausgaben erfolgen beschrieben Als Beispiel einer Aufgabe k nnen wir die Erstellung eines Vorlesungsangebotes in unserem Haupt beispiel betrachten Ein Beauftragter eines Lehrstuhles erh lt eine Aufforderung zur Erstellung von Angeboten zu einer Vorlesung Die organisatorische Einheit ist der Lehrstuhl einer Universit t Hilfs information und Zusatzinformation sind die Angaben zu den angeforderten Kursen oder zu den neu angebotenen Kursen Damit kann der Gesch ftsvorfall so wie in Bild 28 dargestellt werden os Fintrag Kontrolle Abschlu _ er Daten zur der Daten zur er Angabe zur Eintrag Lehrver Lehrver Lehrver anstaltung anstaltung anstaltung Bild 28 Gesch ftsvorfall Erstellung eines Angebotes f r eine Lehrveranstaltung Diese Graphik kann auch durch weitere Einzelschritte untersetzt werden Anstelle der graphischen Darstellung kann auch eine tabellarische Darstellung gew hlt werden Gesch ftsvorfall Eintrag einer Lehrveranstaltung nach Aufforderung Ausl ser Organisatorische Einheit Hilfs und Zusatzinformation Aufforderung f r Beauftragten Lehrstuhl Kurse Studieng nge R ume T tigkeiten f r 1 Eintrag Beauftragter des Lehrstuhles Hauptinformation a
367. utzt wird und die Transaktion erst dann abgebrochen wird wenn auch die kompensierende Transaktion nicht zum Erfolg f hrt sowie e Ersatztransaktionen Pi contingented_by Ps bei denen bei Auftreten eines Fehlers der Transaktion P die Transaktion P auf den Beginn zur ckgef hrt wird und anschlie end T ausgef hrt wird so da die Gesamttransaktion nur dann abgebrochen wird wenn sowohl P als auch P gt nicht zum Erfolg f hren Eine einfache Transaktion ist eine Folge P 01 02 03 0m von Basismodifikations und Retrieval Operationen ber dem Datenbankschema ER IT 1 lt i lt m Ner mit T Ur U7 f r 1 m Transaktionen k nnen auf einen Datenbank Zustand ER sequentiell angewandt werden und f hren zu einer Transition Om 02 01 ER Der Effekt der Anwendung einer Transaktion P auf ER ist definiert als Transformation die die Integrit tsbedingungen erh lt d h P ER Ler UUZ Er Damit kann eine Transaktion als integrit tsinvariante oder konsistenzerhaltende Zustandstrans formation verstanden werden Sie stellen daher eine besondere Form von Programmen dar Wir nutzen als Ausf hrungsmodell das Zustandsmodell in Bild 29 Eine Transaktion ist entweder inaktiv oder aktiviert oder beendet EOT Eine aktivierte Transaktion ist beim Bereitstellen al ler ben tigten Ressourcen BOT oder in der Bearbeitung oder bereit zum Abschlu Commit wobei dann die G ltigkeit
368. verf gen und deshalb einer Transaktionssemantik unterliegen Ein entfalteter Workflow ist ein vollst ndig instantiierter Workflow Alle Parameter eines entfalt baren Workflow sind mit entsprechenden Werten belegt In Bild 30 wird die Beziehung zwischen einem generischen Workflow und einem entfalteten Workflow dargestellt Fin entfalteter Workflow ist demzufolge ein Durchlauf oder eine spezielle Instanz eines generischen Workflows Bild 30 Generische und entfaltete Workflows Komposition von Workflow Feldern zu Programmen Auf Seite 68 wurde bereits die Workflow Maschine eingef hrt Oft erscheint es einfacher eine al gebraische Notation mit abgeleiteten Operationen zu verwenden Obwohl die Workflow Maschine zur Komposition der Workflow Felder ausreicht wollen wir im Abschlu noch eine algebraische Sprache anf hren Diese Sprache harmonisiert mit der Algebra die wir SiteLang verwenden Ein atomares Workflow Programm ist ein Workflow Feld Einfache Steueranweisungen sind die sequentielle Ausf hrung bei der Workflow Programme sequentiell nacheinander ausgef hrt werden wobei die Semantik des ersten Programmes die Semantik des zweiten Program mes erg nzt und das leere Programm entsteht wenn die Vereinigung der Semantik zum ae 864 ge 78 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 5 FUNKTIONALIT T parallele Verzweigung N bei der Programme parallel ausgef hrt werden k nnen und das ter miniert wenn bei
369. von Materialien und Dokumenten mit unterschiedlicher Sichtbar keit und unterschiedlichem Recht auf Einsicht Funktionen zur Unterst tzung der Zusammenarbeit von Mitgliedern der Gruppe untereinander bzw mit den interessierten Akteuren und Funktionen zur Archivierung der Materialien mit unterschiedlicher Einsicht in die Dokumente je nach Rechten und je nach Freigabestatus Diese Funktionsmenge ist bereits in einer Reihe von Anwendungen in generischer Form entwickelt worden So kann z B Das CPAN Verzeichnis zu Perl Anwendungen auch zur schnellen Entwicklung der erforderlichen Funktionalit t f r Sichten Suiten herangezogen werden Parametrisierte Anpassung an den Akteur Um Benutzern in ihren Rollen entgegenzukommen sollen Content Objekte in gewissem Ma e an folgende Dinge adaptierbar sein e an den Benutzer insbesondere an das Benutzerprofil die Sprache seine Kenntnisse und Fertig keiten seine Pr ferenzen e an das Benutzungsportfolio d h die Arbeitsaufgaben des Benutzers e an die Arbeitsumgebung des Benutzers insbesondere die technische Infrastruktur wie Hard und Software der Arbeitsplatzrechner die Kommunikationsinfrastruktur und e die Benutzungsgeschichte Eine solche Anpassung ist nicht im allgemeinen Ma e m glich Ein Sichtenschema ist jedoch parame trisierbar und im Rahmen dieser Parametrisierung an den konkreten Kontext adaptierbar Dazu erweitern wir die Spezifikation der Content Typen Anwendbare Abstrakti
370. weitere Perspektiven erweitern und zugleich die obigen Be ME un l o s s URL 01 s uma PET S DL ar ne INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 141 Information Story Metaphern Benutzer zur Story Metaphern Darstellung zur Informations 4 und Funktiona darstellung it ts Daten Prozesse ne Content Funktionalit t Repr sentation Repr sentation der Daten der Prozesse Y Technische Umgebung des Benutzers Layout Nutzun gsraum Playout Bild 56 Dimensionen des Gestaltungsrahmens In der Dimension des Benutzers wird der Benutzer entweder als Akteur charakterisiert oder mit sei nem Profil und Portfolio angegeben Einbezogen wird das Polarit tenprofil Ableitbar ist dann die Zielgruppe und die erforderliche Anpassung In der Dimension der Daten werden die erforderlichen Sichten betrachtet In der Dimension der Datenrepr sentation werden Parameter zur Gestaltung der Oberfl chen wirk sam wie e Form und Farbe Kontrast und Rhythmus und e Struktur und Komposition eingesetzt In der Dimension der Prozesse werden die Abl ufe der Story betrachtet In der Dimension des Proze repr sentation werden die entsprechenden Implementationen der Stories dargestellt In der Dimension der technischen Umgebung des Benutzers werden die Potentiale der Verbindung der Technik des Benutzers und der Server Technik dargestellt Diese Po
371. wir f r das obige Beispiel an da die Zeit essentiell f r InGruppe ist d h Key InGruppe Person Gruppe Zeit oder Key InGruppe Person Gruppe Zeit Funktion Weiterhin kann z B gelten Key Vorlesung Kurs Semester Semester Raum Zeit Semester Dozent Zeit Schl ssel folgen der Komponentenkonstruktion und k nnen auch f r einen Teil gelten z B Name Vornamen lt Vorname use gt FamName Mindestens ein Schliissel wird tiber die Komponente an den Relationship Typen vererbt Funktionale Abh ngigkeiten sind eine wichtige Gruppe von Abh ngigkeiten Eine funktionale Abh ngigkeit R X Y ist f r einen Typ R und Teilmengen X Y seiner Elemente definiert Sie gilt in einer Klasse RC falls die Gleichheit von Objekten o o aus R ber X die Gleichheit ber Y f r o o impliziert Funktionale Beziehungen von Attributgruppen in unserem Beispiel sind geplanteLV Semester Zeitrahmen Raum Studiengang Professor Kurs geplanteLV Professor Semester Zeitrahmen Kurs Raum angeboteneLV Semester Kurs Professor Kardinalit tsbeschr nkungen werden als kombinatorische Beschr nkungen in der min max No tation und der Partizipations Semantik als Paar von Kardinalit ten verwendet Damit unterscheidet sich unsere Notation von der Lookup Semantik die z B UML verwendet Die letztere kann jedoch in einer n m Notation ebenso mitgef hrt werden Wir betrachten hi
372. wird Ein DBMS sollte man nicht benutzen e wenn ein hoher zus tzlicher Aufwand entsteht e durch hohen initialen Aufwand f r Hardware und Software bei geringem Nutzen durch den sp teren Betrieb e durch hohe Allgemeinheit der vorhandenen Funktionen und e durch die Einf hrung von Algorithmen zur Unterst tzung von Sicherheit konkurrierenden bzw parallelen Betrieb e wenn die Anwendung und die Datenbank eher einfach sind e wenn Real Zeit Forderungen nicht vom DBMS unterst tzt werden k nnen und e wenn kein Mehrfachparallelzugriff auf Daten vorliegt Das Skript beabsichtigt nicht eine vollst ndige Einf hrung in die Datenbank oder zumindest in die Datenbankentwurfsliteratur zu geben Das Literaturverzeichnis wurde bewu t kurz gehalten Die Referenzen in Tha00 und Tha91 sowie in GMUVVOO und FvH89 sind stattdessen f r weitere Studien zu verwenden Wir gehen in diesem Skript davon aus da der Leser bereits grundlegende Begriffe der Datenbanktechnologie kennt Eine Reihe von Fachbegriffen die standardisiert verwendet werden werden deshalb nicht nochmals eingef hrt 10 Dieses Skript konzentriert sich auf die Spezifikation der konzeptionellen Benutzer Gesch ftproze und strategischen Schicht Deshalb werden Aspekte der Darstellung auf logischer oder physischer Schicht vollst ndig ausgelassen F r die Spezifikation von Strukturierung und Funktionalit t auf lo gischer Sicht verweisen wir auf Tha03 Wir wollen k
373. wobei die bergebenen Ob jekte nur innerhalb des Kollaborationsvertrages ver ndert werden d rfen Meist ist eine nderung und ein L schen auf der exportierenden Datenbank untersagt Mit der Vererbung der Objekte an andere Datenbanken werden Objekte mit einer sehr langen Lebenszeit versehen Die Geschichte der Ver nderung wird dann in den vererbten Varianten fortgeschreiben Facility Management Systeme werden in sehr unterschiedlichen Bereichen angewandt wie im Baubereich f r Patienteninformati onssysteme im Verwaltungsbereich und bei Kunden Management Systemen Sie sind eine spezifische Form der evolution ren Datenbanksysteme Neben inkrementellen Datenbankssystemen sind auch Ar chivdatenbanksysteme als evolution re Datenbanksysteme bekannt Das Denda Projekt Dynamic Environmental Databases war Bestandteil des DFG Innovationskollegs Entwick lung und Einsatz dynamischer Datenbanken zur Absch tzung des kologischen Entwicklungspotentials im Lausitzer Braunkohlerevier Die unterschiedlichen Gesichtspunkte auf Umweltdaten die unterschiedliche Granularit t der Da ten die unterschiedliche Genauigkeit der Daten und die unterschiedliche zu erreichende Funktionalit t erlaubte keine vollst ndige Integration der Daten Mit dem Standardisierungkatalog zur integrierten Forf hrung konnte eine weitgehen de kollaborative Arbeitsweise erreicht werden Das Nichteinhalten der entwickelten Standards im Fortf hrungsprojekt Sonderforsch
374. wohl ein Datenbankentwurf immer f r eine bestimmte Umgebung und damit f r eine bestimmte Plattform durchf hrt wird sollte der Entwurf zuerst die Anwendung ad quat widerspiegeln und zuletzt erst durch die Implementationseinschr nkungen der gew hlten Plattform getragen werden Ein solcher Entwurfszugang ist erst durch die Entwicklungen der Datenbanktechnologie und der theorie w hrend der letzten 10 Jahre erm glicht worden Es gibt erst in Ans tzen methodische Umsetzungen auf dem internationalen Markt In diesem Skript stellen wir eine Zugang vor der auf tiefliegenden theoretischen Erkenntnissen beruht Es ist in diesem Skript nicht unser Ziel die Datenbanktheorie in aller Tiefgr ndigkeit vorzu stellen sondern eine Methodik zu entwickeln die auf den Erkenntnissen dieser Theorie beruht diese aber nicht vordergr ndig verwendet Viele der Tips in diesem Skript haben Lehrs tze im Hintergrund Wir versuchen weiterhin die Fallen und Untiefen die mit ungeschickten Methodiken verbunden sind zu vermeiden oder zu umschiffen Dadurch wird auch eine Reihenfolge der Entwurfsschritte mit dik tiert Es gibt eine umfangreiche Literatur zum Datenbankentwurf auf der Grundlage des relationalen Modelles Das relationale Modell eignet sich jedoch nur f r einige Entwurfsphasen Die Semantik und der Zusammenhang zwischen den relationalen Schemata ist nur relativ umst ndlich und abstrakt darstellbar Das damit erforderliche Abstraktionsniveau berfordert a
375. zur Infrastruktur wird durch Datenbanksysteme gut unterst tzt Ein gut entwickeltes Datenbanksystem erlaubt die Pflege der Strukturierung und stellt die entspre chende Funktionalit t f r die Prozesse zur Verf gung Ein Benutzer sieht ein Informationssystem aus einer anderen Sicht Ihm wird ein Interaktionsraum zur Verf gung gestellt Die Benutzung des Syste mes findet im Rahmen des Story Raumes statt Durch Content Typen werden der Interaktionsraum und das Datenbanksystemes zu einem Informationssystem verbunden Wir werden im weiteren se hen da Content Typen eine komfortable Erweiterung des Sichtenkonzeptes f r Informationssysteme darstellen Ein Aspekt der nicht vernachl ssigt werden kann bislang aber nur auf strukturellem Niveau behandelt wurde ist die Verteilung Es sind dazu eine Reihe von Ans tzen bekannt Dienste in verteilten Systemen berwinden die r umliche Trennung von Systemen durch eine Funktio nalit t zur Daten bertragung und eine zeitliche gemeinsame Taktung der Datenspeicherung Es k nnen in diesem Zusammenhang Dienstgeber und Dienstnehmer unterschieden werden In e z le Se RE PN 0 a re 00 Ane 0 38 a Lk CN 42 ii 3 PERNE SMe SEHEN OR RENNEN INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 27 Lokalisierungsabstraktion 4 unterstiitzte Sichten Funktionalitat l Taie Sichten Container 2 Benen Informationseinheiten Akteure A A Filtrierung zugelassene Konstrukt
376. zur induktiven Konstruktion von komplexeren Konzepten aus bereits konstruierten oder Basiskonzepten die meist als Konstruktionsmethodiken verstanden werden und e Konsistenzregeln wie Integrit tsbedingungen und die Normalisierung erlauben eine Siche rung der Qualit tsanforderungen Einbettungsregeln erm glichen eine Integration in den bereits vorhandenen Entwurf unter Ber cksichtigung von Priorit ten Anwendbarkeitsregeln etc Zur Darstellung von Strukturierung und Funktionalit t k nnen verschiedene Repr sentationsme chanismen gew hlt werden Darauf aufbauend sind verschiedene Entwurfsszenarios m glich Datenstrukturgetriebener Entwurf Es wird zuerst die Struktur der Anwendung dargestellt darauf auf bauend die Funktionalit t und die Interaktion Dieser Zugang wird am h ufigsten im Informa tionssystementwurf angewandt Proze orientierter Entwurf Es werden zuerst die Prozesse und die erw nschte Funktionalit t der An wendung dargestellt und auf dieser Grundlage die Struktur und Interaktion Dieser Zugang wird im Rahmen der Softwaretechnologie angewandt er ist aber f r den Datenbankentwurf in dieser Auspr gung wenig sinnvoll Architekturdominierter Entwurf Es wird zuerst ein Bauplan des Informationssystemes anhand der Anwendung abgeleitet Die Architektur basiert auf Komponenten und Assoziationen zwischen den Komponenten Es werden die einzelnen Komponenten unter Ber cksichtigung ihrer Asso ziationen und da

Informationssystem-Entwicklung

Contents

Download Pdf Manuals

Related Search

Related Contents