Home

Informationssystem-Entwicklung

1. e Tempus zur zeitlichen Relativierung Pr senz Perfekt Plusquamperfekt etc Modus zur Bewertung der Modalitat 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 ablauf 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 Fin Konzeptfeld ist ein generisches Konzept aus dem ein Konzept durch Instantiierung einer Reihe von Merkmalen abgeleitet wird Dieser Zugang entspricht
2. 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 Storyraum Szenen Dialogschritte und Szenario Wir unterscheiden zwischen dem Teil eines Systemes der f r den Benutzer sichtbar ist und den in ternen Teil eines Systemes das 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 St 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 intensionale Logik e Ein Akteur stellt die Beobachtung in Beziehung zu den Aufgaben die er gerade l sen m chte INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 121 e Der Output wird in Beziehung gesetzt mit einer Umgebung bzw
3. 7 Der Struktur Funktions und Semantikentwurf wird integriert durchgef hrt 8 Durch bersichtliche Repr sentationstechniken 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 l Wird das richtige Produkt erstellt Modell A Verfeinerung Verifikation Qualitatsforderungen Wird da
4. Die Semantik einer Transitionsregel wird durch einen Kalk l mit Regeln der Form Voraussetzung Voraussetzung Bedi Folgerung es definiert Wir verzichten hier auf die vollst ndige Angabe der Semantik und verweisen auf die Literatur Als Beispiel fiihren wir die folgenden Regeln an ohne auf den Beweis dieser Regeln einzugehen yields P R U yields Q ER V 2 UUV konsistent yields DO P PAR ER 6 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 C x gt al U 2 wobei a ar yields LET z t IN P DO P ER U Ya I yields P ER le al Ua bei I d ERE yields FOR ALL x WITH DOP ERC C eth wobel range x 6 Der Wertebereich range z ER C ist definiert durch die Menge o ER HER true yields P ERS a U bei yields CHOOSE x WITH DOP ER U wobei a range x fall OER 0 yields CHOOSE x WITH DO P ER 0 alls range x amp yields P ER U yields Q ER U V yields DO P Q ERF U V yields P RC U yields DO P Q R U falls U konsistent ist falls U inkonsistent ist yields SKIP ER wobei 1 f s lE
5. Die drei P s von Workflow Modellen sind Prozesse als das Kernst ck der Spezifikation Politiken und Anwendungsstrategien und 64 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 5 FUNKTIONALITAT Praktiken der Anwendung die spezifische Seiten zum Ausdruck bringen P r die Verhaltensmodellierung ergeben sich neue Modellierungsforderungen 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 Verfiigung Das ervveiterte ER Modell verfiigt 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 Pi Pz Pa zugelassen die ihrerseits wiederum aus Folgen von Transaktionen bestehen Die Semantik der geschachtelten Transaktionen basiert auf einem schrittweisen Abschlu der Komponenten Transaktionen F hrt eine der Komponenten Transaktionen zu einem Fehler dann wird die gesamte Transaktionen abgebrochen Au erdem sind zugelassen e kompensierende Transaktionen P compensated_by P bei denen bei einem Auftreten eines Fehlers die Transaktion zu einer Kompensation des Fehlers benutzt wird und die Transaktion
6. PREPRINT BTU INFORMATIK I 15 2003 Vorstudie Storyentwurf Stories Feinstudie Szenenentwicklung Plot Entwurf Szenenbeschreibung Szenenraum x Implementation Szenenausschm ckung nwendungsgebiet Lastenheft Diskurs flichtenheft Handlungsrahmen Pr sentations raum KAPITEL 7 INTERAKTIVIT T Anwendungsschritt a Ereignis bs Storyboard Thema Dialogschritt Drehbuch Arbeits oberfl che Inszenierung Bild 39 Die Arbeitsprodukte im Abstraktionsschichtenmodell f r den Storyraum Dialogaspekte INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 107 Aufgaben und Zielen im Groben Der Handlungsrahmen ist mit der Darstellung der Motive und Ziele im vorigen Schritt bereits skizziert Noch ehe ein Drehbuch erstellt wird mu zumindest f r den Dialogteil ein Entwickler wissen 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 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
7. 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 runnig activities basieren auf einem erweiterten ECA Mo dell Sie verwenden eine Menge von Ausf hrungsschritten die rekursiv andere Trans aktionen enthalten und Kontroll und Datenflu Skripte Es wird eine explizite Kom pensation f r Transaktionen vorgegeben Das Konzept wird durch eine Kommunikation zwischen den Ausf hrungsschritten unterst tzt Es sind 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 lokalen Systeme
8. Robustheit Skalierbarkeit und Dauerhaftigkeit 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 an die Arbeitssituation auch explizit modelliert werden INFORMATIONSSYSTEM ENTWICKLUNG IM CO DES
9. heit Gegebenenfalls werden Aspekte der Verteilung 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 anst
10. schiedlichen 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 und die Handlungsabl ufe Sie werden implizit vorgenommen z B durch eine Annahme zur ersten 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 dem praktischen
11. 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 Beniamin 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 and design for database applicati ons Prentice Hall Upper Saddle River 1998 M H Brackett Data sharing Using a common data architectu
12. 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 lt gt S2 GID and S1 GID S2 UID 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 REST
13. Computer Science Press Rockville MD 1983 INFORMATIONSSYSTEM ENTWICKLUNG IM Co DESIGN ZUGANG 8 185 Mok96 Mor03 MR92 MS95 Pae00 PBGG89 Pro72 Rah94 RG94 Rie99 Ris88 RS97 Sch96 Sim94 Teo89 Tha91 Tha00 Tha01 ITha02 Thao3 Tsa89 Web95 YTS 99 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 and A Netke editors Proc Process Modelling pages 256 275 Springer Berlin 1999 N Rishe Database design fundamentals Prentice Hall Englewood Cliffs 1988 O Rau
14. Container k nnen verfeinert werden e durch Instantiierung oder Adaption der Parameter e Vergr erung und Verkleinerung der Kapazit t Hinzuf gen von Integrit tsbedigungen und e Verfeinerung der folgender Operationen der Vergleichsfunktion bzw der Mustermenge der Auswertungsfunktion eval der Inspektionsfunktion inspect und der Auswahlfunktionen e sowie durch Verbesserung der Darstellung von e Abstrakten als Zusammenfassungen des Inhaltes der Content Objekte und e Erweiterung der Kuverts die wir im folgenden betrachten 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 eine Unterst tzung f r die Zusammenarbeit in Arbeitsgruppen erfolgen Damit hat ein Content Typ Arbeitsplatz auch die Zusammenarbeit in Arbeitsgruppen und die Publikation der Resultate der Zusammenarbeit zu gew hrleist
15. 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 mit einer Hinterlegungsstelle 178 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 9 DOKUMENTATION 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 Ge sichtspunkten und allgemeinen Anwendungsf llen anstreben ist das Komponenten Schema d
16. U T W und i H UDUT Wir bezeichnen die zeitweilige volle G ltigkeit mit R lp In I2 ZR Wir k nnen damit die G ltigkeit zwischen Phasen definieren a Die Formel a ist g ltig in R Ip und ZR falls R lp i fiir jeden Zeitpunkt 2 jedes Intervalls J des Zeitrahmens bezeichnet mit R lr ZR Fo In diesem Fall ist a eine statische Integrit tsbedingung falls yes minT S maxT S Die Formel a ist m glich g ltig in R lp und ZR falls f r ein i Uzerg 7 H a bezeichnet mit RC Iz ZR E 0a Besitzt ein Zeitrahmen ZR Unterbrechungen dann wird f r die Formel o keine Forderung erhoben Fin Zeitrahmen wird f r die Implementationsschicht direkt durch Phasen repr sentiert Damit kann die G ltigkeit von Formeln und die Zulassigkeit 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 ZRschit i e IN Uih GE DHkeEN und ZRpunkt i 2 E IN 0 sowie ZRyon IN IN x IN eingef hrt 72 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 5 FUNKTIONALITAT Transitionsbedingung Eine Formel o hei t Transitionsbedingung falls notwendig g ltig in allen Intervalle von Z Rschritt ist Wir notieren Transitionsbedingungen auch durch a 7 Allgemeine Vor und Nachbedingung Fin Paar von Formeln a
17. 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 geeignet 160 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 8 VERTEILUNG 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 unterschieden werden nach Proze charakteristika und Proze wissen Umfang des S
18. ltigt haben INFORMATIONSSYSTEM ENTWICKLUNG IM CO DES GN ZUGANG OBY 8 115 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 Differenzierungen nach Notenskalen fiir die Antonyme vornehmen sachlich romantisch konventionell originell niichtern 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 abgeleitet werden Bekannt ist z B nach KT95 das Fremdbild wie in Bild 40 stabil ld stark introvertiert ee extravertiert aggressiv gesellig hi labil Bild 40 Das Fremdbild des Bayern hnliche Profile sind auch f r andere Gruppen bekannt Mit
19. rfnissen von Kunden angepa t und konfektioniert verkauft werden Dabei wird nicht nur eine Datenbank an sich vermarktet 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 Akquisition Speicher Zugriff eS eee SS Ss eee en os en DB Dat Dlien Vaten Datenbank DB import 77 extraktorenl Ne Export 2 7 database En Werkzeuge u miming DE _Datenhank Warenhaus Client Bild 72 Die drei Komponenten eines Datenbank Warenhauses Das Input Interface kann auch als Legacy Interface bezeichnet werden Es werden sehr unterschied liche Datenbanken zum Einsatz kommen die z T auch schon vor l ngerer Zeit entwickelt worden INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 173 und auf anderer technologischer Grundlage basieren bis hin zu Datenbanksystemen der ersten Ge neration Der Speicher dient der Ablage dieser Daten auf ei
20. 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 auseinandersetzen 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
21. snle und v yields f s1 8n t Update I v yields P R U yields IF 6 THENP ELSE ER U yields Q R V yields IF THENP ELSE Q ER V yields P Hte 55 Ti T yields r t1 tw 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 verwenden falls true falls oer 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 R Ir und ihre Schnappsch sse S i R In o dom R i Ir o einf hren Gegeben seien eine Formel a ber R eine temporale Klasse RC Ir ber R und Schnappsch sse S 0 RC IR S i RO lh S maxT RC lp Wir k nnen nun eine Frf llbarkeit von Formeln analog zur Modallogik definieren Ein Zeitrahmen ZR besteht aus einem Paar T S
22. tigkeiten f r 1 Eintrag Beauftragter des Lehrstuhles Hauptinformation angeben 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 So f r jedes Objekt in der Datenbank Menge von Aktivit ten T f r jedes Objekt in der Datenbank Diagramm D C SX To U ToX So Vor und Nachbedingungen zu Aktivit ten Ve s f r s t So x To als Vorbedingung f r eine Ak tivit t und N t s f r 1 s 5 x To als Nachbedingung f r eine Aktivit t Damit kann eine Darstellung durch eine Hoare Logik VtN verwendet werden Spezifikation eines Lebenszyklus So To Fo Vo No 58 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 5 FUNKTIONALITAT 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 Objekt
23. 15 2003 KAPITEL 7 INTERAKTIVIT T Die Dimensionen des Gestaltungsrahmens Wir k nnen den Gestaltungsrahmen um weitere Perspektiven erweitern und zugleich die obigen Be trachtungen systematisieren Der Gestaltungsrahmen kann mit sechs Dimensionen separiert werden Information Story Metaphern Benutzer zur Story Metaphern darstellung zur 277 4 und Funktiona arstellung itats Daten Prozesse uz Content lt gt 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 des Daten werden die erforderlichen Sichten betrachtet In der Dimension des Datenrepr sentation werden Parameter zur Gestaltung der Oberfl chen wirk sam wie e Form und Farbe e 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 T
24. 8 VERTEILUNG Der Kollaborationsvertrag wie stellt dar welche Partner wer mit wem vvelche Dienstekomponenten vvas mit welcher Qualitat mit welchen Verantwortlichkeiten voraus auf welcher allgemeinen Vertragsgrundlage worauf 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 Typische Pr fmechanismen sind Pr fsum men der Kodierungstheorie und Hilfssi
25. 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 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 Funktionalitat wird durch Angabe der unterstiitzenden Systemfunktionen dargestellt Die Interaktivitat basiert auf dem Storyboard der Anwendung Der Stil der Kollaboration legt die vertraglichen Vereinbarungen fest Er wird durch 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 Kol
26. 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 stellung der Dienste des Kollaborationsvertrages und des Qualit tsvertrages unterlegt INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 179 Erganzende Festlegungen PW Es k nnen Festlegungen zum Prasentationsstil und der Benut zungsoberfl che Bildschirmlayout Drucklayout Tastaturbelegung Dialogstruktur ber 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 Dokumente der Aktionsschicht A sind das Anwendungsschema als Skelett AD mit einer Spezifikation der Anwendungstypen die Nut
27. Arbeitsgruppe haben zu der hier verwendeten 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 bereitgestellt als Container Objekt 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 INFORMATIONSSYSTEM ENTWICKLUNG IM Co DESIGN ZUGANG 8 105 Das verallgemeinerte Seeheim Modell Das DBIS Modell fiir Informationssysteme Informationssystem Pr sentations Story Raum komponente Stories Akteure Graphik Szenario Kontext basi
28. BTU INFORMATIK I 15 2003 KAPITEL 8 VERTEILUNG 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 Anwendungsdien nn bay fine Dun 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 kommerziellen Systeme befriedigt z B i
29. 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 Theorie 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 Rechte char 18 null
30. Beispiel sind die Relationship Typen InGruppe Person Gruppe 1 Zeit Von Bis Funktion 0 Direkt Voraussetz setztVoraus Kurs vorausges Kurs 0 0 Professor Person 4 Berufungsgebiet 0 Ein 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 Eine Relationship Klasse besteht aus Objekten des Relationship Typs die den statischen 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 G
31. 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 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 Die Erf llung einer Aufgabe erfolgt in Arbeitsablaufen 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 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 semantischen Rahmenbedingungen sind definiert durch e Bedingungen unter denen der Arbeitsvorgang ausgefiihrt werden kann und e organisatorische Randbedingungen INFORMATIONSSYSTEM ENTWICKLUNG IM CO DES GN ZUGANG By 6 119 Arbeitsabl ufe werden durch Aktivit tenfolgendiagramme beschrieben Sie bestehen aus einem Aktivit tstyp zur Kategorisierung
32. Die Zieltechnik beeinflu t in sehr starkem Ma e die Qualit t und auch die Implemen tierbarkeit von einzelnen Szenen Einheitlichkeit Neben Standardinteraktionen besitzen wir auch aus dem Inhalt abgeleitete Interak tionen 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 professionell zu ge stalten Fehlerrobustheit Eine Fehlbedienung darf weder zum core dump noch zu unkontrollierbaren Zu st 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 wie derholte 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 semantischen Be deutung zu versehen Darstellungsskalierung Je nach Akteur je nach vorhandenem Client oder Darstellungsmedium sind unterschiedliche Interaktionsm glichkeiten vorzusehen Offene Systeme Ein Informationssystem wird in immer st rkerem Ma e mit anderen Systemen in integrierter Form verwendet Deshalb ist der Output f r einige Standards mit aufzubereiten Erweiterbarkeit Ein Informationssystem beginnt aufgrund der nderungen in der Anwendung
33. Es kann seine Existenz unabh ngig von anderen beginnen und beenden Damit werden formale Handlungen des Existenzbeginns und endes grundlegend zur Umsetzung von Handlungen innerhalb der Datenbank Wir unterscheiden bei der Beschreibung der Funktionali 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 rung von Stored Procedures Triggern etc die in Modulen zusammengefa t werden INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 55 ee Produktfunktionalitat Motivations schicht Vorstudie Skizzierung Produktfunktio Lastenheft Funktionen 3 h ft Gesch ftsproze eschaftprozesse schicht Feinstudie Verfeinerung Arbeitsschritt Pflichtenheft Funktion Handlungen Aktions g schicht Entwurf Entwicklung Aktionen Nut zer Maschine konzeptionelle W
34. Funktionalit t von Informationssystemen Prozes se werden meist nur in einer rudiment ren Form 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 unterschiedliche Arbeitsweisen f r die Arbeit mit der Datenbank Werden die Oberfl chen erst I
35. 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 Studiengang m Studiengang Typus m Tupus Professor Professor from tKurs gehalteneLV Kurs t Person gehalteneLV geplanteLV angeboteneLV Verantwortlicher4LV Person Studiengang E Typus Professor gehalteneLV 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 Person l Kurs Semester L retrieve _ slice sort _ retrieve Studiengang retrieve Typus retrieve Bild 34 Content Typen zur Archivsicht auf gehaltene Lehrveranstaltungen Darstellung von Sichtenschemata Wir erweitern die Darstellung von ER Schemata wie bereits z T in Bild 34 verwendet Optionale Komponenten sind fiir Relationship Typen von S
36. Partitionierung 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 Daten k nnen auf verschiedene Art partitioniert werden wie in Bild 64 INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 161 Horizontale Partitionierung Daten werden horizontal zerlegt d h eine Tabelle oder Relation wird tupelweise zerlegt in verschiedene Teilrelationen und verschiedenen Medien zugeordnet In Bild 64 wird die Relation R durch Anwendung von Selektionsoperationen in drei Teilrelationen zerlegt wobe
37. Profil Repr senta tionsstil Emphasis Default 1 1 O V 1 n a Obligation Content objekt D Benutzung Rechte kategorie Rollen kategorie vir Aufgabe Bild 45 Repr sentation der Elemente von SiteLang Der Vorteil dieser Abbildung des Storyraumes liegt auf der Hand Es k nnen Anderungen jederzeit in einfacher Form eingebracht werden ohne sich direkt auf die gesamte Proze welt auszwirken 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 Storyraumes Eine Datenbank Unterst tzung ist nicht in jedem Fall f r den Storyraum 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 Contentobjekt und Dialogschritte beschrieben Dialogschritt Ein Dialogschritt ist die kleinste Story Einheit Sie erlaubt die Darstellung der Retrieval Sichten der bereitgestellten Funktionen einer Einschr nkung der involvierten Akteure auf ak tive Akteure und einer Steuerspezifikation mit Ereigni
38. Rekursion pe 0 falls s NULL f u f s falls s NULL H if s NULL Wir 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 STECO Id 3 e Summierung f r Klassen mit Nullwerten die durch die 0 ersetzt werden null _ sum STECO AO 3 e Summierung f r Klassen mit Nullwerten die durch die undef ersetzt werden null _ sum undef STECO hundet 4 Ublich ist die Anwendung der zweiten Option Zahlen der Objekte je nach Behandlung der Nullwerte F r Klassen ohne Nullwerte count sreco e F r Klassen mit Nullwerten count sreco null _ e Alternativ f r Klassen mit Nullwerten STECO hunder y 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 ZW minNULL STECNULL Id min mMaXundef 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 29 sum 7 sum count count 7 count 2 INFORMATIONSSYSTEM ENTWICK
39. Rollen der Akteure und e Sichtentypen Das Ubergabefeld erlaubt den bergang von Objekten einer Sicht eines Akteurs auf Objekte ei ner Sicht eines anderen Akteurs Es kann der Kontext und auch der Vertrag des Uberganges zus tzlich 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 Das Bulkfeld ist an Parameter gebunden f r die das Workflowfeld insgesamt abgearbeitet wird INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 77 Wir haben diese Theorie der Workflow Felder mit den Kompositionsoperationen fiir Workflows har monisiert damit eine entsprechende Entfaltung der komplexen Workflow Felder vorgenommen werden kann Generische Workflows und entfaltbare Workflows Workflow Felder erlauben oft eine einfache Darstellung durch entsprechende Ausdriicke K nnen Workflow Felder durch eine Stammform spezifiziert werden dann nennen wir diese Stammform gene rischer Workflow Generische Workflows stellen ein Analogon zu generischen
40. Schritte wie in Bild 33 darstellen INFORMATIONSSYSTEM ENTWICKLUNG IM CO DES GN ZUGANG Motivations schicht Gesch ftsproze schicht Aktions schicht konzeptionelle Schicht Implementations schicht Bild 33 Die Arbeitsprodukte im Abstraktionsschichtenmodell f r die Sichtenentwicklung Produktdatenskizze Vorstudie Skizzierung Sichtenskizze Feinstudie Darstellung Sichtenskelette Entwurf Sichtenentwurf ichtenschemata Implementation Transformation Sichten anfrage menge BY 6 nn Lastenheft Sichten 75 Pflichtenheft Sichten K Aktionssichtensuite Sichtensuite logische Sichtensuite Produktdaten ontologische Einheit erntyp Sichtentyp anfrage 83 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 Ausvahl 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 diesen Rah
41. Spezifikation der Dialogschritte und Dialogszenen Eine vollst ndige Beschreibung der Dialogschritte kann mit dem Arbeitsblatt erstellt werden INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 127 Unterstiitzung der Arbeitsgruppe Ejnreichen on gabe Mitglied Ho Deadli Rollen Verantwortlichkeiten Zeitbeschrankungen Ablauf 7 Einreichen eines Beitrages Phase Erstelle Beitrag Redaktionskommissionsmitglied Redaktionsperiode _ Gemeinsame ee Beitrage anderer B itrag 2 Art Existenz Giiltigkeit Beitrage zum Durchmustern Perso 4 peic private Funktionalit t Content Schreiben Einreichen evidieren Download der letzten Version Raum Arbeitsresultate iskussion der Beitrage Beitra Durchmustern vorhandener Beitrage Diskussionsraum Bild 50 Der Spezifikationsrahmen f r Beitr ge von Arbeitsgruppenmitgliedern Dialogschritt header Name Layout Titel Container Inhalt Text multimedia object Graphik Bild Video Audio Funktionalitat Operationen algorithmisches Objekt Anpassungsstil Finordnung in Hierarchien Adh sion Adaptation Interaktionsstil Steuerungstil involvierte 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 de
42. Systemes Die erstellten Komponenten werden an hand der Ziele evaluiert Es werden au erdem 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 herangefiihrt 13 Priifen der Systemsicherheit Wirtschaftlichkeit und Ergonomie Das System wird anhand von Qualit tskriterien wie 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
43. 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 MVielleicht sollte man eher das Small is beautiful in den Mittelpunkt stellen INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 137 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 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 Benutzer
44. auf Weiterhin kann im Entwicklungsproze ein Urteil wieder revidiert werden Unsere Vorstellung vom Modellierungsurteil haben wir in Bild 4 in vereinfachter Form zusammen gefa t Realit t Ausschnitt der Realit t Dinge der HE Realitat Begriff Pr dikator 1177 Kontext il Theorie Revisio Entwicklungs proze Schema als Resultat und Ausschnitt age eines Entwicklungs z 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 Ha
45. 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 logie kann ein Wort in allen seinen Variationen dargestellt werden durch 74 B THALHEIM PREPRINT BTU INFORMATI
46. ber den Namen des Pro grammes durch eine Instantiierung der formalen Parameter durch aktuelle Parameter durch die Angabe des Nutzers und der Steuerungsumgebung angegeben Die Angabe des Nutzers der ein anderes Programm sein kann oder ein Benutzer erfolgt nicht nur f r Abrechnungs sondern auch f r Benachrichtigungszwecke Die Steuerungsumgebung er laubt eine detallierte Angabe der Steuerung der Priorisierung der Ausf hrung auf an deren Knoten Zur Angabe kann au erdem eine Spezifikation der Ausnahmenbehandlung insbesondere f r den Fall eine konkurrierenden Abarbeitung geh ren Steuerungsspezifikation Zur Steuerungsspezifikation unterscheiden wir drei R ume e Im Nachrichtenraum werden sowohl die Benutzernachrichten als auch die Systemnach richten verwaltet Im ersteren Falle sind Informationen gesetzt zur Sichtbarkeit No tifikation und zum Datenstrom des Benutzers im letzteren zur bertragung Signoff und Signon Nachrichten e Im Parameterraum werden alle aktuellen Parameterzuweisung 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 INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 67 e Im Ressourcenraum wird die Allokation von Daten Routen Knoten etc zu den aktu ellen Prozessen dargestellt Weitere Modelle sind m glich
47. ber der Menge G aller Strukturen definiert mit folgenden Eigenschaften A x X fir jedes X 6 A A1 An B B Bn falls f r ale i 1 lt i lt n lt A lt Bi gilt A A A1B falls Ay B gilt e 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 2 gilt auch Y Ux Z Z sowie Y Nx Z Y 2 A 2 und Z x Y A falls X A B Y A C Z A D dann gilt auch Y ox Z 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 Aj An Y A Bi Bn Z Ci Cn dann gilt auch A By OA Cissa Br OA Cn f r o mU A 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 oder der Form Y oC fir Y lt X a dom Y o C C dom Y und alle Vergleichspr dikate die ber Y definiert sind F r viele Typen sind dies lt gt lt gt Ein Objekt o 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 9 Pradikate dann sind es auch aA 6 a V 9 und a Ein Objekt o e
48. das System Wenig oder keine Redundanz verringert den Pflegeaufwand der durch das System zu leisten ist Damit werden 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 ma einfacher gepflegt erweitert und verstanden werden 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 t
49. definiert und gilt in einer Klasse Relation ber R dargestellt durch R X Y Z 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 das 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 R mit o xuy o und o o Eine n tzliche allgemein bekannte Eigenschaft von mehrwertigen Abh ngigkeiten ist die Dekompositionseigenschaft Es gilt R X Y Z genau dann wenn sich RC vertikal dekomponieren l t nach X UY und X UZ d h formal R R X UY M RX uz Weniger bekannt ist dagegen da die G ltigkeit der mehrwertigen Abh ngigkeit zu einem neuen quivalenten Schema f hrt bei dem der Typ R ersetzt wird durch die dekomponier ten Typen wie in Bild 24 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 Ein Datenbank Schema ER besteht aus einer Menge von Typen T Uz 3 und globalen statischen Integrit tsbedingungen Xer Unsere Strukturierungssprache unterst tzt das Abstraktion
50. denen die assoziierten Objekte zu einer Objektmenge er fa t werden k nnen und die 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 zu komplexeren Objekten umgeformt werden k nnen 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 fiir eine begleitende Navigation f r die Oberflachen der Benutzer erstellt Die Assoziations funktion erlaubt die Erstellung eines Profils mit einer neuen Sicht Bearbeitungsfunktionen erm glichen die Bearbeitung von Daten aus der Datenbank die Bearbeitung von Sichtendaten und von pers nlichen Daten der Benutzer Datenbank Modifikationsoperation
51. die Struktur einer Anwendung die gesamte Funktionalit t und Benutzbarkeit durch den 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 meist als Urteil ber die darzustellende Realit t ein 12 B
52. die eigentlich durch Attribute dargestellt werden ein Entitytyp eingef hrt werden Attributnamen dienen einer intuitiv verst 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 von logischen Datenmodellen repr sentieren kann 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
53. diesen Profilen k nnen Portfolios f r die einzelnen Benuutzergruppen 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 ngt von der intuitiven Erkenntnis da die vorhandene Information zur L sung einer Aufgabe nicht aus reicht da das Wissen zu gering ist da die Information nicht oder nicht so schnell generiert werden kann aus vorhandenen Wissen und Informationen da die Unsicherheit Unbestimmtheit Unsch rfe oder die Widerspr che nicht anders aufgel st werden k nnen Wir unterscheiden den Informations bedarf 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 Informationsdiensten aus den folgenden Kategorien bereitstellt Informationsdienste im allgemeinen Interesse orientieren sich insbesondere analog zum Zeitungen auf die Bereitstellung von Informationen des t glichen Alltags Beispiele sind Wetterdienste Ver anstaltungskalender Regionalinformationen Sportinformationen un
54. 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 Contentsuiten besitzen eine verschiedene Bedeutung Temporale Aspekte Contentsuiten entwicklen sich ber die Benutzungszeitr ume Die Zeita spekte k nnen konzeptionell mit den Contentsuiten verbunden werden Context Contentsuiten besitzen einen Kontext der sie nicht in Konflikt miteinander bringt 150 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 8 VERTEILUNG Bedeutungstreue kann durch eine Theorien und Modellierungswelt und eine abgestimmte Begriffslandkarte unterstiitzt werden Die Entwicklung einer Spezifikationsmethode zur Un terst tzung der Bedeutungstreue ist jedoch noch ein Forschungsthema Heterogenitat ist in verteilten Systemen die Regel Sie tritt in unterschiedlichen Facetten auf Heterogenitat der Netzwerke Heterogenitat der Plattformen verursacht durch unterschiedliche Betrie
55. eine spezifische Form des Drill down Das Roll up beginnt mit einem speziellen Begriff und hangelt sich ber die Gattung oder Kategorisierung zu den gewiinschten Begriffen Das Umschauen oder Kramen ist eine Suche mit einer Drill down Funktion zur Verfeinerung Die Formulierung eines vollst ndigen Suchausdruckes z B mit einer SQL Anweisung ist eher die Ausnahme 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 erzeugt durch Instantiierung des Kontextes technische Umgebung Aufgabe Geschichte Umst nde und durch Adaption an den Benutzer Profil Portfolio Diese In formation 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 Kontextraumes 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 Rec
56. einen Kontext im allge meinen Damit wird durch den Akteur eine andere Beziehung eingegangen als dies bei der Modellierung von algorithmischen Systemen tiblich ist Mensch Maschinen Schnittstellen erfordern deshalb eine explizite Beriicksichtigung 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 gorithmisch beschreibbar R Benutzer A Benutzer A 0 _ IO I0 A nyyetidi 2 es Inter Benutzer A Inters stem Inter Benutzer B face 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 der auch das System ohne Benutzerinteraktion seinen Zustand ndert wobei dies ggf auch f r einen Benutzer nicht mehr verstehbar oder nachvollziehbar ist Das Verhalten wird noch weniger einsichtig wenn das System seinen Zustand aufgrund
57. 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 Es wird eine Produktdatenskizze mit einer Grobstrukturierung der
58. erst dann abgebrochen wird wenn auch die kompensierende Transaktion nicht zum Erfolg f hrt sowie Ersatztransaktionen P 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 P gt 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 oz 03 0m von Basismodifikations und Retrieval Operationen ber dem Datenbankschema ER T 1 lt i lt m Ner mit T Ur Er f r l lt i lt m Transaktionen k nnen auf einen Datenbank Zustand ER sequentiell angewandt werden und f hren zu einer Transition Om 02 01 ERF Der Effekt der Anwendung einer Transaktion P auf ER ist definiert als Transformation die die Integrit tsbdingungen erh lt d h pero on n eyERS falls sat oxfoi 6R7 E Ber VUZ Dr 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 der st
59. explizite Darstellung einer Generalisierung Ein un rer Relationship Typ stellt dagegen eine Spezialisierung dar wenn INFORMATIONSSYSTEM ENTWICKLUNG IM CO DES GN ZUGANG Student Ob 6 Professor Semester Student Professor Semester Raum Kurs ire Voraus set Bild 19 HERM Diagramme mit und ohne Relationship Typen h herer Ordnung Kurs Semester Studiengang Vorschla Typus Zeit Vorschlag Nebenbeding Zeitrahmen Professor Person 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 Relationshiptypen 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 Darstellungsfor
60. 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 uf B 2B B 2K unde Vilnformation ggg kaufen KP2 K kaufen bzw C ustomer 2 kaufen Lern Sites BWlissen gKlemen KW 2 Klemen Information sites B2 formation 2G ast i formieren 7 informieren KToginformieren Arbeitsgruppen Sites A rbeitsgruppe 2 As A 2Ginformieren agieren Corporate ldentity Sites P rovider 7 2G shauen Unterhaltungs Sites nterhaltung 2 agieren GU 2 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 134 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 7 INTERAKTIVIT T Akteure werden mit ihren Kollaborationsbeziehungen dargestellt Sie umfassen Kooperationsbeziehungen Koordinationsbeziehungen und 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 untersetzt in Rechte zu Ko operation Koordin
61. ist f r Pradi kate o und Ersetzungsfamilien y o R ist definiert durch die Menge RP minu g 0 0a RC Eine oft verwendete Definition basiert auf dem Ausdruck RC og RC U R Da mit wird jedoch ein anderer Effekt erzielt Gilt z B a R und Ro x 0 dann wird die urspr ngliche Intention verloren Dieser Finf hrung liegt jedoch die oft praktizierte Ersetzung von Update o o durch die Folge Delete R o InsertUpdate R 0 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 RO x S 0 0 o0 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 R auf R durch eine Reduktion aller Objekte von R auf den R Mitunter wird auch die Notation RC R anstelle von Tip RC verwendet Schachtelung Es sei R ein Element von R Dann wird die Schachtelung vg R von R 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 o R r R A o R o Ri o RC NoTRNa X RA Eh Entschachtelung Es sei R ein Mengenelement von R Die Entschachtelung qz R einer Klasse definiert einen neue
62. labo tionenl neh muni schirm Infor Funk gruppe ritat 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 dienen der Kontrolle INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 145 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 Es kann die Intensit t und die Dominanz der Eigenschaften 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 Akteure d
63. mit einem Verpackungsumschlag in das verpackte Content Objekt inte griert werden Funktionen wie Markierungsfunktionen sind durch Sichten die ber materialisierten Sichten entstehen darstellbar Deshalb ist keine Neuentwicklung notwendig sondern nur ein Spezifi kationsrahmen zur Verf gung zu stellen Dieser Rahmen kann verallgemeinert werden zu generate MAPPING VARS AUSGABESTRUKTUR from DATENBANKTYPEN where AUSWAHLBEDINGUNG represent using ALLGEMEINER PR SENTATIONSSTIL amp ABSTRAKTION GRANULARIT T MASSEINHEIT PR ZISION amp ORDNUNGEN DER PR SENTATION 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 Sichtensuite in einem Vierschritt Verfahren die Spezifikation erstellen Das Resultat dieses Spezifikationsprozesses nennen wir Content Typ Eine Instanz eines Content Typs nennen wir Content Objekt Fine 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 gestellt Sie enthalten die Spezifikation der Strukturierung der dem Akteur zur Verfiigung gestellten D
64. ngenden Darstellung der Daten sowie dem technischen Workflow der wiederum auf Systemprozessen basiert 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 von den 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 Da tenbanksysteme hat sich diese Architektur sogar mit einer Verallgemeinerung zur Arch Architektur noch nicht durchgesetzt Vorstellbar ist aber nach Sch96 auch eine Erweiterung der Pr sentations komponente zu einem Dialogmanagementsystem Die Arbeiten der DBIS
65. nicht jedes Sichtenobjekt einem Datenbankobjekt zugeordnet werden kann mu deshalb f r eine Modifikation der Datenbank eine andere Funktion zur Verf gung gestellt 26 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 2 SPRACHEN Tina Musterfrau Benutzer zuf lliger in der Nutzer DBMS Falle A parametrische relationales HERM Datenbank Such Ausdr cke schema anforderung Such Anfrage SQL 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 D
66. 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 terst tzt werden Dazu werden Techniken der Sichten Kooperation genutzt 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 Fingabe 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 werden und in den Arbeitsraum eingebracht werden Integration in die Arbeitssichten In die aktuellen Arbeitssichten k nnen auch entsprechende Content Objekte den Parametern zugewiesen werden so da mit einer Importfunktion auch das aktuelle Content Obj
67. 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 138 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 7 INTERAKTIVITAT Auswahl der multimedialen Medien Ein Akteur sollte entsprechend seinem Benutzerprofil die Inter aktion und die benutzten multimedialen Formen selbst und evt auch dynamisch ausw hlen k nnen Die Gestaltung von Oberfl chen erfordert die Einbeziehung so unterschiedlicher Disziplinen wie Wahrnehmungspsychologie Ergonomie Soziologie Informatik Grafikdesign und Marketing in die Da tenbankprogrammierung In erster N herung k nnen die Gestaltungselemente Typographie Symbo le und Pictogramme Farbe sowie Proportion und Aufbau des Bildschirms betrachtet werden Hinzu kommen die Betrachtung der Eleganz und der Einfachheit der Organisation und visuellen Struktur Zuordnung von Widget Typen Sichtensuite Fenster Funktionalitat Men Operationsauswahl Strukturierung Konstantenfeld Datenfeld Gruppe Finfach Mehrfachauswahl Liste Tabelle Parameterfestlegung Strukturierung Schemata Name Typ Wertebereich Vorbelegungen o Reprasentationstypen Fenster Men Gruppe Konstantenfelder Datenfelder Operationsauswahl Liste Tabelle Standardwerte Benutzerpr ferenzen Umgebungsbeschreibung Stileigenschaften o Abb abst
68. 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 12 11 und 12 21 n 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 verbleibenden Typen gebunden INFORMATIONSSYSTEM ENTWICKLUNG IM Co DESIGN ZUGANG 8 103 Die Assoziierbarkeit von Typen der Schemata wird durch die Wertebereiche der Typen der Sich tenschemat begrenzt Typen T in G und T in z sind wertebereichsvertr glich falls dom T dom 13 gilt Es ist anzumerken da die Wertebereichsvertr glichkeit nicht auf eine Teiltypen Eigenschaft G11 N fai Go1 und in N fia S 2 f r die Morphismen der Sichtenkooperation reduzierbar ist Die beiden Schema Morphismen fi2 fG und f21 fK definieren eine Gleichungstheorie Wir k nnen vereinfachend annehmen da alle Typen Namen in den Schemata G und 6a verschieden sind Damit k nnen wir f r alle Typen 7 in die Gleichung T f 2 T und f r alle Typen T in OY die Gleichung Tz fa T2 zur Gleichungstheorie hinzuf gen Falls wir an einer vollst nd
69. tzt werden 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 DD Verwaltung einfach oder nicht existent Sere Steuerung der Parallelitat 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 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
70. und 6 hei t Vor und Nachbedingungen falls aus RC lr i ZRpunkt Da die G ltigkeit von RC la i 1 ZRpunkt OF folgt Wir notieren allgemeine Vor und Nachbedingungen auch durch a 8 Wird der Zeitrahmen durch die Anwendung eines Prozesses P oder Programmes P definiert dann schreiben wir a 2 Temporale Formeln sind mit RC Ir i ZRvon O8 bzw RC Ir i 2 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 Vy immer in der Zukunft Vp immer in der Vergangenheit einmal in der Zukunft Jp einmal in der Vergangenheit U a 9 a ist g ltig bis 9 g ltig wird Weiche deontische Integrit tsbedingungen werden f r Z Rgchrit eingef hrt Obligation Eine Obligation Oa ist durch die G ltigkeit von RC Iz 1 ZRgehritt Oa definiert Erlaubnis Eine Erlaubnis Pa ist durch die G ltigkeit von CRS ih 1 ZRgchritt Oa definiert Verbot Ein Verbot Fo ist durch die G ltigkeit von RY lr 1 Z Rschritt 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 2 Oa Obligationen umfassen Erlaubnisse KD3 Po Die Erlaubnis ist dual zu
71. 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 aufgebaut 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 xx 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 Pers nlicherArbeitsraum Parameter realisiert werden Damit steht eine allgemeine Technologie zur Realisierung beliebig komplexer Szenario zur Verfiigung Diese Technologie erlaubt auch die Generierung entsprechen
72. und mittelbar auf die Repr sentation der Daten und 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 Interaktivitat 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 Der 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 Spezifikation der Repr sentation der Daten 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 Auf Dar Kol Funk Wahr Kom Bild der der Ziel Pola Adap tion gabe stel
73. 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 von 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 Fxtra 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 Kooperation 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 Storyraumes und im Rahmen der Spezifikation der Verteilung dargestellt Es werden unterschiedliche Aspekte f r den St
74. voneinander sein Datensharing 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 fiir den konkurrierenden Zugriff tiber das Netz und e eine Transaktionsverwaltung Damit besteht ein verteiltes DBMS aus Rechnern die Knoten zugeordnet sind einem Kommunikati onsnetzwerk zur Verbindung der Knoten aus einem Netzwerk Hard und Software aus Transaktions prozessoren TP und aus Datenprozessoren DP INFORMATIONSSYSTEM ENTWICKLUNG IM Co DESIGN ZUGANG 8 159 TP TP rmKommunikationst gt 10 netzvverk 85 DP DP Lokales DBMS 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 sung besteht in der R
75. wie 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 e 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 wie lokale Variablen oder Parametervariablen besitzen dagegen nur eine Lebenszeit 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 kann 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
76. wird benutzt um die Annahme von Content Objekten zu verweigern oder auch dem Benutzer f r seine Spezifikation ein passendes Contentobjekt 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 a miz true falls dm M v lt m nm A w w Vur 1 vw L LAT ram false andernfalls Mit diesem allgemeinen Vergleich kann ein Container sowohl alle Elemente als nicht unterscheidbar betrachten M als auch alle Elemente genau unterscheiden M Alpht INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 97 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 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 Pradikat success eval t wird der Erfolg
77. 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 Aktionssichtensuite Eine Suite besteht aus eine Menge von Elementen einem Integrations bzw Zu sammenhangsschema und Obligationen zur Pflege des Zusammenhanges Die Aktionssichten 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 zusam menstellen Damit werden durch die Sichtenskelette alle Typen repr sentiert die f r den An wender eine Bedeutung haben Die Typen stellen eine Verfeinerung der Typen des Pflichtenhefts dar oder sind neu eingef hrt Die Aktionssichtensuite 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 wesentlichen Typen mit einschlie en so da dieser Entwurfsschritt analog zur Spezifikation des 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 werden Durch die Informationen aus dem Storyboard
78. 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 eine 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 Storyraum Dialogaspekte 106 Das Fremdbild des Bayern 115 Die Zusammenarbeit von Akteuren zum Erreichen von Zielen 2 117 Das Sicherheitsprofil von Akteuren 117 Algorithmisches Verhalten versus Mensch Maschine Verhaltes eines oder mehrerer Ak Teur an Gh ur ar aa a 777 121 De
79. 7T2 lt M T1 T3 f r Typen T T von types G und Teiltypen 77 7 von jeweils 7 75 e 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 unseren Modell sind die Hyperkanten hierarchisch Es existiert eine lexikographische Nummerierung Eii ip der Kanten in H so da F C E genau dann gilt wenn 7 der Beginn von 7 ist Die Wurzel ist der Knoten F3 Fine andere Darstellung kann auch analog zu Bild 21 mit dem erweiterten ER Modell angegeben werden indem die Rauten als Relationship Typen Folge an der jeweils dar unterliegenden Schale angeh ngt werden In diesem Fall wird ein Stern Schema erzeugt Meist wird jedoch eine vollst ndige hierarchische Strukturierung nicht m glich sein Dann erhalten wir ein Schneeflocken S
80. APITEL 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 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 Pradikatenlogik der ersten Stufe gegeben Deshalb lassen sich dann statische Integritatsbedingungen als Formeln der Pradika 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 Spezifikation der Struktur in Abh ngigkeit vom Typensystem mit de
81. 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 den 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 die 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 zugru
82. 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 Mit diesen Anforderungen erscheint es sinnvoll sich der Zug nge von Skriptsprachen zu bedienen Dadurch kann auch eine Realisierung von Containern mit den Mitteln von Skriptsprachen erfolgen Ein Container wird beschrieben durch eine abstrakte Zustandsmaschine 1 M opse Xe mit einem Namen zur Bezeichnung des Containers 96 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 6 SICHTENSUITE 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 Daten 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 Beglei
83. 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 des Computers an den Benutzer werden zum Abruf von Daten be nutzt Dabei kann die Struktur durch meist deterministische Ablaufdiagramme dargestellt werden Men s k nnen mehrere Optionen oder Funktionen darstellen aus denen der Benutzer ausw hlen kann Men s k nnen auch als Popup oder Klappmen 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 136 B THALHE
84. Ber cksichtigung ihrer Asso ziationen und daraus 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 Unabh ngigkeit der Repr sentation der Implementatierung 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 1 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 Prozess
85. Dialogablauf und die zugrundegelegten Funk INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 113 tionen und Daten Es k nnen zu wenig zu viel oder die korrekte Anzahl von wichtigen Fakten in den Entwurf eingehen Dies trifft insbesondere auch auf die Darstellung der Begleitinformation zu Zugleich werden die Vorkenntnisse der Benutzer mitberiicksichtigt 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 vorgerufen werden 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 Ausgestaltung 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 Quali
86. 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 kategorisiert werden in Teilabsichten die den Hauptabsichten dienen und Hauptabsichten Damit ergibt sich auch eine zeitliche Ordnung und eine Va riation in der Reihenfolge Dabei k nnen die Absichten gemeinsam dargestellt werden die sich einem gemeinsamen Zweck unterwerfen Gesetz von der Einheit des Zwecks Teilab sichten 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 diese Informationen f r die Gestaltung der Szenen Eine kluge und durchdachte 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 Entwick
87. HEMA 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 Sichtensuite 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 sinnvoll DeferUntilNoUserActive Das Ablage Schema kann sowohl eine einzelne URL bzw URI als auch eine Menge zulassen falls eine redundante Speicherung erforderlich ist F r die Archivsicht erhalten wir mit Darstellung durch den deontischen Operator F Verboten extend Archivsicht by MODIFIKATION F Insert F Del
88. IGN ZUGANG BY 6 3 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 B
89. IM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 7 INTERAKTIVIT T 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 ist 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 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 intergalaktische Multimedia Fffekte verzichten Oberfl chen sollten im allgemeinen der Anwendungsphilosophie der Anwendungslogik und dem Anwendungszweck folgen Deshalb sollte eine Anwendung immer als Ganzes e
90. INFORMATIK I 15 2003 INDEX Global and local as view 168 Global as view 168 Grober Typ 178 Gruppenarbeit 147 HERM 48 HERM Algebra 60 HERM Anfrage 63 HERM Diagramm 48 Heterogenitat 150 Hierarchisches ER Diagramm 48 Historie 128 Hypergraph 93 Implementationsschicht 34 Information 3 Informationsbediirfnis 115 Informationsbedarf 119 Informationsbeschaffungsverhalten 116 Informationslogistik 107 Informationspr sentation 116 Informationssystem 3 Inklusionsabhangigkeiten 51 Inkrementelles System 170 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 147 Kollaborationsrahmen 29 134 153 Kollaborationsvertrag 152 Kommunikation 147 Kommunikationsrahmen 111 Konkurrenz 65 Konsistenz 150 Kontext 85 109 Konzept 177 Konzeptfeld 74 Konzeptionelle Schicht 34 Konzeptionelle Spezifikation 37 Konzeptlandkarte 177 Konzeptrahmen 74 Kooperation 147 155 Koordination 147 155 Kuvert 95 Lastenheft 37 177 Linguistik 5 Local as view 168 Logische Spezifikation 37 Logistik 107 Lookup Notation 49 M glich g ltig 71 Mehrwertige Abh ngigkeit 51 Mengen Operationen 61 Metapher 138 Metaphorikrahmen 145 Mockup 109 Modallogik 71 Modellierungswelt 150 Modifikation von Objekten 61 Motivationschicht 34 Multi
91. INN s p ylequeuolyyun ser s p Tleyueuol yun UII jleTyUeseIder NYS uonyuny uond zuoyi uonyy g zorq s r qry yornp gezorg yynporg q mp g zolq azo MOY u suni ss zovdsayeq s r eqrreuonyunn3ynp uond zuox pueg mopom ypanp MOPYIOAA Old YOINP MOP IOAN mor soqjou 211 02 1 euleyosssunpuemuy s p Tregusyeq u se s p fleqyueyeq WII 1107yuose1del dAyssunpuem dA ydozuoy uordozuoy uy q mp dAyusyeq q mp dAyusyeq yornp dAyusyeq dhzuazog euloyps euloyosssunp reypuend zuoy uond zuoxy ZZDIS YOINp euloyos uoljdezuoy ys yassuoryY YD1YOsgezoudsjyeyosay JYDIIYDSSUOIIEAIIO 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 unterstiitzen Strukturierungsorientierte Entwicklung Es werden 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 Entwicklungansatz hat aber den Nachteil einer hohen Modifikationsrate aller vorher erstellten Dokumente Proze
92. 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 VVas diese VVissenschaft 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 Verh
93. Interaktion mit entsprechenden Funktionen iiber 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 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 invol viert ist Es gibt Beziehungen zwischen den Akteuren nur durch entsprechende Dialoge 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 allgemeiner 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 mit 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 eine Gruppe von Benutzern in Beziehung mit dem gesamten Spektrum der Ausbildung di
94. Intervall lt A el sation F higkeiten x ame profil Familienname Rufname AnzJahreBerufserfahrung Person Vornamen Titel Anrede Geburtsdaten Biometriedaten Geschlecht Familiengeschichte Pa Charakterisierung 5 profi LetzterEintrag P Beschreibung R Art Eigenschaft Name Priorit t Bildungs einrichtung 7 Gegenstand Status Spezialisierung Beschreibung KAPITEL 2 SPRACHEN Kommentar Ab Bis gt Kommentar Ist Von Bild 8 Das Person Konzept mit obligatorischen allgemeinen und optionalen Bestandteilen Rollenkonzepte Interne Rolle Externe Rolle e Kontakt Partner AdreBkonzepte 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 ni
95. K 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 da ein Arbeitsablauf hoch parallel ist e da ein Arbeitsablauf eine R ckkopplung mit Wartezeiten erfordert und e daf 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 e die Assoziation mit Sichtentypen sowohl f r 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 Kontextbedingungen e der
96. K I 15 2003 KAPITEL 5 FUNKTIONALITAT eine Stammform zur Parametrisierung der unterschiedlichen Dimensionen wie z B Zeitdimension und Akteurdimension die Wortbildung d h durch Regeln zur Assoziation von VV rtern zu komplexeren Ausdriicken wie z B Ableitung Zusammensetzung und Abktirzung 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 fiir 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 Numerus mit dem eine Einzelbehandlung oder eine Gruppenbehandlung erm glicht wird Konjugation zur Instantiierung von n wertigen valenten Beziehungen mit 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 er a wir
97. Klasse von Interfacewerkzeugen orientieren Mit der Angabe 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 spezifiziert durch eine Darstellung folgender Parameter Funktion Die Werkzeuge k nnen einfache Funktionen zur Verf gung stellen z B wie HTML mit einer Reihe von Um gebungen 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 Bindungsfunktionen mit denen Informationen und Content Suiten eingebunden wer den k nnen besitzen und 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 objekt orientierte oder zustandsorientierte Dar stellung der Funktionsabarbeitung Kollaboration Die Funktionalit t der Werkzeuge kann ggf auch einem Benutzer s
98. LUNG IM CO DESIGN ZUGANG BY 6 63 SQL m sum 77 count eounpeut u counties null null null sum ndef 77 undef undef 77 count 7 count count 1 undef SQL benutzt eine Variante die nicht die intuitivste ist Wir pr ferieren in der HERM Algebra die mit annotierten Varianten fiir den Fall von Klassen mit Nullwerten Die Funktionen avg i und ave ef werden dabei der SQL Form avg vorgezogen Die algebraischen Operationen k nnen zur Bildung von komplexeren Ausdriicken 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 Ausfiihrungsbedin 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 durch Prozesse verfeinert Der Zusammenhang der Arbeitsvorg nge wird durch verallgemeinerte Transaktionsmodelle dargestellt In der Datenbank ver ndern Prozesse die Zust nde Deshalb werden die Zustandsver
99. M uq 6810990 TPSTIEIS 4 uvu s TNMGH Pbif oru eyipeaq Mu 2814S dAL an ynns drysuoryepoy BULOIPS YA 4 SS T TVNHHH y rseq YA uesunsUIpeq myey 878 113974U TUITDS AZq q sTe VUISIPeIeg yop izidur sojeuorje oL PL PILL UdULOT R OY S TEUOL T T uoneS rs3y euwog osseIM eyoeids SLIOSU I 84391 i INZ HT POTV Tomuszue4su S pun 3nz INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 19 2 Sprachen zur Modellierung von nformationssystemen 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 Funktionalit t Inter aktivit t und Verteilung verbinden lassen Eine allgemeine Vorstellung der integrierten Elemente vermittelt Bild 5 Generelle Aspekte von Informationssystemen 627175 Strukturierung Funktionalit t Interaktivit t Verteilung hb Struktur Prozesse Content Objekte Stories Dienste Kollaborationsrahmen _ Statische Dynamische Integrit tsbedingungen Integrit tsbedingungen Szenarien Benutzergruppen Aufgaben Konzeptionelle Sp
100. MATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 27 Lokalisierungsabstraktion 4 unterst tzte Sichten Funktionalitat kizi Sichten Container Gee Informationseinheiten Akteure A A zugelass ne 5 Modifik tions 7 onstruktion anforderungen rozesse globale Datenbank Prozesse schema bereltgestellte Aspektkategorien 1 statische Aspekte dynamische Aspekte Bild 11 Die Infrastruktur fiir die integrierte Entwicklung von Informationssystemen A 4 A Informations Content Inter Typen aktions Story Daten raum Raum bank system Bild 12 Die Unterst tzung von Informationssystem 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 Dateniibertragung Dienste werden charakterisiert durch eine Dienstleistungsvereinbarung als verbindliche Regelung des Dienstverhaltnisses eine Sammlung von Funktionen die zur Erftillung des Dienstes abgerufen werden k nnen und Dienstmerkmalen zur Darstellung der Qualit tsparameter Die Funktionalitat 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 Dat
101. NALITAT Programme der Workflow Maschine Elementarprogramme sind alle zugelassenen Ausdriicke der HERM Algebra Wir unterlegen dabei eine Semantik der Abstract State Machines Sie wird im folgenden kurz eingefiihrt In diesem Buch werden wir die Semantik nur anwenden so da wir auf eine detallierte 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 Pa Ein Programmschritt kann auf einen anderen Programm schritt folgen 00 Pi H Dr P k Verzweigung mit einer logischen Bedingung if o then P else Po true y Fin Programmschritt kann verzweigen unter einer Bedin l 20 2 IF gung Ly no P false Wiederholte Ausf hrung mit einer logischen Bedingung DO P LOOP a Der Bequemlichkeit halber f hren wir auch eine Programm D0 P schleife ein Diese ist auch durch andere Konstrukte abstrak ter Maschinen ausdr ckbar LOOP a Parallele Ausf hrung mehrerer Programme ohne Einschr nkung DO P PAR PAR DO Pk Programme k nnen parallel ausgefiihrt werden Die parallele DO P Ausf hrung ist beendet wenn alle Programme been
102. NFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 11 nachtraglich entwickelt dann ist eine Vielfalt von Sichten zur Unterstiitzung 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 Verf gbarkeit einer bestimmten zumeist unvollst ndigen Entwicklungsumgebung oder einer bes
103. 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 fiigt 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 Sa Zustand 7 Entwicklung ick 1 ntegration un Struktur Entwicklung 77 Modellierung Komponentenabstraktion oS eee Se Bild 2 Die vier Prinzipien der Informatik Jedes der vier Prinzipien besitzt unterschiedliche Facetten So sind die Kooperation die Kom munikation und
104. Operationen wie insert delete und update dar bei denen eine Instantiierung durch Angabe der Strukturen der Typen er folgt fiir deren Klassen sie angewandt werden Ebenso wie generische Operationen k nnen generische Workflows durch Instantiierung in Workflows berf hrt werden Die Parameter k nnen auch abhangig voneinander sein Wir unterscheiden hierbei die folgenden speziellen Typen Entfaltbare Workflows sind generische Workflows mit generischem Laufzeit Workflow bei denen die instantilerbaren Parameter keine Nebenbedingungen auf andere Parameter besitzen Sie k nnen zur Laufzeit voll entfaltet werden Typische entfaltbare Workflows sind Workflows fiir Grup penarbeitspl 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 verf gen und deshalb einer Transaktionssem
105. 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 in verschiedenen Elementen der Story werden auch Zu sammenh nge zwischen den einzelnen Sichten erkannt Wir spezifizieren die Zusammenh nge in einem Integrationsschema der Sichten Die Koh sion
106. Programmbibliothek aufge DO rt tn 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 00 Vorlesung Klassifikation ehooseKl DO Vorlesung Studiengang chooseSG DO Vorlesung Praktika inputPr true r IF Praktika DO Skip DO Vorlesung Hauptdaten inputHD Dalai true DO Vorlesung Ubung input b false po Skip DO Vorlesung Nebenbedingung chooseNB pt Vorlesung Raumforderung chooseRF Abstrakte Semantik von Datenbank Transitionen Das Datenbank Schema definiert die Strukturierung der Datenbank Fin Zustand der Datenbank kann durch eine Modifikation partiell ge ndert werden Anderungsoperationen T s1 5n t vom Teiltyp 77 von T basieren auf Anfragen Sie sind auf einem Objekt eine
107. Protd PartnerGruppel Rechte Port Proto chro rung Zeit cher tio koll folio koll nisa heit nen dis ablauf tion kurs INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 155 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 run
108. RICTIONS 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 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 betrieblich
109. Sie ist niemals Selbstzweck sondern steht im Dienste der Arbeit mit dem Datenbanksystem B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 7 INTERAKTIVIT T Durch die Einengung auf den Bildschirm wird die Vermittlung einer Botschaft auch ein geschr 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 das Aussehen von Requisiten dienen der Gestaltung von Oberfl chen Eine multimediale Arbeitsumgebung schlie t die Verwendung von T nen ein T ne sind ebenso eine Informationsquelle Die wichtigste Funktion des Tones liegt im Dialog mit dem 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 nicht 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 Kombin
110. Skalierung unterzogen wer den Wir k nnen z B mit der folgenden Kategorisierung die Profile der Akteure zum Erstellen eines Lehrveranstaltungsvorschlages 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 7 Kommando matik matik sations C mierung matik station sprache erfahrung ohne Sicherung B ro 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 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 zusammenw
111. 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 konzeptionelle Eigenschaften und e innerhalb der Implementationsschicht durch Dienstgtiteeigenschaften 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 chanismen fest 30 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 2 SPRACHEN Der Kooperationsrahmen bestimmt die Art des Zusammenwirkens der unterschiedlichen
112. 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 108 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 7 INTERAKTIVIT T sondern eine Menge von Stories die Abl ufe in der Anwendung beschreibt In diesen Fall ent wickeln 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 des Anwendung Die Stories werden durch einen Plot in diesem Entwurfsschritt verfeinert Das Plot ist eine Anordnung der Ereignisse des Story Raumes In der Dramaturgie 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 f r die Stories d h die Planung und den Ablauf der Szenen e den allgemeinen 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
113. THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 1 EINFUHRUNG relationale Modell fiir den operationalen Entwurf eine 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 Funkti
114. Telefonnummern mit einer angepa ten Ordnungsbeziehung und ohne Unter dr ckung f hrender Nullen Analog kann ein Typ emailTyp oder URL eingef hrt werden Attribut Typen werden ber einem Basis Datentypen 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 gegeben durch einen Ausdruck A T Der Wertebereich dom A des Attribut Typs ist der Wer tebereich des Basis Datentyps Der Wertebereich des leeren Datentyps A besteht aus L Sind X Xn Y Attribut Typen und A B C D Markierungen dann sind A X 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 z B dom A X1 Xn dom X1 x x dom Xn und dom A Y 20 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
115. 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 Entschachtelung geschachtelter Strukturen Die Entschachtelung 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 z B Lehrveranstaltungen nach Vorlesungssemestern Studieng ngen und Stu dienabschniten geordnet werden in dieser Reihenfolge Angabe von Dekompositionen bzw Separationen des Content Typen Wir k nnen den inne ren Zusammenhang ein
116. 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 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 gefa t Die Gesch ftsproze schicht wird oft auch als Anfor derungsspezifikationsschicht bezeichnet Im Rahmen dieser Schicht werden neben den Anforderungen jedoch auch konkrete Entscheidungen zur Realisierung getroffen so da wir diese Schicht erweitern m ssen zur Spezifikation der Anforderungen Spezifikation der pragmatischen Annahmen Spezifika tion der Systemumgebung und Spezif
117. Verteilungssprache DistrLang Mit der ersteren k nnen wir alle datenbank basierten Aspekte wie Strukturierung Funktionalit 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 i
118. W von Intervallen von IN und einer bin ren Relation W ber TS Wir bezeichnen mit maxTS den maximalen Zeitpunkt von TS und mit minT S den minimalen Zeitpunkt Der einfachste Zeitrahmen ist das Intervall TS 0 maxT S 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 R Ir i a notiert Die Formel a is notwendig g ltig in R lp zu einem Zeitpunkt i I 7 TS und f r einen Zeitrahmen ZR falls R lp i a f r alle Intervalle 7 I mit 7 7 W und alle Zeitpunkte IUT Wir notieren dies mit R lp 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 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 R lg und ZR ab I bis zu Is f r RE TS falls RC Ip i fir alle Intervalle I mit T 7 W bzw
119. Zeit Raum beschr nkt Content Content Algebra Deontischer Situationskalk l Interaktions raum Bild 44 Der Interaktionsraum verglichen mit dem Systemraum Eine Szene besteht aus Dialogschritten in denen die zugelassenen Akteure bestimmte Aktionen un ternehmen Wir fassen diesen Spezifikationsansatz in der Sprache SiteLang zur Entwicklung von Storyboards zusammen Sie erm glicht die Beschreibung eines Story Raumes Der Story Raum besteht aus Szenen und markierten Transitionen zwischen diesen Szenen Die Markierung von Szenen wird beschrieben durch Ereignisse oder Aktivit ten f r den bergang von einer Szene zur n chsten durch die invol vierten 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 Contentobjekte die Manipulationsanfor derungen die zugelassenen Operationen die Vorbedingung eine Abschlu bedingung und die Ereig nisse die zum Schritt f hren sowie die agierenden Akteure der Szene 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 spezi fiziert werden Formal k nnen wir diese Begriffe von SiteLang wie folgt einf hren Der Story Raum ist ein gerichteter bewerteter Graph bestehen
120. a tentypen kann sich ggf auch auf die Funktionalit t auswirken e Datentypen verf gen nur ggf ber eine eigene Ordnungsbeziehung e Datentypen verf gen ggf ber eine Klassifikation innerhalb der Daten des Wertebe reiches Diese Klassifikation kann einfach oder mehrfach hierarchisch analytisch oder synthetisch monothetisch oder polythetisch und ein oder mehrdimensional sein 44 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 4 STRUKTURIERUNG 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 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 einf hren zur Dar stellung von
121. ad 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 gt sind Konkurrenten falls read P Nwrite P oder read P O urite P oder urite P N write P 0 Parallele Ausf hrung von Transaktionen ist immer m glich vvenn diese keine Konkurrenten sind In diesem Fall ist der Effekt der parallelen Ausf hrung quivalent zu P P2 ER oder zu P P R 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 e 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 D realisiert werden e Au erdem kann man Transaktionen nach dem ACTA Metamodell analog anwenden F r unsere Belange erscheinen jedoch diese HERM TA Formen ausreichend e Es wurden unterschiedliche Modelle zur Ausf hrung und Steuerung von Gesch ftsprozessen Ha
122. als auch mit den Anforderungen von SPICE 2 0 validiert 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 G f r Sichten f r Container Theorien und Umgebungen werden mit erweiterten mathematis
123. alten Und seht nur hin f r wen Ihr schreibt Goethe Faust Vorspiel auf dem Theater Direktor Die Herangehensweise 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 Handlungen zur Darstellung des dynamischen Verhaltens wie e Anderungsoperationen 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 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
124. altens 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 von Thomas Feyer am Beispiel der Interaktionskomponenten vertieft 2 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 0 VORVVORT 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 werd
125. alter 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 Umsetzung Deshalb ver wenden wir das Diensteverwaltungssystem mit den entsprechenden Schnittstellen und Protokollen auf dem Implementationsniveau Zur Spezifikation der Verteilung abstrahieren und verallgemeinern die Ans tze zur Verteilung INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 29 ienstnehmer Dienstgeber IDienstnehmercode Stummel Ger st Dienstgebercod Verpacken Senden Empfange Auspacken Funktions Parameter Parameter eintritt Funktions aufruf Waften Auspacken Verpacken F rnktions Ergebnis Empfangen Ergebnis 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 r bestehen aus Content Typen der Sichten
126. anismen genutzt werden sollen e falls eine Fehlerbehandlung und Archivierung erforderlich ist und e falls eine geringe Entwicklungszeit f r sich ndernde Anwendungen bevorzugt 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 GMUW00 und FvH89 sind stattdessen fiir 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 logis
127. ann 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 Pr zision 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 Daten Typ des Sichtenschemas ist durch die verwendeten Daten Typen gege ben Wir k nnen damit f r einen allgemeinen Daten Typ eine Menge von Pr sentationsformaten entwickeln 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 sualisierung 92 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 6 SICHTENSUITE e Das Prinzip der visuellen Kommunikation orientiert auf eine klare 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 Ges
128. anny DeVito in Das Geld anderer Leute Datenbank und Informationssysteme sind heute integrierte eingebettete oder selbst ndige An wendungen und integraler Bestandteil der nfrastruktur 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 Prasentationssystemen 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 Kontextes 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 Struktu
129. antik 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 Ein 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 78 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 5 FUNKTIONALITAT die sequentielle Ausf hrung bei der Workflow Programme sequentiell nacheinander ausgefiihrt 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 Widerspruch f hrt parallele Verzweigung N bei der Programme parallel ausgef hrt werden k nnen und das ter miniert wenn beide Programme terminieren exklusive Au
130. ard 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 124 Szenarium 124 128 Szene 37 109 Teilstruktur 60 Temporale Formel 72 Temporale Klasse 71 Thema 107 Theorienwelt 150 Transaktion 64 Transitionsbedingung 72 Transparenz 151 BY 8 191 Typ 37 43 Umbennenung 62 Umschlag 95 Update 61 Vereinigung 61 Verpackungsumschlag 95 Verteilte Datenbank 158 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 118
131. arieren in Workflow zur Darstellung der Folgen von Prozessen der Anwendung Produkte zur Darstellung der Interaktivit t sollen eine Beschreibung der Anwendung aus der Sicht der Benutzer erm glichen Deshalb wird die Interaktivit t als Raum als Handlungsabl ufe der Benutzer oder ihrer Abstraktionen als Akteure d h als Story Raum beschrieben Dieser Story Raum fu t auf INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 37 Szenen zur Beschreibung eines generellen Schrittes der Anwendung und auf Dialogschritten zur Beschreibung der einzelnen Aktionen Produkte zur Darstellung der Unterstiitzung der Verteilung sind im Rahmen von Anwen dungen von Informationssystemen 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 Aktionssichtensuite Konzeptionelle Schicht mit der konzeptionellen Spezifikation mit der Beschreibung der vier Aspekte durch ER Schema Workflow Maschine Drehbuch und Sichtensuite Implementation
132. artitionierungskonzepte Die Partitionierungstiefe kann bei einer Partitionierung von keine Partitionierung bis zu einer Par titionierung auf Attribut bzw Objektniveau reichen F r die Partitionierung sind einige Korrektheitsregeln in verschiedenen Abstufungen einzuhalten 162 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 8 VERTEILUNG Vollstandigkeit 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
133. aten und die Darstellung der Funk tionalit t Damit werden dargestellt Daten innerhalb von Content Objekten sind klassifizierbar in eine Reihe von Kategorien 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 Prozesse mit denen ein Akteur Handlungen und Aktionen mit dem Informationssystem ausf hren kann Wir unterscheiden dabei Unterst tzende Prozesse f r die Aktionen und Manipulationsanforderungen an das Informationssystem zur Ver nderung der Daten Wir fassen die Daten in Klassen zusammen Ein Content Typ spezifiziert eine solche Klasse und basiert auf einem Sichten Schema 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 erfolgen kann F r die Beschreibung von Containern unterscheiden wir zwischen allgemeiner Containerfunktionalit t mit der Bes
134. ation der Szenen der Dialogschritte der Bedingungen f r die Stories der Handlungs berg nge Spezifikation der Contenttypensuite der notwendigen Funktionalt t zu deren Unterst tzung Modulare Verfeinerung der Datentypen Normalisierung der entwickelten Datentypen Kontrolle des Storyraumes 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 Sichtensuite 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 Performanzbetrachtung 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 cksichigung m glicher Technologieentwicklungen und Ver nde rungen in der Anwendung 42 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 K
135. ation und zur Kommunikation 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 Kollabo ration k nnen wir die folgende Tabelle verwenden oder auch ein Arbeitsblatt wie bereits bei der Spezifikation der Szenen und der Dialogschritte Kollaborationsrahmen Kollaboration Art des Zusammenwirkens Arbeitsplatz Form Rollen Formie Raum Ver Bezie Arten Diskurs Ak Gruppe Rechte Port Organi rung Zeit trag hungen typ teure folio sation Wir unterscheiden verschiedene Arten von Kopplungsmechanismen die auch im Kombination verwendet werden k nnen Bei einer Interaktionskopplung werden die gleichen Daten interaktiv verwendet Die Operationen sind durch Interaktion gekoppelt Dazu existieren verschiedene Kopplungsmethoden interne Kopplung globale Kopplung externe Kopplung Kontrollflu kopplung Wanderdatenkopplung und Parameterkopplung Die Komponentenkopplung erlaubt nur ein Zusammenspiel der Objekte Es k nnen verschiede ne Grade der Kopplung unterschieden werden versteckte Kopp
136. ation 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 relevanter 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 Reaktio
137. ationsdiskurs dar Kollaborationsform In der Kolloaborationsform werden die Konfigurations und Zugriffsparame ter die Ereignisverarbeitung die Synchronisation und die Parameter des Kollaborationsvertra ges untersetzt Eine alternative Darstellung wird gegeben durch eine Darstellung von Architektur Formation und Berechnung wie im Arbeitsblatt auf Seite 158 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 bert ragung und Datenverwaltung fiir jede Komponente Zur allgemeinen Darstellung von verteilten Syste men fiir die Implementationsschicht verweisen wir auf Monographien und Lehrbiicher 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 Contenttypen den Kollaborationsrahmen und die Archite
138. ationshiptypen und seinen Komponenten Statische Integrit tsbedingungen werden als Formeln der hierarchischen Pr dikatenlogik allge mein dargestellt 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 Entity Klassen Wir nehmen an da Entity Klassen stets eigen identifiziert sind d h 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 Per
139. atischen 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 werden 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 INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 65 Inaktiv Zur ckgewiesen BOT IC falsch EOT Aktiv Beendigung 4 wahr Bereit zum Abschlu Bild 29 Die Zust nde einer Transaktion 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 write P re
140. aufgrund der Modellierung Die Funktion 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 Charakterisierung nach Interaktionsart Die wichtigste Arten sind die folgenden INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 99 Durch den Sprechakt wird die Interaktionsform beschrieben Im illokation ren Akt wird die kommunikative Funktion der menschlichen Kommu nikation nachgebi
141. aum 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 objekt 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 Sichtensuite INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 53 Motivations schicht Vorstudie Skizzierung h Lastenheft Daten Gesch ftsproze schicht Feinstudie Darstellung Grober Typ Pflichtenheft Daten Skelett Aktions T schicht Entwurf A Anwendungstyp h Anwendungsschema konzeptionelle Schicht Implementation Transformation Typ ER Schema mplementations 757 schicht nn logischer Typ logisches Schema Bild 25 Die Arbeitsprodukte im Abstraktionsschichtenmodell f r die Strukturierung 54 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 5 FUNKTIONALITAT 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 sp
142. b 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 zu entwickeln neben Kollaborationskonzepten Daten werden abh ngig von ihrer Geschichte Daten werden in unterschiedlichen Quellen in unterschiedlicher 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 ere Zugriffsmengen zu berstehen empfiehlt sich eine gr ere Verteilung und eine mehr stufige Sichte
143. bar INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 61 e Typ erhaltende Operationen f hren zu Klassen vom gleichen Typ Mengen Operationen Es seien RC und R Klassen vom R Dann k nnen wir folgende Operationen definieren Vereinigung R U Re olo R Voe RC Durchschnitt R N R o o R AoE Differenz R R olo R Ao g RC Auswahl von Objekten aus einer Klasse Gegeben sei ein Pradikat o ber R Die Selektion o R wird induktiv eingef hrt durch strukturelle Rekursion mit 07 UR OR und Oo R srecg 4 R bzw in der aufgel sten Form o 0 o do o 0o R Urn R oo R Ur oo R falls RO Ng R gilt Wir nutzen eine andere Finf 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 o ist durch die Vereinigung R Ufo von Mengen f r Klassen R und Objekte o vom gleichen Typ R beschreibbar Streichen von Elementen Die delete Operation Delete RC o ist durch die Differenz R N o von Mengen f r Klassen RT und Objekte o vom gleichen Typ R definierbar Analog kann man auch das Streichen von Mengen delete BC RC einf hren Update von Elementen Die Modifikation Update R a 7 von Klassen PC
144. 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 Controling 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 Entwicklungsproze kann an die unterschiedlichen Kontextbedingungen angepa t und auch optimiert werden Niveau 4 un
145. 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 f r den Verbund das Sortieren oder auch Kommunikationsfunktionen 168 Die B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 8 VERTEILUNG Ein spezielles Beipiel sind VVorkstation 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 Spezialisierung erschwert Lastbalancierung Erweiterbarkeit und Fehlertolera
146. bley 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 statecharts 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 Ge
147. bsicht 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 besondere Sorgfalt bei der Aussch pfung aller Darstellungsm glichkeiten notwendig 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 Qualit 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 Granulier
148. bssysteme Hardware Datenbank Management Systeme bzw Programmiersprachen Heterogenitat durch unterschiedliche Programmiermethodiken Heterogenitat der Datenbankschemata Heterogenitat der Funktionalitat der Informationssysteme und Heterogenit t der Storyr 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 Objektsuiten 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 Objektsuiten kann berechnet werden so lange Objektsuiten hierarchisch strukturiert sind und die Integrit tsbedingungen stratifi zierbar sind In vielen F llen ist ein Herausfiltern von Konflikten m glich Das Auffinden von Inkonsistenzen kann durch Modellierung der Inkonsistenz und Konfliktbedingungen 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 auch die Konsi stenz zerst ren Mit Transaktionsmodellen kann dem entgegengewirk
149. chaft 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 120201 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 R
150. chema Ein Beispiel einer Adhasionsmatrix f r das Schema in Bild 34 ist mit folgender Matrix gegeben Archivsicht Ti Ta T Ta Ts Te Ta T Verantvvortlicher 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 Kurs gehaltene Lehrveranstaltung Kurs gehaltene Lehrveranstaltung Studiengang 94 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 6 SICHTENSUITE 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 separiert werden durch die Adh sion der hinzukommenden Typen der n chsten Schale Dadurch k nnen wir sogar eine hierar chische Charakterisierung vornehmen In den seltensten 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 Verantwort
151. chen Schriften dargestellt Zum Beispiel bezeich nen 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 Fin 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 Leider hat sich im Datenbankumfeld eingeb rgert ber Modelle zu reden statt ber Sprachen INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 3 1 Einf hrung Ich bin nicht ihr bester Freund Ich bin ihr einziger Freund D
152. cher 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 kein 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 10Stattdessen empfehlen wir Bis95 KE96 oder den Klassiker der Modellierung LM78 EINFUHRUNG KAPITEL 1 PREPRINT BTU INFORMATIK I 15 2003 B THALHEIM 18 u d4A u qq rg u gur q su qq lg BUNTLIJLIA PUN PPPALJYDLIJUJ Lap BUNZINISLIJUN UazING uUazYyIIUg 104 syleqry Yoinp ysop1equn PU urne yq 4403S pun v d4T 9u quo0 IDLA144D19JuJ U qu vuoduroy pun m ry ry PU s ur qs4 Sop gur q g HUNJIIJLIA Bu nd n poyy u unsurp qsieqrid quy y q srureu4p pun 98892014 oploiseq yy 7oyyouowyyung sap D nd nq poyy u sun3u
153. chographischen Profil und nach Adaption an Profil 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 Storyraumes Es wird der Storyraum so optimiert da ein Benutzer sei ne Aufgaben mit dem einfachsten Szenarium bew ltigen kann Hilfreich ist hierbei eine angemessene Navigation im Storyraum 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 Sprachbarr
154. chreibung 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 zur 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 Es werden Daten die nur f r die Planung im laufenden oder kommenden Semester von Bedeutung sind nicht archiviert Mit den archivierten Daten k nnen zu einem sp teren Zeitpunkt die Daten zu Lehrveranstaltungen eingesehen werden die stattfanden und in denen Studenten entsprechende Leistungen erreicht haben 86 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 6 SICHTENSUITE Lehrveranstaltungen die stattfanden in denen aber Studenten keine Abschliisse erreichten werden ebenfalls gespeichert sind jedoch fiir die Archivsicht nicht mehr von
155. chreibung der Lehrveranstaltung 1 1 1 5 Zuordnung der Lehrenden zur Lehrveranstaltung 1 1 2 Angaben zur Art der Lehrveranstaltung 1 1 2 1 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 Teilstrukturen von Strukturen und Typen sind mit folgenden Operationen definiert 60 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 5 FUNKTIONALITAT Die Definition von Teilstrukturen basiert auf der Ordnung lt die als kleinste bin re Rela tion
156. cht 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 mehr 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
157. chten die zur Modifikationsf higkeit von Sichten bei nicht modifizierbaren Sichten verwendet werden Maskierung von Fehlern Fehler k nnen abgeschw cht werden durch erh hte Funktionsredun danz wiederholte Ausf hrung oder bertragung oder Datenredundanz RAID Speiche rung 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 Es werden die Integrit tsbedingungen zusammen mit den Pflegestrategien spe zifiziert und durch entsprechende Prozeduren unterst tzt So kann z B eine Zusammen fassung 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 Verfahren k nnen mit expliziten Abwehrma nahmen und krypto
158. d e zu Funktionen zur Sitzungsverwaltung Prozeduren und Programmme zur Anpassung des Content Objektes an den aktuellen Benutzer d h e zur Anwendung von Abstraktionen zur Anpassung des allgemeinen Repr sentationsstils und e zur Anpassung an den inhaltsbasierten Repr sentationsstil INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 95 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 der Inhalt und die unterst tzten Aufgaben die Fignung 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 umfa t zu e Vertrauensw rdigkeit 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 Annotatione
159. d 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 Verwendbare Dokumente aal aa2 aal Betroffene Dokumente aa3 oo Obligationen 4 aa5 Erstellte Dokumente 7 oo Obligationen Resultate rel rr2 rr3 Ziele und Gegenstand bbb INFORMATIONSSYSTEM ENTWICKLUNG IM CO DES GN ZUGANG BY 6 181 Beteiligte cc dd Theoretische Grundlagen e ee ef Methoden und Heuristiken gg Beginnbedingung hh AbschluBbedingung kk Diese 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 f hrte Es wird neben der Dokumentation der Entwicklung auch eine Erfassung der verbliebenen und z T neu entstehenden Arbeitsaufgabe
160. d 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 116 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 7 INTERAKTIVITAT sich zunehmend in eine starkere Konkurrenz mit Printmedien wie Nachschlagewerke Verzeich nisse wie Adre b cher begeben Informationsdienste zur Erf llung von Arbeitsaufgaben werden zuerst als allgemeine Betriebsinforma tionssysteme wie z B als Campusinformationssystem erfolgreich sein Die Achillesferse der heute vorrangig entwickelten Wirtschaftinformationsdienste ist die Aktualit t der angebotenen 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 Arbeitsfortschrittes 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 werden und damit einer
161. d aus Szenen und den Transitionen zwischen den Szenen d h Story Raum Szene E A k E C 1 Szene x Szene A Szene SzeneBeschreibung k 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 AkteurID Rechte Aufgaben Zuordnung Rolle Reprasentation Stil Defaultwerte Betonung Kontext Hardware Software Kanal Intention INFORMATIONSSYSTEM ENTWICKLUNG IM CO DES GN ZUGANG BY 6 123 Datenbank Unterst tzung f r den Storyraum Es sind verschiedene Repr sentationen m glich f r Szenen und Dialogschritte 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 aktiv Element Von Dialogausdruck MbasiertAuf Szene C aktiv involviert Szene Story Dialogschritt ausdruck Element von Umstande involviert Plattform Kanal Event Condition Dialog Kontext Akteur m schritt AcceptCondition ID Ausriistung Gruppe
162. 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 Ein 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 Expo se Treatment und ausgearbeiten Story Ein solches schrittweises Vorgehen bringt betr chtliche Vorteile durch schrittweise Beseitigung von Unsicherheitsfaktoren und Hinzuf gen von zus tz lichem Material mit sich Jede Szene kann damit ihren richtigen Platz in de
163. der Begleitinformation das Aktualisie ren der entsprechenden Datenbest nde und kann durch Integration entsprechender allgemeiner und inhaltsbasierter Repr sentationsstile einschlie lich entsprechender Metaphern eine automatische Ge nerierung 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 Abstraktionsgranularit 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 Wertebereic
164. der 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 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 Obwohl 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 Umgangssprache und der Informatik zu breit verwandt wird bleiben wir beim Begriff Content INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 21 Darstellung der Beziehung der Zeichen zu
165. 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 e Ein maskierter Benutzer kann einen Dienst durch
166. det sind po A Alle Programme beginnen mit dem gleichen Zustandsraum po P H Eine parallele Ausf hrung ist erfolgreich durchgef hrt wenn keine konkurrierenden Ver nderungen der Datenbank mit unterschiedlichen Werten f r die gleichen Datenbankobjekte erfolgen P H 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 l l LET z t IN P D0 P zugewiesen werden Diese Zuweisung gilt nur lokal Ausf hrung nach Auswahl eines Wertes CHOOSE x WITH 8 DO P Es wird ein x Wert unter einer Bedingung gew hlt Damit wird das Programm ausgef hrt sup Ausf hrung f r alle zutreffenden Werte FOR ALL x WITH DO P Alle Werte fiir einen Parameter die zutreffen werden gew hlt Es wird daf r das Programm P parallel aus FOR ALL x WITH o D0 P gefiihrt SKIP Programmschritt zur Darstellung des leeren Programmschrittes SKIP Konzeptionell kann auch der Programmschritt ohne Auswir kungen auf den Zustand ben tigt werden 25 INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 69 Modifikationsschritt zur Durchfiihrung einer Modifikation der Datenbank DO fla 2 Sn t Es wird ein paralleler Update f r eine Datenbank Klasse DO ausgef hrt mit den Parametern 31 Sn F S1 n h Aufruf eines Programmes aus der Programmbibliothek DO ril TA Es kann ein Programm aus der
167. 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 Das Dreieck wird oft jedoch als Spannungsdreieck f r gesellschaftliche Beziehungen aufgef hrt INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 fi werden innerhalb eines Schemas verschmolzen und sind dann Bestandteil einer gro en Strukturein
168. e henden Informationen das Layout abgeleitet Es orientiert sich 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 e 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 144 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 7 NTERAKTIVITAT Metaphern zur Storydarstellung und Funktionsunterst tzung
169. e Die aktuell vorhandenen Prozesse werden mit entsprechenden Aktivit ten verglichen Es wird die Systemleistung 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 e Qualit tsaspekte 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 e Aufwand und Frtrag 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 Ermittlun
170. e die Benutzer e ben tigen e mitbringen und ggf auch e nicht besitzen sollen Die letzte Kategorie dient auch der Charakterisierung von Wissens Fertigkeiten und F hig keitsl 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 LFe auf eine Klassifikation der Akteure nach Eigenschaften ausgerichtet e F higkeiten die Akteure zur Bew ltigung der Arbeitsaufgaben besitzen sollen e Fertigkeiten 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
171. e durch Nutzung der kontrollierten Redundanz e Dezentralisierte Datenbanksysteme zur Reduktion des Kommunikationsaufkommens und der Abh ngigkeit vom Netz Mehrrechnerdatenbanksysteme sind eine typische Realisierungsform von homogenen integrierten Datenbanksystemen Es sind im Wesentlichen 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 e 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 besi
172. e erfordern Der Moment eines Lebenszyklus sind alle Eigenschaften des Objektes im Zustand s Die Spezifikation der Nutzer 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 Ordnung und ihren Beziehungen die verwendeten Hilfmittel 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 Umgebun
173. ealisierung 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 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 Benutzer nicht sichtbar
174. echnik dargestellt Diese Potentiale 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 eingesetzt mit denen ein Bezug auf die Benutzerwelten und die das Verst ndnis der Daten auf die Benutzer darstellen INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 143 In den kombinierten Dimensionen des Benutzer Proze Proze repr sentation werden Metaphern der Be wegung wirksam In der kombinierten Dimension der Daten Benutzer Welt wird der Informationsgehalt der Wert der Information und die Benutzbarkeit der Information dargestellt 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 st
175. edeutung 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 e Kommunikationsabl ufe sind entweder symmetrisch oder asymmetrisch je nachdem ob Facetten der Kollaboration auf Gleichheit oder Unterschiedlichkeit beruhen Die unter
176. eibung als XML Schema oder DTD Datei document type definition Diese Schemata sind aufeinander abbildbar Demzufolge kann jede Entwurfseinheit einer h heren Schicht so wie in Bild 14 auf Seite 33 dargestellt einer Menge 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 verfiigen 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 tiber einen Surrogat Schliissel 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 mit dem erweiterten ER Modell dann 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 Ein 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 Gesells
177. einander 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 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 coin Syntax Syntax Allgemeir rst ndnis Erzeugbarkeit Verwaltbarkeit Semantik Pragmatik Pragmatik Semantik x Konzepte Begriffe Konzepte Begriffe Theorienwelten Benutzeryelten Konzeptionelle
178. einen Schreib tisch einer Gruppe einen Arbeitsraum 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 140 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 7 NTERAKTIVITAT Leistung Werkzeuge stellen Funktionalit t in eienr bestimmten Qualit t und mit einer be stimmten Kompetenz zur Verf gung Die Spezifikation der minimalen Qualit tsanforde rungen wie Allgegenwart Sicherheit ist mit dem Gestaltungsrahmen vorzugeben 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 adaptiert werden an den Kontext und die Benutzung 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 vo
179. einer Interaktion mehrerer Benutzer ndert In letzten 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 Content des Benutzers enth lt auf einer Begriffs Konzept oder Kontent Algebra aufsetzt aber einer anderen Logik unterliegt Der Interaktionsraum setzt in unserem Verst ndnis auf dem Systemraum auf erweitert diesen jedoch um Benutzeraspekte Wir f hren dazu weitere Begriffe ein Der Storyraum widerspiegelt die Menge aller Stories 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 als Klasse auffassen Szenario stellen ein B ndel oder einen Pfad von Durchl ufen dar 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 122 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 7 INTERAKTIVIT T Systemraum H ERM Strukturierung H ERM Funktionalitat H ERM Logik Berechenbare Funktion Systemraum i a Interaktionsraum
180. ekt 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 Sichten Kooperation In unserer Anwendung kann z B die Archivsicht um Funktionen zum Druck erweitert werden wie 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 auch ein Sitzung Container zur Verfiigung gestellt In diesem Container werden die Sitzungen mitprotokolliert Damit ist dann auch eine Weiterf hrung eines bereits partiell du
181. elle von Agenten Wir betrachten auch im wesentlichen 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 orie
182. ellt So sind z B Contentobjekte mit Akteuren assoziiert Sie k nnen ffentlich sein von Akteuren gemeinsam benutzt werden oder 126 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 7 INTERAKTIVIT T auch privat sein Akteure beteiligen sich in Dialogschritten in unterschiedlichen Rollen und Verant wortlichkeiten Die Contentobjekte werden als Contentsuite mit einer entsprechenden Funktionalit t bereitgestellt F r Arbeitsgruppen sind Dokumente und Arbeitsr ume typische Contentobjekte Die Contentobjekte sind ggf nicht dauerhaft g ltig und k nnen entstehen modifiziert und gel scht wer den Die Dialogschritte werden zur Bew ltigung von Aufgaben mit bestimmten Intentionen benutzt Als typisches Beispiel kann die Untersetzung des Spezifikationsrahmens f r Dialogschritte von Arbeitsgruppen Sites wie in Bild 49 angesehen werden Die Akteure sind Arbeitsgruppenmitglieder Arbeitsgruppenleiter und verantwortliche insbesonde re Administratoren Der Storyraum besteht aus einer Reihe von Dialogschritten wie z B dem Zusammenarbeitsschritt Die Contentobjekte z B die Gruppendokumente k nnen auch spezielle Dokumente wie Tages ordnungen allgemeine Nachrichten oder pers nliche 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 Speic
183. emein spezifiziert mit einem Definitionsrahmen der Form 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 eine Menge von Objekten zu einer abstrakten Menge zusammengefa t werden kann und auch diese Zusam menfassung wieder aufgehoben werden kann Umordnungsfunktionen mit denen eine Menge von Objekten auch in einer anderen Ordnung dargestellt werden kann Navigationsfunktionen 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
184. emodell in Bild 57 Dieses Modell verallgemeinert und erweitert das Dienstemodell in Bild 13 Komponente eines verteilten Systemes Kommunikation Kooperation Koordination PER asynchron x synchron Aufgaben 7 verwaltun Gi 2 Sender Arbeitsproze 8 mitglied p Empf nger manager Koordinator St 1 Organisations Komponente manager des ions ualitatspara verteilten 7 Arbeitsraum 57 Systems Diensteverwaltungssystem Contenttypen Informationseinheitmanager Kompetenzregeln Bild 57 Die Implementationsschicht eines verteilten Systems Die Verteilung unterstiitzt die Kollaboration Die iibliche 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 Tatigkeiten die von Gruppenmitgliedern ausgefiihrt werden um zielbezogene Aufgaben zu erfiillen und somit das Gruppenziel zu erreichen Der Kollaborationsdienst wird im Rahmen der Implementierung durch einen konkreten Kollabo rationsrahmen unterlegt Dieser Kollaborationsrahmen setzt auf einer verfiigbaren Kollaborationsar chitektur einem Kollaborationsstil und einem Kollaborationsmuster auf Das Abstraktionsschichtenmodell erlaubt eine Separation der Spezifikation in 148 B THALHEIM PREPRINT
185. en 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 Sichtensuite ILC mit den entsprechenden Sichtenschemata zur Unterst tzung der Content Typen 180 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 9 DOKUMENTATION die physischen Schemata IP der Implementation sowie die Sicherheitsarchitektur S und das Fehlervervvaltungsschema 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 standhalt Deshalb wiurd die Co Design Methodik einer Bewertung durch das SPICE 2 0 Framework im Sommer 2003 unterzogen SPICE unterscheidet fiinf 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 Entwicklungsproze Niveau 2 Beherrschung des Entwicklungsprozesses Der Entwicklungsproze selbst ist beherrsch
186. en 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 Kollaborationsmodell 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 Austauschpro
187. en G nstig ist wenn die Entwurfsdokumente aufeinander Bezug nehmen bzw eine Untersetzung der Entwurfsdokumente der n chsth heren Schicht wie in Bild 14 darstellen RER AL et Bild 14 Entwurfseinheiten auf verschiedenen Abstraktionsebenen Gleichzeitig beobachten wir da drei Dimensionen in der Modellierung auseinander gehalten werden m ssen 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 Enwicklungsraum auf wie in Bild 15 Abstraktionsschicht Version Architekturkomponente Bild 15 Entwicklungsdimensionen fiir dei Entwurfsdokumente Das Abstraktionsschichtenmodell zur integrierten und abgestuften Entwicklung Wir betrachten explizit unterschiedliche Abstraktionsschichten und integrieren die Darstellung der Architektur der Anwendung und die
188. en 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 7 E Mperson 577000 _betriebsIS _aufgabenAkteur Wir k nnen die Parameter spezialisieren Fine m gliche Spezialisierung ist die folgende r beziehung angestellter U partner r charakteristik namen U _gebDaten U identDaten U _geschlecht INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 23 Constraints Bedingungen Wort Regeln Optionalitat R Umfeld no VVortformen a Assoziierte Null Konzepte u Default 1 Kontext Syntax __ Parameter Valenz Historie Pragmatik Konzept D Bindungsform Semantik 0 Semantische Anwendungs x portfolio Erweiterungs Modellwelt semantik 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 Q geschieden per
189. en Wir unterscheiden aktive Content Objekte akti vierte Content Objekte und passive Content Objekte und entwickeln Kooperationsvertr ge zwischen 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 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 Signaturverfeinerungskopplung Implementationsver feinerungskopplung und Erweiterungskopplung Durch die Koh sion wird die Bindung zwischen den einzelnen kooperierenden Objekten beschrie ben Es existieren verschiedene Arten
190. en 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 ersetzt durch die aktuelle USERID ein fehlender lt user_node gt wird ersetzt durch die aktuelle KNOTENID ein fehlender lt birth node gt wird ersetzt durch die aktuelle KNOTENID 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 unterst tz
191. en 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 zuriickzuspeichern Sichten Objekt Modifikationsoperationen erm glichen eine tempor re Ver nderung der Daten in den Sichten Diese Daten k nnen materialisiert werden oder werden mit dem Erl schen der Sicht auch gel scht 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 sinnvoll integrierbar in andere Objekte In unserem Hauptbeispiel sollte z B die bernahme von Kursbeschreibungen m glich sein Integration in den eigenen Arbeitsraum Es k
192. en kann Ad hoc Methoden und Sprachen bringen meist 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 TD 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
193. en verwendet wurden und ggf eine 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 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 toleriert wird und eine Anpassung an das Wachstum einfach ist INFORMATIONSSYSTEM ENTWICKLUNG IM Co DESIGN ZUGANG 8 165 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 Abhilfem glichkeiten existieren eine Reihe Durch die Verwaltung von Synonymen Aliases f r jed
194. en 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 Storyraumes verdichtet Jedes Szenario l t sich dadurch als ein Durchlauf durch den Storyraum darstellen Die Grobdarstellung des Storyraumes durch einen Handlungsrahmen umfa t die Beschreibung von Szenen Dialogschritten 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 Beschreibung der Sichten und der Verteilung PV Die Sichtenskizze beschreibt die einzelnen Sichtweisen der
195. enNr FName ProduktNr Datum Menge Umsatz 25 Sachsen Buch 56 Elektronik 4 Hardware Software Jan Febr Mar Apr Zeit Branche Bild 73 Die 3 dimensionale Aggregation von VERKAUF In der Aggregation fiir 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 die bereits betrachteten durch SQL Anfragen leicht generiert 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 Hinzuf gen eines Attributes in der Group By Klausel berechnet Durch eine Definition von Sichten und deren Materialisierung kann ein Datenbank Warenhaus zusammengestellt werden Demzufolge kann man zwischen Mikro Daten der Datenbank und den Makrodaten des Warenhaus
196. ene zur kollaborativen Planung eines Lehrveranstaltungsangebotes eines Lehrstuhles 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 verlassen werden ohne weitere Schritte 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 nfrage Anfangs schritt eig te Buchungs schritt Bild 53 Dialogschritte innerhalb eines Suchszene Neben den hier dargestellten Suchschritten gibt es noch weitere Varianten f r Dialogschritte zur Suche e Die antonymbasierte Suche beginnt mit einem Begriff den man nicht sucht der aber relativ gut das Gegenteil umschreibt 130 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 7 INTERAKTIVITAT Das Zappen erlaubt den Beginn an einer beliebigen Stelle und
197. enntnisse ber die Strukturen Prozesse und Dialoge einer Anwendung besitzen In den n chsten Teilkapiteln stellen wir zuerst die Datenspezifikation die Funktionsspezifikation 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 spezifizierbar als generelle Einheit oder Basiseinheit Resul tate der Entwicklung der Informationssystemanwendung sind Produkte zur Darstellung der Strukturierung sollen die Strukturierung der Daten auf unter schiedlichem Abstraktionsniveaus beschreiben Wir nutzen dazu eine Separation 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 sep
198. eraktivit 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 ALSS0 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 47 Hierarchisches ER Diagramm versus HERM Diagramm 48 Kardinalit tsbeschr nkungen im Vorlesungsbeispiel 49 Beziehungen der Objekte im Vorlesungsbeispiel 50 Die Zerlegung von R in zwei Relationship Typen
199. erteilungskonzepten 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 sichtenorientierter Entwurf nicht m glich ist Wird aber eine konkrete A
200. erwenden 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 mitgef hrt wird durch berschreibung oder durch das Anlegen einer neuen Version 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 archiviert 172 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 8 VERTEILUNG Diese Schemakomponenten werden mit zwei Sichtenkooperationsformen unterstiitzt Injektionsformen untersttitzen die Injektion von Daten in Partnersysteme Die Struktur ist gegeben durch eine Sicht 5782 Ys auf die exportierende Datenbank die in eine Sicht 5 4s der importierenden Datenbank eingebettet werden kann Die Funktionalit t No der Sicht des exportierenden Systemes wird ebenso in die Funktionalit t Oo Zo des importierenden Systemes eingebettet wobei alle Modifikationsoperationen allerdings gestrichen werden Insertformen unterst tzen das Einf gen von Daten des exportierenden Systemes in Daten de
201. es 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 Sichtweise auf das Content Objekt durch den Benutzer gew hlt wird kann dann sogar zur Laufzeit entschieden werden Da nicht alle Typen des Sichtenschemas in der glei INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 93 chen Form miteinander assoziiert sind kann die St rke der Assoz terung direkt mit den Typen verbunden werden Wir nutzen daf r eine Adhdsionsmatriz die zwischen den Typen des Sichtenschemas definiert ist e 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 e Die Zuordnung mu nicht vollst ndig angegeben sein f r Teiltypen eines Ty pen T Ist AM T Ta nicht definiert dann nehmen wir als Adh sion den Ab stand in der Typendefinition der Typen des Schemas an Ist ein Schema nicht zusammenh ngend und ist keine Adh sion unter den Elementen der nicht zusam menh ngenden Teilschemata defineirt dann nehmen wir AA4 T1 72 oo an Eine Adh sionsmatrix ist konservativ falls AM T
202. es unterscheiden INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 177 9 Die Dokumentation der Spezifikation Nicht Kunst und Wissenschaft allein Geduld will bei dem Werke sein Goethe Faust Erster Teil Hexenktiche Mephistopheles Entwicklungsdokumente In unserem Vorgehensmodell werden folgende Dokumente schrittweise erarbeitet verfeinert bzw dienen als Basis fiir 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 Finsatzfelder 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 kurz beschrieben sowie deren Einsatz und Gewinnung Produktdaten werden in Konzepten zusammengefa t und zu einer Konzeptlandkarte vereint Beschreibung der Produktfunktionen LF Es wi
203. esajel oqfiay m y u ss Ipy GaZO1g ueyeq uajuauodwoy 9 LIYOSSOTRICT upg 9TeMJJoS uouezg pun eyewoyag s3unpu muy ozssunIyHJsny 98697014 s yos so 4 Woy 891101 pun mans OSSIUSTOIO u uor yuni u voryun yuequoyeq ngay u19 S 9 ssunpuomuy my uodAT yq OSSTUSIOIO u r qur SS Z y fqo yen s r sypeydson suorqesrre3mo qosiyeq s r oldsiyenq s r Syyeypsar JOzusag ISSTUZTALI u r qur SS Z sqyyeyosos suorljestuesi0 9410 o dsayen s r n qepsiyeq s r izydney ydney 1 psyeyosesydney lop uossepy Rp SS TY Jaue d oyyodsy oyyadsy ayostze4s 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 fiir die gesamte Anwendungsentwicklung vorgenommen Besitzer in der Motivationsschicht Durch den Besitzer werden die Randbedingungen fiir die Entwick lung vorgegeben Entwerfer in der konzeptionellen Schicht Ein Entwerfer ist hauptverantwortlich in der konzeptio
204. ete 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 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 kann oder einschreiben kann und Begleit Daten die der Benutzer einsehen aber nicht modifizieren kann 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 erweitert um die Angabe type for modification for retrieval used for input for output for escort only displayed with subtype Um die Identifizierbarkeit zu gew hrleisten verwenden wir dabei evt auch Typen die dem Benutzer nicht angegeben werden Weiterhin k nnen diese allgemeineren Typen auch f r die Spezifikation der Funktionen verwendet werden Anreicherung der Sichtenschemata um Funktionen Ein Funktion ist allg
205. explizite Trans ferkomponente an Datenbank Farmsysteme wurden in YTS 99 eingef hrt Sie nutzen die Mechanismen von Sich tensuiten aus Informationseinheiten sind verallgemeinerte Sichten Diese Sichten werden mit einer Funktionalitat ausgestattet die sowohl Retrieval als auch Modifikation von Daten als auch die Arbeit mit den Daten unterstiitzt Container unterstiitzen 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 Verfiigung Datenbank Farmen erfordern einen Entwurfsschritt mehr Wir k nnen mit der vorgeschlagenen Methodik jedoch Datenbank Farmen auf der klassischen Datenbank Technologie aufsetzen So wurde 170 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 8 VERTEILUNG 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 Farm Lokale Anwendungel system Anwendungel Filter und Filter und Transfor Transfor Lokales ee 50 Lokale DBS DBS Bild 70 Generelle A
206. ezifikation von Informationssystemen el ER Schema Datenbank Maschine Interaktionsraum Diensteraum r Story Raum Content Typen Tice back Architektur Sicht Container Akteure Funktionalit t Szenen Kollaborationsrahmen Logische Spezifikation von Informationssystemen R relationales Schema Stored procedures Dini It Dienste und Kollaborations XML Schema Transaktionen eye verwaltungssystem Schema Programme Trigger berfl chen Verteilung Protokolle Qualit t Bild 5 Integrierte Entwicklung von Strukturierung Funktionalit t Interaktivit t und Verteilung Wir beabsichtigen den vollen Entwicklungsproze in seiner Gesamtheit zu begleiten Deshalb ist 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 ver
207. 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 186 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 DANKSAGUNG Danksagung fiir 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 als 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 mi
208. g Pa ralle lit t Ver trag Ar beits proze Part ner Dis kurs typ Part Gruppe Dien Port Organi ste folio sation 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 dar 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 veransta
209. g Daten Ak teure Dialoge zu ihrer Ausf hrung notwendig ist Durch Zeitregeln Ausf hrungsh ufigkeiten und 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 eine Kollaborationsdiagramm dar und beinhaltet die folgenden Angaben 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 A
210. g Ereignisse und Sichten mit Input Output in Eventknoten dargestellt Knoten sind Ereignisse 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 Be ein Sender als Erstellung als 1 gedeutete l s sung gehende und Ubertragung von Empfanger von Mittei Mitteilung Mitteilungen gedeutete anschlie enden lungen ermittelt gedeutete Transition Sichten H Information 5 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 Ein Arbeitsvorgang im Rahmen eines Gesch ftsprozesses wird beschrieben durch 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 eingehe
211. g 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 Sichtensuite Die Sichtensuite wird je nach gew hlten Transformationsmodus f r die Abbil dung 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 als physische Sicht erzeugt werden Relationale DBMS unterstiitzen oft nur typ basierte Sichten In diesem Fall wird fiir jeden Typ einer Sicht eine Sichtentypanfrage angegeben Der Zusammenhang der Sichten wird mit einer integrierten Sichtenanfragemenge in der logischen Sichtensuite 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 entspre chende XSL Regeln unterst tzt werden Wir k nnen die einzelnen
212. g von Basiskonzepten e Konstruktionsregeln 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
213. g von organisatorischen Ma nahmen Zum Erreichen des Zieles werden Ma nahmen anhand der vorher herausgearbeiteten 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 e Organisationsmodellierung nach der Sollstruktur 10 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 1 EINFUHRUNG 9 Feinmodellierung des zuk nftigen Gesch ftsprozesses Es kann nun die Aufgabenverteilung fiir 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
214. geben 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 klassischen 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 mit einer Folge von Attributen Markierungen sind als solche ausgewiesen Ein Entity Typ wird durch ein Rechteck graphisch repr sentiert 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 6 B 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
215. gemeldet inspect m t t Semt choose M w hlt ein Element aus einer Multimenge aus Wir ben tigen nur vier Zustandsver nderungfunktionen zur Ver nderung von 2 Z M O mit Elementen t T upelg und Mustern Muster Schnelle Beladung Die Funktion load ZxTupele gt Z mit load Z M O t 1 eval t O erlaubt eine sofortige Beladung von Containern Langsame Beladung Die Funktion lazzyload Z x Tupel Z mit lazzyload T M O t success eval t gt Z MU eval t 0 unterstiitzt eine verz gerte Beladung ohne auf die Beendigung der Berechnung von eval zu warten Lesen im Containers Die Funktion read Z x Muster x Tupel 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 Middleware 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
216. 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 Inder Verwendungsphase werden die Daten schrittweise erweitert um die Verwendungsgeschich te der Geb ude ihrer Bestandteile ihrer Pflege ihres Ersatzes ihrer Erweiterung und um Pro blemaufzeichnungen 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 Zusatz Zusatz Zusatz datenbank datenbank datenbank datenbank system system system system injiziert injiziert injiziert injiziert SP Usp S Use S Esr S Esm OP Nor O Moc O Xor O Nom modifizierbar modifizierbar modifizierbar Insert Insert gt Insert gt Injektion Injektion gt Injektion injiziert injiziert injiziert er DBS der Planungs 2 poe Vervendungs phase phase P phase Bild 71 Die allgemeine Architektur f r inkrementelle Evolution von Datenbanksystemen Inkrementelle Systeme v
217. graphischen Verfahren kombiniert werden INFORMATIONSSYSTEM ENTWICKLUNG IM Co DESIGN ZUGANG 8 153 Diese Modelle werden erg nzt zu Modellen 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 berlegungen sind wir jedoch in der Lage eine allgemeine Theorie des Kollaborationsraumes zu entwickeln Kollaboration spielt sich in drei Facetten e Kommunikation Kooperation und Koordination ab Der Kollaborationsrahmen von Seite 134 Kollaborationsrahmen Kollaboration Art des Zusa
218. h 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 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
219. haring 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 wird jedoch meist nur partiell sein 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 benutzen wie eine zentralisierte Datenbank Nichtsichtbarkeit der Lokalisierung bei sichtbarer Partitionierung Der Benutzer mu die Partiti on angeben nicht aber die Lokalisierung Sichtbarkeit der Lokalisierung und
220. he 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 Sichten Schemata 6 und und entsprechende Datenbanken ev und ey Fin partieller Schema Morphismus von und wird 102 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 6 SICHTENSUITE als Paar fi fG von Funktionen definiert so da fi eine partielle Einbettungsfunktion von Typen von G in Typen von 62
221. her zur Verf gung gestellt Der Zeitrahmen wird durch die Zusammenarbeit der Arbeitsgruppe vorgegeben Kooperation Vollst ndiges Dokument Dr ntention ulgaben Mitglied Deadline Leiter Rollen Verantwortlichkeit Zeitbeschrankung Ablauf A Moderator 2 Phase rbeitet mit Arbeitsgruppenmitglied Zeitintervall Gemeinsame ruppendokumente Wandzeitung ffentliche Art Existenz Lebensspanne y Funktionalitat Content Editieren j m rn Meinung nt Verpacken Antwor Kl r ume hi Arbeitsresultate Protokoll u rchiv Diskussionsraum Report Programm Bild 49 Der Spezifikationsrahmen fiir Arbeitsgruppen Sites Der Spezifikationsrahmen fiir 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 Storyraum umfa t z B den Dialogschritt einer Beitragserstellung Die Contentobjekte sind Beitr ge Sie werden mit der blichen Funktionalit t wie bei Texteditier systemen unterst tzt Die Beitr ge k nnen abgelegt zwischengespeichert oder auch gel scht werden Der Zeitrahmen wird durch den Aufgabenbereich der Redaktionsgruppe diktiert Dokumente die keine Endfassung darstellen werden nach der Redaktionsperiode gel scht oder ggf archiviert Wir k nnen den Spezifikationsrahmen aufsetzen auf der Theorie der Wortfelder Die detaillierte
222. hichtenmodell 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 hren Wir modellieren deshalb die Akteure in dieser Etappe mit ihren Rollen Rechten 106 B THALHEIM Motivations schicht Gesch ftsproze schicht Aktions schicht konzeptionelle Schicht Implementations schicht
223. hnittstellen 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 erhoben validiert und eingebracht in die Datenbank Eine typische Zeitdimension ist Tag Woche Jahr die mit der Dime
224. 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 Lokale Autonomie wird erhalten 2 H INFORMATIONSSYSTEM ENTWICKLUNG IM Co DESIGN ZUGANG 8 163 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 Datenbanksystem
225. hte und die darauf aufbauenden Rollen Das Portfolio der Akteure wird bestimmt durch die Aufgaben durch die spezifischen Rechte durch die spezifischen Rollen durch die Umst nde der Benutzung und durch die 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 DES GN ZUGANG BY 6 131 Version Navigation u a Funktionalit t sowie dem Sicherheitsprofil die Anpassung an den Benutzer wobei auch Ort Zeit und Benutzungsgeschichte variieren k nnen die Auslieferung von Content in Containern deren Typ variieren kann und die auch an pa bar sein m ssen an die verpackten Content Objekte 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
226. hwieriges 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 Schon die Schreibweise bzw die Art der Abk rzungen ist f r Texte vereinheitlicht Die Schl sselanpassung
227. i gefordert wird da sich die Relation R aus den Teilrelationen wiederherstellen l t durch Vereinigung dieser Teilrelationen Damit m ssen die Bedingungen a 9 und y als Disjunktion 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 zur Partitionierung Selektion und Projektion angewandt A Aa A A Ap As A A Ag A 152304 Relation Ra 2 Relation Ry 04 R Relation R3 0 R horizontale Partitionierung 1 Rekonstruktion Dekompostion durch Selektion R Ri U R U R A Az A Relation R vertikale Partionierung 1 x Rekonstruktion Dekomposition durch Projektion R R HA As X R YA A Aa A A Relation B RUHA Ao A elation HA A3 RUAL AY Bild 64 P
228. ichten 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 Identifikation des Typs angezeigt 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 Sichtensuite Es werden die Sichten als konzeptionelle Sichten in ihrem Zusammenhang mit einer Erweiterung um gef 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 Modifikation in der Datenbank sich auf die Sicht auswirkt Diese Materialisierung nutzt dann das folgende Schema extend Sichtenschema by MODIFIKATIONSMODUS store ABLAGE SC
229. ichtweiterf 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 Nutzung des riesigen TB Datenbestandes bei gleichzeitiger Pflege erreicht wurde INFORMATIONSSYSTEM ENTWICKLUNG IM CO DES GN ZUGANG 171 py 6 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 fiir Sichtensuiten 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 Fiir Facility Management Systeme ist keine Systematik bekannt Diese Systeme besitzen einige Phasen In der Planungsphase werden die Daten zu Geb uden und den Bestandteilen 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 Architekturphase wird die Geb udearchitektur entwickelt Es entstehen zugleich un terschiedliche Sichten auf die
230. ie 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 tsbedingungen kurz and allgemein dargestellt Dazu kann sowohl ein hierarchisches ER Modell herangezog
231. ie 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 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 Der Austausch wird durch durch eine entsprechende Dienstgeber Dienstnehmer Architektur INFOR
232. ieren aufbaut weder fremdsprachig noch 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 Arbeitsgrunppe unter dem Begriff omasicher zusammengefa 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 142 B THALHEIM PREPRINT BTU INFORMATIK I
233. ieren nicht etwa den Endan wender In diesem Zusammenhang werden auch die Beziehungen der Endbenutzer soweit 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 Es wird damit jedoch die Implementierung 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 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
234. ig 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 kontrollierte Redundanz partiell ber winden Transparenz wird in der Informatik verstanden a
235. igen Integration interessiert sind dann k nnen die Gleichungen ersetzt werden durch Term Ersetzungsregeln der Form T fi T oder fi T T 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 IT TT al eu li EU T S EU T 5 U T S1 Tm Sm EU S T Vrus U T S f r Substitution von vr 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 Interaktivit 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
236. iger Data stores data warehousing and the Zachman framework Mac Graw Hill Quebcor 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 Springer Berlin 1978 In German L A Maciaszek Database design and implementation Prentice Hall Sydney 1990 D Maier The theory of relational databases
237. ikation der Systemorganisation und architektur Die Aktions schicht ist mit dem Abstraktionsschichtenmodell eingef hrt worden um eine explizite Darstellung der INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 35 Anwendungsszenario vornehmen zu k nnen Im klassischem Systementwurf wird diese Schicht meist bergangen und zu einem sp teren Zeitpunkt durch entsprechende Sichtensuiten 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 vurf Spezifikation nteraktivitat Konzeptionelle Sehicht Imple men tation Spezifikatior der Strukturierung Implementations schicht Spezifikation der Funktionalitat Bild 16 Das Abstraktionsschichtenmodell des Info
238. ilung Dialoge Funktionen Str 1 Motivations schicht 2 3 Gesch fts proze schicht 4 6 8 8 10 Aktionsschicht 11 145 12 16 13 Teils 18 17 Konzeptionelle 19 Schicht 20 21 9 22d 22 22c 22d Mn 24d 24a 24b 24c 244 25 25 Implementations schicht 26 27 27 26 1 27 gt 28a 28b 28c 28d Bild 17 Schritte in unserem Vorgehensmodell INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 Al 6 m 10 11 12 13 14 15 16 17 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 Contenttypen Spezifikation der Qualit tsanforderungen und deren Umsetzung im System Entwicklung von Sicherungsstrategien Konzeptionelle Schicht Spezifikation des Storyraumes Spezifikation der Akteure ihrer Portfolio Rollen Rechte Profile Spezifikation der Sichtensuite der Dienste und Austauschrahmen Entwicklung der Workflows Kontrolle der Contenttypen anhand von Contentobjekten Validierung der statischen Semantik Kontrolle der Integrit tserzwingung Spezifik
239. 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 Madchen Riide 2 Welpe Analog kann auch eine generelle Klasse eingef hrt werden Diese Beobachtung f hrte V J Propps Pro72 zu seiner Spezifikation der M rchen Er stellte z B f r das M rchen Die wilden Schw ne den Ausdruck iblatc At BAC Sch H Z seh Z VV L N V Sch H Z R x 3 auf Die Buchstaben werden jeweils f r eine Konzeptfeld verwandt z B I 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 Klassen in denen Workflows a
240. indeutiges 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 rekursiv oder iterativ aufgrund ihrer Architektur und Entwurfsgeschich te aufgebaut PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 3 ABSTRAKTIONSSCHICHTENMODELL B THALHEIM 32 U ST A U S Usp UI ff pours3unypyorAqun seq II IPP OP 3X9 U0 JO JNO u u uoduroyi Fungw yasagl S H P OTN T3oTouU9 T Joules pun soyynpo g s p Sunqr rq s gi Jasaljquawe du a TPPOIN wagsAg soyyNpoig UINeIgNsgqe s p Sunqto1yoseq S sopeoy 1 21150 a soumneijetdg s p Sunqro1yosoq soumneipetdg s p Sunqreryosog Jaueld 1 14 1912 uesnz pun Usp PIU EPoN uewuydez seq Tepowsdun ynjsny Tepoun s ndwond n poyy r urequoo umesfio01g ued 13001 ued uorjeyyizeds usuor WIT oreu zg uoDdD usp s T3 qens sZunIynjsny SUOTJESIUCZIO eyolly Z2 N assezoig Unyans 8 ff pour sunsuIp s unuq s gi qu uoduroy qu
241. ion 66 Ausbildungsprofil 114 Ausf hrungsmodell 119 Austauschrahmen 147 Auswahl von Objekten 61 Barrierefreiheit 140 Bedeutungstreue 149 Begriffslandkarte 150 Benutzer 113 Benutzer Arbeitsplatz 99 Benutzer Gesichtspunkt 104 Benutzungskontext 130 Benutzungspraferenz 116 Beweglichkeit 149 Closed world assumption 5 Cluster Klasse 46 Cluster Typ 46 Codesign Modell 18 189 Container 95 Content Klasse 85 Content Objekt 85 Content Typ 85 Corporate design 136 Corporate identity 140 CSCW 147 Daten Typ 36 Daten Warenhaus 172 Datenbank Farm 169 Datenbank Schema 51 Datenbanksystem 3 Dauerhaftigkeit 150 DBMS 3 Delete 61 Deontische Bedingung 72 Dialogschritt 37 107 109 123 Dialogszene 37 123 Dienstverhalten 29 Dienstvertrag 29 Differenz 61 Diskurs 105 177 Drehbuch 104 Durchschnitt 61 Effekt 64 Einfiigen von Objekten 61 Einf hrungsschicht 35 Entfaltbarer Workflow 77 Entfalteter Workflow 77 Entity Klasse 45 Entity Typ 45 Entschachtelung 61 Entwicklungsschritte 177 ER Diagramm 48 ER Modell 48 Ereignis 107 178 Erreichbarkeit 149 Ersetzungsfamilie 60 Evolution res System 170 Exklusionsabh ngigkeit 51 Fragmentierung 160 Freiz gigkeit 149 Funktionale Abh ngigkeit 49 Generative Programmierung 129 Generischer Workflow 77 Gesch ftsproze 178 Gesch ftsproze schicht 34 Gestaltungsrahmen 111 134 136 138 190 B THALHEIM PREPRINT BTU
242. ion 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 kann man zwei grunds tzliche Zug nge zur Gestaltung von Oberfl chen ableiten 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 sein sind einfacher auch durch den Benutzer zu pflegen und f r den eingearbeiteten Benutzer auch durchschaubar 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 INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 147 8 Sprachen zur Darstellung der Verteilung Entzwei und gebiete Tiichtig Wort Verein und leite Bessrer Hort Goethe Sprichw rtlich Allgemeine Architektur von Kollaboratio
243. irken 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 8Die 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 ein effizienter Updateservice auf der Grundlage einer guten Updatestrategie m glich ist INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 117 Mit Akteur Zusammer Art der arbeit usammenarbeit Von Erf llungs kriterium Medien Typ Aufgabe Bild 41 Die Zusammenarbeit von Akteuren zum Erreichen von Zielen Finem Akteur kann ein Sicherheitsprofil zugeordnet werden Wir vervvenden dazu eine Daten struktur wie in Bild 42 27 Verbote Aufgabe 7 Akteur Lowi Benutzer m Rolle rolle Bild 42 Das Sicherheitsprofil von Akteuren Das Sicherheitsprofil eines Akteurs wird charakterisiert durch Sicherheitsoptionen mit denen die gesam
244. 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 bei minimalen Aufwand be nutzbar sind 174 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 8 VERTEILUNG 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 auszulegen f r sehr gro e Datenbanken 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 Benutzer nicht in der Lage ihre spezifischen Anfragen in einer abstrakten Notation zu formulieren Deshal
245. k Voraussetzung vorausgesetzt 0 2 gilt Damit haben wir quivalente Formen F r n re Relationship Typen ohne eigene Attribute ist die Lookup Notation look R R n m quivalent zur verallgemeinerten Kardinalit tsabh ngigkeit card R R Ri n m In unserem Beispiel k nnen wir z B eine Einschr nkung da erst dann ein Eintrag in die Klasse legtab gef hrt wird wenn der Student eine Vorlesung erfolgreich abgelegt hat wobei das Resultat nicht mitgef hrt wird als Lookup Bedingung unter der Voraussetzung da nur Pr fung und Schein bzw Schein und Praktikum bzw Pr fung und Praktikum absolviert werden m ssen dargestellt werden durch look legtab Ablageform 0 2 dargestellt Diese Bedingung ist quivalent zu card legtab Student Vorlesung 0 2 Eine Kardinalit tsbeschr nkung card R R 0 1 ist quivalent zur funktionalen Abh ngigkeit R Ri gt R Eine Lookup Kardinalit tsbeschr nkung look R Ri 0 1 ist quivalent zur funktiona len Abh ngigkeit R R R 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 N
246. kflow 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 konzeptionellen und der Implementationsschicht auf der Grundlage von V
247. ktion Integrit tsbedingung Im Detail stellt sich die Entfaltung der Tabelle von Seite 57 wie folgt dar INFORMATIONSSYSTEM ENTWICKLUNG IM CO DES GN ZUGANG 6 59 Handlungen des Akteurs Eintrag einer Lehrveranstaltung nach Aufforderung Ausl ser Organisatorische Einheit Hilfs und Zusatzinformation ntegritatsbedingungen obligatorisch Beendigung_Bis_Termin erlaubt Entfernung von Angebot verboten Parallelangebot zu anderem Lehrstuhl Methodenregeln Ausf hrung Mit_Unterbrechung Erinnerungsskripte tempor re Ansicht Gruppenarbeit Erfolgsmeldung Umgebung Sitzung Objekt 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 Inhaltsbes
248. ktur des Dienste und Kollaborationssystemes 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 wird kann z B f r Trader Architekturen in einer e Learning Anwendung wir z B http damit dfki de INFORMATIONSSYSTEM ENTWICKLUNG IM CO DES GN ZUGANG Motivations schicht Gesch ftsproze schicht Aktions schicht konzeptionelle Schicht Implementations schicht Vorstudie Skizzierung Vertragsraum Feinstudie Verfeinerung BY 6 157 Dienstanforderungen Lastenheft Verteilung Kollaborationsvertrag Pflichtenheft Verteilung Kbllaborat Entwurf Entwicklung ionsraum Kollaborationsrahmen Qualitat Diensteraum Implementation Transformation ertei
249. kumente 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 777 Kommunikationssysteme 77 777 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 beriicksichtigen 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 Zusammenwirkens 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
250. laboration e Broker bzw Trader Customer Kollaboration Client Dispatcher Kollaboration e Publisher Subscriber Kollaboration und Model View Controller Kollaboration Die Architektur kann als Verallgemeinerung der Architektur verteilter Datenbanksysteme 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 hinnen 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 diesen Anforderungen die Aufgabe Strukturierung F
251. langt 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 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 berladen 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 o
252. ldet z B pr positionaler Akt Typische Darstellungsformen sind Assertion Direktive Kommissive Deklarative und Expressive F r den perlokation 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 t dient der Einbettung des Dialoges in die Spezifikation der Funktionalit t Ein Content Typ Benutzer Arbeitsplatz sollte die eine oder 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 ihren Portfolio Aufgaben Umst nde und Ziele gruppiert Diese Abstraktion wird durch Einf hrung von Akteuren unterst tzt Arbeitgruppen Eine Zusammenarbeit findet in Arbeitsgruppen und zwischen Arbeitsgruppen statt Diese Interaktionsfor
253. ler 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 einer 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 INFORMATIONSSYSTEM ENTWICKLUNG IM CO DES GN ZUGANG BY 6 111 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 end seine Qualit t d h insbesondere die folgenden Qualit tskriterien Benutzerf hrung Die Akteure ben tigen neben einer angepa ten Hilfe auch eine F hrung durch komplexe Prozesse Differen
254. leth ppl modu zu Person D Content befin at Profi Obyekt sich i Bereehtigung Ro befindet Arbeits Firma Rolle as ext Kategorie Raum 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 Aufendarstellung 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 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
255. lichen Facetten der Kol laboration werden durch einen 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 Vermittllung 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 INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 141 Einordnung in Zielgruppen Polaritaten Profil insbesondere das psy
256. licher 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 Extraktionsfunktionen des Content Typen aus dem Content Objekt gewonnen werden k nnen Allgemeine Beschreibungen des Inhaltes und der Strukturierung der Content Objekte einschlie lich der Variablen 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 un
257. ls 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 Wir nehmen au erdem an 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 aktu elle 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 seine entsprechenden Lernelemente angeboten bekommt und 76 B THALHEIM PREPRINT BTU INFORMATI
258. ls das Verbergen der einzelnen Komponenten vom Benutzer des verteilten Systems 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 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 15 Transparenz ist in der deutschen Sprache dagegen ein Synonym von Licht Durchl ssigkeit 152 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL
259. lt 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 110 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 7 INTERAKTIVIT T Kategorisierung der Endbenutzer Aktionen und Dialoge existieren nicht unabh ngig von den Akteuren Es k nnen die Akteure kategorisiert 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 charakteris
260. ltes System Kollaboratives System a Contenttypen Kollaborationsrahmen Architektur ienste und Kollaborationssyste Verteilung Protokolle Bild 62 Die Arbeitsprodukte im Abstraktionsschichtenmodell f r die Verteilung 158 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 8 VERTEILUNG wie folgt zusammengestellt werden Trader Kommunikation Kooperation Koordination Kollaborations rahmen Architektur Asynchroner Client Kooperationsmanager Koordinationsmanager Content Suite Management System Formation Modell Protokoll Trader 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 Fine 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
261. ltung betrachtet werden 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 l gabe ord kurs ner ste folio mens nisa mo nung typ raum tion dell 156 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 8 VERTEILUNG Die unterschiedlichen Bestandteile von Kommunikation Kooperation und Koordination k nnen f r das Arbeitsblatt zusammengefa werden zum Austauschrahmen 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 Unterstiitzung Zugriff zur Imple mentation der Kollaboration und den Kollabor
262. lung verstreute Kopplung und spezifizierte Kopplung Die Vererbungskopplung folgt der hierarchischen Struktur der Typen des Schemas Je nach Erzwingungsmechanismus unterscheiden wir nderungskopplung Signatur nderungskopplung bzw Implementations nderungskopplung Verfeinerungskopplung Signaturverfeinerungskopp lung Implementationsverfeinerungskopplung und Erweiterungskopplung Durch die Koh sion wird die Bindung zwischen den einzelnen kooperierenden Objekten beschrie ben Es existieren verschiedene Arten aufgrund der Modellierung Die Operationskoh 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 Typkoh 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 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 INFORMATIONSSYSTEM ENTWICKLUNG IM Co DESIGN ZUGANG 8 135 Zur Gestaltung von Software und insbesondere von Dialogen nach ergonomischen Kriterien stellt die DIN N
263. m gew hlt wird h ngt vom erforderlichen Detaillierungsgrad ab Sollen At tribute mit dargestellt werden wird das hierarchische ER Modell sehr schnell zu un ber sichtlich In den ersten Abstraktionsschichten stellt es aber eine gute Alternative zum HERM Diagramm zum een Diplomand Diplomas Side Person Universitatsmitarbeiter Professor Projektmitarbeiter 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 bezechnet Z B sind Person und InGruppe Klassen entsprechenden Typs Statische Integritatsbedingungen 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 Kardina lit tbedingungen zur Spezifikation der Beziehung zwischen einem Rel
264. mata ist nur relativ umst ndlich und abstrakt darstellbar Das damit erforderliche Abstraktionsniveau berfordert auch aufgrund der Komplexit t die Entwerfer Selbst die Perle der relationalen Theorie die Normalisierungstheorie erfordert vom 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
265. meinerung von Sichten darstellen und um eine Funktionalit 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 Funktionalit t eines Datenbanksystemes 4 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 1 EINFUHRUNG 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 TZG97 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 abgesti
266. men auf diese Anwendung am Ende des Abscchnitt noch einmal zur ck Zuerst stellen wir unseren Zugang zum Gestaltungsrahmen vor Der Gestaltungsrahmen ist spe zifiziert durch INFORMATIONSSYSTEM ENTWICKLUNG IM Co DESIGN ZUGANG 8 139 Playout mit Werkzeugen Layout Metaphern Akteure und Qualit tsanforderungen 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 sind in eine Vielfalt in den 90er Jahren ent wickelt worden da eine bersicht schwer f llt Zugleich f llt ins Auge da fast alle diese Werkzeuge keine gro e Verbreitung gefunden haben Ein Ursache ist sicherlich auch der Hang zur featuritis Die Werkzeugentscheidung sollte sich an einer
267. men fiir die Definition der logischen Sichten Im allgemeinen ben tigen wir jedoch in Anwendungen komplexere Unterstiitzung Spezifkation einer Sichtensuite Zur Begleitung der unterschiedlichen Arbeitsschritte sind auch unter schiedliche zusammenh ngende Sichten zu definieren Spezifikation einer Funktionalit t f r die Sichtensuite 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 Sichtensuiten k nnen auch durch logische Sichtenanfragemengen unterst tzt werden Die Funktio nen sind mit einem allgemeinen Funktionsrahmen allgemein darstellbar und dann an die konkrete Sichtensuite 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 Einstellungen automatisch weitergef hrt werden k nnen Sitzungsobjekte k nnen di rekt realisiert werden oder
268. men 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 Erledigung 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 zu ggf zu unterschiedlichen 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 je nach Einwahl und Ausweis als Akteur e je nach Gruppenzugeh rigkeit e je nach Content Objekt Menge bzw Container 100 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 6 SICHTENSUITE Memo kategorie Aufgaben Ziele antwortungs Ve typ nutzt Content eitergabe Typ art Akteur Portfolio art freigegebe lt gt Atis
269. mierung von einer klaren Semantik profitiert erlauben diese Art von Verwirrung nicht bei der Spezifikation WF W Fy W F W F Bild 31 Ein berlagertes und verwirrendes Workflow Programm Dieses Programm vermischt Ausf hrung Sequentialit t und Nebenbedingungen zur Entscheidung Die Alternativen sind vereinfachbar wenn sicher ist da z B W F2 vor WF 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 F3 W F3 V Fy V WF4 WEF A vI VV FA W Fo W Fo Bild 32 Ein OR AND und eine 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 Gr nden bevorzugen wir die etwas rigidere Semantik der Wor
270. mit dem Definiti onsbereich def fi2 G12 ist is ist die korrespondierende Einbettung von Klassen von Gt in die von e d h Ti Gy 62 und fG T 6 mit der Eigenschaft 7 6 6T Er zl fis r falls fi definiert ist f r den Typen T d h die Abbildung fi2 erh lt die Semantik von G2 Damit kommutiert das linke Diagramm in Bild 37 Die Partialit t von f12 definiert ein Sichtensehema 611 in G und eine Sicht f12 611 in Es sei au erdem ein partieller Sehema Morphismus f21 von G1 und Gz gegeben 6 G 12 67 Go Sh 2 FRN z G m fx Sx 65 55 Bild 37 Partielle Schema Morphismen zur Sichtenkooperation Die Schema Morphismen fi2 fG und 21 fK definieren eine Sichtenkooperation falls f r jeden Typ 7 S N fo1 G21 und jedem Typ 7 Gai N fi2 Gi1 f r jedes Paar der entsprechenden Klassen TC GY T GF die Funktionen S T 0 FE TS FSCS TY definiert sind und die kommutierenden Gleichungen fS fG TP TE TY gelten Durch die Sichtenkooperation wird ein Input eines Schemas mit dem Output eines anderen Sche mas verkniipft Diese Verkniipfung erlaubt eine Verbindung von Sichten wie in Bild 37 bei Angabe der Funktionen fi und fa Sind die Typen der Sichten entweder ber Schema Morphismen
271. mmenwirkens Arbeitsplatz Form Rollen 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 158 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 name Zielobjekt Parameter Damit wird eine Ortstransparenz reali
272. mmt erfolgen Lokalisierung wo Anwendungen sind 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
273. n 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 Ereignisse 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 aber auch der Arbeit die Aufmerksamkeit entzogen werden Damit wird die Exposition von Ort und Zeit zum Entwurfsproblem Auswahl der Informationen Ein Szenario kann verstanden werden als eine Folge von Ein zelinformationen Alle Informationen 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 Informationsauswahl ist daher die Kenntnis aller Fakten ber den
274. n 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 f hren 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 f gen diese Verpackungsinformation mit dem Content Objekt zu indem durch Variable Werte Paare eine erweiterbare Attribut Information mitgef hrt wird Container f r die Auslieferung von Content Objekten Content Objekte sollen dem Benutzer zur Verf gung 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 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
275. n Typen T R r R oR f r die Konkatenation o und die neue Klasse oe Dom T 30 R o R r R oO R r R A olX o X 62 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 5 FUNKTIONALITAT Potenzmenge Die Potenzmenge P R M M C R ist eine geschachtelte Klasse ber dem Typ R Umbennenung Gegeben sei ein Typ R Es sei 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 RC auf eine Klasse pg R o R ber d R ab Verbund Der Verbund 201 x 502 ist definiert durch den Ausdruck Hrus o rasen rans SC2 eh So 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 miissen zwei Eigenschaften beziiglich der Ordnung auf 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
276. n der Modellierung Urteile durch den Modellierer gef llt welche Dinge der Realit t f r welchen Ausschnitt mit welchen Eigenschaften von Interesse sind Es gibt eine ganze Reihe von Urteilen die f r uns von Interesse sind e 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 e 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 Ansatz im folgenden 16 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 1 EINFUHRUNG den im Kontext agierenden Individuen
277. n vorgenommen Dazu geh ren insbesondere auch Listen von Obligationen die erweitert werden beim Entstehen weiterer Obligationen und die verk rzt werden beim Erf llen von Obligationen 182 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 LITERATUR Weiterfiihrende Literatur Fine Literaturliste zum Co Design von Strukturierung Funktionalitat Verteilung und Interaktivitat wird 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 VVeb95l wurde aber die Objekt Orientierung zu stark mit Konzepten berladen ohne auf deren Integrierbarkeit zu achten Au erdem wurde mit der Orientierung auf Einzelobjektspezifikation den Belangen der Massendatenverarbeitung zuwider gehandelt Deshalb fri sten 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 erscheint fast unm glich Um eine weitergehende Lekt re zu erleichtern verwenden wir deshalb die folgende Klassifikation Hauptliteratur
278. n 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 orientiert man an den F higkeiten der Benutzer und ihren Bed rfnissen ob ein black boz Zugang der dem Benutzer Details der Implementation vollst ndig vorenth lt ein glass boz 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 ist ist auch bei der Gestaltung die Wirtschaftlichkeit zu beachten Die Oberfl chen sollten generisch bzw parametrisch sein oder zumindest einem Standard folgen der mit der Anwendung korrelliert Die Wiederverwendung von existierenden Oberfl chen erleichtert ebenso wie die Standardisierung 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 optimierbar sein Die Gestaltungsprinzipien k nnen in einem Qualit tskatalog zusammengefa t werden Sie werden zur Bewertung der Oberfl che herangezogen Zieltechnik
279. narchitektur 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 genz und zur Simulation INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 175 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 Schnupperangebote sollen zur Benutzung des Warenhauses verleiten Die Akzeptanz des Warenhauses kann dadurch verbessert werden Sc
280. nd lungen und Workflows entwickelt Das einfachste Modell ist das Modell der Job Control Language JCL Dieses Modell wurde f r Skriptsprachen erweitert Eine Transaktion kann ebenso wie ein Modul als abstraktes Programm aufgefa t werden mit einem Namen und formalen Parametern f r den Input Output und die Reporte zum Programmdurchlauf Jedem abstrakten Programm sind Parameter Werte Paare zugeordnet die entweder zur Auf rufspezifikation oder zur Steuerungsspezifikation herangezogen werden Diese Parameter sind entweder ereignisbasiert oder wertebasiert Wir verwenden solche Ereignisse oder Werteparame ter in der konzeptionellen Schicht um einen allgemeinen Rahmen f r die Implmentationsschicht schaffen zu k nnen Zu solchen Parametern geh ren 66 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 5 FUNKTIONALITAT e allgemeine Aufrufparamater 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 Fehlerparameter
281. nde 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 Anwender 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 INFORMATIONSSYSTEM ENTWICKLUNG IM Co DESIGN ZUGANG 8 109 A
282. nde Daten Unterlagen eine organisatorische Einheit die eine Aufgabe durchf hrt eine Tatigkeit der Benutzer bzw einen Ablauf von Tatigkeiten der Benutzer verwendete Hilfsmittel und Zusatzinformationen die diese Tatigkeiten untersttitzen und einer Ablage und einem Adressaten in die oder an den Ausgaben erfolgen 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 Eintrag Kontrolle Abschlu 107 er Daten zur er 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
283. nders 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 INFORMATIONSSYSTEM ENTWICKLUNG IM Co DESIGN ZUGANG 8 183 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 94 Bro00 BS97 503 CP84 Dad96 DGH 3 Dre95 DT04 Ebe94 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 theory Addison Wesley Redwood City 1993 M Agosti Database design A classified and annotated bibliography Cambridge University Press
284. nderungen modelliert Die Prozesse veranlassen legale Transitionen von Zust nden Darauf aufbauend k nnen die Integrit tsbedingungen durch Bedingungen zur Ausf hrung und durch Nachbedingungen 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
285. ne Wertezuweisung an alle Parameter zu einem Szenarium Diese Direktspezifikation wird insbesondere f r Informationssysteme angewandt deren Pr sentati onssystem nicht generiert werden soll Mit einer redundanten Entwicklung von Elementen ist die Einf hrung von Identifikatoren f r die Elemente sinnvoll Dialogschritte k nnen spezifiziert werden durch Tabellen der folgenden Form Dialog on event Vorbedingung Contentobjekt zugelassene zugelassene Akteur accept on schritt 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 Storyraum 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 INFORMATIONSSYSTEM ENTWICKLUNG IM CO DES GN ZUGANG BY 8 125 Dialogszene Steuerung Ereignis Vorbedingung Akzeptanzbedingung n chster Dialog schritt Contentobjektsicht Manipulations zugelassene l operation O
286. nellen 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 Anderungen der Entwurfsdokumente sind abzustimmen Komponentenlieferant in Abhangigkeit 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 minstration Leitung Infrastruktur Rollen der Gestaltung Projektierung Architekt Berater und Rollen der Ausf hrenden Entwerfer Designer Programmierer Das Zachman Modell verdeutlicht unterschiedliche Abstraktionsschichten mit unterschiedlichen Spezi fikation und unterschiedlicher Detaillierung Ein integrierter Entwurf mu deshalb auch unterschied liche Detaillierungsgrade erm glich
287. nerhalb 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 Diese Zugang stellt einen allgemeineren Zugang dar erbt allerdings auch die Nachteile von GAV und LAV Die strukturelle Integration ist definiert als Tripel I G 6 M bestehend aus einem globalen INFORMATIONSSYSTEM ENTWICKLUNG IM Co DESIGN ZUGANG 8 169 Datenbankschema G iiber einer Sprache Ag einer Kollektion G von lokalen Datenbankschemata S ber einer Sprache As und einer Abbildung zwischen G und Die Architektur von Systemen die ber strukturelle Integration realisiert werden ist in Bild 69 dargestellt Lokales Lokales Lokales 1 Schema 2 dehema n Globales konze
288. ng A B B B Die verwendeten Zug nge kann man klassifizieren wie in Bild 68 dargestellt Mehrrechnersysteme Externspeicher zuordnung gemeinsam partitioniert Topologisch Verteilung lokal lokal ortsverteilt Rechner eng nahe lose nahe lose lose kopplung 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 Universalitat 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 Die beiden letzten Architekturen haben eine Reihe von Vor und Nachteilen INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 167 Kriterium Shared nothing Shared disk Leistungsfa statische Datenpartitionierung be stimmt lokale Erreichbarkeit alle
289. ngebot 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 Raumzuordnung 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 Ordnung 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 Elemente So k nnen z B Objekte vom Typ geplanteLehrveranstaltung in Bild 20 kann auch nur Objekte verweisen werden 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
290. nheitlicher 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 abgelegt ohne einen Hinweis auf den letzten update oder auch ihre G ltigkeit 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 abge legt Deshalb sind hier auch Probleme zu l sen die f r die Sichtenintegration typisch sind Ein sc
291. nnerhalb des Kollaborationsvertrages ver ndert werden d rfen Meist ist eine nderung ein Streichen 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 nde rung wird dann in den vererbten Varianten fortgeschreiben Facility Management Systeme werden in sehr unterschiedlichen Bereichen angewandt wie im Baubereich f r Patienteninformationssysteme im Verwaltungsbereich und bei Kunden Management Systemen Sie sind eine spezifische Form der evolution ren Datenbanksysteme Neben inkrementellen Datenbankssystemen sind auch Archivdaten banksysteme 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 Sonderforschungsbereich an der BTU Cottbus und die N
292. ns und Diensteverwaltungssystemen Wir modellieren die Verteilung von Informationssystemen als Kollaboration oder Zusammenarbeit von Systemen Systeme oder Akteure arbeiten tempor r zusammen zur gemeinschaftlichen L sung von Aufgaben Sie bilden einen tempor ren Verbund oder eine tempor re Arbeitsgruppe verf gen ber gemeinsame Arbeitsinstrumente z B eine Objektsuite und folgen einem Kollaborationsvertrag 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 Kollaborationsdienst
293. nsion 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 Bild 73 darstellt Der Relationship Typ basiert dabei auf den Relationen 176 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 8 VERTEILUNG KUNDE XundenNr KundenName Geschlecht Alter PRODUKT ProduktNr PName PGruppe Branche Hersteller Farbe Preis ZEIT Datum Tag Monat Quartal Jahr FILIALE FName Ort Land Region und besitzt auBerdem die Attribute Anzahl Umsatz Land Berlin VERKAUF Brandenburg 10 Meck Pomm Kund
294. ntiert auf eine Verallgemeinerung ohne Bezug zur kon 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 ebenen verteilt werden 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 fiir 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 fiir 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 Darstellun
295. ntworfen 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 stellung der Suchmechanismen sollte zum einem integriert erfolgen zum anderen durch die Architektur in separaten Einheiten gehalten werden Insbesondere sollten der Suchmechanismus und die verschie denen Verkn pfungsnetze nicht mit der Information gemeinsam dargestellt sein Eine Integration bedeutet 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 Inf
296. nwendung 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 Sichtenintegration wie die im folgenden behandelten Probleme nicht auf 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 eine entsprechende Sicht erzeugt die die Ver arbeitung der Daten
297. nz 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 o Intra TA Parallelitat o o o Erweiterbarkeit o o Verfiigbarkeit o Verteilungstransparenz o geographische Verteilung o Knotenautonomie DBS Heterogenit t o 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 Das lokalen Schemata sind vollst ndig in
298. on Spezifikationen aus den Objekten der Datenbank erzeugt Das allgemeine Vorgehen der statischen Datenbankmodellierungsprachen l t sich somit wie folgt charakterisieren e Typen sind ber ihre Typausdr cke 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 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 Klassen sind Typen zugeordnet e Sie stellen Container f r die Objekte des jeweiligen Typs dar e 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 Korrek
299. onalit t Benutzbarkeit und Effizienz in gleichem Ma e ber cksichtigt Die Qualit t von Schemata wird bestimmt 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
300. onisationsmodell zum Abgleich der Ausf hrung von Aufgaben die sich im Arbeitsbe reich befinden Das Ausf hrungsmodell kann durch Rahmenbedingungen e wie Angaben zur Zeitdauer minimal maximal normal und e den Ausf hrungspriorit ten erg 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 120 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 7 NTERAKTIVITAT Die Variablitat ist bestimmt durch den Zusammenhang der Arbeitsvorg nge und der Vorgehensweise zur Aufgabenerf llung Die VVahrnehmungen des Benutzers unterst tzen die schnellere Erfa
301. ooperationsformen 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 Zusammenarbeit 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 Pos
302. orientierte Entwicklung Es wird zuerst die Funktionalit t der Anwendung entworfen und pro totypisch realisiert Danach werden die entsprechenden Datenstrukturen entwickelt danach die Pr sentationskomponente und die entsprechenden Sichten Dieser Zugang wird im Software Engineering pr feriert entspricht aber selten den Gegebenheiten der Entwicklung von Informa tionssystemen 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 Storyraum 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 de
303. orkflow Schicht Implementation Transformation Prozesse Workflow Maschine Implementations Module Programme Transaktionen ored procedures Datenbank Maschine Bild 26 Die Arbeitsprodukte im Abstraktionsschichtenmodell fiir die Funktionalitat 56 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 5 FUNKTIONALITAT 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 Darstellun
304. orm 66234 Teil 8 folgende Kriterien auf Erwartungskonformitat Ein Dialog ist erwartungskonform wenn sich die Erwartungen Erfahrungen und bisherigen Handlungen der Benutzer im Dialog wiederspiegeln Steuerbarkeit Ein Dialog ist steuerbar wenn er dem augenblicklichen Arbeitsstil der Geschwindigkeit 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 wesentlichen Parametern Benutzbarkeit Durchlauf etc beeinflu t werden Benutzbarkeit Die Benutzbarkeit bzw Brauchbarkeit kann durch verschiedene Parameter bewertet werden 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
305. ormation 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 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
306. oryraum 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 durch Angaben zu 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 w ltigung 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 Spezifikation 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 K
307. otation in verschiedenen Formen definiert DBIV SS2002 9 DBI WS2002 3 Compiler SS2002 PB gt Schein Priifung Praktikum Informatik TIT VVS2002 BvB Informatik III WS2003 8 Antje B rbel 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 III WS2002 BvB als auch DBIV SS2002 3 mit Pr fung und Schein abgelegt Emil dagegen nur Scheine in Informatik II WS2002 BvB und DBI WS2002 8 Kardinalit tsbeschr nkungen sind mitunter nicht erf llbar in nicht leeren endlichen Klas sen Ein Beispiel einer solchen nicht erf llbaren Menge von Integrit tbedingungen ist das Paar card Voraussetzung setzt Voraus 0 2 card Voraussetzung vorausgesetzt 3 4 Dagegen ist INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 l card Voraussetzung setzt Voraus 0 3 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 Unp Xn mit Teilmengen X Y C Up und Z Up Y UX
308. otokoll Recovery globale Deadlock Behandlung Lastverteilung balancierung Administration besondere Probleme in ortsverteilten Syste men Netzwerkpartitionierungen Knotenau tonomie Lastverteilung balancierung parallele Anfrageverarbeitung Administration 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 ist i Allg nur
309. peration _ gugelassener Akteur _ Transition nach 2 Dialogsschrittausdruck Dialog schritt Akteure Rechte Aufgaben dnung Szenenabfolge Content Repr sentations Kontext Rolle Transition object stil Aufgabe Bild 47 Sichtenstern f r eine Dialogszene mit entsprechenden SiteLang Elementen Der Content der einzelnen Dialogschritte wird durch eine Contentobjektsuite bestimmt Die unterst tzende Funktionalit t f r die einzelnen Dialogschritte wird auf der Funktionalit t der Contenttypen aufgesetzt Der Kontext der einzelnen Dialogschritte wird durch den Kontextraum determiniert Diese sechs Dimensionen k nnen in Zusammenhag mit dem Zachman Spezifikationsrahmen gestellt werden Wir unterschieden vier Hauptdimensionen f r jeden Dialogschritt die zugelassenen Akteure des Dialogschrittes die Einbettung in den Storyraum die bereitgestellten Contentobjekte 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 Dialogschritt Akteur 7777 T tobjekt Zeitrahmen o e Offentliche Art Existenz G ltigkeit Private l Funktionalit t Content R ume Arbeitsresultate Bild 48 Der Spezifikationsrahmen f r Dialogschritte Die Assoziationen werden gleichzeitig mit dem Rahmen dargest
310. ple choice Workflow 77 Notwendig giiltig 71 Objekt 43 Objekt Gesellschaft 52 Ontologische Einheit 81 178 Open world assumption 5 Parallelisierter Workflow 77 Partitionierung 160 Partizipation Notation 49 Pers nlichkeitsprofil 115 Pflegeschicht 35 Pflichtenheft 37 Plot 108 Polarit tenprofil 115 Portabilit t 149 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 177 Produktdatenskizze 81 177 Produktfunktion 177 Produktfunktionalit t 177 Profil 114 Programme 68 Projektion 61 Proze 36 Qualit tskatalog 137 Rechtetyp 119 Relationship Klasse 45 INFORMATIONSSYSTEM ENTWICKLUNG IM CO DES GN ZUGANG Relationship Typ 45 Robustheit 150 Rolle 119 Schachtelung 61 Schema 3 36 51 Schema Morphismus 101 Schliissel 49 Schnappschu 71 Schneeflocken Schema 93 Selektion 61 Semantik 5 Semiotik 5 Sicherheit 149 Sicherheitsoption 117 Sicherheitsprofil 117 Sicht 37 Sichten des Lastenheftes 81 Sichten des Pflichtenheftes 81 Sichtenintegration 101 Sichtenkooperation 101 Sichtenskizze 81 178 Sitzungs Objekt 100 Sitzungs Schema 100 Skalierbarkeit 151 Skizze 178 SPICE 180 Statische Integrit tsbedingung 42 Stern Schema 93 Steuerspezifikation 66 Story 107 178 Story Raum 122 Storybo
311. plementation Programmkode assoziierte Szenario assoziierte Szenen Kollaboration Integrationsstrategie obligatorisch good practice optional n tzlich Ein Szenario ist z B in Bild 51 beschrieben Hauptstory z B als Folge von Szenen Szenario Ausschnitt des Story Raumes mit ohne Seitenpfade 7 5 gt SC3 Seitenpfad mit partieller Ver nderung des Szenariums SCI 5 sco gt SC4 SC5 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 Storyraumes an einen konkreten Durchlauf kann durch den Aufbau 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 staltungsangebot gemeinsam Dabei existieren zwei Einwahlst 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 era
312. ptionelles Schema Globales Verteilungsschema Lokales Lokales Lokales kanzeptionelles kanzeptionelles kanzeptionelles Schema 1 Schema 2 Schema n Lokales Lokales Lokales ternes nternes ternes ge ema 1 ge ema 2 Schema 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 Biicken 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 eine
313. r Daten wodurch higkeit Ausfiihrungsort von DB Operationen gr Bere M glichkeiten zur Lastbalancierung geringe M glichkeiten zur Lastbalancie rung oder Finsparung von Kommunikations vorg ngen besonders problematisch dominie rende Transaktionstypen und DB Bereiche entstehen Kommunikation f r Synchronisation und Koh renzkontrolle nahe Kopplung kann zur Leistungssteige rung eingesetzt werden trotzdem h here Fle xibilit t zur Parallelisierung Erweiterbar neuer Rechner erfordert physische Neu auf keine physische Neu Aufteilung der DB 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 verteiltes Commit Pr
314. r Gruppe untereinander bzw mit dem 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 Funktionalitat fiir Sichtensuiten herangezogen werden Parametrisierte Anpassung an den Akteur Um Benutzern in ihren Rollen entgegenzukommen sollen Content Objekte in gewissem Ma e 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 in allgemeinem 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 Abstraktionen 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 k
315. r Interaktionsraum verglichen mit dem Systemraum 122 Repr sentation der Elemente von SiteLang a naaa aaa a 123 Der Zwiebelzugang zur Generierung der Oberfl chen von Anwendungen 124 Sichtenstern f r eine Dialogszene mit entsprechenden SiteLang Elementen 125 Der Spezifikationsrahmen f r Dialogschritte a aoao aaa a 125 Der Spezifikationsrahmen f r Arbeitsgruppen Sites 126 188 50 l 52 58 q 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 12 73 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 BILDVERZEICHNIS Der Spezifikationsrahmen f r Beitr ge von Arbeitsgruppenmitgliedern 127 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 138 Dimensionen des Gestaltungsrahmens oaoa aaa a 142 Die Implementationsschicht eines verteilten Systems 147 Eine Schichten Architektur f r verteilte System 148 CORBA auf IDL Grundlage 154 OMG Architektur 154 CORBA Architektur 2 10 01 0122 0 0 0 0 0 0 0 0 0 0 154 Die Arbeitsprodukte im Abstraktionsschichtenmodell f
316. r Klasse T definiert falls ler T7 1 1 gilt Eine Menge U 1 8 1 86 01 1 lt i lt m von objekt basierten Anderungsoperationen ist konsistent falls aus T si1 Simi Tj 83 1 8jn f r 1 lt i lt j lt m die Gleichheit o folgt Das Resultat der Ausf hrung einer konsistenten Menge U von Anderungsoperationen f hrt zu einer Zustands nderung der Datenbank R zu ER U J Update Ty Sil Sini Oi falls oi E U ERC 0 andernfalls f r Objekte o of ERC 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 ole true f r alle Variablenbelegungen f r die freien Variablen von 70 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 5 FUNKTIONALITAT Eine Workflow Maschine W ER 6209 P basiert auf einem Datenbank Schema ER einer initialen Datenbank E R einer Menge von parametrisierten Programmen und einem ausgezeichneten Programm das Hauptprogramm genannt wird sowie den dynamischen Integrit tsbedingungen Fine 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 U
317. r Motivationsschicht danach auf der Gesch ftsproze schicht dann auf der Aktionschicht und danach die Aspekte auf der kon zeptionellen Schicht entwickelt Nach Abschlu des konzeptionellen Entwurfes wird eine Trans formation hin zur logischen Spezifikation vorgenommen Dieser Zugang erfordert wenige Kor rekturen im Entwicklungsproze und erscheint deshalb besonders geeignet Er wird im weiteren pr feriert Wir kombinieren diese Vorgehensmodelle zu einem schichtenbasierte 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 Entwicklungschritte 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 Entwicklung der Architektur des Systemes 4 Skizzierung des Storyraumes Formulierung der Interaktivit t f r das Pflichtenheft 5 Skizzierung der Sichtensuite f r die einzelnen Komponenten der Dienste und des Austauschrah mens Formulierung der Verteilung und Strukturierung f r das Pflichtenheft 40 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 3 ABSTRAKTIONSSCHICHTENMODELL Fkt Struktur Verte
318. r Obligation 4 Fa Po Verboten heiBt nicht erlaubt Weitere allgemeing ltige Formeln der deontischen Logik sind z B Oa Pa O o A 8 o Oa A O Oo A P av 0 o Pav PE Oav OB O aVv 8 Oa 6 P oA8 Pad PB Fa F oA86 Oo A PB P ad 0 Oo A O a o INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 73 8 gt PB 8 gt Fa FO A Fr A O o y gt Fa e O o V B A Fad FB e Oo A O o 4 8 y gt O O a a gt Oa OB 6 Fa Ola 6 O a O a 6 a o OB O o A 7a Oo A O a 6 A na gt A o gt false e a O 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 die
319. r Spezifikation des Seienden entity der Beziehungen relationship und der Eigenschaften Attribute Dinge stehen in Beziehung bzw besitzen Eigenschaften die klassifiziert werden durch eine Rolle oder durch Klassenbildung Die Gesamtheit der Dinge wird modelliert unter Ber cksichtigung der Beziehungen untereinan der e Aussonderung Separation Spezialisierung e Verallgemeinerung Generalisierung von Gemeinsamkeiten und e Aggregation zur Darstellung komplexerer Daten mit entsprechenden Operationen Spezifikation der statischen Semantik d h durch einschr nkende Bedingungen f r wirklich keitsgetreue Nachbildung der Anwendung wie e die eindeutige Bestimmung aller Objekte Schl sselbedingung 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 e Verweisbedingungen auf Objekte der Komponentenklassen sowie e allgemeine Bedingungen inh rente Bedingungen des Modells wie die folgenden e Gesamtheitsregel universe of discourse Verneinungsregel INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 43 Sichten und abgeleitete Begriffe sind erschlie bare Objekte und werden durch Anwendung v
320. r Story erhalten 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 entsprichen 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 und Aktionen vornehmen und dazu Daten vom Format der Aktionssichtensuite 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
321. r die Vertetlung 157 Grunds tzliche Architektur verteilter DBMS 159 Partitionierungskonzepte 161 Die Architektur von f derativen Datenbanksystemen 1 164 Namensaufl sung 0 0 01 0 0 0 0 165 Namensaufl sung ber Synonyme ee 166 Zug nge f r Mehrrechnersysteme a 166 Verallgemeinerung der Dreiebenen Architektur zu einem verteilten Schema 169 Generelle Architektur von Datenbank Farmen 170 Die allgemeine Architektur f r inkrementelle Evolution von Datenbanksystemen 171 Die drei Komponenten eines Datenbank VVarenhan ses 172 Die 3 dimensionale Aggregation von VERKAUF 176 Index Abarbeitungsmodell 118 Abstrakt 94 Abstrakte Spezifikation 65 Abstraktionsschicht 33 Aggregation 48 Akt 110 Akteur 36 99 114 Akteurmodell 120 Aktionsschicht 34 Aktionsspezifikation 37 Aktivit tenfolgendiagramm 119 Algebra 60 Allgegenwart 149 Anforderungsspezifikationsschicht 34 Anfrage 63 Anvendungsgebiet 105 177 Anvendungssehritt 105 177 Arbeitsablauf 118 Arbeitsgestaltungsdimension 119 Arbeitsgruppe 99 Arbeitsoberfl che 111 Arbeitsplatz 99 Arbeitsprofil 114 Arbeitsschritt 178 Arbeitssituation 4 Arbeitsvorgang 118 Architektur 178 Archivdatenbanksystem 170 Aspekt orientierte Programmierung 129 Attribut Typ 43 Aufgabe 56 118 Aufrufspezifikat
322. r weiteren Bearbeitung zu gute kommt und die in einer Spezifikation nicht fehlen sollten optionale Bestandteile die eine Beschreibung sinnvoll erg nzen aber die nicht erforderlich sind f r den Abschlu der Spezifikation 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 anch 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 Erfahrunsberichte DBMS Beschreibung Strukturierung Funktionalitat Interaktivitat Kontext Struktur statische IC Operationen dynamische Story Raum Akteure Aufgaben Intention Ge IC Erzwingungsstrategien Contentobjekte Re schichte Umgebung Ziele pr sentation Implementation Im
323. rakter Contenttypen Wechselwirkung zwischen auf Zielsystem Arbeitsplatzen innerhalb einer Gruppe gruppeniibergreifend Position Ausrichtung nordnung Layout innerhalb einer Gruppe Prioritat globale Festlegungen Geometrie Konfiguration der Generierun gruppeniibergreifend Anwendungssemantik Gestaltungsgesetze Bild 55 Die Vorgehensweise zur Zusammenstellung von Benutzungsoberfl chen der Anordnung und Bedienung der Bilder und der Repr sentation und Stilfragen Auf dieser Archi tektur kann auch die Vorgehensvveise 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 Metapher der gesamten Gestaltung unterlegt werden k nnen Wir kom
324. rbeitet 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 Eigenschafts basierte Suche mu robust sein Wir wenden deshalb daf r SoundEx Algorithmen an e Die assoziative Suche geht dagegen von assoziierten Begriffen aus So kann z B eine Hotelsuche INFORMATIONSSYSTEM ENTWICKLUNG IM CO DES GN ZUGANG BY 6 129 Szene zur kollaborativen Semesterplanung Einreichung der Daten durch ehrstuhlleit a Akzeptierung eler Zuvveisung Kurs ZEICHEN Best tigung von Kursen anforderung an Mitarbeit Login durch den Lehrstuhl neuer Kurse als Vorschl ge Anpassung der Daten r einen Kurs Daten Auswahl von Daten f r das Kurse Darstellung f r Kurse Da Alte gespeicherte ten vergangener Semester Best tigung der Kurszuvveisun durch Mitarbeiter von Neben bedingunger Bild 52 Sz
325. rchitektur von Datenbank Farmen z B im Denda Proyekt17 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 Die Komponentensysteme werden mit einer Verbindungstechnologie wie oben darge stellt miteinander gekoppelt Die Kopplung folgt dem Skelett der Anwendung Die Kopplungsopera toren sind dazu der Verbund M der Theta Verbund die verallgemeinerte Vereinigung U und die verallgemeinerte Projektion 7 Aus den Verbindungsoperatoren k nnen die Modifikationsoperationen auf der Grundlage der 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 wobei die bergebenen Ob jekte nur i
326. rchlaufenen Workflows m glich Funktionen der Sitzungsverwaltung sind insbesondere Funktionen zum Offnen Protokollieren und SchlieBen von Sitzungen mit denen ein Arbeitsstand gespeichert werden kann die Erhaltung pers nlicher Daten gew hrleistet wird mit denen Nebensitzungen und Gruppensitzungen unterstiitzt 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 werden k nnen 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 Versammlungen Veranstaltungen etc durch eine Reihe von Funktionen wie 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 von Materialien und Dokumenten mit unterschiedlicher Sichtbar keit und unterschiedlichem Recht auf Finsicht Funktionen zur Unterstiitzung der Zusammenarbeit von Mitgliedern de
327. rd 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 Weitere Bestandteile LW beschreiben die Ber cksichtigung von Rechten Privatrecht Daten schutzrecht
328. re 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 ftir 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 R E Eberts User interface design Prentice Hall Englewood Cliffs 1994 184 Elm92 Emb98 00 Fer95 FS95 FvH89 Gil90 Glo96 GR94 Gur00 Hal95 Hau00 Haw90 Hor99 HP97 IZG97 Kas03 KE96 KE01 KK93 KM03 KT95 Kun92 Leo92 LFe LL99 LLO3 LM 78 Mac90 Mai83 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 LITERATUR A K Elmagarmid editor Database transaction models for advanced applications Morgan Kauf mann San Mateo 1992 D W Em
329. rf llt das Pr dikat a falls dies entsprechend der Definition von o gilt Damit definieren wir o falls o das Pradikat a erf llt Aion 0 andernfalls Erf llt ein Objekt o das Pradikat a dann Ersetzungsfamilie Fine Ersetzungsfamilie y o R e vom R ist eine Menge bestehend aus einem Paar von Objekten und Klassen vom Typ R Eine Ersetzungfamilie beschreibt f r 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 h T ha T xT T gegeben Dann definieren wir S8TEChg hy ho Or ho STeCho hi ho His hils f r einelementige Kollektionen 191 STECho hi ha T Ur T falls T Nr T 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 tionalen Algebra Demzufolge sind die Elementaroperationen auf die gleiche Art formulier
330. rgegeben Metapher Ein System soll sich dem Benutzer in einer einheitlichen Form pr sentieren wobei die allgemeine Arbeitsumgebung mit einbezogen wird ebenso wie eine bevorzugte Form der Darstellung In unserem Beispiel kann z B die Raumplanung mit einer Reiter Darstellung unterst tzt werden die Vorlesungs bersicht durch hierarchische Strukturen unterst tzt werden die dem Studienplan und der Lehrstuhl bersicht folgen 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 sein Umsetzung der Prinzipien der visuellen Wahrnehmung Schnittstellen sollen einfach sein leicht zu berschauen und auch so zu bedienen da die bersicht nicht verloren geht Dazu sind Parameter der visuellen Wahrnehmung wie Ordnung und insbesondere Hierarchie Wir kung auf bestimmte Akteure und auch der Schrittfolge durch eine entsprechende Struktur zu unterst tzen Daraus kann sowohl die vertikale als auch funktionale Navigation abge leitet werden Da auch multimediale Elemente eingebracht werden k nnen spielt neben der visuellen Kommunikation auch die audio basierte Kommunikation sowie auch andere Arten eine Rolle Insbesondere f r barrierefreie System wird auf die anderen Kommunikationsm glich keiten zur ckgegriffen Umsetzung der Prinzipien der visuellen Kollaboration Die unterschied
331. ri 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 INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 187 Verzeichnis der Illustrationen 1 Die drei Prinzipien der Kristallographie der Gesellschaftswissenschaft und der Ma thematik wu 77777777577777777777 6 Die vier Prinzipien der 6 Modellierung Verfeinerung Verifikation und Validierung 14 Modellierungsurteile durch Individuen im Modellierungskontext und das Dilemma der Modellierung a e a ss aa wur ra le dy Be Be cadi GH ee Fae 16 Integrierte Entwicklung von Strukturierung Funktionalit t Int
332. rierung einer Datenbank beschreibt Funktionalit 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 Verallge
333. rmationssystem Entwicklungsprozesses Die Spezifikationssprachen k nnen sich f r die Schichten und die einzelnen Spezifikationsteile stark unterscheiden Fine solche Sprachvielfalt ist jedoch nicht immer angebracht 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 natiirlichsprachigen u erungen Formu lartechniken und formalen Darstellungsmitteln wie Diagrammen zur Darstellung der Datenstrukturen und der Sichten formalen Proze sprachen und Skriptsprachen zur Darstellung von Drehb chern F r 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 fiir einen Sprachmix entscheiden dann sollten wir in jedem Fall die Abbildbarkeit der Konstrukte von Schicht zu Schicht garantieren k nnen Auf die na rliche Sprache sollte schon aufgrund des ihr innewohnenden Potentials keinesfalls verzichtet werden Formulartechniken sind eine Vorstufe der formalen Darstellung Formale Techniken wie ER Modelle CSP Modelle sind fiir 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 ein
334. rp qs e t3 qur M n si e s pun INYNIIS oytoseq yq Bunuarungynuls suras Q zueIs mpprpIy W9 o 10A soure oyuauoduoy s p vur q q zue surlloyo3ozq 79807 HY SULETI reg Penlsqayy Sunjo A oyofuoq boufny osspyysboufny sap u poy yy UIULYDA zyopdspiaguy asspjyaopfuazuy bupTang 42S sbum ys p 011121 28 50 1 4100 UIWYDA UIWWDSNZ SUO14DLOGD I0O y SU0140140Q0110 yy paqinuaddnsy wIoznu alloy Ulezynueg uoddniy eureyos moyy V Jozjnuog g osseTy SueyouS suoryestues1Q SUNIST OPO Surpreog 1048 wme1 10Ig UINLIVUdZG OLTEU ZS Zuerjong 104S SOLIOIS umey uodAyL yolqo asse yy dAL 90 2u00 qu uov JU9YUON JU9YUOJ Sue Jong y r Suo uoryeso ur mg u qq rs dAyu q tg emm q su qq ts y fqou q rg OSSEINUOINDIIS TVNHHH WYA H opuozyngs ogun seuloyps MOTION 1807 STIUEWOS YUH stureudq s p yryueuog INHHH q srureu444 BUOYS yolqo SS TY Soure N assoZOlg wIUIeISOIg MOPP LOA MOP ION MOP ION WYHaH 07299 persqy r rseq
335. rund 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 12Wie bereits betont benutzen wir Benutzer neutral und nicht geschlechtsspezifisch 114 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 7 INTERAKTIVITAT Benutzer k nnen anch ihren Eigenschaften gruppiert und mit einem Typkonzept dargestellt wer den Ein Akteur ist ein Benutzer Typ der eine Gruppe von Benutzern abstrakt darstellt Damit werden die allgemeinen Charakteristiken von Benutzern beschrieben In der konzeptionellen Model lierung sind wir mehr an einer Darstellung von Akteuren orientiert Akteure sind den einzelnen Dialogschritten und damit den Szenen mit entsprechenden Rechten und Rollen zugeordnet Diese Rollen erlauben einem Akteur das Agieren mit dem Informations system Eine direkte
336. ruppe 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 Fall 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 A
337. 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 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 Schliissels zu sein So kann z B zum Schl ssel das Teilattribut Name Vornamen Familienname Geburtsname 1 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 e HERM Typen werden induktiv aufeinander basierend definiert INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 45 Name Familienname Geburtsname f 855 varstring30 varstring30 Titel 20 a Pe 1 Benutzung 1 Familientitel string AkademischeTitel varstring10 varstring15 varstring 10 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 nicht leeren Folge von Attributen und einer Menge von statischen Integrit tsbedingungen Der Prim rschl ssel wird direkt durch Unterstreichen der Attribute ange
338. s 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 Aufstellung der n chsten Schritte mit einem Mo nitoring der verschiedenen Ereignisse und zur Berechnung der Interproze Abh ngigkeiten zur Aufstellung des n chsten Schrittes und der Proze Agent zur Ausf hrungskontrolle eines Prozesses 68 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 5 FUNKTIO
339. s Produkt richtig erstellt Y Implementation Bild 3 Modellierung Verfeinerung Verifikation und Validierung Obwohl ein Datenbankentwurf immer fiir eine bestimmte Umgebung und damit fiir 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 Sche
340. s impor tierenden Systemes Die Struktur 77 7 Y und die Funktionalit t Ost No der Sichten des exportierenden Systemes wird dabei eingebettet in die Struktur S 5 Xs und die Functiona litat t Xo des importierenden Systemes Kann eine Modifikation im importierenden System auf den importierten Daten vorgenommen werden dann wird die Funktionalit t Oser Yo 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 Zusammenfiihrung 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 mehrdimensional 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 Datenbank Warenhhaus oft auch als Daten Warenhaus bezeichnet stellt die n chste Ent wicklungsetappe f r breit benutzbare Datenbanksysteme dar Im Prinzip kann man sich Farmen von Datenbanksystemen vorstellen die durch eine Art Warenhausverwaltung den Bed
341. s yala n Content Typen Raum Struktur Funktionalit t Anwendungskomponente Container Dialog p 8 Strukturierung Funktionalitat management 7 Struktur Prozesse generator system Statische Dynamische Integritats Integritats Sichten bedingungen bedingungen tor DBMS generator Pragmatik Pragmatik a b Bild 38 Spezifikation von Informationssystemen Kollaborationsrahmen Die Interaktion basiert auf der Existenz mehrerer Parteien die in unterschied lichen Rollen agieren kollaborieren und unterschiedliche Interessen verfolgen 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 Teilen diskutiert unterscheiden wir zwischen dem Diskurs den Handlungsrahmen dem Storyboard dem Drehbuch und der Inszenierung der Dialoge In un terschiedlichen Entwurfsetappen spezifizieren wir die Dialoge im Abstraktionssc
342. sNr Name Geburtsdatum Relationship Typen haben ggf auch eigene Attribute die auch Bestandteile eines Schl ssels sind Zum Beispiel nehmen 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 1 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 Schl ssel wird ber 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 1 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
343. schichtenmodell Es kann die Struktu rierung der Daten in jeder Schicht durch das Entity Relationship Modell repr sentiert werden Wir verwenden dazu Schemata unterschiedlicher Abstraktheit und Granularit t Datenstrukturierung 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 52 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 4 STRUKTURIERUNG Konzeptionelles ER Schema Auf der konzeptionellen Schicht wird ein detailliertes HERM Diagramm erstellt das u a auch fiir alle Typen des Anwendungsschemas entsprechende Verfeinerungen enthalt Diese Beziehungen finden auch Eingang in die Sichtensuite Logisches Schema Das HERM Schema wird in ein entsprechendes Schema des logischen Datenbank Modelles transformiert Es kann blichervveise ein objekt relationales oder relationales Schema sein aber auch eine Beschr
344. siert Die Objektdienste Object 154 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 8 VERTEILUNG Common Facilities Object Request Broker Object Services Betriebssystem Transportdienste Bild 59 CORBA auf IDL Grundlage Services realisieren Basisfunktionen fiir die Erzeugung und Verwaltung von Klassen und Objekten zur Namensverwaltung und fiir die Persistenz von Datenbank Objekten Mit den Common Facilities werden allgemeine Hilfsfunktionen Klassenbibliotheken zur Verfiigung 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 fiir die Verwaltung globaler OIDs und die Registrierung von Objekten Die Kommunikation zwischen ORBs wird iiber das IIOP Internet Inter ORB Protokoll realisiert Client Objekt Implementation IDL Object Stubs stellen Skelett Adapter ORB Kern 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 Funk
345. son past y Beziehung Ist Partner _y Von Partner _person Ab Bis A Bis _today In analoger Form k nnen wir Adressen spezifizieren Adresse _geographAdr _kontaktAdr _historie DE M Adresse _betriebsIS aufgabenAkteur Die Darstellung der Konzepte kann auch in der Form von ER Modellen erfolgen 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 lg Personen Rollen Eine Algebra zur Verbindung wird aus der HERM Algebra abgeleitet Wir verwenden dabei die HERM Operationen m bl L Y PNameSpace Aggr STCho hi 24 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 Charakterisierung
346. sschicht mit der logischen Spezifikation mit einer Beschreibung der vier Aspek te durch logisches Schema Datenbank Maschine Inszenierung und logische Sichtensuite 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 u u rq ssuorensq y Uap me d 33u auoo u d443u quoo ur yzyanusq soyJoqyus4 soyJouy mnsu qu rs mnsu quq rssuony v rd s p m qu qq rg usIse s p mT qu v ts UII i nu sgid i poyu uond zuoyi dA us y q stsoyoauo younp dAL dAqu epynpolq 14915 wap diy eur q s DIS PPPPAS FOIS ZZDIS yypIsusyepyyNpoig 14216 dA 44u93u0D u d443u quoo Iz nusq s r qu qu rd s p soqjoy yonqueiq preoq 1og T qu urqe s unipueH usIse s p Tregsinystaq UII jleTyUeseIder 111 88 uomuy AP BWOLL STUSTOIOSFTUNPUOMUY YLIyassgunpuamuy uorydozuoy q mnp yylryossoreiq q mp yr yosdoreiq yemp 23Lrq ssorerqq 1114 1910 q rq s p q rq s um M ZS 101 WI vu zg A103 IOUID UL 9USZG SSUNPUSMUY WII v zs auazg dAyyusJuodg u d433u quoo ur yzyanusq s y yuyo opd soyJoyus4 MOT ION SUTYOSeULIEZ
347. ssen 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 124 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 7 INTERAKTIVITAT Prasentationsmaschine Container Generator Contentobjekt Generator Sichten Generator Datenbanksystem DBMS 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 Szenario Der Storyraum 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 ei
348. ssung 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 Vorschl ge eines Lehrstuhles f r Lehrveranstaltungen Spielraum Kollaboration 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 Interak tionsdiagramme sind gerichtete Graphen deren Knoten Zust nde des Systemes darstellen und deren Kanten Transitionen darstellen die durch einen Akteur ausgel st werden k nnen Es kann ein Akteur in seinen Rollen mit seinen Rechten bei der Aufgabenl sung dargestellt werden Das Akteurmodel nimmt zusammenfassend folgende Informationen auf Profil des Akteurs Arbeitsziele des Akteurs Sicherheitsprofil des Akteurs und Portfolio des Akteurs
349. st 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 INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 149 Facetten der Verteilungsqualitat Die Qualitat der Verteilung wird aus unterschiedlichen Gesichtswinkeln beurteilt Die Bandbreite der Anforderungen ist sehr hoch VVir k nnen dies an einer Reihe von Dimensionen feststellen Allgegenwart Ubiquity Daten haben eine unterschiedliche Aktualit t je nach Anforderungen 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 Objektsuiten ber Re plikationsmechanismen miteinander verbunden sind und die alle gleichzeitig die gleiche Aktualit t haben Mobilit t der Rechner bedeutet zugleich auch eine Herausforderung an die
350. swahl M bei der genau ein Programm zur Ausf hrung nichtdetermistisch aus gew hlt werden kann Synchronisation f 4 das 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 verschiedene Ausf hrungspfade mit vollst ndiger Synchronisation 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 mit Bedingungen erfolgt die erst zur Laufzei
351. t 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 Y 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 Verwendung in vielen kommerziellen Systemen wie z B Tandem NonStop SQL DB2 Oracle etc Der n chste Schritt sind interoperable f derative Informationssysteme wie in Bild 58 Diese Ent wicklungslinie l t sich f r interoperable f derative Systeme fortsetzen 166 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 8 VERTEILUNG logischer Objektname Tokale Synonymtabelle 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 Partitionieru
352. t 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 verz gerte Auswahl bei der alle Alternativen ausgef hrt werden und eine Auswahl der Alter native erst nach Ausf hrung erfolgt verbundene parallele Ausf hrung bei der die Alternativen in zuf lliger Reihenfolge sequentiell ausgef hrt werden und Meilenstein basierte Steuerung bei der eine Aktivit t ausgef hrt wird bis ein Meilenstein er reicht ist Abbruchanweisungen sind Abbruchaktion bei der eine Aktion abgebrochen wird und Fallabbruch bei der ein Fall abgebrochen wird INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 79 Diese Algebra kann durch die Algebra der Workflow Maschine ausgedriickt 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 darstellbar die in der Workflow Literatur breit diskutiert werden Typischer Unsinn dieser Literatur ist die Auseinandersetzung mit kondensierten und berlagerten Programmen wie in Bild 31 dargestellt Da die Program
353. t 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 Interaktionsm 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 aufg
354. t tenprofil erstellt werden mit einer ordinalen Bewertungsskala zur Darstellung der Ausgepr gtheit der Figenschaften 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 Kommunikat
355. t 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 Beladungskpazit 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 I th 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 Alphabet Alph Variable k nnen auch die Kuverts und Abstrakte aufnehmen Werte sind Contentobjekte Ein Container ist konsistent beladen falls seine Tupel Variablen eindeutig sind Wir fordern jedoch keine Konsistenz a priori Ein Container verf gt ber eine Muster Vergleichsfunktion 226 mit der Elemente verglichen werden k nnen Der Mustervergleich h ngt von den Mustern M ab die ein Container vergleichen kann Die ser Mustervergleich
356. t 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 Arabien habe ich sehr viel gelernt zu den Anforderungen zu den Tricks und kleinen Br cken die jede Methode erfordert und zu gro en Anwendungen 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 bei der Entwicklung von informationsin tensiven Websites gefunden Das Cottbuser InfoTeam hat mehr als 35 gro e Websites entwickelt Im wesentlichen wurde die Co Design Methode verwendet was auch gleichzeitig zu Herausforderungen an die Methodik f hrte Die Bewertung der Methodik nach dem SPICE 2 0 Framework wurde durch die Gruppe um H Jaakkola in Po
357. t 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 getroffen sowie die Einordnung in Arbeitsr ume und Zeitr ume 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 Fallfragen Wer wie arbeitet zusammen mit wem was zu welchem Gegenstand INFORMATIONSSYSTEM ENTWICKLUNG IM Co DESIGN ZUGANG 8 133 woraus auf welcher Anspruchsgrundlage Diese Fallfragen verallgemeinern wir zu Spezifikationsrahmen fiir die Art des Zusammenwirkens Die Beziehungen 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 Programmerung auch auf allgemeine Beziehungsstrukturen zur ckgreifen oder explizit die Einhalt
358. t 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 unterst tzt durch die klassische Datenbanktechnologie Robustheit von Systemen erfordert Fehlertoleranz Es treten unterschiedliche Arten von Fehlern auf Benutzerfehler werden verursacht durch eine falsche Benutzung der Dienste durch autorisierte Benutzer Durch eine gute Gestaltung des Storyraumes 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 hebung m glicher Fehler der einzige Ausweg INFORMATIONSSYSTEM ENTWICKLUNG IM CO DESIGN ZUGANG BY 6 151 e Zuf llige Fehler oder byzantinische Fehler sind alle Fehler die nicht eindeutig zuge ordnet werden k nnen die eine Beliebigkeit aufweisen e Timing Fehler treten beim Vorhandensein von Zeitschranken oder bei Synchronisie rung auf Eine Proze kann nicht rechtzeit
359. taltung auf die Darstellung der Content Typen erweitert Der allgemeine Repr sentationsstil wird durch style sheets unterstiitzt 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 Sichtendefintion 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 erlauben Hierarchische Strukturierung als Darstellungshilfsmittel Eine besondere Pr sentationsform ist die hierarchische Darstellungsform Wir k nnen hierarchische Darstellungsformen einf hren e durch
360. te Sicherung des Systemes dargestellt werden kann 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 ausgestattet zur Erf llung von Aufgaben 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 118 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 7 INTERAKTIVITAT 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 e Beschreibung des Inhaltes der Aufgabe e die Spezifikation der Rechte des Akteurs im entsprechenden Dialogschritt e die Beschreibung der Rolle des Akteurs und e Ausf hrungsmodelle f r das Agieren mit Angaben zur Zeitdauer minimal maximal normal sowie zu den Ausf hrungspriorit ten Fine Aufgabe ist eine Vorgabe zu zielorientiertem Handeln und wird durch die folgenden Aspekte beschrieben e
361. terface zum f derativen Schema Konstruktions 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 zentralisierter Katalog vollst ndig replizierter Katalog Mehrfachkataloge Kombination aus den beiden ersten Ans tzen und partitionierter Katalog Ein 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 wo 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 Katalogdat
362. theitskriterien 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 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 ops T 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 Pradikate Sie sind au erdem durch eine Reihe von Eigenschaften eingeschr nkt die im Datenbank system zu beachten sind und oft im Entwurf bersehen werden e Die Pr zision und Genauigkeit sind ggf f r Typen wie REAL eingeschr nkt e Die Granularit t von Daten kann sehr unterschiedlich sein Die Skalierung von D
363. timmten Entwicklungsmethodik und resultieren in e unterschiedlichen Spezifikationssprachen und e 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
364. tokollen 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 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 Transaktionsverw
365. tzen die nicht mehr auf einem globalen 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 Schema 164 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 8 VERTEILUNG In
366. und den Zusammenhangs der Sichten k nnen Obligationen f r den Entwurfsproze abgeleitet werden Fine Bereinigung von Integrationskon flikten kann auf der Grundlage des Sichtenintegrationsschemas erfolgen Deshalb wird dieses Schema weiter parallel verfeinert Sichtensuite Die Sichtensuite stellt auf der konzeptionellen Schicht eine Menge integrierter Sichten schemata dar die auch durch entsprechende Strukturen des ER Schemas und durch Anfrage mengen unterstiitzt wird Die einzelnen Sichten werden nun im Detail entworfen Fiir 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 detaillier tes HERM Diagramm angegeben Diese Typen stellen eine Verfeinerung der Typen des An wendungsschemas dar Die Verfeinerungsbeziehung wird direkt zur Erzeugung der Sichtensuite genutzt Der Entwurf der Sichten kann nach den gleichen Methodiken wie der Entwurf 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 des konzeptionellen Entwurfes vollst ndi
367. ung auch einen Akteur berfordern was h ufig vorkommt bei einer direkten bertragung von Dar stellungen mit Printmedien 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 konzeptionelle 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 dargestel
368. ung der allgemeinen Gesch ftsbedingungen postulieren Arten der Aktivit t werden durch Verbgruppen relativ gut charakterisiert mit Verben der Hand lungen wie kaufen lernen und informieren ergative Verben wie fliehen Proze verben wie einschlafen ingressive Prozesse und verbl hen egressive Prozesse und Verben zur Be schreibung eines Zustandes wie schlafen oder haben Wir sind f r Informationssysteme an der ersten und der letzten st rker interessiert In diesen beiden Gruppen unterscheiden wir e Verben des Geschehens e Verben des Zunehmens Verben der bereinstimmung Verschiedenheit Verben des Mitteilung e Verben des Argumentation e Verben der Zustimmung e Verben der Leitung e Verben des Zusammentreffens e Verben der sinnlichen Wahrnehmung e Verben der Nahrungsaufnahme und e 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 Handlung 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
369. unktionalitat 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 Die Prozesse werden damit tiber diese Einbindung in das Schema auch fiir die Sichten benutzbar Damit erhalten wir ein Entwurfsviereck bestehend aus der Datenspezifikation 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 Lokalitat der Strukturen und Prozesse dargestellt e Die Benutzerdimension dient der Darstellung des Systemes aus Benutzersicht einschlie lich der Organisationsmodelle In der Zeitdimension wird die Entwicklung der Anwendung dargestellt 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 e
370. 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 hierzu ein vereinfachtes Diagramm in Bild 22 gehaltene Vorlesung Ablage form 0 Resultat vorausgesetzt 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 RF 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 R mit k Elementen falls zu jeder Kombination von Objekten oj von RE j Zi L lt j lt 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 R zuordnen d h das Objekt sieht vermittels RC h chstens j m und mindestens n Objekte aus der anderen Klasse 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 loo
371. uptkriterien bei der Beurteilung der Qualit t neben diesen Kriterien Ein wichtiger Problemkreis vor Einf hrung eines Informationssystemes ist das Abw gen ob dieser Einsatz 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 5 in der Darstellung komplizierter Beziehungen der Daten 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 tsmech
372. urch 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 Lebevvesen zum Gegenstand vom Gegenstand zum Lebevvesen 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 fiir den Kontext Intention fiir 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 Kontrastierung 146 B THALHEIM PREPRINT BTU INFORMATIK I 15 2003 KAPITEL 7 INTERAKTIVITAT 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 Polari
373. von gleichartigen Aktivit ten einer Transition von Input Outputdaten durch die Aktivit t und der Steuerung des Beginns der Verzweigung etc und der Beendigung einer einer Aktivit t 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 initiiert werden kann einem Datenaustausch mit der ben tigte Daten f r die Ausf hrung bereitgestellt werden k nnen 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 Synchr
374. zelnen Spezifikationsteile im Abstraktionsschichten modell untersuchen Dabei k nnen wir auf die Erkenntnisse die in den vorangegangenen Kapiteln dargestellt sind zur ckgreifen 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 fiir eine etwas umfangreichere Anwendung mit etwa 500 Entity Relationship und Cluster Typen im ersten Schritt ein kurzes sechsseitiges Essay mit der Beschei 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 K
375. zer Maschine AF mit einer Darstellung der Handlungen und der entsprechenden Ak tionen die Aktionssichtensuite AC mit den Sichtenskeletten und den entsprechenden Kerntypen der Storyboard mit Szenario Aufgaben und Benutzergruppen AS zur Darstellung der Interak tivit t wobei der Repr sentant eines Benutzertyps Akteur wird mit einem Profil und Portfolio beschrieben 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 einschlie t und auch die Qua lit tskontrollmechanismen Die Dokumentation der Implementationsschicht I sollte aus den vorhandenen konzeptionellen Sche mata generiert werden Sie umfa t die logischen Schemata mit dem logischem Schema ILD mit einem objekt relationalen oder semistrukturierten Sche ma und entsprechenden logischen Typ
376. zierung 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 auch 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 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 Do
377. zt wird Prinzipiell werden nur stabile Strukturen repr sentiert Teiltypenhierarchi en k nnen ansonsten bis ins letzte Detail 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
378. 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 Teo89 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 1 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 CP84 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 AD93 BS03 KK93 1 LL99 Leo92 LM78 Mai83 MR92 PBGG89 Tha91 Tsa89 Weiterfiihrende und interessante Literaturquellen sind beso

Download Pdf Manuals

Related Search

Informationssystem Entwicklung

Informationssystem-Entwicklung

Contents

Download Pdf Manuals

Related Search

Related Contents