Home

Skript - Informationstechnik

1. Man zeichne einen Programm Ablaufplan PAP Werkzeuge bzw Hilfsmittel unterst tzen die eingesetzten Methoden oder Verfahren Sie sollen den Einsatz von Methoden oder Verfahren erleichtern beschleunigen sicherer machen z B make RCS allgemein CASE Utilities Organisationsmodelle ToDo Allgemein Der Entwurf von Software ist ein kreativer Akt Es gibt keine Patentrezepte Gott sei Dank Vergleich mit dem Bau eines Hauses Es gibt Architekten und Handwerker jeder ist Spezialist auf seinem Gebiet Rohre schwei en Elektroinstallation usw besser nicht von Architekt Gesamtplan erstellen Entwurf und berwachen Projekt Management ab 4 st ckigem Haus besser nicht von Handwerker Ein guter Architekt kann ein 4 st ckiges Haus mit 20 Mann auch ohne Plan bauen Besser ist es jedoch erst einen Plan zu erstellen und dann zu beginnen Methoden Bauplan und Netzplan Werkzeuge CAD f r Statik Netzplanprogramm f r Ressourcenverwaltung und Zeit berwachung Aber die geistige Arbeit wie Analyse d h wo der Eingang Treppe Fenster Entwurf von welcher Firma die Glaselemente mu er letztendlich selbst machen oder auf alte Pl ne zur ckgreifen reusability 1 7 2 Programmentwicklungszyklus Alle w hrend der SW Entwicklung und anschlie ender Wartung und Pflege anfallenden Einzelaktivit ten werden zu T tigkeitsgruppen zusammengefa t Jede Gruppe produziert ein oder mehrere Teilprodukte d
2. Programmieren besteht aus dem Zusammenf gen von Bausteinen welche spezielle Teill sungen bereitstellen 7 21 Dazu ein Beispiel in NATURAL 2 find KUNDE with PLZ 76000 and UMSATZ gt 50000 sorted by NAME display NAME PLZ ORT UMSATZ at end of data write Summe Umsatz sum UMSATZ Oft eigene Entwicklungsumgebung f r speziellen Problembereich Im Anwendungsbereich schnellere Programmierung weniger Fehler Weniger Flexibilit t als bei 3 GL Keine Optimierungsm glichkeiten 5 Generation Sprachen der K nstlichen Intelligenz KI Al e klassische Sprachen LISP PROLOG e Shell Sprachen KEE Babylon ART Knowledge Craft KES LOOPS S 1 Es sind Wissensrepr sentationssprachen auf der Basis von Regeln bzw Frames Der Programmierer braucht keine Kenntnisse ber Ablauflogik Struktur der Probleml sung Programme sind auf Rechnern mit gleichem Entwicklungssystem portabel Fehleranf lligkeit beschr nkt sich auf falsches bzw inkonsistentes Wissen Debug oft ber spezielle Erkl rungskomponente m glich Performance der Applikation oft sehr schlecht Anwendung bei Nicht Standard Problemen schlecht strukturierten Problemen etwa bei Auskunft Beratung Diagnose Konfiguration 7 22 Dazu als Beispiel das Problem der T rme von Hanoi in PROLOG hanoi N loesung N links mitte rechts loesung 0 _ _ _ loesung N A B C M is N 1 loesung M A C B write A gt B loesung
3. Funktionsbeschreibung d h nur bzgl des Verhaltens an den Schnittstellen und nicht des inneren Aufbaus black box Schnittstellenbeschreibung w hrend in den Diagrammen die aktuellen Parameter dargestellt sind wird hier die Definition der formalen Parameter gegeben Realisierungsbeschreibung Beschreibung der internen Arbeitsweise eines Moduls also die Algorithmenbeschreibung Letzteres stellt den bergang zur Implementierung her Neben einer verbalen Form die im wesentlichen die Dokumentation zum Source Programm liefert gibt es auch formalere Formen etwa formal definierten Pseudocode oder Struktogramme aus denen Werkzeuge auch direkt Code erzeugen k nnen oder zumindest Codefragmente erzeugen k nnen die dann noch w hrend der Implementierungsphase auszuf llen sind Bez glich Pseudocode und Struktogramme Nassi Shneidermann Diagramme wird auf das Buch Goll Gr ner Wiese C als erste Programmiersprache verwiesen 6 5 7 Eigenschaften eines Operationsdiagramms Operationen repr sentieren Funktionen oder Prozeduren einer Programmiersprache Ahnlich wie in den Moduldiagrammen wird auch hier nur die statische Aufrufstruktur dargestellt und keine R cksicht auf den dynamischen Programmablauf genommen Wichtigste Information ist neben der Aufrufbeziehung die Darstellung der Schnittstelle d h die u ere die Blackbox Sicht auf eine Operation Eine Operation sollte in ihrem Umfang so bemessen sein dass sie im Rahmen i
4. Best 4 Bestand Die Verbindung der Speicher erfolgt nur ber gleichlautende Namen Durch diese Regel kann es wie im Beispiel zu Diagrammen kommen in denen auf Speicher nur lesend bzw nur schreibend zugegriffen wird Die Regeln des Vertikalen Balancing gelten auch in Verbindung mit dem Datenlexikon und werden dann als Datenlexikon Balancing bezeichnet Aufgrund der gezeigten Datenlexikon Eintr ge sind auch folgende Diagramme korrekt balanciert ToDo 4 13 4 4 4 Schematische Darstellung der Hierarchie Ebenen Im folgenden Bild ist noch einmal zusammenfassend das Schema der Hierarchien von Diagrammen ber drei Ebenen zu sehen Kontextdiagramm Ebene 0 Ebene 1 System ist Parent von name bzw 3 Ebene 2 3 2 ist Child von name bzw 3 0 F r alle Prozesse kann und sollte eine Proze beschreibung zumindest in der Form einer Minispec erstellt werden F r alle Prozesse die nicht weiter verfeinert werden muss eine Prozessbeschreibung erstellt werden Proze beschreibungen werden nun im Folgenden besprochen 4 5 Proze spezifikationen Jeder Proze kann durch eine Proze spezifikation P Spec beschrieben werden Elementare Prozesse das sind Prozesse die nicht verfeinert werden m ssen durch eine Proze spezifikation beschrieben werden Statt P Spec wird h ufig auch der Begriff Minispec benutzt Eine Proze spezifikation kann textueller Art sein Sie kann dann abgefa t sein 1 nat rl
5. Fachhochschule Esslingen Hochschule f r Technik Fachbereich Informationstechnik Prof Dr rer nat Heinich Weber Prof Dr rer nat Manfred Dausmann Skriptum zur Vorlesung ETENN amp rain H gt Te m RI i Grundlagen der Informatik 2 Software Engineering Fachhochschule Esslingen Hochschule f r Technik Fachbereich Informationstec hnik Flandemstrafk 101 73732 Esslingen a N Inhaltsverzeichnis 1 Einf hrung 2 Programmentwicklungszyklus 3 Problemanalyse 4 Strukturierte Analyse 5 Die Methode SA RT 6 Strukturierter Entwurf 7 Implementierung 8 berpr fung und Test 9 Phasen bergreifende T tigkeiten 10 Literaturverzeichnis 1 Einf hrung In den 60 er Jahren verursachten die Kosten f r die Hardware den gr ten Teil der EDV Kosten Die Softwarekosten waren vernachl ssigbar gering Im Laufe der Zeit nderte sich dies Bedarf an umfangreicherer komplexer Software nimmt zu z B grafische Oberfl chen Datenbanken Kommunikation e Projekte werden komplexer und un berschaubarer z B Automatisierungsprojekte Unternehmensdatenmodelle e Lebensdauer von vielen Softwareprodukten ist relativ gering z B Versionen von DOS Turbo Pascal Word au er bei IBM e Hardware ist sehr viel billiger geworden aber auch kurzlebiger Abschreibung auf B rocomputer 3 Jahre e Gemeinkosten und Lohnkosten Lohnnebenkosten sind stark gestiegen d h Miete Kapitalkosten L
6. ToDo 5 6 5 3 Entscheidungstabellen Eine Entscheidungstabelle bestimmt in Abh ngigkeit vom Wahrheitsgehalt bestimmter Eingangsbedingungen eine oder mehrere auszuf hrende Aktionen Sie besteht aus den vier Teilen e Bedingungen e Eingangsmatrix e Aktionen e Ausgangsmatrix Die Spalten der Eingang und Ausgangsmatrix werden auch als Regeln bezeichnet Jede einzelne Regel beschreibt unter welchen Bedingungen welche Aktionen ausgef hrt werden sollen Eine Regel bildet im Bedingungsteil eine Kombination aller Bedingungen Sie ist dann erf llt wenn alle Bedingungen Zust nde annehmen die den der Regel zugeordneten Zust nden entsprechen Zur Formulierung von Bedingungen gibt es drei m gliche Eintr ge J die Aussage ist wahr N die Aussage ist nicht wahr und es ist unerheblich ob die Aussage wahr oder falsch ist Ist eine Zelle der erf llten Regel mit einem Kreuz X versehen dann wird die Aktion derselben Zeile ausgel st Sind in einer Spalte mehrere Kreuze gesetzt dann werden entsprechend mehrere Aktionen ausgef hrt 5 3 1 Einfaches Beispiel In der folgenden Entscheidungstabelle wird beschrieben wie die Kunden eines Versandhauses zur Weihnachtszeit betreut werden Eingangsbedingungen sind der Wert der von einem Kunden w hrend des abgelaufenen Jahres bestellten Waren BW und die Kenntnis der Vertriebsmannschaft ber die Vorlieben eines Kunden hier ob er Alkohol ablehnt oder nicht Entsprechend dieser Bedingu
7. Coupling ist ein Ma f r die Unabh ngigkeit der Moduln und Operationen untereinander Der Grad der Unabh ngigkeit kann durch Uhntersuchen der Schnittstellen festgestellt werden Es ist ein Entwurfsziel Moduln zu erstellen die nur schwach gekoppelt sind loose coupling Die Minimierung der Kopplung ist notwendig da bei hoher Kopplung die folgenden Probleme auftreten e Es ist unm glich eine Funktion zu verstehen ohne dass noch andere Funktionen mitbetrachtet werden m ssen e Von Anderungen Erweiterungen sind immer viele Funktionen betroffen 6 28 e Es gibt eine hohe Wahrscheinlichkeit dass durch eine nderung eine Funktion mit hoher Kopplung ebenfalls betroffen ist Je weniger Kopplung zwischen zwei Funktionen herrscht umso unabh ngiger sind diese Funktionen Je unabh ngiger die Funktionen sind umso besser ist der Entwurf Eine v llige Vermeidung von Kopplung ist nicht m glich Durch Minimierung der Schnittstellenbandbreite wird ein Design verbessert Ziel dabei ist die kleinste notwendige Menge an Daten zwischen Funktionen auszutauschen Die Aufteilung in mehrere Moduln Funktionen um den Umfang der Schnittstelle zu minimieren verbessert verringert gleichzeitig die Kopplung Kann die Schnittstelle nicht weiter verbessert werden hilft noch die Betrachtung der Kopplungsart Man unterscheidet folgende Kopplungstypen e Daten gut e Datenstruktur e Signal e Global e Inhalt schlecht Zwei Funktionen sind mi
8. New York 1990 Yourdon E Constantine L L Structured Design Yourdon Press prentice Hall Englewood Cliffs New York 1979 Yourdon E Modern Structured Analysis Yourdon Press Prentice Hall 1989 10 2
9. darum m ssen Programme gegen ber fehlerhaften Eingaben robust sein Zuverl ssigkeit ist besonders wichtig bei Systemen mit Sicherheitsverantwortung Wesentliche Hinweise Normen I DIN V 19250 DIN V VDE 0801 01 90 Sicherheitstechnische Anforderungen werden durch eine Risikoanalyse des Gesamtsystems ermittelt Grundprobleme dabei sind 6 Es m ssen Aussagen ber sehr kleine Wahrscheinlichkeiten gemacht werden Auch Risiken welche sich eigentlich einer numerischen sogar kostenm igen Bewertung entziehen m ssen vergleichbar gemacht werden Ein Gesamtsystem hat in der Regel folgenden Aufbau Aktuatoren Benutzer SS Messen Steuern Regeln System ext SS 7 3 6 Robustheit Die Robustheit ist eine graduelle Aussage dar ber wie viele falsche Eingaben vom Programm erkannt und gemeldet werden Zur Vermeidung der Auswirkungen von Fehlern m ssen diese zuerst entdeckt error detection und dann e behandelt error recovery werden Da das Programm oftmals die Intention einer Eingabe nicht kennt mu es dem Benutzer den Fehler genauer das Fehlersymptom samt aller potentiell m glicher Diagnosen mitteilen Bei einer automatischen Error Recovery versucht man das Programm soweit in Ordnung in einen Zustand zu bringen da weitere Eingaben m glich sind und die Auswirkungen auf die internen Daten beseitigt d h r ckg ngig gemacht werden Beipiel Compiler der Fehlerfall ist beinahe
10. der Normalfall Hinweise e Die Robustheit einzelner Module ist bei der Integration und beim Test sehr hilfreich e Robustheit kann sehr effizienzhemmend wirken insbesondere wenn jedes Modul die gleichen Daten berpr ft Als Abhilfe bietet sich an mehrere Versionen eines Moduls mit abgestufter Robustheit zu schreiben 7 3 7 Verf gbarkeit Die Verf gbarkeit ist sehr eng mit der Zuverl ssigkeit eines Programms verkn pft Ein Programm besitzt einen hohen Grad an Verf gbarkeit wenn Ausf lle nur selten vorkommen und Standzeiten nur von kurzer Dauer sind In vielen Bereichen insbesondere wenn Prozesse gesteuert geregelt oder berwacht werden m ssen ist eine hohe Verf gbarkeit gefordert lebenserhaltende medizinische Ger te Kraftwerke auch Kern m ssen ununterbrochen geregelt werden zwar langsam jedoch bei St rungen evtl sehr rasche Reaktion Verkehrsleitsysteme Ampeln Schranken Flugsicherungsrechner Vermittlungsrechner der Post Ausfallzeit 1h 40Jahre Fertigungsstra en Stillstand kostet sehr viel Geld Im Bereich von betriebswirtschaftlichen Anwendungen sind die Anforderungen i a nicht so hoch jedoch 6 Bei Datenbest nde von Versandh usern z B aktuelle Bestellungen Lieferungen Ratenzahlungen kann eine sehr hohe Verf gbarkeit gew nscht sein 7 13 Weitere Beispiele Ben tigt man nach einem Systemausfall Stunden um die Datenbest nde in einen konsistenten Zustand zu brin
11. desto schwieriger wird die berwachung der Qualit t der SW und um so un berschaubarer sind die Auswirkungen nachtr glicher Anderungen Die Programme werden stets komplexer gr ere Rechner lassen dies zu jedes Jahr um den Faktor 2 wie bei Speicherchips und Mips der Mensch kann in seiner bescheidenen intellektuellen Leistungsf higkeit dabei nicht mithalten Das f hrt zu dem Engpa oft versteht nur noch der Programmierer sein Programm andere nat rlich auch aber erst nach Monaten des Gr belns Selbst der Programmierer versteht sein Programm nicht mehr wenn er sich l ngere Zeit nicht damit besch ftigt Damit wiederum werden die Kosten f r Systemwartung zunehmend gr er und damit auch wichtiger Hinzu hinzu kommt noch Wartung ist oft Beseitigung von verschleppten Fehlern Ziel jeder industriellen Software Erstellung ist sollte sein das Erreichen einer e hohen Produktivit t und e Qualit t unter Einhaltung der e geplanten Kosten und Termine Anmerkung In Forschung und Lehre findet in der Regel keine industrielle Software Erstellung statt weil das Ziel oft offen ist und der Einsatz keine Rolle spielt Das Ziel kann nur erreicht werden wenn die verschiedenen Aufgaben von Entwicklung Sprachen u Werkzeuge Tools Qualit tssicherung tats chlicher Stand der SW Zeit Kosten Management Organisationsmodelle Kommunikation den Projektteilnehmern bewu t sind Na
12. eines Programms dar Es gibt praktisch keine gr eren Programme welche vollst ndig fehlerfrei arbeiten obwohl die meisten davon durchaus mehrschichtig und gr ndlich getestet wurden Entsprechend der hierarchischen Gliederung des Entwufs in einzelne Module welche sp ter zur L sung zusammengef gt werden unterscheidet man beim Funktionstests den e Modultest und e Integrationstest sowie den sich anschlie enden e Leistungstest Der Aufwand welcher zur Vorbereitung und Durchf hrung von Tests ben tigt wird darf nicht untersch tzt werden Funktions berpr fung Testen 40 Quelle Inform Duden Insbesondere ist die Ermittlung von aussagekr ftigen Testdaten keineswegs einfach und sollte bereits in der Phase des Entwurfs erfolgen 2 6 2 5 Installation und Abnahme Bei der Installation wird das Softwareprodukt in seine Zielumgebung verpflanzt und bernimmt dort seine Aufgabe Dazu sind i d R organisatorische Umstellungen Konvertierung und oder erstmalige Erfassung von Datenbest nden Installation von Infrastruktur notwendig Gelegentlich mu Motivationsarbeit geleistet werden um die Mitarbeiter von dem neuen System zu berzeugen Sind die Benutzer keine DV Fachleute so ist oftmals eine Schulung f r die normalen Benutzer und den e sp teren Administrator des Systems local Guru notwendig Die Installation stellt prim r ein innerbetriebliches organisatorisches Problem dar Sup
13. hne 7 Ba i I 1950 1970 1985 Problem trotz hoher Erstellungskosten haben die Systeme M ngel sie sind meist fehlerhaft erf llen treffen nicht die Anforderungen der Benutzer werden zu sp t fertiggestellt werden meist teurer als geplant Viele Systeme k nnen erst nach umfangreichen nderungen eingesetzt werden wenn berhaupt viele enden in der Schublade oder in der Rundablage unterm Tisch 29 nicht ausgeliefert 19 stark berarbeitet sp ter nicht mehr verwendet 3 verwendet nach nderungen 2 unver nder verwendet 47 nicht verwendet Quelle Comp Wo 15 4 88 Die meisten Fehler entstehen nicht w hrend der Programmierung sondern lassen sich auf Fehler in fr heren Phasen zur ckf hren wenn es diese Phasen berhaupt gegeben hat 20 Fehler durch 25 Codierfehler Fehlerbeseitigung 7 Dokumentationsfehler 3 andere Fehler 45 Design und Analysefehler H ufig pflanzen sich Fehler in Folgephasen fort nach Murphy in sonderbarer fast mysteri ser Weise Je sp ter Fehler entdeckt werden desto h her sind die Kosten f r ihre Beseitigung 1 2 Fehler k nnen nur auf derjenigen Abstraktionsstufe gefunden werden auf der sie gemacht wurden Zeit Analyse _ ij Betrieb Spezifikation gt Installation Entwurf Integration Codierung Test Eingabe gt bersetzung Dies f hrt dazu da Fehler aus fr hen Phasen relativ lange unbemerkt
14. hohen Ma e wiederverwendbar Die daraus resultierenden Eigenschaften der Module sind im Wesentlichen Er kann ohne Kenntnis seines inneren Aufbaus in eine Umgebung eingebettet werden Er kann ohne Kenntnis der Umgebung in die er eingebettet werden soll entworfen und implementiert werden Er soll nur logisch zusammenh ngende Aufgaben beinhalten Seine Schnittstellen sollen m glichst einfach und schmal sein insbesondere aber eindeutig sein Er soll m glichst getrennt bersetzbar sein damit der Aufbau von Modul Libraries gef rdert wird Existiert bereits ein Bibliotheks Modul welches die gew nschte Funktion erf llt bzw nach geringer Modifikation erf llen k nnte dann sollte eine Schnittstelle so definiert werden dass das bestehende Modul bernommen werden kann Falls notwendig sind Entwurfsentscheidungen zu treffen und hinreichend in den entsprechenden Modulspezifikationen zu begr nden Entwurfsentscheidungen k nnen z B Betriebssystem Implementierungssprache Datentypen f r Schnitt stellen betreffen 6 26 6 8 Evaluation eines Entwurfs Der Entwurf legt die Grundlage f r e hochgradig paralleles Vorgehen innerhalb der Implementierungsphase Dadurch werden k rzere Fertigungsdauern realisiert e unabh ngige Realisierung von Teilaufgaben Durch klar definierte Schnittstellen und Modulspezifikationen ist keine Abstimmungen mehr erforderlich e Wiederverwendung der Software Durch den modul
15. sein n chstes Eingabepaket dann l uft er erneut Andere Arten von Aktivierungen sowie eine Deaktivierung ist nur im Rahmen der SA RT m glich Das grunds tzlich Neue daran ist allerdings nur die Deaktivierung F r diese Aktionen werden nicht unbedingt die Proze aktivierungstabellen ben tigt denn entsprechende Aktionen k nnen auch aus Entscheidungstabellen oder RT Diagrammen heraus veranla t 5 15 werden F r kompliziertere F lle bietet aber nur die PAT entsprechende Ausdrucksmiittel an Aktivieren von Prozessen hei t der Proze arbeitet nun tats chlich datengetrieben er f hrt also seine Funktion aus e Nur Prozesse welche nicht ber eine C Spec gesteuert werden sind stets aktiv e ProzeBaktivierung erstreckt sich rekursiv ber alle Ebenen e Ein Proze ist nur dann aktiv wenn alle seine Vorg nger aktiv sind e Wird ein Proze deaktiviert so werden rekursiv alle enthaltenen Teilprozesse deaktiviert auch jene welche nicht explizit durch eine C Spec gesteuert werden 5 5 2 Einfaches Beispiel Im folgenden Beispiel einer PAT im Zusammenhang mit der Steuerung eines EC Geldautomaten werden die vier Prozesse Vorgang W hlen Karte_Pr fen Vorgang_Bearbeiten und Karte_Ausgeben durch die Signale Pr fen Bearbeiten und Auswerfen gesteuert Bei dem Signal Auswerfen sollen alle Prozesse deaktiviert werden au er Karte_Ausgeben Nur dieser Prozess wird aktiviert und ist damit der einzige Prozess der auf Ereignisse reagi
16. 8 4 2 Grenzwertanalyse und quivalenzklassenbildung Ein Grenzwert ist ein Wert am Rand einer quivalenzklasse K Eine Aquivalenzklasse ist eine Untermenge gleichartiger g ltiger bzw ung ltiger Eingaben derart da falls eine Eingabe aus einer Klasse von g ltigen Eingaben eine g ltige Ausgabe erzeugt so auch jeder andere Wert aus dieser Klasse falls eine Eingabe aus einer Klasse von ung ltigen Eingaben einen Fehler erzeugt so auch jeder andere Wert aus dieser Klasse Beispiel if a lt D5 OR a gt 10 then Klasse 1 MAXINT 3 4 11 12 MAXINT Klasse2 5 6 10 Welches sind entsprechende quivalenzklassen bei dem Programmst ck if a lt 5 OR a gt 10 if a mod 2 0 else 8 9 8 4 3 Erfassung Ausf hrung aller m glichen Codesequenzen Ein Programm wird zerlegt in Maximal gerade Programmst cke wird die erste Anweisung ausgef hrt dann auch sicher die letzte Programmverzweigungen auch Mehrfachverzweigungen abh ngig von Bedingungen welche per amp bzw verkn pft sind Daraus ergibt sich ein Programmflu graph mit Knoten sind die Programmverzweigungen sowie ein Start und evtl mehrere Endknoten ausgezeichnete Knoten Gerichtete Kanten sind die maximal geraden Programmst cke Wir unterscheiden Anweisungen CO Pfade C1 Bedingungen C2 Pfade und jeder Schleifengrenze C3 Bei einem Cj Test sind so viele und solche
17. Ein Event stellt ein Ereignis dar bei dessen Eintreten ein Zustands bergang und eine Aktion ausgel st wird Die Kombination Ereignis Aktion wird im Diagramm dem entsprechenden bergang zugeordnet Die Kombination kann auch in der folgenden Form notiert werden Ereignis Aktion Es gibt einen ausgezeichneten Zustand den sogenannten Startzustand In ihm befindet sich das System zu Beginn Dieser Zustand ist dadurch zu erkennen dass ein Pfeil auf ihn zeigt der keinen Ausgangszustand hat Dieser Pfeil kann zur Verdeutlichung mit dem Ereignis Start oder Init beschriftet werden F r die Zustands bergangsdiagramme gelten folgende Regeln e Bei einem bergang kann die Aktion fehlen ein Ereignis muss aber immer da sein das f r einen bergang verantwortlich ist e Aus einem Zustand k nnen mehrere Pfeile herausf hren Die Ereignisse die an diesen Pfeilen stehen m ssen dann disjunkt sein Ansonsten h tten wir kein deterministisches Verhalten Es w rde ja bedeuten dass bei ein und demselben Ereignis mehrere berg nge m glich sind und es wird nicht spezifiziert wie sich der Automat verhalten soll e berg nge k nnen auch zu dem Zustand f hren von dem sie ausgegangen sind Dies ist stets dann der Fall wenn ein Ereignis eine Aktion ausl sen aber keine Zustands nderung bewirken soll Die M glichkeiten von Zustands bergangsdiagrammen sind an dem nun folgenden schematischen Beispiel zu sehen Ereignis3 Aktion3 Zustand
18. Einheiten bilden muss um die Komplexit t neuerer Software Systeme in den Griff zu bekommen und um insbesondere eine Hierarchiebildung zu erm glichen Denn nach den oben definierten Begriffen enth lt ein Modul nur Operationen und kann nicht weitere Module enthalten Operationen lassen sich sogar gar nicht mehr weiter zerlegen Ein Paket kann Module enthalten aber auch weitere Pakete Damit ist eine Hierarchiebildung gew hrleistet Dieser Paketbegriff lehnt sich an Java an In der Realisierung wird ein Paket zu einem Dateiordner Verzeichnis Statt des Begriffs Paket wird h ufig auch der Begriff eines Subsystems verwendet Pakete werden im Folgenden nicht weiter behandelt Sie stellen wie gesagt eine Erweiterung des MD dar dessen Grundlagen wir zuerst erarbeiten m ssen 6 2 4 Dynamische Strukturen mit Tasks Wir benutzen Operationen Moduln und Pakete um die statischen Strukturen eines Systems auf verschiedenen Abstraktionsebenen zu modellieren In weniger komplexen Systemen ist das auch ausreichend um ein System seinen Aufbau und seine Organisation zu verstehen denn seine dynamisch Struktur ist einfach und besteht aus einer Ablaufstruktur dem sogenannten Hauptprogramm Heutige System beispielsweise im Client Server Bereich bestehen aus mehreren Ablaufstrukturen die teils unabh ngig voneinander sind teils aber auch miteinander kommunizieren um Dienste des jeweils anderen in Anspruch zu nehmen Das dynamische Verhalten solcher S
19. Mi erfolg eines SW Projektes ist oft abh ngig von gr ndlicher Vorplanung 3 3 Durchf hrbarkeitsstudie F r die erarbeiteten Ziele und L sungsvorschl ge mu gepr ft werden ob e sie berhaupt technisch realisierbar sind hinreichend gro er schneller sicherer Rechner M glichkeit der Vernetzung Umgebungsbedingungen Temperatur Staub EMV e die notwendigen Randbedingungen geschaffen werden k nnen technischer Natur personelle Voraussetzungen soziales Umfeld z B Personalrat bei ISDN e sie konomisch vertretbar sind d h innerhalb eines vorgegebenen Rahmens ausgef hrt werden k nnen Terminvorgaben Urlaubszeit in Automobilbranche zus Mitarbeiter aus anderer Abteilung f r bergangszeit Mitarbeiterschulung noch vor Weihnachtsgesch ft Kostenvorgaben Mittel f r Beschaffung Rechner in 7 93 zus Personal binden f r n Monate ab 8 93 Das Ergebnis der Durchf hrbarkeitsstudie f hrt e zur Aufgabe des Projekts e zur Revision der Anforderungen oder 3 4 e zur Durchf hrung des Projektes 3 4 Projektplanung Zum Abschlu der Problemanalyse erfolgt die Projektplanung Sie umfa t die Formulierung von Grob und Teilzielen welche innerhalb eines zeitlichen Rasters angesiedelt werden Projekt und alle Teilziele sind fest sie k nnen sich grunds tzlich nicht aus der Arbeit am Projekt ergeben Aus dem Projekt heraus kann jedoch der Ansto zur getrennten Analyse von Ideen ne
20. Probleme anzupassen Es enstehen Entwurfsmuster design patterns die aus einem Ger st von Klassen bestehen und auf viele Anwendungen bertragbar sind Objekt orientierter Entwurf ist Gegenstand einer anderen Vorlesung und wird hier nicht weiter vertieft 6 2 6 Zusammenfassung Wir k nnen den Begriff Modul ganz allgemein verwenden wenn wir eine Komponente bezeichnen die w hrend des Entwurfs erstellt wird Komponente oder Baustein sind Synonyme f r diesen Modulbegriff In der Methode die im Folgenden vorgestellt werden soll wird der Begriff Modul allerdings auch noch verwendet f r eine ganz bestimmte Art von Komponente Als Entwurfskomponenten stehen n mlich zur Verf gung e Operationen e Moduln e Packages e Tasks In diesem Zusammenhang bezeichnet der Begriff Modul die Zusammenfassung von Operationen und Daten zu einem neuen Baustein 6 8 6 3 Strukturen eines Entwurfs Wenn man einen Entwurf aufbaut kann man dies grunds tzlich danach ausrichten wie die Komponenten zusammenspielen sollen Es enstehen zwei unterschiedliche Entwurfsstrukturen e eine Hierarchie mit zentraler Steuerung und Kontrolle oder e ein Netzwerk mit dezentraler Steuerung verteiltes System Bei Netzwerken sind die Komponenten datengetriggert gleichwertige Komponenten kommunizieren miteinander Jede Komponente kann wie ein eigenes System betrachtet werden Bei einer Hierarchie werden die Komponenten aus einer baumartigen Struktur gesteuer
21. Software Live Cycle dar jedoch entf llt auf dieses anteilig am Gesamtprojekt ein hoher Anteil ca 40 70 aufgrund e der langen Laufzeit dieser Phase und e des multiplikativen Faktors wenn das Softwareprodukt mehrmals ausgeliefert wurde was der Regelfall sein sollte Neben der Beseitigung von bei gr eren Systemen unvermeidlichen Fehlern ist es die Aufgabe der Wartung Anpassungen und Erweiterungen des Systems an die sich ndernden Anforderungen vorzunehmen Fehlerkorrekturen und mehrfache Erweiterungen und nderungen ber die Jahre f hren zu einem zunehmend un bersichtlicheren System Saurier Durch die zunehmend berproportionale Bindung von Personal steigen die Kosten f r jede weitere Anderung stark an so da schlie lich ab einem gewissen Alter der Software eine Neuentwicklung langfistig kosteng nstiger ist als eine Ausdehnung der Wartung Man spricht hier gelegentlich von einem Verschlei der Software Der Software Live Cycle schlie t sich mit der Neuentwicklung eines Systems welches das alte abl sen soll 2 8 3 Problemanalyse Ziele der Analysephase e Das zu l sende Problem und alle wichtigen Umgebungsbedingungen m ssen vollst ndig und eindeutig erfa t werden e Die Durchf hrbarkeit und Wirtschaftlichkeit der geplanten Softwareentwicklung m ssen untersucht werden Die Problemanalyse gliedert sich in vier Teile Problemanalyse Durchf hrbar Projekt planung 3 1
22. Testdatens tze zu w hlen da m glichst CO Test jede Kante mindestens einmal durchlaufen wird damit auch jede Anweisung C1 Test jeder m gliche Pfad von Start bis Ende mind einmal durchlaufen wird C2 Test alle Teilbedingungen in einer Programmverzweigung mindestens einmal mit dem Wert wahr und einmal mit dem Wert falsch durchlaufen werden C3 Test alle m glichen Pfade von Start bis Ende f r jede enthaltene Schleife mit allen charakteristischen Werten mind einmal durchlaufen werden wobei charakteristische Werte f r eine Schleifenbedingung sind true false Index lt min Index min Index gt min Index lt max Index max Index gt max Die Durchf hrung eines Whitebox Tests wird ber den Deckungsgrad des Tests z B 100 CO oder 92 C1 angegeben Es ist offensichtlich da eine 100 tige berdeckung i a nicht erreicht werden kann Beispielsweise ist 100 C3 bei geschachtelten Schleifen kaum m glich wegen der kombinatorischen Explosion 8 10 Bei komplexen Bedingungen gilt jeder Teil mindestens einmal true und einmal false und ganze Bedingung mindestens einmal true und einmal false 8 4 4 Beispiel Man entwerfe einen C2 Test f r das folgende Programm Geg int a b c Ges Aussage ob Dreieck mit den Seiten a b c gleichschenklig gleichseitig oder ungleichseitig ist Algorithmus C1 S1 if a lt 0 b lt 0 I c lt 0 then write Seitenl nge mu gt 0 sein C2 S2 if
23. auch vorher definiert Sind Felder und Strings richtig initialisiert Sind die Laufvariablen in geschachtelten Schleifen disjunkt Liegen Indizes innerhalb der Grenzen 1 Element Nr 0 1 Sind die Indizes ganzzahlig Gibt es ung ltige Zeiger Gibt es Uber Unterlauf Rundungsfehler von Variablen Kann Division durch 0 auftreten Wird die Priorit t der Operatoren richtig verwendet bzw geklammert Sind die boolschen Ausdr cke korrekt Werden bei Entscheidungen alle F lle ber cksichtigt Terminiert jede Schleife Vgl Mye 79 8 3 5 Automatische Methoden der Programmvalidierung Wenn Fehler entdeckt werden k nnen dann i d R durch komplexe und aufwendige bersetzer welche das Quellprogramm durch Syntax u Semantikpr fung so weit wie berhaupt m glich analysieren Weitere automatische Analysen beschr nken sich darum oftmals auf formale Aspekte wie keine zu langen Zeilen im Programmtext keine zu komplexen arithmetischen oder logischen Ausdr cke berpr fung der Einr ckregeln bei Bl cken Funktionsdeklarationen Einhaltung von Programmiierrichtlinien Aus den ermittelten Daten H ufigkeit des Auftretens werden Software Metriken erstellt Sie lassen jedoch nur sehr begrenzt R ckschl sse auf die Qualit t von Software wie z B Modularit t Wartbarkeit Testbarkeit Sicherheit zu 8 4 Das Testen von Programmen Eine M glichkeit der quasiautomatischen Programmvalidierung bie
24. auf der einen Seite Daten identifizieren Datenkopplung auf der anderen Seite auch Information tragen die das Verhalten eines Moduls beeinflu t wie im folgenden Beispiel Kundenschl ssel 0000 8899 Standard Kundenkonto 8900 8999 Internes Einkaufskonto 9000 9999 Mitarbeiter Einkaufskonto Hybride Kopplung sollte vermieden werden indem man den Daten und den Signalanteil trennt Dadurch wird zwar wieder die Schnittstellenbreite erh ht was eigentlich schlecht ist daf r aber gewinnt die Klarheit der Schnittstelle enorm Funktionen sind global gekoppelt wenn sie Daten gemeinsam benutzen die nicht ber einen normalen Funktionsaufruf ausgetauscht werden Damit wird effektiv die eigentliche Funktionskommunikation verborgen die die Grundlage f r das Pr fen und Verbessern eines Entwurfs ist Die Probleme der Globalen Kopplung sind e Funktionen die globale Daten benutzen greifen darauf ber einen expliziten Namen zu Eine Wiederverwendung wird damit schwierig e Unterschiedliche nicht zusammenh ngende Daten die in einem gemeinsamen globalen Speicherbereich untergebracht sind sind schwer zu warten e Die Verwendung von globalen Datene erschwert die Lesbarkeit eines Programms Es ist kaum m glich die Kopplungsart zu bestimmen wenn die Kommunikation im wesentlichen ber globale Daten erfolgt e Au erdem ist es schwer zu sagen welche Funktion welche Daten ben tzt Bei nderung an einer Stelle m ssen alle Funktionen gepr f
25. auf die verschiedenen Benutzerklassen z B Warenhaus Verk ufer Storno f r Abt Leiter Bestellungen Zahlungsanweisungen Verhalten bei auftretenden St rungen Notma nahmen Hauptproblem bei der Analysephase jeder hat zun chst nur seine Sicht auf das Problem 1400 VRR 5 2CH4 OH 3H5 2 if Gnt p 1400 Bet Oftmals werden mehrere alternative L sungskonzepte erarbeitet jedoch stets unter Einbeziehung des Anwenders MERKE 1 Nur selten wird ein Problem zum ersten Mal gel st 2 Auch wenn jedes Problem individuell gel st werden mu so gibt es doch i d R eine Vielzahl hnlicher bereits gel ster Teil Probleme 3 3 3 Oftmals kann es sinnvoller sein eine Standardl sung fertiges Produkt einzukaufen oder die L sung in Zusammenarbeit mit einem anderen Unternehmen zu erstellen Spezialisierung bzgl Hardware SUN HP NeXt Software PDV DTP gt Oftmals ist der Mi erfolg des Einsatzes von EDV darauf zur ckzuf hren da man versucht die aus der Handarbeit gewohnte Organisation Arbeitsabl ufe technische Verfahren in die Datenverarbeitungsphase hin berzuretten Das betrifft u ere Verfahren wie auch rechnerinterne Abl ufe 2 Oftmals existieren in der bergangsphase alte und neue L sung dies bedeutet zus tzliche Arbeit auch Kosten weil zwei Systeme parallel betrieben werden m ssen darum Dauer der Ubergangsphase planen Fazit Erfolg oder
26. automatische Verifikation unterst tzen In der Praxis spielt die Verifikation noch keine gro e Rolle Unter der Programmvalidierung versteht man die Pr fung der Spezifikationstreue einschlie lich etwa geforderter Leistungsdaten Die Pr fung kann beispielsweise bestehen aus e Simulation e Gegen berstellung von Programm und Testprogramm evtl Testautomat e Plausibilit tsbetrachtungen e Code Inspektion e Messungen 8 1 Systematisches Testen bedeutet das Ausf hren des Programms mit einem vorher festgelegten Satz von m glichen Eingabedaten den sogenannten Testdaten Tests k nnen praktisch nur die Anwesenheit von Fehlern zeigen keinesfalls die Fehlerfreiheit Bei der Auswahl von Testdaten ist daher besondere Sorgfalt notwendig Testdaten werden nicht erst nach erfolgter Implementierung ausgew hlt sondern sind Bestandteil des Entwurfs Bereits beim Entwurf sollte ein m glichst vollst ndiger und zugleich minimaler Satz von Tests bzw Testdaten bestimmt werden Vollst ndig Jede Anweisung des Programms mu mindestens einmal mit Grenzdaten durchlaufen werden Minimal Den gleichen Test mit unterschiedlichen Testdaten f r einen Modul braucht man nicht mehrmals durchzuf hren wegen kombinatorischer Explosion und resultierendem Aufwand und Nachdenken lohnt immer 8 2 Klassifikation von Fehlern Fehler lassen sich naiv nach ihrem Typ einteilen Formale Fehler wie z B Schreibfehler falsche Anwend
27. bleiben bevor sie entdeckt werden Bereits 1968 und 1969 fanden zwei NATO Konferenzen statt auf denen L sungsans tze entwickelt wurden um die Softwarekrise zu l sen Zur L sung der aufgezeigten Probleme begann man strukturierte Methoden zu entwickeln Erste Ans tze befassten sich ausschlie lich mit der Codierung Dijkstra h rt endlich auf mit GOTO zu programmieren Die in der Folgezeit entwickelten Methoden und Techniken befassen sich mit der ingenieurm igen Entwicklung von Software Sie werden unter dem Oberbegriff Software Engineering bzw Programmkonstruktion zusammengefa t o OOP Analyse o Ward Mellor o De Marco 7 i Entwurf o Yourdon Constantine Ern chgerung o Parnas o Hatley S o Wirth Program mierung Dijkstra 1970 75 80 85 90 95 Dijkstra Programmverifikation sequentielle parallele Prozesse kein goto mehr Wirth Strukturierte Programmierung PASCAL Modula 2 Hatley Pirbhai Real Time Modelling Parnas Einf hrung des Begriffs Modul und Definition Yourdon Constantin Structured Design Technique SD De Marco Structured Analysis SA Ward Mellor Erweitererung der SA De Marco um Kontrollprozesse Chen Entity Relationship Approach XEROX Corp Smalltalk ab 1970 entworfen 1983 Smalltalk 80 von A Goldberg D Robson Stroustrup OOP mit C 1983 bei AT amp T Booch Jakobson OO Analyse und Design mit UML 1995 Rumbaugh Prinzipielles Problem Je komplexer die Systeme werden
28. dargestellt y Datenparameter P Hybridparameter Kontrollparameter N Funktionsr ckgabe J Ein Ausgabeparameter Hybridparameter k nnen sowohl Daten als auch Kontrollparameter beschreiben beispielsweise im Erfolgsfalle einen Wert im Fehlerfalle einen Fehlerindikator Diese Art von Parametern stellt aber eine schlechte Kopplungsart dar und sollte vermieden werden Darauf werden wir sp ter noch zu sprechen kommen Parameter mit einem Doppelpfeil stellen Returnwerte der Operation dar Je nach Art des Ergebnisses wird der Kreis leer gelassen ausgef llt oder mit einem Punkt versehen Eine Aufrufkante kann nur einen Returnparameter haben Returnparameter sind immer Ausgabeparameter Die beiden letztgenannten Arten von Parameter n mlich Hybridparameter und Returnparameter werden wegen ihrer spezifischen Eigenheiten nicht in jeder Methode unterst tzt Sie kamen beispielsweise im urspr nglichen Structured Design nicht vor 6 19 6 5 4 Beispiel eines Operationsdiagramms ToDo 6 5 5 Arten von Operationen Je nachdem wie eine Operation mit den anderen verkn pft ist kann man verschiedene Klassen von Operationen unterscheiden O A O 2 K O S K 7 K Eingabe Ausgabe Transformations Koordinierungs Operation Operation Operation Operation 6 20 6 5 6 Beschreibung von Operationen Jede in einem Operationsdiagramm verwendete Operation mu auch beschrieben werden Man unterscheidet drei Teile in einer solchen Beschreibung
29. dass es sich um einen Modul handelt der eine komplexe Logik beinhalten muss um die vielen Module aufzurufen Mit gro er Wahrscheinlichkeit ist damit die Verst ndlichkeit und Wartbarkeit gering Au erdem ist es unwahrscheinlich dass der Modul noch anderweitig wiederverwendet werden kann da er zu viele Abh ngigkeiten hat Ein geringes Fan Out kann durch Faktorisieren erreicht werden Ziel dieser berlegungen ist ein balanciertes System Ein System ist balanciert wenn e ein hoher Fan Out auf den oberen Ebenen und e ein hoher Fan In auf den unterene Ebenen herrscht wie es das folgende Schema zeigt Durch diese Bedingungen wird gew hrleistet dass auf den oberen Ebenen Daten von hoher Abstraktion verarbeitet werden a E EZ o Da E Balancierte Systeme sind sehr stabil gegen ber nderungen der Spezifikation oder externer Ger te Im Gegensatz dazu stehen input bzw output gesteuerte Systeme bei denen die oberen Hierarchieebenen direkt mit physikalischen Ein oder Ausgabedaten arbeiten wie es das folgende Bild zeigt 6 37 Input oder output gesteuerte Systeme sind sehr anf llig gegen ber Spezifikations nderungen und k nnen in der Wartungsphase sehr hohe Kosten verursachen Sie sollten daher gemieden werden 6 8 7 Scope Of Effect eines Moduls Eine andere berlegung die man zur Bewertung eines Moduls anstellen kann betrifft das Scoping Man unterscheidet zwei Scopes e Der Scope of Control eines Mod
30. der gesamte Fluss selbst in mehrere Richtungen weiterflie t e Mit Merge Fluss wird ein Fluss bezeichnet der mehrere Anfangssegmente aber nur ein Endsegment hat Dabei ist es unerheblich ob diese Anfangssegmente Verfeinerungen des Flusses sind oder der gesamte Fluss selbst aus mehreren Richtungen kommt Die Verfeinerung das Aufspalten und das Verbinden von Fl ssen muss ber die Definition der Fl sse Segmentnamen ber das Data Dictionary abgesichert sein Darauf wird sp ter noch ausf hrlich eingegangen 4 2 3 Speicher Ein Speicher dient zur Ablage der auf den einflie enden Fl ssen transportierten Daten Prozesse k nnen lesend und schreibend auf einen Speicher zugreifen Ein Speicher tr gt immer den Namen des Typs der in ihm enthaltenen Information d h den Namen der mit ihm verbundenen Fl sse F r Speicher gelten die folgenden Regeln e Jeder Speicher erh lt einen sinnvollen Namen der einen R ckschluss auf seinen Speicherinhalt erm glicht Der Name muss im Data Dictionary definiert werden e Ein Speicher sollte nur dann angelegt werden wenn mindestens zwei Knoten zu unterschiedlichen Zeitpunkten auf den Inhalt zugreifen e Datenfl sse zwischen Speicher und Knoten k nnen unbenannt sein In diesem Fall wird auf den gesamten Speicher zugegriffen Den Fl ssen von oder zu Speichern k nnen generell keine Namen zugewiesen werden da sie wie oben erw hnt mit dem Speicher mit dem sie verbunden sind identifiziert w
31. die Spezifikation einer Vielzahl von technischen Details erfordert e die Personen die die Anwendung verstehen nicht die gleichen sind die sie implementieren Technologische Randbedingungen wie Performanz Zuverl ssigkeit Testbarkeit Wartbarkeit Kosten und physikalische Einschr nkungen f hren zu einem iterativen Vorgehen mit manchmal gro en Korrekturen w hrend der Designphase Aus diesen Gr nden gibt es f r einen Design folgende Zielsetzungen e Wartbarkeit neue Komponenten sollen gegen bestehende leicht ausgetauscht werden k nnen e Flexibilt t neue Anforderungen sollen leicht integriert werden k nnen e Wiederverwendbarkeit einzelne Komponenten sollen auch in anderen Software Systemen eingesetzt werden k nnen e Lesbarkeit die Struktur des Systems soll bersichtlich dargestellt werden e Teamarbeit verschiedene Personen sollen gleichzeitig am System entwickeln k nnen 6 3 W hrend bei der Analyse die gegenw rtigen Anforderungen beleuchtet werden muss ein Design auch zuk nftige Anforderungen ber cksichtigen um diesen Zielsetzungen gerecht zu werden Denn das Ziel ist eine modulare Struktur f r das System zu schaffen um den Wartungsaufwand zu reduzieren und die Wiederverwendbarkeit zu steigern Ein guter Entwurf unterst tzt also eine Phase die erst in einiger Zeit stattfinden wird Die w hrend des Entwurfs erstellten Komponenten werden Module genannt Man lehnt sich bei diesem Begriff bewu t an di
32. eines Programms mu die Semantik der verwendeten Programmiersprache zun chst mit Hilfe der wp s beschrieben werden Beispielsweise lauten die Regeln f r die Programmiersprache Pascal D5 Zuweisung wp x t N Nt x D6 Konkatenation wp S1 S2 N wp S1 wp S2 N D7 Entscheidung wp if B then S4 else S2 fi N B amp wp S1 N B amp wp amp 2 N 8 14 D8 Schleife wp while B do S od N 3 i e N Hi N wobei Ho N B amp N Hi 1 N B amp wp S Hi N D h es gilt Ho B amp N H1 B amp wp S Ho N B amp wp S B amp N H2 B amp wp S H1 N B amp wp S B amp wp S Ho N B amp wp S B amp wp S B amp wp S aB amp N 8 6 2 Beispiel Gesucht ist die schw chste Vorbedingung daf r dass nach der Ausf hrung des Programmst cks if x 2 0 then y x else y X fi gilt Die folgende Ableitung ist ein Beweis daf r da dies stets gilt wp if x gt 0 then y x else y x fi y gt 0 mit D7 x 20 amp wp y x y gt 0 x lt 0 amp wp y x y gt 0 mit D5 x gt 0 amp x gt 0 I x lt 0 amp x gt 0 x gt 20 x lt 0 true Dass die Ausgangsbedingung zu true abgeleitet wurde bedeutet doch dass dies offensichtlich ohne jede Vorbedingung also stets gilt 8 15 9 Phasen bergreifende T tigkeiten 9 1 Dokumentation Allgemeine Grund Regeln zur Dokumentation F r Projekt wird eine
33. hrung der Softwareentwicklung sollte der Lieferant einen vollst ndigen und eindeutigen Satz von funktionalen Forderungen haben 5 4 Planung und Entwicklung 5 5 Planung der Qualit tssicherung 5 6 Design und Implementierung 5 7 Testen und Validieren 5 8 Annahme 5 9 Vervielf ltigung Lieferung und Installierung 5 10 Wartung 6 Qualit tssicherungssystem Unterst tzende T tigkeiten 6 1 Konfigurationsmanagement 6 2 Lenkung der Dokumente 6 3 Qualit tsaufzeichnungen 6 4 Messungen am Produkt 6 9 Schulung Beispiel eines Qualit tssicherungshandbuchs in Rot 93 9 11 9 3 Projektorganisation In der Praxis werden SW Projekte innerhalb einer Gruppe realisiert Spezifische Aufgaben innerhalb eines Projekts sind e Verwaltungs Administrationsarbeit Projektleitung Vertretung des Proj gegen ber der Firmenleitung Vertretung des Proj nach au en Kundenkontakt Termin u Kosten berwachung Controlling e Eigentliche Projektarbeit Analyse und Spezifikation Entwurf Implementierung Test und Integration Dokumentation Installation Abnahme e Qualit tskontrolle sicherung e Konfigurations Versionsverwaltung e Betreuung der Entwicklungsumgebung Pflege Ausbau Know How Formen der Projektorganisation sind e Hierarchische Projektorganisation e Einflu Organisation e Matrix Organisation e Chef Programmierer Team 9 12 9 4 Planung Steuerung und berwachung des Projekts Wesentlicher Grund f r die Defin
34. sind e interne Realisierung des Moduls unbekannt und uninteressant e lediglich berpr fung anhand der Schnittstellen Spezifikation des Moduls Beispiel Man entwerfe Testdaten f r die Prozedur Eingabe 3 Seitenl ngen eines Dreiecks Ausgabe ungleichseitig gleichschenklig gleichseitig Einige Testf lle 1 ungleichseitig bei 1 2 3 oder 2 5 10 keine Ja Antwort da kein Dreieck 2 gleichschenklig bei 2 2 4 keine Ja Antwort da kein Dreieck 3 bei gleichschenklig alle Permutationen mit 2 gleichen Seiten 4 Testfall mit einer Seite gleich 0 oder 4 5 Testfall 0 0 0 6 Testfall mit nicht ganzzahligen Werten 7 Testfall mit nur 2 Eingabewerten 8 8 Kennzeichnend f r Whitebox Tests sind interne Realisierung liegt in Form des Quell Codes vor Whitebox Tests werden manchmal auch als Glasbox Tests bezeichnet W hrend Testf lle f r Blackbox Tests bereits in der Designphase entworfen werden k nnen und sollten denn zu diesem Zeitpunkt ist ja die Schnittstelle und das Verhalten bez glich der Schnittstelle bekannt handelt es sich bei den Whitebox Tests um zus tzliche Tests die nun nachdem die Implementierung bekannt ist entworfen werden k nnen Die Definition von neuen zus tzlichen Testf llen ist notwendig da nun auch die Eigenschaften eines Moduls durch die Implementierung genauer bekannt sind Im Folgenden wenden wir uns einer Reihe von Methoden zu mit deren Hilfe Whitebox Testdaten gewonnen werden k nnen
35. siv Wandle ASCII Eingabe in internes Format um Dividiere die Eingabe durch 360 und multipliziere Ergebnis mit Pi Wandle Ergebnis in einen ASCII Zeichenstring um Die Beurteilung eines Moduls h ngt vom Standpunkt des Moduls ab Moduln die von einem Modul gerufen werden sollten funktional koh siv sein Moduln die andere Moduln benutzen erscheinen oft weniger als funktional koh siv Betrachten wir dazu das folgenden Beispiel Controler Turntable Amplifier Phones Speaker Aus der Sicht des HiFi Controllers sollte das Modul Amplifier funktional koh siv sein Aus der Sicht des Moduls Amplifier bedient das Modul HiFi Controller noch andere Moduln Es erscheint damit weniger als funktional koh siv Ein Modul ist sequentiell koh siv wenn die Reihenfolge der Ausf hrungen entscheidend ist Es findet eine aufeinanderfolgende Verarbeitung von Daten statt Die einzelnen Elemente des Moduls m ssen nacheinander aufgerufen werden Die folgenden Elemente des Moduls Lackiere ein Auto neu sind sequentiell koh siv Auto waschen Fenster und Chromteile abkleben L cher ausf llen Auto sandstrahlen Rostgrund auftragen trocknen Lack auftragen trocknen polieren 6 33 Ein Modul ist kommunikativ koh siv wenn f r die Durchf hrung verschiedener Aufgaben die gleichen Ein oder Ausgabedaten benutzt werden Die folgenden Elemente des Moduls Buchbearbeitung sind kommunikativ koh siv suche Buchtitel suche Buchpr
36. ufiger ist der Begriff Kontrollspezifikation oder Kontrollinstanz Nur wenn ein Kontrollfluss in einen Barren hineinflie t wird er dort verarbeitet Kontextdiagramm Kontrollflu Kontrollfl sse k nnen ebenso in Datenspeichern abgelegt werden wie Datenfl sse Prozesse dienen nicht der Verarbeitung von Kontrolifl ssen oder zur Ablaufbeschreibung Endet ein CF in einem Proze so mu er in tiefere Ebenen verfolgt werden bis er in einem Barren verarbeitet wird Im obigen Bild wird P1 nicht durch Taster 1 gestartet Soll dies der Fall sein so mu Start Eingang einer entsprechenden Proze aktivierungstabelle f r P1 sein Wie im folgenden Bild zu sehen haben Kontrollfl sse ihren Ursprung 5 2 im Kontext Diagramm d h kommen von au erhalb des Systems Quelle in einer Kontrollspezifikation oder in einem Proze und werden aus einem Datenflu abgeleitet Prozess 2 3 Name P16 Input Wert Limit Output ontr Out K3 Die Namensgebung sollte den Kontrollcharakter verdeutlichen z B Taste_gedr ckt Fehler13 vorw rts Druck steigend Kontrollfl sse sind i d R bin re Gr en k nnen jedoch auch einen gr eren Wertebereich besitzen Es sind dann aber stets diskrete Wertebreiche Je nachdem wie sie in einer Kontrollspezifikation verarbeitet werden werden Kontrollfl sse bezeichnet als Bedingung wenn sie als Eingang einer Entscheidungstabelle dienen Ereignis falls sie als Eing
37. verantwortlich ist 4 2 Qualit tssicherungssystem 4 2 2 Dokumentation des Qualit tssicherungssystems Alle Elemente Forderungen und Vorkehrungen f r das Qualit tssicherungssystem sollen in einer systematischen und geordneten Weise klar dokumentiert sein 4 2 3 Qualit tssicherungsplan Der Lieferant sollte auf der Basis des Qualit tssicherungssystems f r jede Software Entwicklung einen Qualit tssicherungsplan erarbeiten und dokumentieren 4 3 Interne Qualit tsaudits 4 4 Korrekturma nahmen 5 Qualit tssicherungssystem Lebenszyklust tigkeiten 5 1 Allgemeines Ein Software Entwicklungsprojekt sollte nach einem der verschiedenen Lebenszyklusmodelle organisiert sein 5 2 Vertrags berpr fung 5 2 2 Qualit tsrelevante Vertragspunkte Unter anderem werden folgende Punkte f r einen Vertrag oft als zutreffend erachtet a Annahmekriterien b Behandlung von Anderungen der Auftraggeberforderungen w hrend der Entwicklung c Behandlung von Problemen die nach der Annahme entdeckt werden einschlie lich qualit tsbezogener Anspr che und Auftraggeberbeschwerden d T tigkeiten die vom Auftraggeber erbracht werden insbesondere die Rolle des Auftraggebers bei der Festlegung der Forderungen bei der Installation und bei der Annahme e vom Auftraggeber bereitzustellende Einrichtungen Werkzeuge und Softwareelemente f anzuwendende Normen und Verfahren 5 3 Spezifikation des Auftraggebers F r die Durchf
38. verwendet wurden Sie werden nun im Folgenden formal eingef hrt 4 3 4 2 Datenflu diagramme Datenflu diagramme sind eine grafische Darstellung von Systemfunktionen Prozessen und ihren Schnittstellen den Datenfl ssen Datenflu diagramme k nnen aus den folgenden Komponenten aufgebaut werden Datenflu A XN Materialflu Aktion Proze Aufgabe Speicher Ablage Quelle oder Senke von Information oder Material Mit ihnen lassen sich die funktionale Struktur e bereits bestehender Analyse wie auch e neu zu entwickelnder Systeme Spezifikation u abstraktes Design darstellen 4 4 Beispiel Lexikon korrekt geschriebene W rter W rter W rter Unter der funktionalen Struktur wird hier die Hierarchie von Systemaktivit ten zusammen mit ihren Schnittstellen untereinander sowie zur Umgebung des Systems verstanden Funktional hei t in diesem Falle statisch d h es ist kein zeitlicher Ablauf enthalten A B gt u Y G Nach De Marco ist Pi unendlich schnell Aber es ist klar da B erst nach A berechnet werden kann Datenflu diagramme zeigen anschaulich welche Daten auf welchen Wegen durch das System flie en welche Bearbeitungsstationen sie dabei passieren und von welcher Art die jeweils vorgenommene Bearbeitung Transformation ist Es werden die Ein Ausgabedaten d h die Schnittstellen f r das gesamte System ebenso wie f r jeden enthaltenen Bearbeitungs
39. werden e Relevante Testf lle nicht zu komplex w hlen sie sollen von Menschen nicht vom Compiler bearbeitet werden e Erfordert Vorbereitung der Teilnehmer diese sollten Listing kennen Auch hier wird wieder der Programmablauf anhand des Listings schrittweise durchgespielt Dabei sollte jedoch nicht das korrekte Durchspielen der Testf lle im Mittelpunkt stehen sondern das gedankliche Nachvollziehen von Varianten und die Beantwortung von auftretenden Fragen Was w re wenn i nicht diesen Wert h tte sondern Die Vorteil dieses Verfahrens sind weniger fehleranf llig da mehrere Personen beteiligt sind bessere schnellere Einarbeitung weil Autor Teammitglied ist Erfahrungen von Spezialisten werden dabei weitergegeben Die Beseitigung von Programmierfehlern ist nicht Bestandteil des Walkthrough sondern wird vom Programmierer gesondert sp ter erledigt Bei entsprechender Zahl von Fehlern ist ein erneuter Termin f r einen Walkthrough mit dem dann berichtigten Programm zu vereinbaren Erfahrungsgem ergeben sich beim ndern von Programmen mehr Fehler als beim Schreiben neuer Fehler Lines Code 8 5 8 3 3 Codeinspektion Codeinspektion bedeutet Sequentielles Lesen und Verstehen des Programms durch eine Testgruppe bestehend aus 3 bis 4 Mitgliedern e Moderator QS Fachmann oder erfahrener Progammiierer er mu keine Details vom Programm kennen Seine Aufgaben sind Verteilung von Unterlagen Leit
40. werden analog zu Datenfl ssen an die Stelle des Systems geleitet wo sie ben tigt werden Zur Unterscheidung ob ein Kontrollfluss weitergeleitet wird oder in einem Diagramm zur Steuerung ben tigt wird enden letztere auf einem Balken auch Barren oder Bar genannt Die Bars bilden die Schnittstelle zwischen den Diagrammen und den zugeh rigen Kontrollspezifikationen Aus bersichtlichkeitsgr nden kann es in einem Diagramm mehrere Bars geben aber sie geh ren alle zu ein und derselben Kontrollspezifikation Die Kontrollspezifikation dient als Quelle und Ziel f r Kontrollfl sse Da die Verarbeitung der Kontrollfl sse in den Kontrollspezifikationen erfolgt legt man zu den CFDs die erforderlichen Kontrollspezifikationen an In der Regel existiert jedoch nicht zu jedem CFD eine Kontrollspezifikation es wird nur dann eine angelegt wenn eine direkte Steuerung der Prozesse des CFDs durch Kontrollfl sse erfolgt Als sichtbares Zeichen daf r dass es zu einem CFD eine Kontrollspezifikation gibt werden die Balken verwendet 5 2 1 Darstellungsmittel Um komplexere Steuerungen m glichst klar darstellen zu k nnen greift man auf Darstellungsmittel der Automatentheorie zur ck Endliche Automaten unterteilen sich in Kombinatorische und Sequentielle Automaten Bei Kombinatorischen Automaten h ngt die Ausgabe einzig von der gegenw rtigen Eingabe ab Sie k nnen mit Hilfe von Entscheidungstabellen dargestellt werden Bei Sequentiellen Automaten h ng
41. wie weit sind sie denn Herr M ller I fast fertig bis auf d h mu noch mind 30 machen II habe gerade erst angefangen und d h hat ca 60 fertig F r viele Methoden der Softwareerstellung und Projektabwicklung insgesamt gibt es Werkzeuge sogenannte CASE Tools CASE Computer Aided Software Engineering e Software Through Pictures STP e Innovator e Rational Rose Jedoch Werkzeuge helfen nur denen die sie richtig anwenden k nnen wollen Wichtiger noch als die Werkzeuge selbst ist das Wissen um die Prinzipien die Methoden die Werkzeuge welche zu beachten sind welche richtig einzusetzen sind welche es gibt wann sinnvoll einsetzbar Organisationsmodelle welche Struktur f r welche Aufgabe bzw Projektphase Zur bewu ten Unterscheidung Prinzipien sind Grunds tze die wir dem Handeln zugrunde legen Sie sind allgemeing ltig und abstrakt Sie entstehen aus Erfahrungen und Erkenntnissen z B schlechte Prinzipien Sage deinem Chef nie wie weit du wirklich bist Mache dich durch trickreiche Programmierung unentbehrlich Zu den guten Prinzipien kommen wir noch Methoden sind planm ig angewendete begr ndete Vorgehensweisen zur Erreichung von festgelegten Zielen Sie enthalten also den Weg d h ein Rezept zu etwas hin Sie machen Prinzipien anwendbar z B schlechte Methoden Man versorge seine Kollegen stets reichlich mit Spielprogrammen z B gute Methoden
42. zisierung der Zielsetzung in Form eines Katalogs von Anforderungen und Randbedingungen dem Pflichtenheft Pflichtenheft Anforderungsdefinition zus tzliche Randbedingungen zus tzliche Vereinbarungen wie z B Termine Abnahmeprotokoll Haftung bei Fehlern Produkthaftungsgesetz Funktionsgarantie mit Recht auf Nachbesserung Aufgaben f r Auftragnehmer Infrastruktur bereitstellen erstmalige Datenerfassung evtl Wartungsmodalit ten Hinweise dazu Technik VDI VDE Richtlinien VD VDE 3694 Deutsche Norm DIN ISO 9000 Teil 3 Qualit tsmanagement und Qualit tssicherungsnormen entspricht unver ndert der int Norm ffentliche Auftraggeber in Deutschland Das V Modell Planung und Durchf hrung von IT Vorhaben in der Bundesverwaltung Koordinierungs und Beratungsstelle der Bundesregierung KBSt Band 27 1 Bundesminister des Innern U berbl in iX 3 95 S 162 ff SW Erstellung mit V Modell International int Norm ISO 9000 3 Quality management and quality assurance standards spez in USA DoD STD 2167 Verteidigungsindustrie Frankreich GAM T 17 Im folgenden ist ein Schema f r ein solches Pflichtenheft zu finden 3 7 Pflichtenheft zum Projekt Proze informationssystem Mai 1993 Auftraggeber FHTE Esslingen vertreten durch Herrn Dr Hard lt Zeichnungsberechtigter Unterschrift Auftragnehmer Fa Mega Soft vertreten durch Herrn Dipl Ing Hacker lt Zeichnungsbe
43. 1 Ereignis Ereignis Aktion Zustand2 5 11 5 12 5 4 2 Einfaches Beispiel Als Beispiel betrachten wir ein Rotationskombinationsschlo wie es in den meisten Stahlschr nken zu finden ist Wir beschr nken uns hier auf 3 R der die eingestellt werden m ssen Die R der m ssen der Reihe nach richtig eingestellt werden Bei jeder richtigen Einstellung werden die entsprechenden Stifte im Schlo ge ffnet bei einer falschen Einstellung muss wieder ganz von vorne begonnen werden Start 1 Stelle falsch 2 Stelle falsch Alle Stifte zu Warten auf zweite Stelle 3 Stelle falsch 2 Stelle korrekt Alle Stifte zu Stift 2 auf Warten auf dritte Stelle 3 Stelle korrekt Stift 3 auf Schlie e Schlo Alle Stifte zu Schlo offen III 5 4 3 Zustands bergangsmatrix Neben der Darstellung als Zustands bergangsdiagramm k nnen die Endlichen Automaten auch durch eine Zustands bergangsmatrix also in einer Tabellenform dargestellt werden Der Informationsgehalt ist der gleiche Die grafische Form des Diagramms ist nur leichter verst ndlich Aus U bersichtsgr nden teilt man die Zustands bergangsmatrix in zwei Teile auf den Goto Teil der die Zustands berg nge beschreibt und den Action Teil der die dabei auszuf hrenden Aktionen enth lt 5 13 Der Automat aus dem Beispiel oben k nnte damit auch folgenderma en dargestellt werden ToDo 5 4 4 Eigenschaften von RT Diagra
44. Dokumentation angefertigt Dies gilt auch f r solche Projekte welche nach der Analysephase nicht weitergef hrt werden Die Gr nde daf r sind die bisher ohnehin geleistete Arbeit wird nicht wertlos Kunde gibt vielleicht zu einem sp teren Zeitpunkt den Auftrag bei hnlichem Projekt reduziert sich die Analysephase kann evtl f r andere honorierte Vorstudie verwendet werden Dokumentation ist nicht Selbstzweck oder l stiges Anh ngsel Wer nicht von ihrer Notwendigkeit berzeugt ist oder keine sehr guten Kenntnisse ber das zu dokumentierende Programm besitzt sollte nicht dokumentieren Es wird sonst nur massenweise nichtssagendes Papier produziert Dokumentation dient den Zielen e Sicherung des rechtlichen Rahmens zwischen Projekt Partnern genaue Spezifikation der Aufgabe Anforderungen und der Projekt Randbedingungen wie Termine Kosten im Pflichtenheft e Sicherung des Projektfortschritts sichere Projektverfolgung und Ist Soll Abgleich von Terminen und Resourcen im Projekt Netzplan schriftliche Festlegung der Schnittstellen zwischen Projekt Phasen SA RT Diagramme ER Diagramme Pflichtenheft Lastenheft Structure Charts Modulbeschreibungen Testergebnisse Abnahmeprotokoll Nachvollziehbarbeit von Entw rfen Entscheidungen Aktionen Protokolle von Reviews nochmalige Pr fung e Qualit tssicherung durch QS Handbuch vgl ISO 9000 9 1 klare Aufgaben und Kompetenzverteilung auf P
45. Istanalyse Die Istanalyse soll die bestehende Systemstruktur beschreiben Systemabgrenzung Was geh rt nicht mehr zum System dazu Was sind wichtige Randbedingungen die es zu beachten gilt Wann funktioniert das System nicht mehr Vorsicht dabei werden die f r das Problem relevanten Teilaspekte der F hrungs und Entscheidungsstruktur des Unternehmens aufgedeckt Systemerhebung e Bereits existierende Informationsfl sse und kan le erfassen e Analyse der vorhandenen Informationsverarbeitungsverfahren Wie komplex ist eine Teil Aufgabe L t sie sich schematisieren mechanisieren Wie weit ist sie bereits automatisiert Wodurch wird die Aufgabe angesto en Welche Ein und Ausgabedaten hat die Aufgabe Wie wird sie momentan gel st Welchen Umfang haben die Daten Welche Verarbeitungsgeschwindigkeiten liegen vor 3 1 Systembeschreibung Nachdem alle Zusammenh nge und Abh ngigkeiten erfa t sind kann ein erstes reduziertes Modell erstellt werden Faktenanalyse Sie liefert genaues Zahlenmaterial mit dem das Modell auf seine Richtigkeit und Vollst ndigkeit hin berpr ft werden kann Leseoperationen sec Tansaktionen sec User mittel max Das Hauptproblem bei der Istanalyse ist die Gewinnung von zuverl ssigem Material weil Betroffene oftmals Widerstand gegen die Einf hrung des Projektes leisten bzw pessimistische Einstellung gegen ber dem Projekt haben Arbeitsplatz gef hrdet Selbstwertg
46. M C B A hanoi 17 6 Generation Neuronale Netze Es gibt eine Trainings bzw Lernphase statt der Programmierung 1 4 GL oder der Wissensspezifikation 5 GL Es ist nicht mehr nachvollziehbar wie L sungen entstehen Selbstorganisation Evtl sind die Systeme selbstlernend und daher nach einer Anfangszeit fehlerfrei 7 23 8 berpr fung und Test Die berpr fung eines Programmes kann erfolgen durch Programmverifikation e Programmvalidierung e Systematisches Testen Dies sind abgestufte Methoden welche sich erg nzen Programmvalidierung und systematisches Testen mu eingesetzt werden wenn eine Verifikation nicht m glich ist wegen der Gr e des Programms mangelnder oder ungenauer Spezifikation oder wegen Kosten Qualifikation des Personals 8 1 bersicht ber die Verfahren F r die Programmverifikation gilt Programmverifikation setzt die Existenz eines geeigneten Kalk ls zur Durchf hrung des Korrektheitsbeweises voraus z B Hoare oder Dijkstra sche Verifikationsregeln Die Methode macht bereits bei der Verifikation von Programmen praktischer Gr e einen so gro en Aufwand da das Beweisverfahren mechanisiert werden mu d h automatische Beweiser werden eingesetzt Automatische Beweiser sind selbst Programme betr chtlicher Gr e sie sind darum selbst i d R nicht verifiziert Es m ssen Programmiersprachen verwendet werden welche eine
47. Moduln bestehen aus Operationen und Daten e Operationen bestehen aus Anweisungen und Daten Die Composed Of Hierarchie wird meist durch einen Baum dargestellt wie bereits oben im einleitenden Beispiel zu sehen war Man spricht vom sogenannten Hierachie Diagramm oder vom Modulbaum Projektbaum 6 3 2 Use Hierarchie Eine andere Art von Hierarchie stellen die Use Hierarchien dar Hier sieht man wie die einzelnen Komponenten sich gegenseitig benutzen Beispiel Fahrer rer ZEN ec di Benzin Use Hierarchien sind n tig um die organisatorischen Strukturen in einem Software System identifizieren Sie zeigen deutlich wer der Chef ist und wer die Arbeit durchf hrt Sie zeigen insbesondere auf wo Schnittstellen zwischen den Designkomponenten ben tigt werden Um Use Hierarchien darzustellen gibt es im Design die folgenden M glichkeiten e Module benutzen andere Module Dies wird in sogenannten Moduldiagrammen visualisiert e Operationen benutzen andere Operationen und globale Daten Dies wird in sogenannten Operationsdiagrammen Structure Charts visualisiert Wie bereits im obigen Beispiel zu sehen m ssen Use Hierarchien nicht mehr baumartig strukturiert sein 6 11 6 4 Moduldiagramme Ein Moduldiagramm beschreibt die statische Aufrufstruktur Benutzt Beziehung der Module eines Programms Da Module selbst keine Komponenten darstellen die aufrufen sondern nur aus Operationen und Daten bestehen werden die Aufrufbezie
48. Nobody is perfect Weiterhin gilt Testen ist ein destruktiver Vorgang Denn Testen ist der Proze ein Programm auszuf hren mit der Absicht dabei Fehler zu finden Positive Arbeitsvoraussetzung ist die sichere Annahme von Fehlern falls nicht besteht nur geringe Motivation zur Arbeit Diese Voraussetzung gilt in aller Regel nicht f r den Autor weil er von seiner Arbeit berzeugt ist d h inbesondere Ein Autor ist ein schlechter Tester f r seine Programme 8 13 8 6 Programmverifikation Programmverifikation ist der streng formale Nachweis der Korrektheit eines Programms mit Hilfe eines Logikkalk ls Die Durchf hrung ist au erordentlich aufwendig und selbst bei kleinen Programmen praktisch nicht mit vern ftigem Aufwand durchf hrbar Beispiele f r solche Kalk le sind die von Hoare und Dijkstra definierten Verifikationsregeln 8 6 1 Methode der schw chsten Vorbedingung Dijkstra definiert die schw chste Vorbedingung weakest precondition Gilt vor Ausf hrung des Statements S die Bedingung wp S N so wird S terminieren und es wird danach N erf llt sein Will man beweisen da ein Programm st ck S den Zustand V in den Zustand N wandelt transformiert so ist zu zeigen dass V gt wp S N Die entsprechenden Regeln f r wp sind D1 wp S false false D2 WennV gt N dann wp S V gt wp S N D3 wp S Q amp wp S R wp S Q amp R D4 wp S Q wp S R wp S Q R Zur Verifikation
49. Plattenplatz min notwendiger Hintergrundspeicher notwendige Peripherie e Software BS Version und Schnittstellen z B SVID XPG 4 zus tzlich zu installierende SW z B Shared Libraries X11Rx Tcl Tk Datenbank server Hilfsprogramme z B Makroprozessor Texteditor Mail Window Manager Kommunikations Protokolle z B Novell IPX TCP IP SLIP 9 6 Installationsanweisung d h einmalige Arbeiten II Installation Guide Einrichtung von reservierten Speicherbereichen auf der Festplatte Einrichtung von Zugriffspfaden auf ausf hrbare Dateien e Zuteilung von Rechten auf Files Devices e Bereitstellung von vorausgesetzter Basis Software e Liste mit bekannten Fehlern Unvertr glichkeiten mit anderen Programmen e Deinstallation Betriebsanleitung d h regelm ige Arbeiten II Administrator Guide e Einrichtung L schung neuer Benutzer bereiche e Tuning Einstellungen e L schen von Arbeitsdateien Log Temp Files e regelm iges Backup e Fehlerbeseitigung troubleshooting Mittler zwischen User u Hotline e Update Service Benutzerhandbuch Nachschlagehandbuch II User Reference Manual e Einf hrung in das Werkzeug Philosophie Terminologie erstes Beispiel Funktionsweise von Online Help e Ausf hrliche Beschreibung aller Funktionen Langfassung typische Anwendungen viele Beispiele e Kurzbeschreibung der Funktionen mit Verweis zur jeweiligen Langfassung Trai
50. Prozesse die den Speicher benutzen m ssen diesen Modul importieren e Ein Datenfluss zwischen zwei Knoten wird zu einem Funktionsaufruf Diese Regeln hier erheben keinen Anspruch auf Vollst ndigkeit Beispielsweise ist das ganze Gebiet RT und DD hier au en vor gelassen Es sollte auch klar sein dass es immer irgendwelche Sonderf lle zu betrachten gibt die eine andere Behandlung erfordern W re dem nicht so dann k nnte man ja diese Transformationsregeln automatisieren und k nnte direkt aus dem Modell Code generieren Es gibt Werkzeuge die eine Unterst tzung anbieten nicht als Automatismus sondern als eine Art Assistent der dem Designer beim Aufbau seiner Systemstruktur hilft Viele Werkzeuge bieten zumindest eine Verkn pfung zwischen dem SA Modell und den MD Komponenten an Bei jeder MD Komponente Modul Operation Daten kann eine Zuordnung zu einem Element des SA Modells Prozess Speicher Diagramm Terminator erfolgen was bedeuten soll diese MD Komponente ist verantwortlich f r die Einhaltung der im Modell f r das betreffende Element festgelegten Anforderungen Damit k nnen Werkzeuge zumindest pr fen ob die MD Struktur das SA Modell vollst ndig umsetzt 6 25 6 7 6 Zusammenfassung Die Beachtung der allgemeinen Designkonzepte ist die Grundlage um die Designziele zu erreichen Dann werden automatisch Systeme erstellt die wartbar flexibel und anpassbar sind Die Komponenten eines solchen Systems sind in einem
51. abenstellung externe Spezifikation keine genaue interne Spezifikation ableitbar so ist auch Korrektheit im strengen Sinne nicht nachpr fbar Dann mu wenigstens die Erf llung der externen Spezifikation also des Pflichtenheftes verlangt werden Weitere Probleme e bereinstimmung zwischen externer und interner Spezifikation Interne Spezifikation ist statisch der Betrieb dynamisch Funktioniert es bei Belastung auch z B pl tzlich viele Daten Zusammenspiel mit dem Grundsystem z B BS mit 20 User Rechtzeitigkeit in der Proze datenverarbeitung e Funktionale Korrektheit ist nur f r g ltige Eingaben definiert Was passiert wenn Fehlbedienung Vgl Zuverl ssigkeit Robustheit 7 3 2 Adaptierbarkeit Ein Programm hei t adaptierbar an eine ver nderte Aufgabenstellung wenn es mit vergleichsweise geringem Aufwand so modifiziert werden kann da es die neue Aufgabenstellung erf llt Adaptierbarkeit ist von Portabilit t Anpa barkeit an neues Grundsystem zu unterscheiden G nstige Voraussetzungen f r die Adaptierbarkeit von Software sind modularer Aufbau der Software funktionale hierarchische Gliederung Damit wird gleichzeitig ein hohes Ma an Wiederverwendbarkeit erreicht Wiederverwendbare Softwarebausteine verf gen i a ber ein hohes Ma an Adaptierbarkeit insbesondere bei OOP durch Klassen und Vererbung Effizienzsteigernde Ma nahmen verringern i a den Spielraum welc
52. alten Moduls oder wenn man keine weiteren Untermoduln mehr findet bzw wenn die Moduln einfach genug sind um sie leicht zu verstehen Die physikalischen Merkmale die man hier zu Rate ziehen kann wurden bereits genannt kein Diagramm sollte gr er als eine DIN A4 Seite sein und kein Diagramm sollte mehr als 7 2 Elemente enthalten Die Faktorisierung sollte aber betrieben werden weil e das System danach leichter zu verstehen ist und e Ver nderungen im System einfacher durchzuf hren sind lokal begrenzt Herausfaktorisierte Moduln stellen h ufig allgemein verwendbare Funktionen dar die mehrfach in verschiedenen Systemteilen benutzt werden k nnen Damit wird also die Wartung von Duplikaten reduziert und es entstehen gute Kandidaten f r die Wiederverwendung in anderen Projekten 6 8 6 Fan In Fan Out eines Moduls Der Fan In eines Moduls ist die Anzahl der bergeordneten Moduln die es benutzen Fu In diesem Fall ist der Fan In des Moduls Sekret r 8 Im Design wird versucht den Fan In zu maximieren Ein hoher Fan In bedeutet n mlich dass es sich um einen h ufig verwendeten also wahrscheinlich auch allgemein verwendbaren Modul handelt 6 36 Der Fan Out eines Moduls ist die Anzahl der direkt von ihm aufgerufenen Moduln In diesem Fall ist der Fan Out des Moduls Boss 9 Im Design wird versucht den Fan Out eines Moduls zu minimieren Er sollte auf alle F lle auf 7 2 beschr nkt sein Ein hoher Fan Out bedeutet
53. altes System existiert auf welches eine Analyse abgest tzt werden kann Ebenso wenn das neu zu entwickelnde System sich bewu t nicht am alten orientieren soll 4 25 4 9 Zusammenfassung Das folgende Bild verdeutlicht nochmals alle Elemente der SA Kontext Diagramm DFD Datenflu Diagramm P Spec Proze Spezifikation gt Datenflu O Proze C Datenquelle senke Speicher OE Definition aller Datenfl sse und Data Dictionary DD Datenspeicher auch Teile davon 4 26 Zur Modellierung eines Systems in der Strukturierten Analyse stehen 3 Beschreibungsmittel zur Verf gung 1 Mehrstufige Datenflussdiagramme beschreiben das System in verschiedenen Abstraktionsstufen Es gibt dabei verschiedene Aspekte f r das Ende der Dekomposition die Gr e einer P Spec lt als eine DIN A4 Proze besitzt genau einen Eingang und einen Ausgang DFD besitzen definierte n 1 Beziehung bzgl Ein und Ausg ngen Wegen bersichtlichkeit und Verst ndlichkeit sollte dabei auch der Umfang eines Diagrammes und der Hierarchie beschr nkt werden max 5 2 Prozesse Diagramm und nicht mehr Ebenen Damit kann man bei ausgeglichenen B umen 33 27 bis 77 823 548 Prozesse darstellen Minispezifikationen beschreiben die Aufgaben der in den Datenflussdiagrammen eingesetzten Knoten Im Data Dictionary DD werden alle Datenfl sse und Datenspeicher definiert und abgelegt Damit wird ihre S
54. ang eines Zustandsdiagramms dienen Aktion wenn sie als Eingang einer Proze aktivierungstabelle dienen Die Verarbeitung von Kontrollfl ssen in Kontrollspezifikationen wird weiter unten im Detail beschrieben 5 1 3 Flu diagramme Daten und Kontrollfl sse Die hierarchische Struktur des Kontrollmodells entspricht dem bekannten Proze modell von SA Beide beginnen stets mit dem Kontext Diagramm Einige Elemente der Diagramme tauchen immer in beiden Diagrammarten gleich auf beispielsweise Prozesse und Speicher Daher bietet es sich an Daten und Kontrollfl sse in einem einzigen Diagramm zu zeichnen einem kombinierten DFD CFD Dieses bezeichnet man auch als Flu diagramm FD Es beinhaltet dann 5 3 e Prozesse f r DFD und CFD identisch e Datenspeicher f r DFD und CFD identisch e Datenfl sse geh ren zum DFD e Kontrollfl sse geh ren zum CFD e Kontrollspezifikationen oder Barren geh ren zum CFD Dies darf solange geschehen wie die bersicht nicht darunter leidet Als Entscheidungshilfe wann ein Datenfluss und wann ein Kontrollfluss vorliegt k nnen folgende berlegungen dienen e Primitive Kontrollfl sse Signale sind stets diskret e Datenfl sse k nnen stetig und diskret sein e Wird die Information verarbeitet so deutet das auf einen Datenfluss hin Wird die Information hingegen zur Steuerung verwendet so deutet das auf einen Kontrollfluss hin 5 2 Kontrollspezifikationen Die Kontrollfl sse
55. aren Aufbau ist Austauchbarkeit von Modulen gegeben Die Evaluation eines Entwurfs ist besonders wichtig weil Fehler innerhalb dieser Phase erst nach der Implementierung festgestellt werden n mlich zum Zeitpunkt der Integration Die G te eines Entwurfs zeigt sich manchmal sogar noch sp ter erst n mlich bei der Wartung oder wenn die Moduln wiederverwendet werden sollen 6 8 1 Entwurfsvalidierung Grunds tzlich mu daher eine berpr fung des Entwurfs erfolgen bez glich F Vollst ndigkeit Widerspruchsfreiheit Konsistenz Konkret hei t das da folgende Fragen gepr ft werden m ssen e Enth lt Hierarchiediagramm bzw Structure Chart alle Module Operationen welche zur L sung der Aufgabe ben tigt werden e Wurden alle im Hierarchiediagramm bzw den Structure Charts auftretende Module Operationen in einer Modulbeschreibung explizit definiert Spezifikation der Aufgabe Spezifikation der Schnittstelle e Existiert f r jede Operation mindestens eine Aufrufstelle in einer anderen Operation oder in sich selbst Rekursion e Werden die Schnittstellen im definierenden und angewandten Auftreten einer Operation konsistent verwendet gleiche Anzahl von Parametern gleiche Reihenfolge der Parameter gleicher Typ auch ob in out oder in out e Wurden nicht vermeidbare globale Daten hinreichend beschrieben und nur den Modulen bekannt gemacht welche sie verwenden 6 27 e Stehen alle ben tigten Bibliotheksfunktion
56. assung Kommunikations Einrichtungen Postleitung ISDN Funk Genehmigungen einholen auch Personalrat 4 Abnahmeprotokoll die Funktionen A B C werden zur Abnahme vorgef hrt Art u Umfang der Dokumentation erworbene Rechte Source Anz d Lizenzen Weitervertrieb Art Umfang der Haftung bei Fehlern i d R ausgeschlossen falls keine grob fahrl ssigen Fehler M glichkeit der Nachbesserung binnen Frist von Fall des Verzugs Konventionalstrafe DM Tag Ersatz Gerichtsstand 5 Zeitplan nur grob insbesondere kein detaillierter Netzplan mit Interna wann Projektbeginn evtl Definition von Meilensteinen z B bernahme von Stammdaten vom Kunden wann Berichte Teil Zahlungen Beginn Installation Probebetrieb Abnahmetermin Mitarbeiter Schulung Garantie Garantiedauer Hot Line 3 9 6 Wartungsmodalit ten evtl nur falls bereits Bestandteil des Vertrags sonst nur Offerte Update Service Kosten Kosten bei Anderungsw nschen Support des Produktes bis evtl besser nicht 7 R cktrittsrecht nach Unterzeichnung des Pflichtenhefts kostenfrei f r beide Partner bis sp testens danach jeweils nach zeitlicher Dauer am Gesamtprojekt Nicht Bestandteil des Pflichtenhefts sind e Netzplan mit Aktivit ten u Personal Resourcen Planung e Entwurf des Programm Systems mit Unterprogrammen Structure Charts o Firmeninterna
57. ation a Pflichtenheft ie Systemspezifikation u Lastenheft Implementierung _Wodurch womit Moduln Daten Testf lle f aa ben WIE SPeZINZIEID funktionsf higes SEE EN System nstallation N wie von Kunde gew nscht Betrieb und was ist noch falsch unsch n p Wartung was soll erweitert werden p unktions und Leistungs berpr fu Wenn man dieses Bild etwas anders zeichnet dann wird klar warum man oft auch vom Wasserfall Modell der Software Entwicklung spricht Jede der Phasen kann nochmals in je 3 Einzelschritte aufgeteilt werden e Planung verfeinert den Rahmenplan e Durchf hrung produziert alle Teilprodukte berpr fung sichert die Qualit t aller Teilprodukte 2 2 Treten innerhalb der Phasen Betrieb und Wartung ber die Zeit mehr und mehr nderungsw nsche der des Kunden auf so wird es in der Regel immer aufwendiger diese nachtr glichen zus tzlichen Leistungen in das bestehende Programmsystem zu implementieren Es gibt einen Punkt ab dem eine Neuentwicklung finanziell g nstiger ist wenn die beiden Fl chen im Diagramm gleich gro sind sie entsprechen gerade den Kosten Aufwand Produktlebensdauer Herstellung Wartung Zeit weniger f r Inst Abnahme u Wartung Tendenz jedoch steigend viele Mitarbeiter u Resourcen f r Realisierung Impl amp Test wenig Mitarbeiter f r konzeptionelle Phasen 2 1 Problemanalyse und spezifikation Diese Phase beste
58. begriff aus den anfangs der 70iger Jahre vorherrschenden Programmiersprachen Diese dienten vornehmlich zum Programmieren im Kleinen Basierend auf den Erkenntnissen von Parnas und der Entwicklung im Programmiersprachenbereich Modula Ada OOP war es notwendig den Begriff des Moduls zu erweitern Nicht mehr nur einzelne Funktionen stehen im Mittelpunkt sondern die Zusammenfassung von Funktionen und oder Daten zu gr eren Einheiten Man sprach vom Programmieren im Gro en und die daf r entwickelte Methode erhielt den Namen Modular Design MD Der Begriff des Moduls wurde dabei nun f r diese gr eren Einheiten verwendet Zentraler Gedanke ist dabei die Kapselung von Daten und Funktionen als Einheit und andererseits die Definition der Schnittstellen zwischen diesen Einheiten um so zu mehr Pr fbarkeit zwischen den Einheiten zu kommen ber eine Exportschnittstelle stellt ein Modul Ressourcen f r andere Moduln zur Verf gung Alle anderen Interna sind verborgen Zur Implementierung eines Moduls kann man andere Moduln benutzen die man in einer Importschnittstelle auflistet Damit hat man folgendes erreicht e Ein Modul ist ersetzbar durch einen Modul mit gleicher Exportschnittstelle e Die Korrektheit eines Moduls ist ohne Kenntnis seiner Verwendung nachweisbar in dem man die Realisierung gegen seine Export und Importschnittstelle pr ft e Der Modulentwickler hat die Kontrolle dar ber was von seinem Modul benutzt werden kan
59. bilit t Ein Benutzer soll ein System entsprechend seinem Kenntnisstand und seiner Ubung unterschiedlich benutzen k nnen Men Kommandosprache Tastenkombination Gedanken bertragung e Selbsterkl rungsf higkeit Die Dialogf hrung sollte dem Benutzer zu jedem 7 14 Zeitpunkt anzeigen in welchem Unterpunkt Men er sich gerade befindet oder in welchem Zustand sich das System gerade befindet wartet auf Eingabe bearbeitet noch den zur ckliegenden Auftrag liest File ein e Fehlertoleranz Dazu geh ren beispielsweise Falsche Eingaben sollten mit einer Erkl rung zur ckgewiesen werden Eingaben sollten r ckg ngig gemacht werden k nnen Warnungen vor Befehlen welche nicht r ckg ngig gemacht werden k nnen Aktive Aufforderung zu zyklischem Sichern Backup von Dokumenten Ein Zweig der Informatik welcher sich mit der optimalen Anpassung von Schnittstellen an die menschlichen Bed rfnisse besch ftigt ist die Hardware und Software Ergonomie Hardware Ergonomie besch ftigt sich mit der Anpassung der Arbeitsger te an die k rperlichen und psychologischen Eigenschaften des Standard Hackers e Bildschirmtechnik II MPR II Norm bzgl St rstrahlung e Tastaturtechnik II zweigeteilte Tastatur getrennter Ziffernblock e Zeigeger te f r Rechts u Linksh nder e Arbeitsumgebung DIN 66234 Teil 8 Bildschirmarbeitspl tze Tisch und Stuhlgestaltung f r erm dungsfreies Arbeiten Arbeitsh he Li
60. ch macht Dennoch werden Modelle aus den genannten Gr nden in der gesamten technischen Welt eingesetzt um die wesentlichen Eigenschaften von Systemen herauszustellen Sie werden gern benutzt weil sie schnell und kosteng nstig erstellt werden k nnen und weil sie leichter zu ndern sind als die Systeme selbst oder Prototypen Die wesentlichen Eigenschaften von Software Systemen sind die logischen Anforderungen Essenz Sie beschreiben die Eigenschaften die das System haben muss unabh ngig davon wie es sp ter implementiert wird Die Essenz eines Systems enth lt alle technologischen Anforderungen aber keine die zur Erreichung der Aufgabe des Systems nicht ben tigt werden Logische Systemmodelle enthalten genau diese Anforderungen H ufig ergeben sich Schwierigkeiten beim Verfassen und Verstehen dieser rein textuellen und schlecht strukturierten Analysedokumente Durch den systematischen Einsatz von Grafiken liefert das mit den Mitteln der Strukturierten Analyse angefertigte Systemmodell eine geeignete Grundlage um Probleme Handlungsalternativen und Entscheidungen zu diskutieren Structured Analysis SA geh rt zu den Basistechniken zur Analyse und Spezifikation im Gro en Sie erm glicht es die Gedanken bzgl eines zu entwickenden Systems m glichst allgemein zu sammeln e zu strukturieren und e schriftlich zu fixieren Die verwendete Sprache mu dazu sehr intuitiv d h e einfach zu verstehen e leicht zu erlernen un
61. cht mehr verf gbar dann riskiert man erhebliche Mehrkosten hat also eine falsche Projektkalkulation Auf jeden Fall mu zus tzliche Zeit f r Wiedereinarbeitung investiert werden 7 16 7 3 10 Effizienz und Leistung Effizienz ist die bestm gliche Ausnutzung aller Ressourcen zur Erf llung einer Aufgabe Bei der Softwareentwicklung bedeutet dies die bestm gliche Nutzung aller Betriebsmittel Die stets ben tigten wichtigsten Betriebsmittel sind e der ben tigte Hauptspeicher Speichereffizienz e und die ben tigte Rechenzeit Zeiteffizienz Die entsprechenden G tekriterien sind im Gegensatz zu den vorherigen zahlenm ig erfa bar und hei en Speicherverbrauch sowie Mittlere Asymptotische Rechenzeit Die Komplexit t eines Algorithmus wird durch dessen Speicherverbrauch sog Speicherkomplexit t und asymptotische Rechenzeit allg Komplexit t definiert Die f r die L sung eines Problems ben tigte Rechenzeit und der ben tigte Speicherplatz f r Programm und Daten h ngen ab von der Art Klasse des Problems des zur L sung verwendeten Verfahrens Algorithmus der Implementierung und vom verwendeten Grundsystem 7 17 Als Beispiel betrachten wir die folgenden beiden Algorithmen zur Berechnung der Potenz ak Gegeben a real k integer und k gt 0 Gesucht Potenz p a p real Ausgabe Algorithmus A Algorithmus B p 1 p 1 q a while k lt gt 0 while k lt gt 0 p p a
62. chteinfall Reflektionen auf dem Bildschirm optimale Arbeitsplatzausleuchtung 7 15 Software Ergonomie entwickelt Kriterien und Methoden zur Gestaltung interaktiver Programmsysteme welche den Bed rfnissen der Benutzer nach ausgeglichener Verteilung der e geistigen e k rperlichen und e sozialen Belastung weitgehend entgegenkommt 7 3 9 Wartbarkeit Die Forderung nach Wartbarkeit von Progammen ergibt sich aus der praktischen Erfahrung Programme sind fehlerhaft und m ssen ein oder mehrmals angepa t oder erweitert werden Fehlerbeseitigung und Programmver nderung sind wesentliche Komponenten im Lebenszyklus von Software 40 70 von Aufwand und Kosten Gro e und damit teuere Programme haben i d R eine l ngere Lebensdauer um rentabel zu sein und m ssen ggf mehrmals an sich ndernde e Grundsysteme e Benutzerschnittstellen e Kommunikationsschnittstellen oder e Benutzerw nsche angepa t werden Eine Neuentwicklung ist dabei wirtschaftlich noch nicht vertretbar Um Probleme mit dem Kunden zu vermeiden mu ein nderungswunsch i a auch dann durchgef hrt werden wenn das Produkt nur f r kurze Zeit eingesetzt oder eine bergangsl sung darstellen sollte Ein Programm ist gut wartbar wenn es modular aufgebaut und gut dokumentiert ist D h nicht dokumentierte Programme sind nicht wartbar Konsequenz von nicht wartbaren Programmen ist der Mitarbeiter unabk mmlich in einem anderen Projekt oder ni
63. d e unkompliziert bersichtlich und schnell in der Notation sein Dazu gibt es eine grafische Sprache mit wenigen Sprachelementen mit denen Datenflu diagramme Data Flow Diagram DFD gezeichnet werden sowie eine Notation f r Proze spezifikationen P Spec und f r Datenstrukturen Data Dictionary DD Datenflu diagramme lassen sich miteinander verkn pfen um die Systemhierarchie darzustellen 4 1 4 1 Beispiel eines Systemmodells In der Problem Analysephase soll e ein System als Teil eines Ganzen abgegrenzt und e die Beziehungen zum umgebenden System erfa t und analysiert werden Dies wird an dem folgenden Beispiel demonstriert Beispiel Weinhandlung Umgebung Lieferungen Kundenauftr ge Zahlungen Rechnungen Intern Lager Buchhaltung Bestellannahme Einkauf Aufgabe Automatisierung von Kundenverwaltung Lagerbestand Ein u Verkauf Eine genaue Analyse umfa t die Beschreibung der Schnittstellen nach au en den sogenannten Kontext Kundenauftrag Lieferung Pr Wein handlung Zahlung gt Rechnung ie Ware Reklamation Weiterhin muss gekl rt werden wohin Lieferungen gehen woher Reklamationen kommen etc Das sind die sogenannten Quellen und Senken eines Systems die Terminatoren Am Beispiel Ware ist dies zu sehen Es kommt Ware von einem Lieferanten Winzer etc Ware geht aber auch weg und zwar zu Kunden Im weiteren Verlauf ergeben sich etwa noch folgende Fragen
64. d beachtet wird 4 1 1 2 Organisation 4 1 1 2 1 Verantwortungen und Befugnisse Die Verantwortungen Befugnisse und die gegenseitigen Beziehungen aller Mitarbeiter die leitende ausf hrende und berwachende T tigkeiten aus ben welche die Qualit t beeinflussen m ssen festgelegt werden insbesondere f r jenes Personal welches die organisatorische Unabh ngigkeit und Befugnis besitzen mu um a Verh tungsma nahmen gegen m gliche Produktionsfehler zu veranlassen b alle Qualit tsprobleme bei Produkten festzustellen und aufzuzeichnen c Probleml sungen nach festgelegten Abl ufen zu veranlassen zu empfehlen oder vorzusehen d die Verwirklichung der Probleml sung zu verifizieren e die weitere Behandlung Auslieferung oder Montage fehlerhafter Produkte so lange zu berwachen bis die Fehler oder der unbefriedigende Zustand behoben sind 9 9 4 1 1 2 2 Mittel und Personal f r die Verifizierung Der Lieferant mu die Forderungen an die interne Verifizierung festlegen angemessene Mittel bereitstellen und ausgebildetes Personal f r die T tigkeit der Verifizierung bestellen T tigkeiten der Veifizierung m ssen Pr fung und laufende Verfolgung der Abl ufe und oder der Ergebnisse von Design Produktion Montage und Kundendienst einschlie en Design Reviews sowie System Verfahrens und oder Produktaudits m ssen von Personal ausgef hrt werden das unabh ngig von dem ist welches f r die Ausf hrung der Arbeit direkt
65. dargelegt werden welche der Einheiten Ressourcen durch andere Moduln benutzt werden k nnen Exportschnittstelle und welche Ressourcen anderer Moduln wie und warum benutzt werden Importschnittstelle Realisierungsbeschreibung Aus welchen Komponenten besteht berhaupt der Modul Die Aufgabenbeschreibung erfolgt in einer verbalen textuellen Form F r die Schnittstellenbeschreibung gibt es eine ganze Reihe formaler Ans tze die auch eine berpr fung auf konsistente Einhaltung erm glichen Sie sind allerdings nicht in allen Werkzeugen vorzufinden So ist etwa im Innovator eine Spezifikation der Schnittstellen von Moduln gar nicht vorgesehen Sie k nnen h chstens textuell zusammen mit der Aufgabenbeschreibung abgefa t werden wodurch eine berpr fung dieser Information nicht m glich ist Die Realisierungsbeschreibung stellt die Composed Of Hierarchie dar und wird in Form eines Baumes visualisiert Grundlage daf r ist eine Zuordnung von Operationen und Daten zu Moduln 6 4 5 Eigenschaften des Moduldiagramms Ein Moduldiagramm enth lt die statische Aufrufstruktur des Systems auf Modulebene Es enth lt keine Abbildung des tats chlichen dynamischen Programma blaufs Aufrufbeziehungen werden also dargestellt unabh ngig davon ob die Aufrufe in einer Alternative stehen die vielleicht dynamisch nie w hrend des Programmlaufs erreicht wird oder ob sie in einer Schleife stehen die w hrend des Programmlaufs 1000 und mehr Mal ausg
66. der Sicht der relevanten Daten 2 Entwurf einer logischen Sicht Aus dem physischen Istzustand wird durch Abstraktion der logische Istzustand ebenfalls in Form eines DFD abgeleitet Bestellung Packzettel Best Eintrag Order 0 Stamm Datei Buch haltung 3 Logische Spezifikation des neuen Systems Die geforderten Verbesserungen Umstellungen Erweiterungen werden im neuen System auf der logischen Ebene eingearbeitet Es entsteht das Sollkonzept in Form eines logischen abstrakten DFD 4 24 4 Bestimmung der physischen Eigenschaften Das System wird in automatisierbare und manuelle Bestandteile Aktionen Prozesse zerlegt Ergebnis physische s Sollkonzept e bzw DFD Frau M ller bleibt also am Telefon Alternativen Bestellungen nur noch per Fax und OCR SW maschinenlesbare Bestell Vordrucke Spracherkennung und Voicemail System D h auch hier k nnen mehrere Alternativen aufgezeigt werden 5 Kosten Nutzen Analyse Wirtschaftliche Kalkulation evtl mehrerer Alternativen 6 Auswahl Auch unter Ber cksichtigung von personellen infrastrukturellen arbeitsphysiologischen ergonomischen berlegungen 7 Dokumentation Alle Dokumente werden in der Strukturierten Sollspezifikation zusammengefa t Teil des Pflichtenhefts Auf Schritt 1 und 2 kann verzichtet werden wenn das logische Datenmodell direkt spezifiziert werden kann Dies ist z B der Fall wenn kein
67. die Schnittstellen zum System d h Welche Daten Materialfl sse treten auf Gep ck Reisepapiere Gep ckschein Kontrollabschnitte gekennzeichnetes Gep ck oder Gep ck Schein Welche Daten Material Quellen Senken sind vorhanden Schublade F rderband Hilfsmittel Substantive T Quelle Senke Daten Material Speicher und Verben TI T tigkeiten Prozesse fett bunt markieren Der gibt an der Gep ckannahme das Gep ck und seine Reisepapiere ab Der Schalterbeamte erkennt daraus den Zielort entnimmt einer Schublade einen Gep ckschein f r jedes Gep ckst ck und f llt die Scheine aus Er trennt die Scheine und heftet je einen Teil an das Gep ckst ck und legt es auf das F rderband Er gibt dem Kunden seine Reisepapiere incl der Kontrollabschnitte zur ck 4 10 Resultierendes Datenflu diagramm Schublade Gep ckschein Gep ck gekennzeichnetes Gep ck Gep ck annahme Reisepapiere Kontrollabschnitte F rderband 4 4 Hierarchien von Datenflu diagrammen Da alle nicht trivialen Systeme zu komplex sind um sie in einem DFD hinreichend genau darzustellen ist eine Einteilung in Abstraktionsebenen zwingend erforderlich Zur Beschreibung solcher Systeme werden hierarchische Modelle gebildet die auf den verschiedenen Abstraktionsebenen jeweils genauere Beschreibungen erlauben 4 4 1 Verfeinerung eines Modells Durch die iterative Top Down Vorg
68. die gestellt und beantwortet werden m ssen passiv Woraus besteht ein Kundenauftrag Welche Positionen enth lt eine Lieferliste Ware Welche Daten enth lt eine Rechnung aktiv Welche Aktionen sind mit Rechnungsstellung verkn pft Welche Aktionen m ssen ausgel st werden wenn Kundenauftrag kommt 4 2 Neben dem Kontext m ssen die internen Vorg nge Daten und Kontrollfl sse erfa t und dargestellt werden Weinhandlung Danach sind noch die folgenden Fragen offen passiv Welche Infos sendet die Warenannahme an die Buchhaltung Welche Infos sendet die Bestellannahme an das Lager u die Buchhaltung aktiv Wann soll das Lager den Einkauf triggern Welche Aktionen m ssen erfolgen wenn Ware geliefert wird Durch die Fragen und die Bilder wird das System nach au en abgegrenzt und e die Beziehungen innerhalb des Systems ermittelt Die Frage lautet berwiegend was passiert wird bef rdert ist zu speichern ist auszuliefern und nicht wie wird es realisiert Ben tigt werden Beschreibungsverfahren mit denen das System Weinhandlung mit seinen Informationsfl ssen und Datenstrukturen sowie den internen Abl ufen beschrieben werden kann Die Beschreibung soll unabh ngig von der sp teren Realisierung erfolgen und ist die Basis f r den anschlie enden Entwurf Die Grundlage des Beschreibungsverfahrens in der Strukturierten Analyse bilden die Datenflu diagramme die hier bereits in Ans tzen
69. e ber wie z B Start Steigflug Horizontalflug Sinkflug Landung e Das System geht in einen anderen Zustand ber wie z B Tresort r verschlossen entriegelt ge ffnet e Das System geht in einen anderen Betriebsmodus wie z B Testmodus Normalmodus Administratormodus Reagiert ein System immer gleich h ngt die Aktion die ausgef hrt wird also immer nur vom Ereignis ab dann spricht man von einem kombinatorischen Automaten dieser stellt einen Spezialfall des Sequentiellen Automaten dar er hat n mlich nur einen Zustand Kombinatorische Automaten k nnen mit Hilfe einer Entscheidungstabelle beschrieben werden Hier ist kein Ged chtnis vorhanden sondern wie schon erw hnt h ngt die Reaktion nicht von einem Zustand ab 5 4 1 Zustands bergangsdiagramme Ein n tzliches Hilfsmittel um Zustands nderungen zu beschreiben sind Zustands bergangsdiagramme Als Komponenten stehen dabei folgende Elemente zur Verf gung e Zust nde States Ein Zustand wird durch einen rechteckigen Rahmen dargestellt Im Innern des Rahmens steht der Name des Zustands Ein Zustand stellt eine Zeitspanne dar w hrend der das System ein bestimmtes Verhalten zeigt e berg nge Transitions 5 10 Ein bergang wird durch einen Pfeil zwischen zwei Zust nden dargestellt Der Pfeil beginnt bei dem Ausgangszustand des bergangs und zeigt auf den Folgezustand den das System nach dem bergang einnimmt e Ereignisse Aktionen Events Actions
70. e Aufrufkante tr gt keinen Namen ihr k nnen aber wie im Beispiel zu sehen die Parameter zugeordnet werden die beim Aufruf notwendig sind Parameter werden im n chsten Abschnitt detailliert erl utert Datenknoten k nnen nur am Endpunkt einer Kante liegen nicht am Anfang Eine Kante zu einem Datenknoten bedeutet dass die dadurch repr sentierten Daten durch die Operation benutzt werden sei es lesend oder schreibend 6 18 6 5 3 Aufrufschnittstellen Die Schnittstellen beim jeweiligen Aufruf k nnen m ssen mitangegeben werden Dabei werden sowohl die Namen der Parameter und deren Richtung festgelegt Parameter werden durch kleine Pfeile mit einem kleinen Kreis am Anfang dargestellt neben der Aufrufkante positioniert und mit dem Namen des Parameters beschriftet Der Pfeil repr sentiert immer einen aktuellen und nie einen formalen Parameter Zeigt der Pfeil zur aufgerufenen Operation handelt es sich um einen Eingabeparameter zeigt er zur aufrufenden Operation so handelt es sich um einen Ausgabeparameter Parameter die sowohl Eingabe als auch Ausgabeparameter sind haben zwei kleine Pfeile die in beide Richtungen zeigen Datenparameter beschreiben normale Daten die verarbeitet werden sollen Sie haben einen leeren Kreis am Kantenanfang Kontrollparameter beschreiben besondere Steuerelemente wie z B Schalterstellungen Signale Ausnahme und Fehlersituationen Flag EOF ALARM Sie werden durch einen ausgef llten Kreis
71. e Hardware an wo das modulare Vorgehen schon seit langem erfolgreich praktiziert wird Damit l t sich das Ziel des Entwurfs folgendermassen formulieren Ziel hierarchische Zerlegung des Problems in m glichst unabh ngig voneinander realisierbare Module welche aufeindander aufbauen in ihrer Komplexit t berschaubar sind sich gegenseitig nicht beeinflussen r ckwirkungsfrei klar definierte Schnittstellen besitzen 6 4 6 2 Der Modulbegriff Wie schon oben erw hnt wurde der Begriff Modul bewu t gew hlt um an die Eigenschaften von Moduln in der Hardware Entwicklung zu erinnern Dort stellen sie eine klar umgrenzte Aufgabe in einem Gesamtzusammenhang dar Es sind Bausteine mit einer gewissen Komplexit t deren Interna nicht weiter interessieren Wichtigstes Kennzeichen ist die Festlegung der Schnittstelle mit dem Ziel der Austauschbarkeit von Moduln mit gleicher Schnittstelle Die Korrektheit eines Moduls ist ohne Vorkenntnis seiner Verwendung in einem System nachweisbar in dem man die Realisierung gegen die Schnittstellenspezifikation pr ft In der geschichtlichen Entwicklung der Entwurfsmethoden wurde dieser Modulbegriff nun auf unterschiedliche Komponenten eines Software Systems bertragen was nat rlich auch damit zusammenh ngt dass man im Lauf dieser Zeit gelernt hat immer gr ere und komplexere Software Systeme zu entwickeln Im Folgenden soll dieser Zusammenhang dargestellt werden und der Modulbegr
72. e genau erf llt Um dies berpr fen zu k nnen ben tigt man eine exakte Formulierung der Aufgabe wie dies bei mathematischen oder logischen Problemen i a m glich ist Das was ein Programm tun soll wird in einer Spezifikation beschrieben Eine exakte Formulierung der Aufgabenstellung eines Programms und damit seine Spezifikation ist in der Praxis meist recht schwierig und deshalb nicht vorhanden Man unterscheidet e Externe Spezifikation Pflichtenheft gew hnlich informelle verbale Spezifikation in der Regel ein Katalog von Anforderungen an das Programm Eingaben des Benutzers und die Reaktion des Rechners darauf Ausnahmesituationen Zeit und Leistungsaussagen e Interne Spezifikation Lastenheft m glichst formale Beschreibung der Ein Ausgabebeziehungen in Form von pr dikatenlogischen Aussagen mathematischen Beziehungen abstrakten Datentypen Aus der externen Spezifikation versucht man die interne Spezifikation die eine formale Natur hat abzuleiten F r eine interne Spezifikation kann eine funktionale Korrektheit definiert werden Liegt eine formale Spezifikation vor so l t sich zumindest theoretisch und mit ziemlichem Aufwand ein Korrektheitsbeweis durchf hren Leider ist dies nur selten m glich Was ist die Spezifikation eines verteilten Systems Teilnehmersystem Was ist die Spezifikation eines Betriebssystems Wann sind sie korrekt 7 7 Ist aufgrund einer ungenauen Aufg
73. e oder im Rahmen eines anderen Projektes entwickelt wurde Vordefinierte Module brauchen daher nicht mehr ausf hrlich spezifiziert zu werden e Zwei Module A B werden durch eine gerichtete Kante Pfeil von A nach B verbunden falls eine Operation des Moduls A einen Aufruf einer Operation des Moduls B enth lt oder auf Daten die zum Modul B geh ren zugreift e Die Pfeile tragen keinen Namen Der Pfeil beginnt also stets beim aufrufenden Modul die Spitze zeigt auf den aufgerufenen Modul e Ein Pfeil von Modul A zu Modul B dr ckt damit aus dass Modul A zu seiner Realisierung Modul B ben tigt dass also Modul A von Modul B abh ngt 6 12 Zyklische Abh ngigkeiten also Modul A h ngt vom Modul B und umgekehrt k nnten theoretisch existieren die meisten Methoden leiten jedoch dazu an solche Abh ngigkeiten zu vermeiden Von zyklischen Abh ngigkeiten spricht man auch dann wenn die gegenseitige Abh ngigkeit zwischen zwei Modulen ber mehrere Stufen also ber mehrere Zwischenmoduln gegeben ist 6 4 2 Beispiel eines Moduldiagramms ToDo 6 13 6 4 3 Konnektoren Ein Konnektor dient als graphisches Hilfsmittel um die Fortsetzung einer Modulverbindung anzuzeigen Er erlaubt eine bessere optische Darstellung eines Diagramms und wird haupts chlich dann eingesetzt wenn sich mehrere Linien kreuzen Konnektoren werden durch einen Kreis dargestellt in dessen Inneren sich der Name des Konnektors befindet Man untersc
74. ef hl verletzt Man mu daher mit unrichtigen verzerrten Daten und Ausk nfte rechnen darf keine Unterst tzung erwarten und mu oft sogar Behinderungen in Kauf nehmen Die Einstellung ist auch erkl rbar da das Know How des Einzelnen bertragbar wird auf Maschinen neuronale Netze f r B rse Experten Systeme f r Kapitalanlage Steuer Medizin Recht 3 2 Sollkonzept Das Sollkonzept oder die Sollanalyse e ist die wichtigste Phase innerhalb der Problemanalyse e ist auch bei kleinen bersichtlichen Projekten unverzichtbar Die Erstellung des Sollkonzepts umfa t die Formulierung der Systemziele d h der wesentlichen Aufgaben des Systems Ziele k nnen vielf ltig sein Kostenverminderung auch Personaleinsparung Geschwindigkeitssteigerung Erh hung der Sicherheit Erh hung der Produktqualit t 3 2 berlegungen bei der Definition der Ziele 1 Benutzermodell Anforderungen an den k nftigen Benutzer des Systems Anwender Qualifikation Schulungen auch Rechnerkenntnisse 2 Basismaschine Minimalforderungen an die sp ter eingesetzte Rechenanlage Systemsoftware zus Betriebsmittel Plattenplatz Band Netzwerk zus Peripherie Farb Bildschirm Maus Tablett Barcode Verarbeitungsgeschwindigkeit Mips Transaktionen Ausfallsicherheit Notstrom 3 Benutzerschnittstelle Zugang eines Benutzers Identifikation Datenschutz Bedienung des Systems aufgeteilt
75. ef hrt wird Das Diagramm l t sich aus den Operationsdiagrammen herleiten jedoch erh lt man eine wirksame Konsistenzpr fung nur dann wenn man beide Diagramme getrennt entwickelt Gerade f r die einfachen Beispiele der Vorlesung sehen die Moduldiagramme einfach aus sie haben jedoch schon ihre Berechtigung und ihren Nutzen in der Programmentwicklung beispielsweise k nnen Includes und Externvereinbarungen f r den Code daraus abgeleitet werden In einem Moduldiagramm ist nicht die Schnittstelle der Aufrufe zu sehen Dies kann auch auf der Ebene gar nicht geschehen da ein Modul ja eine Zusammenfassung von mehreren Operationen darstellt und auch wenn sich viele Operationen aus zwei Moduln aufrufen dies nur mit einem Pfeil dargestellt wird Die Aufrufschnittstelle kann also nur auf der Basis von Operationen dargestellt werden dazu dienen die Operationsdiagramme 6 15 6 16 6 5 Operationsdiagramme Eine Darstellung mit detaillierterem Informationsgehalt bieten die Operationsdiagramme oder auch Structure Charts genannt Man unterscheidet die Art der Operationen und kann pr zise ihre Verkn pfungen d h ihre Schnittstelle beim Aufruf beschreiben 6 5 1 Elemente eines Operationsdiagramms Es gibt vier Arten von Knoten in einem Operationsdiagramm Datensatz i EA o ti Bibliotheks Ban Operation m Globale Daten Externe Daten Diese Knoten werden mit Pfeilen gerichtete Kanten verbunden die den Aufruf einer Operation b
76. ehensweise erh lt man eine Hierarchie von DFDs Die Ebenen sind die Abstraktionsebenen des Modells Die oberste Ebene Ebene 0 wird gebildet vom Kontextdiagramm es besteht nur e aus dem Superproze sowie e allen Verbindungen zu externen Quellen und Senken Terminatoren Externe Quellen und Senken bilden die Verbindung des Systems zur Au enwelt Sie bescheiben somit alle Ein und Ausgaben Quellen und Senken existieren nur auf der Ebene 0 Das obige DFD zur Gep ckannahme ist ein Beispiel f r ein Kontextdiagramm Das Diagramm der Ebene 1 enth lt eine Zerlegung des Systems in die Hauptkomponenten Es hei t deswegen auch Systemdiagramm oder bersichtsdiagramm Weitere Ebenen verfeinern bei Bedarf das Systemmodell Ein Diagram in dem ein Knoten verfeinert wird steht mit der Verfeinerung in einer Vater Sohn Beziehung Parent Child Der Knoten der verfeinert wird hei t Vaterknoten Das Sohn Diagramm erh lt den Namen des Vaterknotens 4 11 Jeder Knoten erh lt entsprechend seiner Position eine eindeutige per Punkt strukturierte Nummer und einen Namen e Alle ein bzw ausgehenden Datenfl sse eines Vaterknotens sind auch ein bzw ausgehende Datenfl sse des Sohn Diagramms balancing e Datenspeicher im Vater DFD werden stets auch im Sohn DFD eingetragen und dort mit mindestes einem der Knoten verbunden D h erfolgt vom Vaterknoten ein Zugriff auf einen Datenspeicher so ist dieser auch im Sohn Diagramm erkennbar D
77. eis lese Buch schreibe Buchzusammenfassung bestimme W rter pro Seite suche ISBN Nummer Kommunikative Koh sion ist akzeptabel da die Funktionen eines Moduls wegen ihrer Datenstruktur zusammengefa t sind Ein Modul mit kommunikativer Koh sion kann h ufig aufgeteilt werden in einzelne Moduln wodurch die Kopplung vereinfacht werden kann und der Zusammenhalt verbessert werden kann Ein Modul ist prozedural koh siv wenn die Elemente in einer bestimmten Reihenfolge ausgef hrt werden m ssen aber im Gegensatz zur sequentiellen Koh sion keine gemeinsamen Daten zu bearbeiten sind Man erh lt solche Moduln indem man das Ablaufdiagramm eines Problems zerschneidet Die folgenden Elemente des Moduls Bereite Weihnachtsessen vor sind prozedural koh siv K che aufr umen Truthahn bratfertig zubereiten Truthahn in den Backofen schieben Duschen gehen Gem se putzen Tisch decken Familie zu Tisch bitten Truthahn servieren Bei einer zeitlichen Koh sion m ssen die einzelnen Elemente nicht mehr in einer bestimmten Reihenfolge durchlaufen werden sondern sie m ssen nur noch zur gleichen Zeit also in einem zeitlichen Zusammenhang aber in beliebiger Reihenfolge ausgef hrt werden Die folgenden Elemente des Moduls Morgenzeremonie sind zeitlich koh siv ins Badezimmer gehen Kaffeemaschine anstellen Zeitung und Milch ins Haus holen Tisch decken Typische Beispiele in der Datenverarbeitung sind Initialisierungsmoduln Ein Modu
78. en e bei Aufrufen die Bedeutung der Parameter in out e bei Datendeklarationen Objektinstanziierung e bei Anweisungsbl cken oder mehreren Zeilen mit gemeinsamer Funktion Hinweise f r die Kommentierung e evtl verschiedene Ebenen von Kommentaren zur leichteren Selektion e eine Kommentierung von einzelnen Zeilen ist wenig sinnvoll e eine Regel der Art mind 50 Kommentar ist wenig sinnvoll weil bei 20 und mehr Kommentar keine bersicht und keine Aussagekraft zu viel Kommentar zerst rt die Programmstruktur gr ere Menge Kommentar wird bei Anderungen kaum aktuell gehalten F r die Dokumentation des Source Codes gilt allgemein Gute Programmierer zeichnen sich durch einfache und klare Programme aus nicht durch schwerverst ndliche Tricks und Kniffe Die Dokumentation des Quell Codes erfolgt gleichzeitig mit der Codierung und durch den Programmierer selbst d h nicht sp ter und auch nicht von anderen Projektmitgliedern 7 4 Programmierempfehlungen e Einschr nkung der verf gbaren Sprachelemente TI Portierbarkeit e keine Nutzung impliziter Definitionen z B integer initial stets 0 e Zwang zum expliziten Casting keine impliziten Typkonvertierungen Beschr nkung der Schachtelungstiefe von Bl cken Beschr nkung der Anzahl von Anweisungen Zeile Beschr nkung der Anzahl von Operatoren Ausdruck Weitere allgemeine Regelungen e Einrichtung zentraler Resource Files f r Texte der Benutzerf hru
79. en beschriebenen EBNF wird das folgenderma en formalisiert KFZKZ I BU 23 Not 1 BU 2 ee Zu ir Ein vollst ndiges DD setzt nat rlich voraus da alle in einer EBNF Definition neu verwendeten Namen ebenfalls im DD definiert werden In unserem Beispiel m te man also noch definieren was Buchstaben und was Ziffern sind BU a R CONOS zu Ir Z on q SISE on Jz Dadurch ist beispielsweise jetzt festgelegt da nur Gro buchstaben auftreten d rfen ber die M glichkeit Terminale an beliebiger Stelle einzuf hren um die Beschreibung abzubrechen hat man die M glichkeit das DD bersichtlich zu halten Am Anfang wird man relativ fr h Terminale einsetzen w hrend man mit dem Fortschritt der Analyse die Erkenntnisse ber einen Typ durch eine Verfeinerung in das DD mit aufnehmen kann Das obige Beispiel kann beispielsweise auch folgendermassen aussehen KFZKZ 1 BU 3 STRICH 1 BU 2 4 19 LEER 1 ZI 4 BU Grossbuchstaben ZI Ziffern LEER Leerzeichen STRICH Bindestrich Damit sollte klar sein es gibt viele M glichkeiten die Eintr ge im DD zu gestalten Man muss dabei allerdings bedenken dass immer dann wenn Terminal auftauchen ein Werkzeug nicht mehr weiter pr fen kann d h der Text zwischen den Apostrophen kann und wird nicht analysiert Die anderen Eintr ge k nnen jedoch auf Vollst ndigkeit und Konsistenz gepr ft werde
80. en der Implementierung zu realisierende Module sp ter gen gen sollen 6 1 1 Unterschied Analyse Design Bei der Analyse geht es darum zu verstehen was der Kunde will die logischen Anforderungen zu erfassen herauszufinden was die essentiellen Anforderungen sind das Aufgabengebiet zu verstehen kurz gesagt in der Welt der L sungen zu denken Beim Design hingegen gilt es zu verstehen wie dies realisiert werden kann also physikalische Realisierungsm glichkeiten zu suchen die Inkarnation der Anforderungen zu beschreiben Strukturen f r die Organisation zu suchen und zu finden kurz gesagt in der Welt der L sungen zu denken 6 1 2 Von der SA zur SD Die Elemente der SA Prozesse P Spec C Spec beschreiben lediglich den zeitinvarianten logischen Datenflu In der Designphase erfolgt der bergang zu sp ter im Rahmen der Implementierung konkret zu realisierenden funktionalen Einheiten P Spec C Spec der SA dienen als Vorgabe f r den Entwurf jedoch 1 Im DFD CFD existieren z B logisch mehrere Prozesse in denen jeweils Ausgaben Bildschirm oder Proze l O vorgenommen werden Sie k nnen evtl geschickt in einem einzigen Modul welcher alle Ein Ausgaben steuert zusammengefa t werden 6 2 2 In vielen Anwendungen m ssen z B Daten sortiert werden Es ist sicherlich nicht sinnvoll nur einen Proze zum Sortieren in einem DFD CFD zu haben Aber es sollte u U nur ein Modul existieren der die Sortier
81. en tats chlich auf Abruf bereit Wurden sie in fr heren Projekten korrekt implementiert Verursachen basieren sie auf speziellen Seiteneffekten Entwurfsvalidierung kann manuell oder in Grenzen auch maschinell bei vorhandenem CASE Tool erfolgen Merke Ein CASE Tool kann lediglich formale Aspekte der Spezifikation pr fen die Semantik bleibt inm verborgen 6 8 2 Bewertung eines Entwurfs Um die Komplexit t von Schnittstellen und die funktionale Vollst ndigkeit beurteilen zu k nnen gibt es zwei Kriterien die Kopplung Coupling und den Zusammenhalt Cohesion e Kopplung ist ein Ma f r die Unabh ngigkeit der Moduln und Operationen untereinander Der Grad der Unabh ngigkeit kann durch Untersuchen der Schnittstellen festgestellt werden Es ist ein Entwurfsziel Moduln zu erstellen die nur schwach gekoppelt sind loose coupling e Zusammenhalt ist ein Indikator f r die Komplexit t eines Moduls und damit f r die Verst ndlichkeit Zusammenhalt ist ein Ma f r die St rke des funktionalen Zusammenhangs der Elemente eines Moduls Es ist ein Entwurfsziel Moduln zu erstellen die einen hohen Zusammenhalt aufweisen high cohesion Diese beiden Kriterien werden nun im Folgenden vorgestellt Danach werden die Methoden skizziert die einem helfen diese Ziele zu erreichen Faktorisieren von Moduln berlegungen zum Fan In Fan Out eines Moduls und Begrenzung des Scope Of Effects 6 8 3 Kopplung von Modulen Kopplung
82. enten bestehen Ein einfacher Datenfluss wird durch eine durchgezogene Linie zwischen zwei Knoten dargestellt Bei einem Kontrollfluss der erst bei SA RT zum Tragen kommt ist es eine gestrichelte Linie Die Flussrichtung wird durch einen Pfeil an einem Ende der Linie symbolisiert Bidirektionale Fl sse die also sowohl eingehen als auch ausgehen haben an beiden Enden einen Pfeil Alle Datenfl sse m ssen benannt und im Data Dictionary DD eingetragen werden Jeder Datenfluss erh lt einen eindeutigen und sinnvollen Namen Der Name ist i A ein Substantiv Will man zus tzlich noch bestimmte Eigenschaften von ihnen beschreiben so wird das Substantiv durch ein Adjektiv erg nzt Die Linie zerf llt in zwei Teile ein Anfangs und ein Endsegment die durch einen kleinen Kreis Flussknoten voneinander getrennt sind Normale Datenfl ssen haben nur einen Namen der f r beide Segmente gilt Der Einfachheit halber wird dann der Flussknoten h ufig weggelassen Ein Fluss kann aber auch verfeinert oder aufgeteilt Split Fluss werden oder mehrere Fl sse k nnen zu einem zusammengef hrt Merge Fluss werden 4 6 e Bei der Verfeinerung eines Flusses erh lt jedes Segment einen eigenen Namen Verfeinerung bedeutet dass ein Segment ein Teil des anderen ist e Mit Split Fluss wird ein Fluss bezeichnet der nur ein Anfangssegment aber mehrere Endsegmente hat Dabei ist es unerheblich ob diese Endsegmente Verfeinerungen des Flusses sind oder
83. entiert werden entfallen weitgehend Unter der Impementierung wird die Realisierung des Entwurfs mit Hilfe einer Programmiersprache verstanden Im allgemeinen ist der Programmierer frei in der Wahl einer Programmiersprache sofern der Anwender nur am ausf hrbaren Programm interessiert ist und keine Rechte am Quellcode f r sich beansprucht Wenn der Anwender eine spezielle Implementierungssprache ein Betriebssystem oder eine Zielhardware festlegt so ist dies stets Bestandteil des Pflichtenhefts Ab dieser Phase kann sich der Einflu einer gew hlten oder vorgeschriebenen Zielhardware bzw Quellsprache auf die Qualit t des Programms auswirken Beispielsweise gibt es nicht f r alle Rechner bersetzer f r jede Sprache Treten Effizienzkriterien hinzu so scheiden u U weitere Sprachen aus Gibt es diesbez glich keine Einschr nkungen so sollte eine m glichst problemnahe Sprache verwendet werden welche eine effiziente Implementierung sicher stellt 2 5 2 4 berpr fung und Test Beim Testen wird ein Unter Programm mit Testdaten gef ttert Stimuli und seine Ausgaben werden mit den erwarteten Ausgabedaten Response verglichen Tritt eine Abweichung ein so liegt ein Fehler vor Das Grundtheorem des Testens von Dijkstra lautet jedoch Program testing can be used to show the presence of bugs but never their absence Darum stellt das Testen nur einen schw cheren Ersatz f r einen formalen Korrektheitsbeweis Verifikation
84. erden Es sind jedoch Verfeinerungen auf der dem Speicher abgewandten Seite eines Flusses zul ssig die dann auch benannt werden k nnen Hiermit ist es m glich auszudr cken dass nicht der gesamte Speicher gelesen geschrieben wird sondern nur Teile davon Da Speicher Teil des Systems sind k nnen sie auf der Kontextebene siehe unten nicht erscheinen Wenn sie nicht Teil des Systems sind dann sind sie nicht als Speicher sondern als Terminator zu modellieren 4 2 4 Terminatoren Ein Terminator dient als Schnittstelle zur Umgebung des Systems Er kann Ausgangs Quelle oder Endpunkt Senke sowohl von Daten als auch von Kontrollfl ssen sein Es kann sich um externe Systeme um technische Prozesse 4 7 um handelnde Personen etc handeln die eben nicht Bestandteil des zu modellierenden Systems sind In diesem Sinne kann es sich auch um eine benachbarte Teilkomponente handeln wenn gerade nicht das ganze System sondern nur eine Teilkomponente modelliert wird Es gelten folgende Regeln e Terminatoren werden mit einem Substantiv benannt e Terminatoren d rfen nur auf der Kontextebene vorkommen siehe unten Zwischen Terminatoren direkt d rfen keine Datenfl sse gezeichnet werden Das w rde ja bedeuten dass ein solcher Datenfluss am System vorbeiflie t also auch mit dem System nichts zu tun hat Wenn das aber so ist dann geh rt der Flu nicht in das Diagramm mit dem wir ja das System modellieren wollen 4 2 5 Konsistenzbed
85. eren kann Damit soll ausgedr ckt werden dass der Automat bei der R ckgabe der Karte an den Kunden nicht unterbrochen werden darf Karte_ Vorgang_ Pr fen W hlen Pr fen Bearbeiten Auswerfen In diesem Beispiel sind nur die ersten beiden Spaltengruppen in der PAT vorhanden da keine Ausgangssignale beeinflu t werden m ssen sondern nur Prozesse gesteuert werden 5 16 5 6 Beispiel Wir betrachten nun im Folgenden ein komplettes Beispiel das das Zusammenspiel von SA und RT Komponenten demonstriert aber auch im RT Teil das Zusammenwirken der unterschiedlichen Darstellungen aufzeigt Dem Beispiel Warenautomat liegt folgende Beschreibung zugrunde Der Kunde gibt zun chst seinen Warenwunsch an Daraufhin wird ihm der Warenpreis angezeigt Nachdem der Kunde den Betrag bezahlt hat wird die Ware ausgegeben Der Automat soll M nzen und Geldscheine in der Landesw hrung annehmen Zuviel gezahltes Geld gibt der Automat als M nzen zur ck Au erdem soll der Automat Falschgeld erkennen W nscht der Kunde sein bisher eingeworfenes Geld zur ck so soll der Automat dies nach Dr cken der R ckgabetaste ausgeben ToDo 5 7 Zusammenfassung Oftmals zeichnet man Daten und Kontrollfl sse in ein einziges Diagramm ein kombiniertes DFD CFD Dieses bezeichnet man auch als Flu diagramm Es beinhaltet dann e Prozesse f r DFD und CFD identisch e Datenspeicher f r DFD und CFD identisch e Datenfl sse geh ren zu
86. ersonen personelle Organisation des Projekts im Organigramm Zuordnung Aktivit ten zu Personen im Projekt Netzplan e Grundlage k nftiger Projektplanung durch Einf hrung eines allgemeinen generischen Projekthandbuchs Installation Fkt u Leistungs pr fung Implementierung Richtlinien Netzplan u Personalplanung Pflichtenheft Analyse Spezif Ma nahmen zur QS Proj Handbuch 9 2 Bei neuem Projekt jeweils 1 Kopie des generischen Projekthandbuchs 2 fortschreitende Version des PH f r akt Projekt verwalten 3 evtl Verbesserungen im genenerischen PH vornehmen feed back 4 Projekt Nachkalkulation zur Korrektur der Ma zahlen f r die Kalkulation tats chlicher Aufwand k nftige Teminplanung tats chliche Kosten k nftige Kostenabsch tzung Gute Dokumentation kostet Zeit Geld wer nicht schlecht dokumentiert ist schneller fertig Die Vorteile sieht nur selten die Person die sie m hevoll und gewissenhaft erstellt hat psychologisches Problem Wer sich der gewissenhaften Dokumentation entzieht m chte gerne weiterhin im DUNKELN d h un berpr f und bewertbar vor sich hin WURSTELN Man unterscheidet Projektdokumentation SW Hersteller Programmdokumentation SW Hersteller u o Kunde Benutzerdokumentation Kunde 9 3 9 1 1 Projektdokumentation Die Summe aller innerhalb eines Projekts angefertigten Dokumente werden im Projekthandbuch zusa
87. es Gesamtsystems Es gibt Schnittstellen zwischen vorausgehenden und folgenden Produkten T tigkeitsgruppen und ihre Produkte werden als Phasen zusammengefa t In der Praxis existiert eine Vielzahl von Phasenkonzepten welche sich durch die Phasenbezeichnungen die enthaltenen T tigkeiten und den Detaillierungsgrad unterscheiden Wir gehen von nachfolgender Phaseneinteilung aus 1 Problemanalyse und spezifikation Vor der eigentlichen Entwicklungsphase des SW Produkts wird das Produkt grob vorgeplant und kalkuliert Ergebnis kann sein berhaupt nicht machen besser einkaufen Danach werden die genauen Anforderungen an das Produkt spezifiziert zusammen mit Anwender 3 Entwurf Hier wird eine softwaretechnische L sung im Sinne einer Systemarchitektur entwickelt 4 Implementierung Die einzelnen Teile werden in einer oder verschiedenen zweckm igen Programmiersprache n geschrieben 5 Funktions und Leistungs berpr fung Nach der Integration aller Komponenten erfolgt der Gesamttest evtl Tuning Redesign 6 Installation und Abnahme Das Produkt wird beim Anwender installiert und nach einer Einf hrungsphase erfolgt die Abnahme 7 Betrieb und Wartung W hrend des Betriebs auftretende Fehler werden beseitigt Pflege m glicherweise muss das Produkt aber auch angepa t und ge ndert werden Wartung 2 1 Die einzelnen Phasen bauen wie folgt aufeinander auf roblemanalyse Was warum p Sollspezifik
88. f a b lt c I a c lt b I b c lt a then write kein Dreieck C3 if Ca b I a c b c C4 S3 then if a b amp b c then write gleichseitig S4 else write gleichschenklig S5 else write ungleichseitig end Programmflu graph m gliche Pfade sind S1 S6 S2 S6 S7 S5 S6 S7 S8 S3 S6 S7 S8 S4 9 A S1 8 11 In der folgenden Tabelle sind Testf lle mit je einem Testdatensatz aus einer Klasse zu finden dabei gilt ci j entspricht Teilbedingung j von Bedingung ci und innerhalb von Teilbedingungen entspricht O false 1 true C1 1 C1 2 C1 3 C2 1 ooo oo o o 00 4 0 0 0 C2 2 0 4 0 0 8 4 5 Zusammenfassung 02 3 0 0 4 0 03 1 Testf ooo 03 2 all ist i 0 4 0 0 03 3 Testfall ist in sp teren Testdaten ent 04 1 n sp teren o 00 O e Testen ist aufwendig und keinesfalls trivial e Testdaten werden nicht weggeworfen da sie nach Programm nderungen erweiterungen erneut ben tigt werden e Oftmals werden gerade bei der Fehlerbeseitigung neue Fehler gemacht e Stets Testen und Fehlerbeseitigung trennen falls nicht unvermeidlich e Testausgaben stets durch bedingte bersetzung einf gen und im Quelltext belassen evtl versch Testlevel Compiler Schalter definieren e Debug Unterst tzung ist unverzichtbar Tests nicht erst beginnen wenn alle Module fe
89. gal ob Netzwerk oder Hierarchie auf einer h heren Abstraktionsebene zu diskutieren e Sichtbarkeit Scoping um Seiteneffekte bei einer nderung zu reduzieren und um die Anzahl der erreichbaren Objekte zu begrenzen Durch Abstraktion wird es m glich einen Systembereich als geschlossene Einheit zu betrachten anstatt vieler einzelner Komponenten beispielsweise ein Betriebssystem statt der einzelnen Betriebssystemfunktionen Abstraktion ist Vereinfachung der komplexen Realit t durch Reduzierung auf das Wesentliche Grobe Verallgemeinerung statt Blick auf das Besondere und Einzelne stehen im Vordergrund Abstrahiert werden k nnen Aktionen Funktionale Abstraktion und Daten Datenabstraktion Funktionale Abstraktion bedeutet dass eine Funktion genutzt werden kann unter Angabe ihres Namens und Beachtung ihrer Schnittstelle Ein und Ausgabeparameter aber ohne Kenntnis ihrer Implementierung Zur funktionalen Abstraktion dienen im Entwurf die Operationen Funktionale Abstraktion bedeutet eine Lokalit t der Kontrolle ber Aktionen Datenabstraktion f hrt zu einer Lokalit t der Daten und der mit ihnen verbundenen Operationen Bei Datenabstraktion ist der Zugriff auf Daten nur ber die definierten Zugriffsoperationen m glich Man spricht in dem Zusammenhang auch von abstrakten Datentypen Ein abstrakter Datentyp ist ausschlie lich ber die auf ihn m glichen Operationen definiert Er besitzt somit die alleinige Kontrolle ber die Datenkons
90. gen so ist die Verf gbarkeit gering F llt ein Rechner nur selten aus doch m ssen die Ersatzteile aus bersee eingeflogen werden so ist die Verf gbarkeit gering Mu man bei einem PC hin und wieder mal den RESET Knopf bem hen das System ist dann aber sofort wieder einsatzbereit so ist die Verf gbarkeit doch relativ gro 7 3 8 Benutzerfreundlichkeit Benutzerfreundlichkeit ist weniger eine Forderung an die Software allgemein als an die Sollanalyse und die damit verbundene Gestaltung der Schnittstelle Benutzer gt Programm Dazu geh rt nicht nur die Definition von Kommandos Men s sondern auch der Fehlermeldungen und fr hzeitigen Warnungen Arbeiten mit einem System unterschiedlich qualifizierte Benutzer dann sollten eventuell verschiedene Ebenen der Benutzerf hrung Hilfe Funktion vorgesehen werden Denn Weitschweifige elementare Fehlermeldungen sind f r Profis langweilig und st rend Zu komplizierte Fehlermeldungen sind f r Nicht Profis wertlos und frustrierend Die Stufen sollten aufeinander aufbauen d h e Begriffe konsistent in allen Ebenen verwenden e Jede Ebene ist vollst ndig jedoch unterschiedlich ersch pfend e Die Ebenen sind konsistent oben Gesagtes ist unten noch g ltig Weitere Kriterien bei der Benutzerfreundlichkeit sind e Problemangemessenheit System soll vom Benutzer nur die Kenntnisse verlangen die er zur Durchf hrung der Teilaufgabe ben tigt e Dialogflexi
91. heidet Start und Zielkonnektor je nach dem wohin der Pfeil zeigt Startkonnektoren zeigen den Beginn einer Aufrufstruktur an der Pfeil geht vom Konnektor auf genau einen aufgerufenen Modul Zielkonnektoren zeigen eine Unterbrechung einer Aufrufstruktur an die Fortsetzung stellt der Startkonnektor mit dem gleichen Namen dar Ein Zielkonnektor h ngt an genau einem Modul d h ein Pfeil zeigt von einem Modul auf einen Zielkonnektor Zu einem Startkonnektor kann es mehrere Zielkonnektoren geben die alle den gleichen Namen tragen Mit anderen Worten an verschiedenen Stellen des Moduldiagramms kann auf die gleiche Fortsetzung verwiesen werden Jeder Startkonnektor ist dagegen eindeutig Es kann nur eine Stelle geben an der dieser Konnektor als Ausgangspunkt einer Aufrufstruktur verwendet wird Das folgende Beispiel zeigt die Verwendung von Konnektoren in einem Moduldiagramm Normaler Modul 1 Normaler Modul 2 Modul Konnektoren k nnen auf die gleiche Art und Weise in Operationsdiagrammen verwendet werden um diese optisch zu verbessern 6 4 4 Beschreibung von Moduln Jeder in einem Moduldiagramm verwendete Modul mu auch beschrieben werden Man unterscheidet drei Teile in einer solchen Beschreibung Aufgabenbeschreibung 6 14 Welche Funktion erf llen die in dem Modul zusammengefa ten Operationen und Daten Warum wurden Sie zusammengefa t Schnittstellenbeschreibung In der Schnittstellenbeschreibung sollte
92. her f r eine leichte Anpassung an ver nderte Aufgabenstellung notwendig ist 7 8 7 3 3 Portabilit t Programme bauen im Allgemeinen auf einem vorhandenen Grundsystem auf z B Betriebssystem Runtime System BIOS Ein Programm hei t portabel wenn es im Verh ltnis zu den Herstellungskosten mit geringem Aufwand auf andere Grundsysteme verpflanzt werden kann Adaptierbare Software ist in aller Regel auch portabel aber die zwei Eigenschaften sind auseinander zu halten Der Wert der Portabilit t wird unterschiedlich eingesch tzt e Rechnerhersteller haben nach au en kaum Interesse an portabler Software um Kunden an sich zu binden e Softwareh user und die Hersteller intern halten sie besonders wichtig um Produkte auf vielen Plattformen anbieten zu k nnen e Anwender haben gro es Interesse um Entscheidungen bez glich der Plattform m glichst freitreffen zu k nnen Unter dem Druck der Anwender geht daher der Trend in Richtung offener Systeme und allgemeiner Standards Beispiele Betriebssysteme Unix grafische Oberfl chen X Window OSF Motif Programmierung X Open Portability Guide XPG System V Interface Definition SVID Netzwerke und Protokolle OSI praktisch TCP IP Text und Grafikformate Postscript Fa Adobe Display Postscript TeX Entscheidend dabei ist da die Schnittstellen offen gelegt werden 7 9 7 3 4 Kompatibilit t Kompatibilit t ist die Vertr glichkeit zwischen ve
93. hrer Realisierungsbeschreibung mit einem Struktogramm in bersichtlicher Weise dargestellt werden kann Das Diagramm l t sich leicht automatisch aus dem Quelltext herleiten jedoch sollte es selbstverst ndlich vor der Implementierung der Module erstellt werden Der wichtigste Nutzen f r die Implementierung besteht darin dass aus der Schnittstellendefinition der Operation der Prototyp der Funktion abgeleitet werden kann 6 21 6 6 Gr eres Beispiel ToDo 6 22 6 7 Entwurfsprinzipien Die Prinzipien nach denen geeignete Module gefunden werden k nnen bzw die beim Erstellen der Hierarchien beachtet werden sollten sind im wesentlichen das Black Box Prinzip das Lokalit tsprinzip das Geheimnisprinzip das Kapselungsprinzip Diese sind eigentlich unabh ngig von einer konkreten Methode und stellen grundlegende Designprinzipien dar 6 7 1 Das Black Box Prinzip Beim Betrachten einer Black Box findet man da die Eingaben und die Ausgaben bekannt sind sowie die Funktionalit t das was getan wird Man findet aber nicht eine Beschreibung wie die Funktionalit t realisiert ist Das Black Box Prinzip in der Software Entwicklung bedeutet e Es sollen Module Operationen geschaffen werden die jeweils eine wohldefinierte Funktion erf llen e Die ausgef hrte Funktion soll leicht verst ndlich sein e Die Black Boxes d rfen keine Annahmen ber die Implementierung anderer Black Boxes machen e Die Anzahl der Schnitt
94. ht aus den Teilen Istanalyse Sollkonzept Durchf hrbarkeitsstudie und Planung Istanalyse e Erfassung des momentanen Zustands Abgrenzung des betrachteten Problems vom Rest e Definition der Umgebung soweit erforderlich Schnittstellen Randbedingungen Sollkonzept e wichtigste Teilphase die Spezifikation des Problems bzw der Aufgabe e basierend auf dem momentanen Zustand mu der k nftig gew nschte Zustand zusammen mit dem Anwender besprochen und festgelegt werden e ggf mehrere Alternativen entwickeln 2 3 Durchf hrbarkeitsstudie e L sungsans tze m ssen ausgearbeitet und auf ihre Durchf hrbarkeit hin untersucht werden entsprechende Umgebung Ausstattung vorhanden notwendiger Aufwand Kosten e Entscheidung ob das Projekt gestartet wird oder nicht Projektplanung e Es werden alle Phasen des weiteren Projekts in ihrem zeitlichen Ablauf detailliert geplant e Der Bedarf an Betriebsmittel Personal Ger te f r die folgenden Phasen wird berechnet 2 2 Entwurf In der Analysephase werden die Anforderungen so beschrieben da sie bewu t keine Hinweise auf eine konkrete Realisierung enthalten Dies beg nstigt die bertragbarkeit der L sung auf beliebige Rechnersysteme Innerhalb der Entwurfsphase entwickelt man ein Modell des gesamten Software Systems welches umgesetzt in ein Programm die gestellten Anforderungen im Pflichtenheft erf llt Hierbei wird das komplexe Gesamtsystem in e u
95. hungen ihrer Operationen bzw die Benutztbeziehung ihrer Daten dargestellt Die Operationen und Daten sind allerdings in diesem Diagramm nicht vertreten sondern wie der Name sagt handelt es sich um ein Diagramm in dem Module die Hauptrolle spielen In einem Moduldiagramm wird die Abh ngigkeit der Module untereinander dargestellt Die Beziehung zwischen Operationen und Daten werden in einem sogenannten Operationsdiagramm spezifiziert das weiter unten erl utert wird 6 4 1 Aufbau eines Moduldiagramms Als Elemente eines Moduldiagramms stehen folgende Symbole zur Verf gung Normaler Vordefin Modul Modul b Konnektor Aufrufkante Module sind die Knoten des Diagramms Sie werden als Rechtecke dargestellt Es sind normale und vordefinierte Module zu unterscheiden Ein Modul wird als normaler Modul dargestellt wenn er in Rahmen des Projektes zu erstellen ist und nicht schon existiert Normale Module bestehen aus normalen Operationen und oder normalen Daten siehe unten Ein normaler Modul wird als Rechteck dargestellt in dessen Inneren der Name des Moduls steht Vordefinierte Module Bibliotneksmodule bestehen aus vordefinierten Operationen und oder vordefinierten Daten Vordefinierte Module werden durch ein Rechteck mit zwei zus tzlichen senkrechten Linien dargestellt gerahmtes Rechteck in dessen Inneren der Name des Moduls steht Dieses Symbol wird verwendet wenn ein Modul bereits fertig existiert sei es dass er eingekauft wurd
96. iche Sprache lediglich Kommentar 2 strukturierte Sprache Pseudo Code Eine Proze spezifikation kann aber auch formal abgefa t sein dann hat sie die Form einer 3 Entscheidungstabelle Diese M glichkeiten werden im folgenden aufgezeigt 4 5 1 Textuelle Proze spezifikationen ToDo Form E A im Text referieren Zu 1 Kommentar 3 4 2 Beton mischen Zement Sand Wasser Beton Fertig Hier steht unser Herr M ller und mischt zuerst den Sand mit dem Zement gut durch Dann mischt er unter Zugabe von Wasser nochmals bis ein dicker Brei entstanden ist Wenn der Beton fertig ist gibt er das Signal Fertig aus 4 15 Zu 2 Pseudo Code 3 4 2 Beton mischen Zement Sand Wasser Beton Fertig repeat Zement und Sand mischen until gut gemischt repeat Wasser zugeben und mischen until dicker Brei entstanden Beton dicker Brei Fertig true 4 5 2 Formale Proze spezifikationen Zu 3 Entscheidungstabelle Bedingung Kunde hat Fahrkarten Kunde hat Gep ck Gep ck schwerer als 50 Kg Kunde zu Fahrkartenausgabe schicken Abfertigen Gep ck aufgeben Nachfragen Wo ist Gep ck Hier nur bin re Eing nge d h J N ToDo 4 16 4 6 Das Datenlexikon F r alle im Verlauf der Analyse Sollspezifikation vergebenen Bezeichner ist ein definierender Eintrag in einem Katalog vorzunehmen dem sogenannten Datenlexikon f r Data Dictionary abgek rzt DD Dies e legt die Ver
97. ie Verfeinerung erfolgt solange bis eine Stufe erreicht ist in der die Prozesse bersichtlich sind und durch eine Proze spezifikation beschrieben werden k nnen Diese Prozesse hei en elementare Prozesse Das sind also solche Prozesse die nicht weiter verfeinert werden Das Nummerierungsschema f r die Prozesse lautet folgenderma en e Der Prozess im Kontextdiagramm System oder Superprozess erh lt die Nummer 0 e Die Prozesse im bersichtsdiagramm werden durchnummeriert beginnend mit der Nummer 1 e Die Nummern aller anderen Knoten setzen sich zusammen aus der Nummer des Vaterknotens einem Punkt und einer diagramm lokalen Nummerierung e Bei der diagramm lokalen Nummerierung werden die Knoten des Diagramms durchnummeriert beginnend mit der Nummer 1 Die Top Down Vorgehensweise ist nicht zwingend Bei gr eren Projekten wird h ufig mit einer tieferen Ebene begonnen Zu einem sp teren Zeitpunkt werden dann die dar berliegenden Abstraktionsebenen erg nzt 4 4 2 Beispiel Systemdiagramm der Gep ckannahme ToDo 4 4 3 Balancing zwischen den Diagrammen ToDo Horizontales Balancing Vertikales Balancing Alle ein bzw ausgehende Datenfl sse des Vaterknotens sind auch ein bzw ausgehende Datenfl sse des Sohndiagramms Erfolgt vom Vaterknoten ein Zugriff auf einen Datenspeicher so muss dieser Zugriff auch im Sohn Diagramm erkennbar sein Beispiel auf irgendeiner Ebene das erste mal ein Speicher DFD x 1
98. ielt behandelt werden Ausl sung eines Signals Aufruf einer vom Anwender definierten Funktion Error Handler Logische Fehler k nnen im allgemeinen nicht von einem bersetzer erkannt werden Ausnahmen sind z B nicht erreichbarer Code deklarierte und nicht verwendete Variablen Funktionen konstante Bedingungen in Schleifen Sie werden i a als Warnungen an den Benutzer ausgegeben 8 3 Andere typische logische Fehler wie nicht terminierende Schleifen bzw allgemein ungewollter d h falscher Programmablauf k nnen prinzipiell nicht im bersetzer entdeckt werden da sie stets auch in der Absicht des Programmierers liegen k nnen Logische Fehler werden im allgemeinen erst durch ihr Symptom erkannt n mlich durch die Nichteinhaltung der Spezifikation Logische und funktionale Fehler treten h ufig in Kombination auf wobei erst eine Analyse die tats chliche Ursache zeigen kann Es gibt mehrere Test und berpr fungsmethoden um logische und funktionale Fehler zu entdecken 8 3 Programmvalidierung Validierung hei t Die Korrektheit des Programms Moduls plausibel bzw einsichtig machen Dazu gibt es diverse manuelle und automatische Methoden die im folgenden vorgestellt werden 8 3 1 Schreibtischtest Eine Testperson berpr ft am Schreibtisch ein Programm am Shreibtisch bedeutet ohne Rechner d h die berpr fung erfolgt an Hand des Listings mit Papier und Bleistift Der Ablauf ist folge
99. if k mod 2 1 then p p q q q q k k 1 k k div 2 Der Algorithmus B ist offensichtlich gr er als A und ben tigt darum auch mehr Programmspeicher im Rechner Beide Algorithmen kommen mit einer unterschiedlichen Menge an Datenspeicher aus Datenspeicher A B real Zahlen a p a p q integer Zahlen k k Summe 2 real 1 int 3 real 1 int Die Anzahl der Rechenschritte Laufzeit zur Berechnung der L sung unterscheidet sich ganz erheblich bei beiden Versionen und ist jeweils eine Funktion der Eingabegr e k Algorithmus A ist klar daher sei nochmals kurz die L sungsidee von Algorithmus B skizziert k Ikn k1 ko z B 1021 11 1111 1101 ak knak k a2 koal e innerhalb der Schleife wird jeweils das ki durch k mod 2 berechnet ist also gleich 0 oder 1 e q wird durch die Anweisung q q q zu a a2 af e bei jedem Durchlauf wird p genau dann mit q multipliziert wenn ein ki 1 ist 7 18 Somit erhalten wir folgende Ergebnisse A B Max Mittel Max Mittel Vergleich k k 2 log2 k 2 log2 k Add Sub k 1 k 1 0 0 Mult Div k k 3 log2 k 2 5 log2 k Zuweis 2k 1 2k 1 3 log2 k 2 2 5 log2 k 2 Summe 5k 2 5k 2 8 log2 k 2 7 log2 k 2 Bei Berechnung der Summe wurde angenommen da die obigen elementaren Operationen alle einen Aufwand von 1 erfordern eine Maschinenoperation Diese Annahme gilt allerdings nicht uneingeschr nkt denn Addition und Multiplikation von Integer bzw Float kann ganz
100. iff so wie wir ihn verwenden wollen hergeleitet werden 6 2 1 Structured Design Structured Design abgek rzt SD von Yourdon Constantine Myers besch ftigt sich mit der Frage Wie kann ein zu entwerfendes Programm geeignet e in Module zerlegt e die Module untereinander organisiert und e ihre Abh ngigkeiten in einem Diagramm dargestellt werden SD unterst tzt die konsequente Top Down Vorgehensweise Es handelt sich um einen funktionsorientierten d h ablauforientierten Entwurf Ein Programm besteht dabei aus hierarchisch angeordneten Programm Modulen Ein Modul nicht Proze im Sinne der SA kann hier an mehreren Stellen auftreten und jeweils verschiedene Aufgaben l sen z B mod A 6 5 Ein Modul kann sp ter bei der Implementierung realisiert werden als e Makro d h rein textuelle Ersetzung z B cpp amp include m4 Inline Code z B f r Assembleranweisungen e Unterprogramme Prozeduren Funktionen in Fortran Pascal C Das hei t es gibt viele Realisierungsm glichkeiten f r einen Modul je nachdem mit welcher Programmiersprache er sp ter implementiert werden soll Die Hierarchie der Module und ihre Abh ngigkeiten untereinander werden in Moduldiagrammen und Structure Charts festgehalten die Funktionalit t der Module in sogenannten M Specs beschrieben 6 2 2 Modular Design Der oben vorgestellte Modulbegriff aus dem SD ist mehr oder weniger identisch mit dem Funktions
101. ine Anderung in UserAccountinfo kann die Funktion Check_Password beeinflussen selbst wenn die Anderung nichts mit Passw rtern zu tun hat Die Funktion Check_Password erh lt Daten die sie nicht braucht Information Hiding verletzt Ein Fehler in der Funktion Check_Password k nnte Daten in UserAccountlinfo modifizieren was aber dann in einer ganz anderen Funktion zu Tage tritt Man sieht also an diesem Beispiel dass Datenkopplung zwar zu einer gr eren Schnittstelle f hrt aber andere Vorteile gegen ber der Datenstrukturkopplung bietet Zwei Funktionen kommunizieren mittels Signalkopplung wenn mindestens ein Steuersignal ausgetauscht wird Durch Signalkopplung wird das Verhalten des Empf ngers beeinflu t Dies ist grunds tzlich unerw nscht da eine der beiden Funktionen dann keine Black Box mehr ist Je mehr Entscheidungsfreiheit die Empf ngerfunktion hat umso mehr ist das Black Box Prinzip gewahrt 6 30 Signalkopplung tritt in zwei Formen auf 1 Das Signal tr gt Information wie etwa den Status Plausibilit t EOF etc Damit ist die Entscheidungsfreiheit des Empf ngermoduls gewahrt 2 Das Signal enth lt die Information wie der Empf ngermodul weitermachen soll etwa in Form von Befehlsadressen Marken Funktionen die aufgerufen werden sollen etc Dies tritt bespielsweise auf bei sogenannten Callback Mechanismen Bei hybrider Kopplung wird Signal und Datenkopplung gemischt So k nnen Schl sselfelder einer Tabelle
102. inungen Insgesamt gelten f r die Verbindung der Komponenten eines Datenflussdiagramms gewisse Konsistenzbedingungen e Fl sse d rfen nicht von Speicher zu Speicher oder von Quelle zu Senke fliessen auch nicht von einer Quelle direkt zu einem Speicher oder aus einem Speicher direkt in eine Senke e Zyklische Datenfl sse sind nicht erlaubt e Prozesse oder Speicher d rfen nicht nur Eing nge oder nur Ausg nge haben aber Timer Letztere Regel gilt allerdings bei Speichern in Unterdiagrammen nicht da ein Unterdiagramm nur ein Teil modelliert kann es vorkommen dass in einem Diagramm nur ein Lesezugriff auf einen Speicher zu sehen ist und in einem anderen der Schreibzugriff Auf die Regeln wird sp ter noch einmal genauer eingegangen Das folgende Diagramm enth lt eine Reihe von Verletzungen dieser Konsistenzbedingungen T P4 ST2 4 0 4 8 4 9 4 3 Beispiel zur Erstellung eines Datenflu diagrammes Folgende verbale Problembeschreibung sei gegeben Der Kunde gibt an der Gep ckannahme das Gep ck und seine Reisepapiere ab Der Schalterbeamte erkennt daraus den Zielort entnimmt einer Schublade einen Gep ckschein f r jedes Gep ckst ck und f llt die Scheine aus Er trennt die Scheine und heftet je einen Teil an das Gep ckst ck und legt es auf das F rderband Er gibt dem Kunden seine Reisepapiere incl der Kontrollabschnitte zur ck Was soll automatisiert werden Gep ckannahme Welches sind
103. istenz und ber die korrekte Nutzung der Daten In dem man in einer Hierarchie Sichtbarkeiten einschr nkt Scoping erreicht man eines der wichtigsten Ziele Information Hiding Durch die Definition von Scopes kann man interne Objekte vor unbefugtem Zugriff verstecken Durch die Verwendung von Scopes wird die Sichtbarkeit und damit die Benutzung von Objekten eingeschr nkt Je kleiner der Scope um so weniger Seiteneffekte sind zu erwarten Als Scope eines Objektes bezeichnet man den Bereich in dem ein Objekt g ltig ist Innerhalb dieses Scopes ist das Objekt bekannt f r alle anderen Objekte im gleichen Scope und kann von diesen genutzt werden Praktisch bedeutet dies dass man innerhalb eines Scopes nicht eine Komponente ndern kann ohne dass nicht zumindest noch eine andere ebenfalls modifiziert werden muss oder dies zumindest gepr ft werden muss F r die Scopes iinerhalb eines Designs gelten folgende Regeln e Alles was innerhalb einer Operation definiert ist ist nur dort sichtbar Andere Objekte k nnen interne Objekte nicht sehen und nicht benutzen 6 10 e Alles was innerhalb eines Moduls definiert ist kann von den Modulkomponenten ohne Einschr nkung benutzt werden So k nnen die Operationen eines Moduls sich gegenseitig aufrufen oder die im Modul definierten Daten benutzen Um Composed Of Hierarchien darzustellen gibt es im Design folgende M glichkeiten e Packages bestehen aus composed of Packages und Moduln e
104. ition eines Vorgangsmodells ist die M glichkeit einer gezielten Projektverfolgung Projektverfolgung erfordert exakte Projektplanung st ndige regelm ige IST Erfassung st ndiger regelm iger IST SOLL Abgleich m glichst vorausschauende Problemerkennung Gesch ftsf hrung Normen u Kundenw nsche Standards Personalangelegenheiten technische Probleme Projekt gt Lr O mitarbeiter IST Termine Projekt ST Kosten Projekt managemen plan SOLL Termine SOLL Kosten Qualit ts sicherung 9 13 10 Literaturverzeichnis Bal 91 Bre 92 Che Coa 91 Coa 91 DeM 79 Gei HaP 88 Mey 79 Ott 91 Balzert Helmut CASE Systeme und Werkzeuge 3 Aufl BI Wissenschaftsverlag Mannheim Wien Z rich 1991 akt ist die 4 Auflage 770 S Breutmann B Burkhardt R Objektorientierte Systeme Grundlagen Werkzeuge Einsatz Hanser Verlag M nchen Wien 1992 Chen P Entity Relationship Model Toward a Unified View of Data ACM Transaction on Database Systems Vol 1 No 1 Coad P Yourdan E Object Oriented Analysis 2nd Ed Prentice Hall Englewood Cliffs NJ 1991 Coad P Yourdan E Object Oriented Design Prentice Hall Englewood Cliffs NJ 1991 De Marco T Structured Analisys and System Specification Prentice hall Englewood Cliffs NJ 1979 GEI Software Tools ProMod Das Ziel ist klar die Methode treffend Beschreib
105. l hat logische Koh sion wenn die Elemente hnliche Aufgaben aber mit v llig verschiedenen Ein oder Ausgabedaten durchf hren 6 34 So sind etwa die folgenden Elemente des Moduls Reisen logisch koh siv reise mit dem Auto reise mit dem Zug reise mit dem Flugzeug reise mit dem Schiff Ein solches Modul ist meist dadurch gekennzeichnet dass viele Flags und Schalter gesetzt werden um die unterschiedlichen Daten zu bearbeiten Dadurch kann ein solches Modul so un bersichtlich werden dass niemand mehr wei was tats chlich passiert Das ist der Grund warum diese Koh sion so tief eingestuft wird trotz des Namens der eigentlich auf eine gute Eigenschaft hindeutet Daher sollte es besser unlogische Koh sion hei en Module sind zuf llig koh siv wenn keine andere Kategorie zutrifft Die Vermutung ist dass die Elemente zuf llig zu einem Modul zusammengefasst wurden Module mit zuf lliger Koh sion entstehen manchmal wenn gemeinsame St cke von Code entdeckt werden So sind etwa die folgenden Elemente des Moduls Verschiedenes zuf llig koh siv Haus streichen Kaffee trinken V lkerball spielen Auto waschen Zur Bestimmung der Art der Koh sion kann man folgende Heuristiken anwenden e Man versucht einen einzigen Satz zu schreiben der die Modulfunktion vollst ndig und genau beschreibt e Falls dieser Satz ein Satzgef ge ist mit einem Komma oder mehr als einem Verb dann ist der Modul wahrscheinlich weniger als funkti
106. lb einer Typdefinition beschreibt dass eine Komponente dieses Typs an der Zusammensetzung des definierten Typs beteiligt sein kann aber nicht muss Die Komponente ist also optional Ein Typname in geschweiften Klammern beschreibt dass Komponenten dieses Typs mehrfach an der Zusammensetzung des definierten Typs beteiligt sind iteration Die Anzahl der Iterationen kann durch Indizes bestimmt werden Beispiele f r DD Eintr ge sind Name Vorname Nachname Datum Tag Monat Jahr Zeichen Buchstabe Ziffer 4 18 Namensfeld 1 Zeichen 30 Alle Datenfl sse und Speicher die in einem DFD gezeigt werden m ssen im DD definiert werden Zus tzlich k nnen auch Komponenten von Speichern und Datenfl sse im DD definiert sein die nicht in Diagrammen auftreten So k nnte im obigen Beispiel zwar Namensfeld in einem DFD auftreten seine Komponente n mlich Zeichen m glicherweise nicht Wenn ein Typname zur Definition eines anderen Typs verwendet wird dann muss er auch im DD definiert werden An beliebigen Stellen auf der rechten Seite einer Definition kann per FZEEXtE gt Kommentar eingestreut werden um den Sachverhalt zu verdeutlichen 4 6 2 Einfaches Beispiel Die Definition von deutschen Kfz Kennzeichen lautet etwa Zuerst kommen 1 bis 3 Buchstaben gefolgt von einem Strich Danach k nnen optional 1 bis 2 Buchstaben stehen Durch einen Zwischenraum getrennt folgen am Ende dann noch 1 bis 4 Ziffern In der ob
107. m DFD e Kontrollfl sse geh ren zum CFD e Kontrollspezifikationen oder Barren geh ren zum CFD Dies wurde bereits in einigen der vorhergehenden Beispiele ausgenutzt Auf der n chsten Seite befindet sich das Schema f r hierarchische DFD CFD als Zusammenfassung ber das ganze Gebiet der SA RT Im Data Dictionary DD werden alle Datenfl sse Kontrollfl sse Datenspeicher und Kontrollspeicher definiert und abgelegt 5 17 Schema f r hierarchische DFD CFC im Rahmen von SA RT Kontext Diagramm DFD Datenflu Diagramm P Spec Proze Spezifikation gt Datenflu C Proze C Datenquelle senke Speicher gt Kontrollflu Kontroll Spezifikation Proze aktivierungstabelle Data Dictionary Definition aller Datenfl sse Kontrollfl sse DD Datenspeicher und Kontrollspeicher auch Teile davon 6 Strukturierter Entwurf Nachdem die Aufgabe das zu l sende Problem e eingehend analysiert ist e eine m glichst exakte Aufgabenspezifikation in Form des Pflichtenhefts gemeinsam mit dem Kunden geschaffen wurde und e sich die Vertragsparter einig sind folgt die Phase des Entwurfs TJ Designphase F r die Entwurfsphase ist es besonders wichtig zu wissen welche Art der Gesamtl sung angestrebt werden soll Traditionelle Methode Gro er Kostenanteil in eigentliche Programmentwicklung damit Kosten f r Pflege und Wartung heute 40 70 m glichst gering gehalten
108. m Ende einer Aufrufkante liegen Es sind normale und vordefinierte Datenbereiche zu unetrscheiden e Ein Datenbereich wird als normale Daten dargestellt wenn er in diesem Projekt zu erstellen ist und nicht schon vordefiniert ist Ein oder mehrere Datenbereiche k nnen einem Modul zugeordnet werden unabh ngig davon ob diesem Modul auch Operationen zugeordnet sind Normale Daten werden durch ein Sechseck dargestellt in dessen Inneren der Name des Datenbereichs steht Zu jedem Datenbereich kann Quellcode eingegeben werden der z B aus Variablen und Typdeklarationen bestehen kann jedoch nicht aus Funktionen e Vordefinierte Daten repr sentieren bereits vorhandene Datenbereiche z B in bestehenden Libraries die lediglich in das neue Projekt eingebunden werden m ssen Vordefinierte Daten werden durch ein Sechseck mit zwei zus tzlichen parallelen Linien dargestellt in dessen Inneren der Name des Datenbereichs steht Vordefinierten Daten kann kein Quellcode zugeordnet werden Weiterhin k nnen Konnektoren benutzt werden Sie werden gleich gezeichnet wie in Moduldiagrammen und unterliegen den gleichen Regeln wie sie bereits oben beschrieben wurden 6 5 2 Verkn pfungen im Operationsdiagramm Operationen werden durch Pfeile verkn pft welche von der bergeordneten aufrufenden Operation zur untergeordneten aufgerufenen Operation gerichtet sind Datens tze verwalten Quittung Globale Daten Datensatz ausgeben Ein
109. m Zweifel w hlt man die schlechtere Kopplungsart um sie dann zu verbessern Man betrachtet seine Funktionen wie Bibliotheksroutinen und fragt Wie erhalte ich den gr ten Nutzen Wie verbessere ich die Wartbarkeit 6 8 4 Zusammenhalt eines Moduls Der Zusammenhalt Koh sion Cohesion ist ein wichtiger Indikator f r die Komplexit t eines Moduls und damit f r die Verst ndlichkeit Koh sion ist ein Ma f r die St rke des funktionalen Zusammenhangs der Elemente innerhalb eines Moduls Module mit hoher Koh sion sind leicht verst ndlich und damit besser wartbar Die Elemente einer Funktion sind Anweisungen Gruppen von Anweisungen oder Aufrufe an andere Funktionen Die Elemente eines Moduls im Modular Design sind Funktionen und zentral definierte Daten Konstanten Datentypen F r die Bewertung des Zusammenhalts gibt es die folgenden Kriterien e Funktions Sicht sehr gut funktionaler Zusammenhalt e Daten Sicht gut sequentieller Zusammenhalt kommunikativer Zusammenhalt e Zeit Sicht mittelm ig prozeduraler Zusammenhalt zeitlicher Zusammenhalt e Sonstiges schlecht logischer Zusammenhalt zuf lliger Zusammenhalt Ein Modul ist funktional koh siv wenn alle Elemente der Erf llung einer einzigen Aufgabe dienen Daher lautet eine h ufige Forderung dass man die Aufgabe eines Moduls in einem Satz zusammenfassen k nnen m sse 6 32 Die folgenden Elemente des Moduls Wandle Grad in Bogenma um sind funktional koh
110. mmen Endliche Automaten oder Zustands bergangsdiagramme werden in der Informatik an vielen Stellen eingesetzt Bei dem Anwendungsgebiet hier n mlich der Modellierung von Kontrolllogik gelten noch die folgenden zus tzlichen Randbedingungen e Ereignisse k nnen in den Barren eingehende Kontrollfl sse sein oder k nnen in der Entscheidungstabelle definiert werden e Aktionen k nnen ausgehende Kontrollfl sse betreffen Prozesse des gleichen Diagramms de aktivieren oder m ssen in einer Prozessaktivierungstabelle definiert werden Man spricht in diesem Zusammenhang auch von den RT Diagrammen weil sie bei der Modellierung von Realtime Eigenschaften eines Systems eine zentrale Rolle spielen 5 14 5 5 Proze aktivierungstabellen In einer Proze aktivierungstabele werden eingehende Signale in Proze aktivierungen und Ausgangssignale umgesetzt Die Tabelle hat hnlichkeiten in der Form und im Inhalt mit Entscheidungstabellen Der Fokus liegt aber eben auf der Proze seite daher die besondere Form Die Tabelle ist in drei Spaltengruppen unterteilt e Die erste Spaltengruppe besteht nur aus einer Spalte in der die Eingangssignale aufgelistet sind Eingangssignale k nnen eingehende Kontrollfl sse Ausg nge der zugeh rigen Entscheidungstabele oder Aktionen aus dem Zustands bergangsdiagramm sein e In der zweiten Spaltengruppe der Proze gruppe bilden die zu steuernden Prozesse jeweils eine Spalte Jede dieser Spalten mu al
111. mmengefa t i d R elektronisch gef hrt Im Verlauf eines SW Projekts l t sich das Ziel einer jeden Phase durch das Vorliegen der Ergebnisse Dokumentation berpr fen Ergebnisse der Analyse Spezifikations und Organisationsphase sind Pflicht Proj Leiter QS Ichlen l heft Impl Des pi Il I2 Tr RT Spezifikation a ANNER Netzplan gang zur DD Vertag int Ablaufplanung Ergebnisse der Entwurfsphase Design sind Structure Charts Testdaten Modul Mod 1 0 Spec Mod 1 1 9 4 9 1 2 Programmdokumentation Programmdokumentation also die Kommentare im Quellprogramm hat i a zwei unterschiedliche Adressaten e diejenigen die das Modul nutzen m chten II Blackbox Sicht e diejenigen die die Funktionsweise des Moduls verstehen ndern wollen II Whitebox Sicht Blackbox Beschreibung ist lediglich Genaue Schnittstellen Beschreibung des Moduls Name Reihenfolge und Typ der Parameter Informationen ber evtl Seiteneffekte Zugriff auf globale Datenssrukturen Aufruf von extern definierten Funktion ben tigte Bibliotheksfunktion Information ber ben tigte globale Resourcen wie allokierter Speicher ben tigte Files Ger te Prozesse D h die Blackbox Beschreibung ist die Summe dessen was im Modulkopf beschrieben ist bzw in der Entwurfsphase andernorts spezifiert wurde II Structure Charts Modul Specs Whitebox Beschreibung gibt ersch pfend Auskunft dar ber
112. n 4 6 3 Weitere Beispiele f r Eintr ge Beispiel 1 Auftragsverwaltung Ganzzahl max 30 Zeichen langer String Auftragsdatum 1 Position 100 Liefertermin Kundenname Kundennummer Monat Tag Jahr Auftragskartei Kopf 1 Auftrag 1000 5 stellige Zahl mit folgender Bedeutung 1 Ziffer 0 f r Standardartikel 1 f r Kundenname Adresse Kundennummer Kundenkartei 1 Kunde 5000 Kundenname Nachname Vorname Kundennummer 10 stellige Zahl wie folgt aufgebaut Position Anzahl BestellNr Artikel Einzelpreis Positionspreis 4 20 Beispiel2 Literatur Datenbank Kennung T1 Typ T2 1 Verfasser 4 Titel T5 Jahr T7 ISBN T8 Abstract T9 Bemerkung 1 char 8 Buch Zeitschrift Diplomarbeit Skript Nachname T3 Vorname T4 1 char 80 1 2 Ziffer Ziffer Ziffer Ziffer 3 Ziffer 3 4 Ziffer 5 Ziffer 1 char 400 1 char 20 1 Buch 5000 4 21 4 7 Vorgehensweisen bei der Strukturierten Analyse Man unterscheidet drei unterschiedliche Vorgehensweisen datenflu orientiert funktionsorientiert und e ereignisorientiert Datenflu orientierter Ansatz Die Funktionen ergeben sich aus den prim r betrachteten Daten und Materialfl ssen Zuerst Fragen der Form welche Objekte werden bewegt Jede
113. n und was verborgen bleibt Damit der Modulbegriff nicht berladen wird werden die Bestandteile eines Moduls also die Funktionen bzw Daten nicht mehr als Module wie im SD bezeichnet sondern man spricht nun von Operationen um allgemein zu bleiben und sich nicht an einen bestimmten Funktionsbegriff einer Programmiersprache anzulehnen In dieser Terminologie fassen Module Operationen und Daten zu einer Einheit zusammen 6 6 Bei der Realisierung eines Moduls mit einer konkreten Programmiersprache gibt es zwei M glichkeiten e In der Programmiersprache gibt es Module als sprachliche Einheiten wie Module in Modula oder Package in Ada Dann wird ein Modul aus dem Design auf einen solchen Modul der Programmiersprache abgebildet e In der Programmiersprache gibt es diesen Modulbegriff nicht sondern nur Funktionen wie in den meisten lteren Programmiersprachen beispielsweise C oder Pascal In diesem Fall wird ein Modul aus dem Design abgebildet auf eine bersetzbare Einheit in der Programmiersprache in aller Regel also auf eine Datei Bleiben wir beim Fall der Programmiersprache C dann werden also die Operationen aus dem MD abgebildet auf Funktionen in C und die Module auf eine Datei die ja in C mehrere Funktionen und oder Datendefinitionen enthalten kann 6 2 3 Hierarchiebildung mit Paketen In neueren Auspr gungen des MD hat man noch den Begriff des Pakets Package eingef hrt aus der Erkenntnis heraus dass man noch gr ere
114. nabh ngig voneinander realisierbare e in ihrer Komplexit t berschaubare ann hernd gleich gro e Einzelbausteine Module zerlegt Man spricht daher auch von Modularisierung Die Vorteile der Modularisierung sind e Parallelisierung des weiteren Entwurfs e Parallelisierung der folgenden Implementierung e Wiederverwendung bereits vorhandener Bausteine soweit m glich e leichte Austauschbarkeit von einzelnen Modulen Beschr nkung des Wissens ber andere Module bei der Implementierung 2 4 Die Modularisierung soll also die Probleml sung verst ndlich und ihre Korrektheit nachpr fbar machen e die unabh ngige Implementierung von Modulen sicher stellen e die Austauschbarkeit von Modulen mit gleicher Funktion erm glichen Die klassischen Verfahren f r den Entwurf sind das e Structured Design bzw e Modular Design Zunehmend an Bedeutung gewinnt das Verfahren e Object Oriented Design OOD das allerdings in anderen Vorlesungen ausgef hrt wird 2 3 Implementierung Wurde der Entwurf richtig durchgef hrt so wird ein hoher Grad an Parallelit t bei der Implementierung erreicht Ergeben sich keine gravierenden Fehler bei der Definition der Schnittstellen so kann jeder Programmierer relativ unabh ngig die ihm bertragene Implementierungsarbeit ausf hren Die projektinterne Kommunikation ist ab dann auf das Notwendigste begrenzt Absprachen untereinander welche in der Praxis nur noch selten dokum
115. nderma en e Testdaten f r die Eingabe ausw hlen Testdaten sollen nicht zu kompliziert sein Testdatensatz aus Entwurfsphase kann verwendet werden e Programmablauf anhand des Listings schrittweise durchspielen Testperson bernimmt Aufgabe eines Interpreters Aktuelle Variablenbelegungen werden mitgeschrieben Gleichzeitig wird das Verhalten bei leichter Variation der Eingabe Daten im Auge behalten z B Grenzf lle bei Verzweigungen 6 Es gibt psychologische Probleme wenn ein Autor seine eigenen Programme testet Die Methode ist langwierig und m hevoll Sie erfordert hohe Konzentration und ist selbst sehr fehleranf llig Oft werden Variablen vergessen und sp ter nachgetragen Sie spiegelt oft nur die eigene Meinung ber die Korrektheit des Programmes wieder 8 4 Die Vorteile wenn ein andere Person den Test durchf hrt sind e Die Testperson arbeitet sich automatisch in das Programm ein e Eine unabh ngige Person hat das Programm verstanden und h lt es f r korrekt 8 3 2 Walkthrough Ein Walkthrough ist analog dem Schreibtischtest jedoch sollten mind 2 max 4 Personen daran teilnehmen darunter auch der Autor Zu dem Team sollten wahlweise hinzugezogen werden erfahrener Programmierer Experte f r die Programmiersprache weiterer Programmierer aus dem Team des Autors eventuell neuer Mitarbeiter unvoreingenommen neue Ideen Folgende Regeln sollten bei einem Walkthrough beachtet
116. ng Hilfetexte Fehlermeldungen Gestaltung der Applikation Fonts Farben e Hinweise zur defensiven Programmierung if fopen else e Konventionen f r Files Namensgebung f r Source Files Header Files Zugriffsberechtigungen auf Files Bezeichnung von Varianten Versionskontrolle Namensgebung bei mehreren verfolgten Varianten Freigabe von Modulen zum Test 7 3 Anforderungen an ein Programm Wie bereits festgestellt oder intuitiv bekannt gibt es unterschiedlich gute Algorithmen bzw Programme Aber wann ist ein Programm gut oder schlecht F r die Bewertung gibt es verschiedene Qualit tsma st be Effektivit t Korrektheit Adaptierbarkeit Portabilit t Kompatibilit t Zuverl ssigkeit Robustheit Verf gbarkeit Benutzerfreundlichkeit Wartbarkeit Effizienz und Leistung O OO N OD GT ro N 7 5 Ein gutes Programm kann nicht gleichzeitig alle Kriterien erf llen manche schlie en sich gegenseitig aus oder stehen sogar im Widerspruch zueinander e Minimiert man den Speicherverbrauch so erh ht sich i d R die Rechenzeit und umgekehrt Beispiel Daten m ssen de komprimiert werden vor nach der Verarbeitung e Eine Erh hung der Verf gbarkeit und Benutzerfreundlichkeit f hrt zu weniger effizienten Programmen Beispiel Benutzereingaben berpr fen redundante Datenhaltung Man unterscheidet daher zwischen absoluten und relativen Anforderungen Absolute Anf
117. ngen werden zur Weihnachtszeit Karten mit oder ohne Pr sente verschickt oder die W nsche noch zus tzlich in einem pers nlichen Anruf bermittelt Algorithmus Kundenbetreuung Buchpr sent pers nl Anruf 5 7 5 3 2 Eigenschaften von Entscheidungstabellen Es ist zu beachten da die Entscheidungstabellen e vollst ndig insbesondere falls keine ELSE Spalte vorhanden e widerspruchsfrei und e m glichst optimiert sind vollst ndig ELSE Teil Widerspruch nicht optimiert Die Tabelle sollte also so aufgebaut sein dass f r jede m gliche Kombination von Zust nden genau eine Regel erf llt ist Die SONST Spalte ELSE Teil ist optional Sie deckt alle Kombinationen ab die durch keine der Regeln erfa t wurden Sie hat daher im Bedingungsteil nur leere Eintr ge Eine ET hei t formal vollst ndig wenn alle m glichen Kombinationen der Eingangsbedingungen abgedeckt sind Formale Vollst ndigkeit wird in den Beispielen oben in der ET 1 0 und der ET 4 0 erreicht Formale Vollst ndigkeit hat Probleme da wo Bedingungen logisch zusammenh ngen wie im gr eren Beispiel der Kundenbetreuung weiter oben Hier sind 3 Bedingungen ber den Bestellwert BW formuliert Wenn man versucht alle formal m glichen Kombinationen einzutragen erh lt man Widerspr che in diesen Bedingungen Diese ET kann nicht formal vollst ndig gemacht werden Eine Entscheidungstabelle die alle tats chlich m glichen F lle abdeckt hei t l
118. nings bungsprogramm e Kompatibilit t zu anderen Programmen e Liste mit Fehlermeldungen und ihre Bedeutung Behebung e Stichwortverzeichnis 9 7 9 1 4 Konfigurationsmanagement Mindestanforderung ist Makefile welches via Versionskontrollsystem die aktuellen freigegebenen Versionen beschafft automatisch die Vollst ndigkeit aller erstellter Module bzw Bibl Module berpr ft entsprechend den Abh ngigkeiten neue Object Module erzeugt bzw Bibl Module zusammenbindet alle ausf hrbaren Programme bzw f r deren Ausf hrung notwendigen Resourcefiles notwendigen Daterfiles erzeugt 9 8 9 2 Qualit tssicherung Die internationale Norm ISO9001 Teil 3 Qualit tsmanagement und Qualit tssicherungsnormen vom Juni 1993 enth lt einen Leitfaden f r die Anwendung von ISO 9001 auf die Entwicklung Lieferung und Wartung von Software Neben 1 Vorwort Zweck der Norm 2 Verweis auf andere Normen i d R schwer auf SW bertragbar 3 Begriffe Definitionen sind die wichtigsten Kapitel 4 Qualit tssicherungssystem Rahmen 4 1 Verantwortung der obersten Leitung 4 1 1 Verantwortung der obersten Leitung des Lieferanten 4 1 1 1 Qualit tspolitik Die oberste Leitung des Lieferanten mu ihre Politik sowie ihre Zielsetzungen und ihre Verpflichtung zur Qualit t festlegen und dokumentieren Der Lieferant mu sicherstellen da diese Politik auf allen Ebenen der Organisation verstanden verwirklicht un
119. nisse Aktionen Diesen Aktionen werden dann in der Proze aktivierungstabelle eigentlich auch eine Entscheidungstabelle Proze aktivierungen und Steuersignale zugeordnet 5 5 5 2 3 Regeln f r C Specs und Kontrollfl sse F r die C Specs gelten folgende Regeln Jede Kontrollspezifikation tr gt den Namen des zugeh rigen Kontroll Flu diagramms Jeder Proze der in der C Spec kontrolliert wird mu im zugeh rigen Diagramm erscheinen Alle Kontrollfl sse die in einem Diagramm auf einen Balken flie en m ssen in der C Spec als eingehende Fl sse erscheinen Alle Kontrollfl sse die in einem Diagramm aus einem Balken flie en m ssen in der C Spec als ausgehende Fl sse erscheinen Die beiden letztgenannten Regeln betreffen das sogenannte Horizontale Balancing von Kontrollfl ssen Die Regeln des Vertikalen Balancing von Kontrollfl ssen seien hier der Vollst ndigkeit halber erw hnt auch wenn sie nicht unmittelbar in Zusammenhang mit C Specs stehen Alle Kontrollfl sse die in einen Knoten flie en m ssen in der Verfeinerung entweder in einen Balken oder in einen Knoten flie en Alle Kontrollfl sse die aus einem Knoten flie en der verfeinert ist m ssen entweder aus einem Balken oder aus einem Knoten der Verfeinerung flie en Weitere spezielle Regeln die nur einzelne Formen von C Specs betreffen werden weiter unten in der Vorstellung der jeweiligen Form genannt 5 2 4 Textuelle Bescheibung von C Specs
120. nn auch noch unausgef llt zur Verf gung steht Eventuell kann ein Dummy Ergebnis zur ckgeliefert werden solange die eigentliche Version noch nicht existiert 7 2 Implementierungsrichtlinien Ziel ist eine m glichst normierte Programmierung zur e schnellen Wiedererkennung gleichartiger Strukturen Darstellungen e Unterst tzung bei der sp teren Analyse und Einarbeitung in das Programm e Unterst tzung der sp teren Programmvalidierung Walkthrough und Test Damit wird gleichzeitig die Wiederverwendbarkeit von Modulen unterst tzt Der Nachteil besteht in einer z T erhebliche Einarbeitungszeit f r neue Mitarbeiter Implementierungsrichtlinien k nnen umfassen Textuelle Gestaltung des Source Codes e maximal 80 Zeichen je Zeile stets darstellbar auf Terminal Drucker e Bl cke werden durch Leerzeilen getrennt e innerhalb von Bl cken gibt es keine Leerzeilen e geschachtelte Bl cke werden je um 2 Spalten einger ckt Form der Klammerungen mit begin end do od m glichst Einsatz von sprachsensitiven Editoren automatisches Einf gen eines generischen Modulkopfes automatisches Einr cken bei Bl cken automatische Plazierung von end nach Eingabe von begin until repeat automatische Einf gung von Kommentar bei Variablendeklaration Klassendeklaration Funktionsdeklaration 7 2 Reihenfolge der Bestandteile eines Modulkopfes Name des Quelltext Files e Modulname e Autor des Moduls e Modifikationshist
121. nz Es gibt eine prinzipielle Einteilung der Programmiersprachen in e Imperative Programmiersprachen Assemblersprachen klassische Hochsprachen objektorientierte Sprachen e Deklarative Sprachen wissens orientierten Sprachen regelorientierte Sprachen frame orientierte Sprachen 7 20 Eine andere Einteilung spiegelt mehr die historische Entwicklung wieder man teilt Programmiersprachen in sogenannte Generationen ein 1 Generation Maschinensprachen e entspricht gerade der Menge g ltiger Maschineninstruktionen bin r einer speziellen CPU z B Bin r Code von intel 8080 PDP11 2 Generation Assembler Sprachen e mnemotechnische Abk rzungen f r Maschineninstruktionen fa t oft die Befehle einer Prozessorfamilie zusammen z B Intel 80x86 Assembler VAX Assembler 680x0 Assembler 3 Generation H here Programmiersprachen HPS e anwendungsspezifische HPS SIMULA PLM zur Programmierung von Mikroprozessor Applikationen COBOL im Bereich Wirtschaftswissenschaften RPG II e universelle HPS Algol Basic Fortran Pascal Modula C Ada e objektorientierte HPS Smalltalk Oberon Eiffel Objective C C Java 4 Generation Anwendersprachen e Datenbanksprachen DDL SQL NATURAL 2 e Sprachen spezieller Applikationen Skript Sprachen PPS dBASE OPEN ACCESS EXCEL Es sind deklarative Sprachen d h Anwender mu nicht den Algorithmus angeben sondern nur das gew nschte Ergebnis beschreiben
122. ogisch vollst ndig Die ET zur Kundenbetreuung ist logisch vollst ndig Durch die Einf hrung einer ELSE Spalte wird eine Entscheidungstabelle sowohl logisch als auch formal vollst ndig Sie sollte jedoch nur mit Vorsicht gebraucht werden da eine ET mit ELSE Spalte nicht mehr auf Vollst ndigkeit gepr ft werden kann 5 8 5 3 3 RT Entscheidungstabellen Wie im obigen Beispiel zu sehen k nnen Entscheidungstabellen vielf ltig in der Softwareentwicklung eingesetzt werden In der konkreten Situation der Beschreibung einer Kontrollspezifikation gelten jedoch noch folgende Randbedingungen e Die Bedingungen m ssen ber die Eingangsfl sse des Barrens formuliert werden e Bei der Formulierung der Aktionen k nnen ausflie ende Kontrollfl sse Ereignisse des RT Diagramms Aktionen der PAT oder Prozesse des Diagramms ber cksichtigt werden Man spricht in diesem Zusammenhang auch von RT Entscheidungstabellen weil sie zur Modellierung von Realtime Eigenschaften eines Systems dienen 5 3 4 Entscheidungstabellen mit flexiblen Werten In der bisher vorgestellten Form k nnen die Zellen einer ET nur die festen Werte J N und annehmen Es gibt eine zweite Variante von Entscheidungstabellen bei der in den Bedingungen nicht unbedingt eine Aussage sondern irgendein Text wie etwa der Name einer Eingangsgr e des Barrens steht Dieser bildet dann zusammen mit dem Zellenwert der hier einen beliebigen Text annehmen darf die Bedingung Die e
123. onal e Falls dieser Satz ein Verb enth lt mit einem oder mehreren und dann ist der Modul wahrscheinlich sequentiell kommunikativ oder prozedural e Falls dieser Satz Zeitw rter enth lt wie zuerst als n chstes danach etc so ist der Modul wahrscheinlich prozedural e Falls der Satz mehr als ein Verb hat mit Verwendung von oder so ist der Modul wahrscheinlich logisch e Falls der Satz komplex ist und mehrere und oder und oder enth lt so ist der Modul wahrscheinlich zuf llig Man kann nicht unbedingt erwarten dass man die Kategorie exakt bestimmen kann Im Zweifelsfall ordnet man den Modul einer schlechteren Kategorie zu Je besser die Koh sion ist desto geringer ist das Risiko dass eine Spezifikations nderung eine gro e Anzahl von anderen Moduln betrifft desto lokaler sind die Anderungen begrenzt Insgesamt wird das System einfacher wartbar und damit kosteng nstiger Interessanterweise stehen Kopplung und Koh sion miteinander im Zusammenhang Bessere Koh sion f hrt automatisch dazu dass die Kopplung abnimmt 6 35 6 8 5 Faktorisieren von Moduln Das Herausl sen von Teilen eines Moduls in ein eigenes Modul bezeichnet man auch als Faktorisierung Dies kann eingesetzt werden um e die Modulgr e zu reduzieren e Redundanz zu vermeiden e Ausf hrung und Steuerung zu trennen Die Faktorisierung sollte nicht mehr weitergef hrt werden wenn die Schnittstelle eines Moduls komplexer wird als die des
124. orderungen sind beispielsweise Korrektheit und Wartbarkeit Auf sie kann keinesfalls verzichtet werden Alle brigen haben relativen Charakter und m ssen gewichtet werden entsprechend dem Einsatzbereich des Programms und e den gegebenen Randbedingungen in Form von technischen zeitlichen oder finanziellen Vorgaben Typische Beispiele Soll eine zu automatisierende Anlage binnen sehr kurzer Zeit in Betrieb genommen werden dann leiden sicherlich die Zuverl ssigkeit Benutzerfreundlichkeit und Robustheit der SW Sollen mit einem Produkt neue Wege beschritten werden z B bessere Kommunikationsprotokolle geeignetere Datenaustauschformate um bessere Ergebnisse zu erhalten oder komplexere Aufgaben l sen zu k nnen dann ist man wahrscheinlich nicht mehr kompatibel zu fr heren Programmen Werden die Kosten von redundanten Mehrrechnersystemen nicht akzeptiert dann ist erh hte Verf gbarkeit und Fehlertoleranz kaum zu erreichen Beim Space Shuttle beispielsweise 3 aus 5 7 6 Die m glichen Qualit ten von Software m ssen dem Informatiker bekannt sein und sollten mit dem Auftraggeber besprochen werden unter Hinweis auf die Auswirkungen und Kosten F Wichtige Anforderungen welche erf llt werden m ssen oder auf welche der Kunde nicht zuletzt aus Kostengr nden verzichtet sollten im Pflichtenheft dokumentiert werden 7 3 1 Korrektheit Ein Programm arbeitet korrekt oder effektiv wenn es seine Aufgab
125. orie e aktueller Zustand des Moduls e Aufrufsyntax e Funktionsbeschreibung des Moduls kurz und pr gnant falls ausf hrliche Modulspezifikation an anderer Stelle vollst ndige Spezifikation falls es die einzige Stelle ist an der die Aufgabe Funktion des Moduls beschrieben wird e Seiteneffekte bzw globale Auswirkungen des Moduls e genaue Parameterbeschreibung Reihenfolge der Bestandteile eines Moduls e Modulkopf e eingeschobene importierte Teile include extern e selbst definierte Makros z B define e vereinbarte Konstanten e vereinbarte Datentypen e vereinbarte Datenstrukturen Variablen e vereinbarte Unterprogramme und Funktionen Namenskonvention f r Bezeichner e Namensl nge m glichst selbsterkl rend oft l nger falls Beschr nkung dann hier angeben TI Compiler Linker e Gro Kleinschreibung von Bezeichnern Datentypen Variablen Prozeduren Funktionen Klassen Objekte e Komposition von Bezeichnern Zusammensetzung von Teilnamen Trennzeichen z B _ fest vorschreiben 7 3 Beispiel Was bedeuten im folgenden Programm die Namen was berechnet das Programm program CF input output var c f real begin read c f c 9 5 32 write f end Som 87 Programmkommentar e Dokumentation des laufenden Programmtextes Programmdokumentation Form und Inhalt Plazierung e bei komplexen arithmetischen logischen Operation
126. port und Entwicklung k nnen jedoch ihren Beitrag zum reibungslosen Ablauf und zur Annahme des Systems leisten Nach erfolgter Installation Schulung und Aufnahme des Betriebs erfolgt die Abnahme des Systems durch den Auftraggeber bei innerbetrieblichen Entwicklungen durch die entsprechende Abteilung oder die Verkaufsabteilung und den technischen Support Bei gr eren Auftragsprojekten sollte die Abnahmeprozedur vor dem Vertragsabschlu festgelegt werden und somit Bestandteil des Pflichtenhefts werden Man erspart sich damit manchen Arger Der Auftraggeber berpr ft ob die im Pflichtenheft aufgef hrten Funktionen und Leistungsmerkmale vorhanden sind und das System auch hoffentlich seinen Vorstellungen entspricht W hrend oder nach der Abnahme erfolgt h ufig noch eine Feinanpassung Tuning des Systems an die speziellen lokalen Gegebenheiten Einstellung von Netzwerkadressen Backupzeiten lokale Peripherie anschlie en und in Betrieb nehmen Passw rter einstellen in der PDV oft umfangreichere Einstellung der Anlage wie etwa Verz gerungszeiten von mechanischen Teilen Empfindlichkeit von Sensoren etc 2 7 2 6 Betrieb und Wartung Im Betrieb zeigen sich die eigentlichen Qualit ten eines Produktes wie Funktionsf higkeit Ausfallsicherheit und Leistung Bei der fast immer notwendigen Wartung zeigen sich die Qualit ten wie guter Entwurf und Modularit t Die Wartung stellt zwar das letzte Glied im
127. proze deutlich L Aktivit ten k nnen manuell oder maschinell ausgef hrt werden ber technische Realisierung erfolgt keine Aussage 4 5 4 2 1 Prozesse Ein Prozess auch Verarbeitungsknoten im Englischen node oder bubble genannt stellt eine Aktivit t dar die ihre einflie enden Daten in ausflie ende Daten transformiert Wie diese Transformation erfolgt wird entweder durch die grafische Zerlegung in Teilkomponenten Verfeinerungsdiagramm des Prozesses durch eine Entscheidungstabelle oder durch eine textuelle Spezifikation beschrieben F r Prozesse gelten die folgenden Regeln e Jeder Knoten besitzt einen f r seine Funktion charakteristischen Namen Der Name sollte aus einem Verb und einem Substantiv bestehen e Die Benennung reicht in der Regel nicht aus um den Zweck eines Knotens genau zu beschreiben Die Funktion eines Knotens wird daher durch eine Proze spezifikation P Spec Minispec ausf hrlich beschrieben e Jeder Knoten besitzt eine Nummer die ihn innerhalb des Systemmodells eindeutig identifiziert Das Nummerierungsschema wird weiter unten erl utert Wie bereits erw hnt wird die Ablaufsteuerung eines Systems nicht durch Knoten beschrieben dies erfolgt mit den Mitteln der SA RT die in einem sp teren Kapitel eingef hrt werden Im Rahmen der SA ToDo 4 2 2 Datenfl sse Ein Datenfluss ist vergleichbar mit einer Pipelin durch den Daten oder Material transportiert werden Er kann aus mehreren Kompon
128. r Sie beinhalten jeweils als wichtigste Elemente e Ein Ausgabe Schnittstelle e Funktion Aufgabe des Moduls e Testdaten Jedes Modul wird dabei durch einen Modulkopf Modulheader beschrieben und eingeleitet etwa der folgenden Art Filename Source get _title c Modulname get title Version 0 1 Autor Frank Hack hack rhds01 fht esslingen de Datum 23 3 94 Modifiziert von Alfred Mueller Tel 3774 Datum 29 5 94 Modifiziert von Fred Stiller stiller stone mit edu Datum 4 6 94 Zustand in Bearbeitung Alpha Test Beta Test freigegeben Aufruf get_title server kennung destination Kurzbeschreibung liefert bei Angabe des Servers der Kennung eines Eintrags und eines Zeigers auf ein ausreichend gro es Speicherst ck den gew nschten Datensatz Seiten Effekte globale Auswirkungen keine Parameterbeschreibung i Name des Rechners als Pointer auf String z B als IP Adr 134 108 3 32 oder als Name rhds0 1 name o io Bedeutung 7 1 Praktische Hinweise Ein entsprechender Header ist f r jedes Modul im Rahmen des Entwurfs sp testens als erster Schritt der Implementierung zu erstellen Handelt es sich um ein globales Modul z B Include Makro so sind unter dem Punkt Seiteneffekte alle Files anzugeben welche das Makro verwenden Im Rahmen der Implementierung erfolgt die Erstellung eines Funktions Prototypen damit f r das Konfigurationsmanagement bereits ein Modul we
129. rarbeitung von Kontrollfll issn wird in den sogenannten Kontrollspezifikationen beschrieben 5 1 Kontrollflu diagramme Ein Kontrollflu Diagramm CFD enth lt Prozesse Kontrollfl sse e Speicher e Kontrollspezifikationen C Spec Die Prozesse sind identisch mit denen in den DFDs d h sie tragen auch gleiche Namen und gleiche Nummern Kontrollfl sse werden grafisch durch gestrichelte Pfeile dargestellt Speicher k nnen neben Verarbeitungsdaten nun auch Steuerdaten aus Kontrollfl ssen aufnehmen und speichern Kontrollspezifikationen sind neu und werden grafisch durch einen dicken Balken Bar Barren dargestellt 5 1 Ein CFD kann somit durchaus isolierte Prozesse enthalten zu denen es weder ein noch ausfliessende Kontrollfl sse gibt Denn auch wenn ein Proze nur datenfluss relevant ist mu er ins CFD bernommen werden Auf der anderen Seite k nnte er durch eine Kontrollspezifikation gesteuert werden was auch im Diagramm nicht sichtbar ist und weiter unten erl utert wird 5 1 1 Einfaches Beispiel ToDo 5 1 2 Kontrollfl sse und ihre Verarbeitung Kontrollfl sse treten zwar als Ein Ausgangsgr en von Prozessen auf werden jedoch nicht von ihnen verarbeitet sondern lediglich weitergereicht Kontrollfl sse werden einzig und allein in den Kontroll oder Steuerprozessen verarbeitet die durch einen Barren im Diagramm repr sentiert werden Der Begriff Proze wird jedoch f r die Barren selten verwendet gel
130. rechtigter Unterschrift Hinweis Pf heft ist juristische Grundlage f r den Vertrag bzw ist der Vertrag II Pf heft darf nur in beiderseitigem Einverst ndnis ver ndert werden 9 2 Inhaltsverzeichnis S 3 1 Allgemeine Beschreibung der Aufgabe Verbale Zusammenfassung Kurzform max 1 2 1 A 4 S 4 ff 2 Genaue Beschreibung der Aufgabe ist der Hauptteil zu realisierende Teilaufgaben und Zusammenhang Umfang Betriebsmodi Fenster Darstellung Ein Ausgabe auch was nicht mehr dazu geh rt Beschreibung der Aufgabe nicht der L sung per SA SA RT IM bzw Objekt Orient Analyse evtl Aufz hlung der Funktionen Betriebsarten Eingabe m glichkeiten und deren Wirkung aus Anwendersicht 2 1 Funktion1 Betriebsart1 Ein Ausgabe1 genau erl utern 2 2 Funktion2 Betriebsart2 Ein Ausgabe2 genau erl utern 3 8 3 Voraussetzungen beim Kunden 3 1 Systemumgebung BS HW SW Voraussetzungen Leistung Sicherheit Speicher Platte notwendige SW Tools GUI Aufl sung Bildschirm Anzahl Farben vorhandene Bibliothek Schnittstellen Compiler B SQL Datenbank oder sonstige Schnittstellen LAN TCP IP Novell Leistung Belastung evtl bekannte Probleme mit anderer SW 3 2 Noch vom Kunden zu erbringende Leistungen Datenbest nde Hardware Ausbau Infrastruktur Notstrom hinreichend L ftung K hlung Anschl sse Adressen Kennungen Datenerf
131. rne Funktionen implementiert sind und wie sie sich verhalten Ohne Kapselung sind alle Daten global verf gbar und es kann auf jedes Statement im Code direkt zugegriffen werden Mit Kapselung ist der Zugriff nur auf solche Objekte erlaubt die explizit zug nglich gemacht wurden Man erreicht damit eine h here Flexibilit t innerhalb einer gekapselten Einheit und erzielt eine strenge Zugriffskontrolle auf die gekapselte Einheit von au erhalb Kapselung ist die Kombination aus Information Hiding und Black Boxes 6 7 5 Anwendung Transformation eines SA Modells Unter Beachtung dieser Designkonzepte k nnen einige Transformationsregeln aufgestellt werden mit deren Hilfe Modelle der SA in einen modularen Entwurf berf hrt werden k nnen Voraussetzung ist allerdings dass ein entsprechendes Realisierungsmodell angestrebt wird in diesem Falle das einer prozeduralen Programmiersprache e Das Kontextdiagramm wird in das Hauptprogramm transformiert e Jedes andere DFD wird zu einem Modul mit einer Exportfunktion e Verfeinerte Knoten Sohnknoten werden zu Importfunktionen im Modul zum Vaterdiagramm e Basisknoten nicht weiter verfeinerte Knoten werden zu internen Funktionen des Moduls der ihrem Diagramm zugeordnet ist e Aus Speichern werden Moduln mit vier Exportfunktionen Create Read Update und Delete e Die Definition eines Speichers wird zu einem Exportdatentyp w hrend der Speicher selbst ein internes Datum des Moduls wird e
132. rschiedenen Teilsystemen Sie liegt vor wenn die Teilsysteme kombiniert verwendet werden k nnen Beispiele e Verschiedene Compiler Pascal C Fortran haben das gleiche Object Format d h Linker kann alle Module zusammenbinden e CAD Programme haben gleiches File Format e Maus Treiber ist kompatibel mit Druckertreiber sie tun sich nichts Man spricht aber auch von Kompatibilit t bzgl Softwareergonomie 1 Im Bereich Grafical User Interfaces GUls regelt eine Gestaltungsanleitung Style Guide das Aussehen einer Motif Applikation damit hat man prinzipiell hnliche Benutzerf hrung gleich strukturierte Kommandos und Unter Men s Datei Bearbeiten Bes 2 Dialog zum Ausdrucken von Files M chten Sie sofort drucken oder im Hintergrund j n j Auf welcher Schnittstelle m chten Sie drucken 1 COM 1 2 COM2 3 LPT1 4 in ein File Bitte Nr 1 bis 4 eingeben 3 Wieviele Exemplare sollen gedruckt werden Bitte Anzahl 1 bis eingeben 1 7 10 7 3 5 Zuverl ssigkeit Zuverl ssigkeit ist ein statistisches Ma f r das Verhalten eines Softwareprodukts unter einer gewissen Last Auftragsspektrum Ein System hei t zuverl ssig wenn gemittelt ber ein Lastspektrum eine hohe Wahrscheinlichkeit f r die befriedigende Ausf hrung von Auftr gen besteht Ein Auftragsspektrum ist eine Gewichtung der Auftr ge nach bestimmten Erfordernissen z B H ufigkeit der Verwendung eine
133. rste Form hei t ET mit festen Zellenwerten die zweite Form hei t ET mit beliebigen Zellenwerten Das obige Beispiel kann als ET mit beliebigen Zellenwerten so formuliert werden Algorithmus Regeln Kundenbetreuung BestellWert BW gt 20000 kein Alkohol Gl ckwunschkarte Weinpr sent Buchpr sent pers nl Anruf 5 9 5 4 Zustands bergangsautomaten Das Verhalten von dynamischen Systemen kann durch Ereignisse ge ndert werden Als Folge eines Ereignisses kann ein System in einen anderen Zustand Betriebsart Modus wechseln Zur Modellierung solcher Systeme dienen dienen die Zustands bergangsautomaten Sequentielle Automaten Es wird ein endlicher Automat beschrieben der aus verschiedenen Zust nden States besteht Zu jedem Zeitpunkt befindet sich der Automat in genau einem Zustand Aufgrund von externen Signalen Events werden Zustands berg nge Transitions ausgef hrt und dabei Aktionen Actions ausgel st Die Reaktion auf ein Ereignis h ngt dabei davon ab in welchem Zustand sich das System befindet Sequentielle Automaten haben also ein Ged chtnis Ein Zustand resultiert e weil das System darauf wartet dass im externen Umfeld etwas geschieht Warten auf ein Ereignis oder e weil das System darauf wartet dass eine T tigkeit durch eine andere abgel st wird Beispiel waschen mischen f llen Beispiele f r solche Zustands nderungen sind e Das System geht in eine andere Bearbeitungsphas
134. rtig sind sondern schrittweise testen und integrieren da sonst Komplexit t zu gro halten C42a 2 2 1 2 2 4 Testdate 3 4 2 3 1 6 1 2 0 4 gt gt PRO PD 018 oO O O OVUI OPR 7Z 0 0 o wo 1 _ Ergebnis Seitenl soll gt 0 Seitenl soll gt 0 Seitenl soll gt 0 kein Dreieck kein Dreieck kein Dreieck halten gleichschenklig gleichschenklig gleichschenklig ungleichseitig gleichseitig gleichschenklig gleichschenklig 8 12 8 5 Psychologie des Testens Es handelt sich beim Testen um die berpr fung von bereits konkret erstellten Programmen Modulen nicht um die berpr fung von abstrakten Algorithmen Testen beinhaltet eine Beurteilung des Testobjekts Arbeit des Autors und damit indirekt eine Bewertung der intellektuellen Arbeit des Autors Bei der Bewertung von Programmen handelt es sich somit vermeintlich um die Bewertung einer intellektuellen Leistungsf higkeit des Autors Aber 1 Die Bewertung anderer menschlicher Gr en physischer wie z B Hochsprung ist weit weniger emotional vorbelastet als diese 2 Auch ein erstklassiger Programmierer wird wenn er unter starkem Zeitdruck steht gro e private Probleme hat t glich um seinen Arbeitsplatz f rchten mu kaum gute oder gar fehlerfreie Programme schreiben Notwendig ist daher ein partnerschaftliches Verh ltnis zwischen Autor und Tester n mit der berzeugung
135. s berschrift den Namen oder die Nummer eines Prozesses aus dem gleichen Diagramm tragen e In der letzten Gruppe der Ausgabegruppe sind die Ausgangssignale des Barrens spaltenweise aufgelistet Jede dieser Spalten muss als berschrift den Namen eines Kontrollflusses tragen Diese Gruppe ist optional In einer ProzeB aktivierungstabelle bedeuten auf der Proze seite 1 Proze aktivieren 1 Proze deaktivieren 0 keine Anderung des Zustandes Es k nnen durch ein Eingangssignal mehrere Prozesse aktiviert oder deaktiviert werden Spielt die Reihenfolge der De Aktivierung eine Rolle dann wird dies durch entsprechende Zahlenwerte 1 2 3 bzw 1 2 3 usw ausgedr ckt Spielt die Reihenfolge keine Rolle und sind keine Deaktivierungen vorzunehmen dann wird statt einer 1 manchmal auch ein X in die Tabelle eingetragen Statt einer O ist manchmal auch ein oder ein leerer Eintrag zu finden Diese Schreibweise wird auch in der Ausgabegruppe verwendet Generell k nnen von einer PAT nur die Prozesse gesteuert werden die sich mit dem Barren zu dem die PAT geh rt im selben Diagramm befinden Prozesse die von der Kontrollverarbeitung nicht betroffen sind brauchen nat rlich auch nicht in der PAT aufgef hrt werden 5 5 1 Proze aktivierung und Proze deaktivierung Im Rahmen der SA z ndet jeder Proze sofort wenn seine Eingaben bereit stehen Eine Deaktivierung ist im Rahmen der SA nicht m glich Erh lt ein Proze
136. s Auftrags Selten verwendete Funktionen erhalten geringes Gewicht Auswirkung bei einer fehlerhaften Ausf hrung des Auftrags Lebensnotwendige Funktionen m ssen totsicher sein Es werden alle Eigenschaften zusammengefa t welche die Fehlersicherheit des Programms beeinflussen Dazu geh ren e Sicherheit gegen interne Fehler im Programm II Korrektheit e Nicht jede St rung darf zum Gesamtausfall f hren TI Ausfallsicherheit e Auftretende Fehler kompensieren n tzliche Redundanz II Fehlertoleranz e Bedienfehler darf nicht zum Gesamtausfall f hren II Robustheit Die Zuverl ssigkeit setzt sich also zusammen aus den Faktoren Korrektheit Ausfallsicherheit Fehlertoleranz und Robustheit Man beachte den Unterschied zwischen Zuverl ssigkeit und Korrektheit Ein System kann zuverl ssig sein obwohl es Fehler aufweist Voraussetzung ist nur da e die Fehler das System nicht unbenutzbar machen e die Fehler nur selten auftreten e die Fehler nicht in F llen auftreten in denen das System dringend gebraucht wird bzw eben unter keinen Umst nden ausfallen darf Umgekehrt kann ein korrektes System unzuverl ssig sein Dies ist z B dann der Fall wenn e die Spezifikation der Aufgabenstellung nicht vollst ndig bzw widerspr chlich ist e durch schlechte Bedienerf hrung h ufig Fehleingaben vorkommen vielleicht sogar Fehleingaben unbeabsichtigt provoziert werden Benutzer machen in der Bedienung erfahrungsgem Fehler
137. s wird mit Namen versehen und ins Data Dictionary DD aufgenommen kaltes_Wasser kaltes_Wasser Filtert ten Kaffeepulver Filtert ten Kaffee Kaffee verbr Filter Kaffeepulver verbr Filter Dann Verfeinerung der Aktion Kaffeekochen Knoten 3 4 kaltes_Wasse l Kaffee Filtert ten Kaffeepulver verbr Filter 4 22 Funktionsorientierter Ansatz Zuerst werden die Aktionen und T tigkeiten Funktionen zusammengestellt entsprechende Fragen welche Aktionen Handlungen Prozesse treten im System auf asser Wasser kochen kochen 1 Kaffee i aufbr hen Filter vorbereiten Kaffee aufbr hen Das Datenflu diagramm entsteht durch die Verbindung der Funktionen durch geeignete Daten Materialfl sse Ereignisorientierter Ansatz Der ereignisorientierte Ansatz kann erst mit den Mitteln von SA RT durchgef hrt werden die im n chsten Kapitel vorgestellt werden 4 23 4 8 Teilschritte der Strukturierten Analyse Tom DeMarco DeM 79 unterscheidet sieben Teilschritte der strukturierten Analyse 1 Istanalyse Das bereits vorliegende alte System bildet die Grundlage f r ein neues Darum Istzustand analysieren und als physischen Istzustand in einem DFD festhalten Bestellung Packzettel Order Bestellungen Rohrpost Problem Nicht algorithmisch denken und Ideen festhalten d h wie also die Daten in einem Proze ver ndert werden sondern nur deklarative Spezifikation aus
138. soweit nicht unvermeidbar z B eigene Ausstattung Infrastruktur interne Personal Urlaubsplanung wann wer was macht interne Stundens tze Gemeinkosten Gewinn 3 6 Zusammenfassung Zur Darstellung von Daten und Abl ufen gibt es eine Vielzahl von Modellen und Beschreibungsverfahren die f r die unterschiedlichen Phasen geeignet sind z B Jackson Diagramme HIPO Charts Warnier Orr Diagramme Wir werden uns mit den folgenden Beschreibungsverfahren besch ftigen Strukturierte Analyse SA Tom De Marco Ward Mellor Realzeit Modellierung SA RT Hatley Pirbhai Informations Modellierung IM Chen ER Modell per Data Dictionary DD Bestandteil von SA bzw SA RT 3 11 4 Strukturierte Analyse Mit Hilfe der Strukturierten Analyse Structured Analysis SA lassen sich logische Systemmodelle konstruieren Der Begriff System kommt aus dem Griechischen und bedeutet ein geordnetes Ganzes oder gegliederte Vereinigung von Teilen Bereits an dieser Definition l t sich erkennen dass darunter viel mehr zu verstehen ist als nur ein Software System Mit Strukturierter Analyse lassen sich zumindest all die Systeme modellieren die ein deterministisches Verhalten zeigen Modelle liefern keine exakte Abbilder der Wirklichkeit sondern eine vereinfachte Darstellung der Funktion eines Gegenstandes oder des Ablaufs eines Prozesses die eine Untersuchung oder Erfiorschung erleichtert oder erst m gli
139. stellen zwischen den Black Boxes soll minimal sein e Die Schnittstellen sollen einfach sein Die Vorteile die sich daraus erzielen lassen sind dass Black Boxes einfach zu konstruieren einfach zu verstehen einfach zu testen einfach zu korrigieren zu modifizieren kurz einfach zu warten sind Das Black Box Prinzip ist unterst tzt also in grundlegender Weise die f r den Entwurf gesetzten Ziele 6 7 2 Das Lokalit tsprinzip Lokalit t bedeutet dass inhaltlich zusammengeh rige Entwurfsentscheidungen auch im Modell eng benachbart sind Entwurfsentscheidungen die nichts miteinander zu tun haben werden auch getrennt abgelegt Damit das Lokalit tsprinzip gewahrt bleibt sind auch ein paar physikalische Regeln f r das Modell zu beachten 6 23 e Alle Dokumente sollen kleiner sein als eine DIN A4 Seite e Es sollen nur 5 2 Elemente auf einer Seite bzw in einem Diagramm enthalten sein Module sollen zusammengeh rende Funktionen zusammenfassen und nicht zusammengeh rende trennen 6 7 3 Das Geheimnisprinzip W hrend das Lokalit tsprinzip sagt dass jede wichtige Entwurfsentscheidung an genau einer Stelle durchgef hrt werden soll sagt nun das Gehimnisprinzip dass diese Entscheidung auch von seiner Umgebung verborgen werden soll Es muss nicht jeder ber alles informiert sein Man unterscheidet zwischen Information Hiding logisch und Implementation Hiding physikalisch Alles was ein Entwickler verbergen
140. t Die Komponenten k nnen nur ber die hierarchische Struktur miteinander kommunizieren Die Komponenten werden vom n chst h heren Level gesteuert sie h ngen von einander ab Software Systeme m ssen nicht eindeutig netzwerkartig oder hierarchisch strukturiert sein Netzwerkartige Strukturen findet man beispielsweise in Client Server Architekturen oder immer dann wenn ein System auch physikalisch auf mehreren Rechnern verteilt ist In diesem Falle kann es dann so sein dass die einzelnen Komponenten eines Netzwerks beispielsweise der Client und der Server in sich wieder hierarchisch aufgebaut sind D h also dass Netzwerk und Hierarchie zusammen vorkommen k nnen Wir werden uns im Folgenden haupts chlich mit Hierarchien besch ftigen Im wesentlichen geht es beim Design um zwei Hierarchien Zusammengesetzt Aus Hierarchie Composed Of Benutzt Hierarchie Use Netzwerke lassen wir unber cksichtigt weil sie wie oben angedeutet meist dazu verwendet werden gr ere Systeme auch physikalisch zu verteilen und wir uns zuerst einmal mit den grundlegenden Methoden f r kleinere Systeme vertraut machen wollen 6 3 1 Composed Of Hierarchie In einer Composed Of Hierarchie wird dargestellt aus welchen Einzelteilen sich ein gr eres Ganzes zusammensetzt Beispiel Fahrgestell 6 9 Eine Composed Of Hierarchie wird aus zwei wesentlichen Gr nden eingef hrt e Abstraktion um die Komplexit t zu verringern und Komponenten e
141. t die Ausgabe von der gegenw rtigen Eingabe und von den vorangegangenen Systemzust nden ab Sie k nnen mit Hilfe von Zustands bergangsdiagrammen dargestellt werden 5 4 Neben einer textuellen Beschreibung stehen f r Kontrollspezifikationen C Spec folgende Darstellungen zur Verf gung e Logische Funktionen in Form von Entscheidungstabellen ET e Endliche Automaten dargestellt durch Zustands bergangs diagramme RT Diagramme RTD Definition der Aktionslogik in Form von Proze aktivierungstabellen PAT Auch die Proze aktivierungstabellen basieren letztendlich auf kombinatorischen Automaten Sie sind also mit Entscheidungstabellen verwandt haben aber eine etwas andere Darstellungsform 5 2 2 Kombinationsm glichkeiten Die drei zuletzt genannten Komponenten k nnen zusammen oder einzeln verwendet werden Bei einer gemeinsamen Verwendung sind die Komponenten miteinander verkn pft So k nnen die Ausg ngen einer ET Eing nge im RT Diagramm oder der PAT sein Ebenso k nnen die Aktionen des RT Diagramms in der PAT definiert werden Die m glichen Zusammenh nge zwischen den Komponenten untereinander zeigt die folgende Abbildung eingehende Kontrollfl sse RG PAT ausgehende Kontrollfl sse und Aktivierungen Das hei t Die C Spec Eingaben werden an Entscheidungstabellen bergeben Kombinationen von Eingaben wirken als Ereignisse Die Zustands bergangsdiagramme erzeugen dann als Folge dieser Ereig
142. t werden die sogenannten Literals Primitive Typen k nnen nicht weiter verfeinert werden Sie k nnen beispielsweise repr sentieren diskrete Daten 4 17 mit Wertebereich true false oder rot gr n kontinuierliche Daten falls aus Kontext dann oft mit Bereich 5 bis 20 C Jeder im Data Dictionary definierte Typ soll wenn auch ber mehrere Ebenen hinweg letztlich aus Literals zusammengesetzt sein Ein Eintrag im Data Dictionary hei t Typdefinition type definition Ein solcher Eintrag erfolgt in einer Form die an die Erweiterte Backus Naur Form EBNF angelehnt ist lt Name des DD Eintrags gt lt Datendefinition gt hei t hier besteht aus den Komponenten lt Datendefinition gt beschreibt den Aufbau per Symbol Semantik Ar terminaler Datenwert z B TRUE gelb Sequenz von Objekten optional vorhandener Teil entspricht 1 alb Alternative entweder a oder b auch mehr als 2 u o Wiederholung min u mal bis max o mal Eine Sequenz sequence gestattet es einen Typ aus mehreren Komponenten verschiedener Typen zusammenzusetzen Eckige Klammern um eine Aufz hlung enumeration von Typen kennzeichnen eine Alternative Die einzelnen Alternativen die aufgez hlt werden werden durch einen senkrechten Strich getrennt Jedes Objekt des definierten Typs enth lt eine Komponente eines beliebig ausgew hlten Typs der Aufz hlung Ein Typname in runden Klammern innerha
143. t werden um sicherzustellen dass keine Seiteneffekte aufgetreten sind e Fehler in einer Funktion treten in der Regel an ganz anderen Stellen im System zu Tage und erschweren damit ebenfalls die Wartung Wenn Funktionen beispielsweise aus Effizienzgr nden nicht ber Parameter kommunizieren sollen sondern global gekoppelt sein sollen dann sollte man wenigstens alle Funktionen die den globalen Datenbereich nutzen in einem Modul zusammenfassen und den globalen Datenbereich in diesem Modul verbergen sodass er au erhalb nicht mehr zugreifbar ist Dadurch werden einige der vorherigen Argumente entkr ftet das Lokalit tsprinzip und das Kapselungsprinzip bleiben gewahrt Inhalts Kopplung ist eine Kopplungsart die unbedingt vermieden werden muss Man versteht darunter dass sich eine Funktion auf die interne Struktur einer anderen Funktion bezieht beispielsweise dass eine Funktion eine Anweisung einer anderen 6 31 Funktion ndert sich auf interne Daten einer anderen Funktion bezieht oder mitten in eine andere Funktion verzweigt Man nennt diese Art der Kopplung auch pathologisch Die meisten heutigen Programmiersprachen lassen diese Art der Kopplung auch gar nicht mehr zu In Assembler sind solche Kopplungsarten allerdings durchaus m glich ebenso bei Programmiersprachen die sich selbst modifizierende Programme erlauben Zusammenfassend l t sich sagen e Je loser die Kopplung zweier Funktionen desto unabh ngiger sind sie e
144. tet das bekannte Testen von Programmen Ersch pfende Tests sind in der Praxis nicht m glich darum ist die zentrale Frage Welche Untermenge aller denkbaren Testf lle bietet die gr te Wahrscheinlichkeit m glichst viele Fehler zu finden Hierzu helfen uns die Methoden des systematischen Testens bei denen Testdaten ber Grenzwertanalyse Aquivalenzklassenbildung und durch Erfassung aller 8 7 m glichen Codesequenzen bestimmt werden Daneben gibt es auch weniger systematische Methoden wie Anwendertestf lle Vom Personenkreis der k nftigen Anwender wird eine Menge von typischen Eingabedatens tzen erstellt welche m glichst realistischen Ursprungs sind e Testen mit automatisch erzeugten Zufallszahlen Einfachste und schw chste Methode weil Testf lle leicht zu generieren sind aber die Chance eine optimale Untermenge zu finden sehr gering ist e Fehlererwartung Aus der Praxis gewonnene Informationen ber besonders fehlertr chtige Situationen siehe dazu auch die Liste von typischen Fehlern weiter oben Verarbeitung von Wert 0 Leer F llzeichen Blanc Tab Newline L nge von String 0 leerer String Probleme bei Datumsarithmetik Tages Monats Jahreswechsel berlauf von Zwischenpuffern m gliche Rundungsfehler Vertauschung der Eingabereihenfolge 8 4 1 Testmethoden Man unterscheidet im wesentlichen zwischen den sogenannten Blackbox und Whitebox Tests Kennzeichnend f r Blackbox Tests
145. truktur und ihre Bedeutung verdeutlicht 4 27 5 Die Methode SA RT Die Ideen der SA sind aus den Erfahrungen bei der Analyse von kommerziellen Systemen wie Banken Versicherungen Buchungssystemen hervorgegangen DFD beschreibt darum in der SA die Zusammenh nge eines Systems nur funktional d h insbesondere mehr oder weniger statisch Jeder Knoten symbolisiert eine Aktion oder Handlung welche einen Eingabestrom in einen Ausgabestrom umwandelt F r den genauen Zeitpunkt zu dem eine Umwandlung stattfinden soll die Zeit welche zur Bearbeitung ben tigt wird oder f r die Reihenfolge in der Aktionen ausgef hrt werden sollen gibt es keinerlei Hinweise im DFD Vergleich mit Schaltnetz in der Elektronik jedoch kommen im DFD auch R ckkopplungen vor Oftmals ist es jedoch notwendig auch diese Zusammenh nge in einem hnlich einfachen Diagramm beschreiben zu k nnen Dazu wurde SA erweitert Die erweiterte Methode SA RT unterst tzt die ereignisgesteuerte Vorgehensweise Damit k nnen Echtzeitsysteme mit Zeitabh ngigkeiten vordefinierten Antwortzeiten oder Ereignisabh ngigkeiten modelliert werden Die in der Anforderungsanalyse bzw Sollspezifikation von DeMarco eingesetzten DFD P Spec und Eintr ge im DD wurden erweitert um ereignisgesteuerte Probleme zu beschreiben Hatley und Pirbhai HaP88 erweiterten das DFD um zus tzliche Komponenten die es erlauben Kontrollfl sse Control Flow CF zu beschreiben Die Ve
146. ttels Datenkopplung verbunden wenn die eine Funktion die andere aufruft und die Kommunikation zwischen ihnen durch Datenparameter erfolgt Datenkopplung stellt damit die notwendige Kommunikation zwischen Funktionen dar und ist daher unvermeidbar Trotzdem sollte sie auf ein Minimum reduziert werden Die Verwendung von Datenkopplung ist keine Garantie f r einen guten Entwurf Beispielsweise sollte die Datenwanderung vermieden werden bei der Daten ohne Benutzung durch Funktionen hindurchwandern X i N x ae A x Zwei Funktionen sind durch Datenstrukturkopplung verbunden wenn sie mit mindestens einem Element aus einer Datenstruktur Feld Record miteinander kummunizieren Bei hoher Datenkopplung ist eine sinnvolle Zusammenfassung zu einer Datenstruktur eine gute Anwendung von Datenstrukturkopplung 6 29 Man sollte allerdings nicht einfach nur Daten die nichts miteinander zu tun haben in einer Datenstruktur zusammenfassen um damit die Schnittstellenbandbreite zu verringern www 888 v 1 ABCDE GH I ZUTUN GETAN ZUTUN A B C D E GETAN G H I Datenstrukturkopplung sollte vermieden werden wenn es m glich ist mit einer berschaubaren Menge von Datenkopplungen auszukommen Dazu werden folgende Alternativen betrachtet User RN Old NV Info Password Password Password New Invalid New Invalid Password Password Password Password Bei der Datenstrukturkopplung k nnen folgende Probleme auftreten 1 2 3 E
147. uen Produktvorschl gen oder verbesserungen sowie effizienteren L sungen gegeben werden Dies sind dann jedoch neue Projekte und haben mit der aktuellen Aufgabe nichts gemein Sie k nnen evtl im Rahmen von Vorlaufforschung Entwicklung als interne Projekte definiert werden In der Planung mu genau zwischen einem Forschungs und einem Entwicklungs oder Kundenprojekt unterschieden werden Hierzu m ssen bereits Methoden zur Erf llung aller Teilziele verhanden sein Bei Forschungsprojekten sollen oftmals gerade diese Methoden erst gefunden bzw ausgearbeitet werden Naturgem kann man hier nicht garantieren da das Ziel auch tats chlich mit den gegebenen Mitteln Zeit Aufwand erreicht wird Bei der Planung eines Entwicklungsprojektes werden alle ben tigten Ressourcen quantitativ und zeitlich m glichst genau eingeplant Betriebsmittel e Netzwerkkomponenten e Rechner Rechenzeit Speicherplatz e Spezialperipherie wie Plotter Scanner Fotobelichter e Entwicklungswerkzeuge wie Emulatoren Analysatoren e die Beschaffung und Lieferung von Teilen Bauelemente Spezialkomponenten Sensoren Aktoren in der PDV e Software Produkte Lizenzen f r Compiler Tools e Beschreibungen und Manuals e Erwerb von evtl noch nicht vorhandenen Wissen e Einplanung finanzieller Mittel 3 5 Mitarbeiter Kapazit tsplanung e Informatiker f r Grob Feinentwurf Programmierer f r einfache Codier
148. uls ist das Modul selber und alle seine untergeordneten Moduln e Im Scope of Effect eines Moduls liegen alle Moduln die von einer nderung einer Entwurfsentscheidung im Modul betroffen sind Die Modulhierarchie sollte so aufgebaut sein dass jede Entscheidung eines Moduls nur sich selbst und seine untergeordneten Moduln betrifft Lokalit tsprinzip und Geheimnisprinzip verbunden mit dem Scoping Wenn dem so ist dann liegt der Scope of Effect eines Moduls in seinem Scope of Control Genau das ist das Ziel im Design das an folgendem Bild schematisch dargestellt wird Scope of Control Scope of Effect 6 38 Der Scope of Effect eines Moduls sollte also eine Untermenge seines Scope of Control sein 6 8 8 Zusammenfassung Die beiden wichtigsten Kriterien f r die Bewertung eines Entwurfs sind die Kopplung und der Zusammenhalt Sie k nnen auf alle Designelemente also Operationen Moduln und Packages angewandt werden Diese Ziele werden unterst tzt durch den Einsatz von Faktorisierung Begrenzung des Scope of Effects auf den Scope of Control Vermeidung von zu gro em Fan Out und Verbesserung des Fan In Voraussetzung selbst bei kleinen SW Projekten ist stets Mindestens eine weitere Person sollte den Entwurf wirklich verstehen und ihn f r korrekt halten 6 39 7 Implementierung 7 1 Vom Entwurf zum Programm Aus der Entwurfsphase liegt die Dekomposition der Probleml sung in Form einer Anzahl von Modulspezifikationen vo
149. ung der Sitzung Anfertigung von Protokoll mit Fehlerliste e Autor e Designer Entwurf des Moduls e Testspezialist Rechtzeitig vor der Inspektionssitzung m ssen Spezifikation und Listing verteilt werden Die Teilnehmer m ssen sich vorher mit dem Stoff auseinandergesetzt haben Das Vorgehen w hrend der Sitzung e Autor erkl rt die Programmlogik Anweisung f r Anweisung e Entstehende Fragen werden vom Team verfolgt und beantwortet Die Erfahrung zeigt da dabei viele Fehler vom Autor selbst w hrend des Vortragens erkannt werden e Das Programm wird mit Hilfe einer Checkliste h ufig auftretender Fehler analysiert Die Dauer einer Sitzung betr gt zwischen 90 120 Min Auch hier gilt Die Beseitigung von Fehlern ist nicht Gegenstand der Sitzung Werden grobe weitreichende oder viele Fehler entdeckt so ist die Sitzung zu einem sp teren Termin mit einer berichtigten Version zu wiederholen Die Liste der entdeckten Fehler dient gleichzeitig der berarbeitung der Checkliste und damit auch der Verbesserung k nftiger Inspektionen Weitere Effekte von Walkthrough und Inspektion Programmierer erkennt eigene Fehler und lernt hoffentlich daraus Erfahrung Programmiierstil anderer kann bertragen werden Progammdokumentation kann berpr ft berichtigt verbessert werden 8 6 8 3 4 Liste der h ufigsten Fehler Hier nun noch die Liste der Fragen die auf die h ufigsten Fehler hinf hren Ist jede Variable
150. ung der Programmiersprache Logische Fehler wie z B angewandtes vor definierendem Auftreten von Variablen Schleifenbedingung ist keine Funktion des Schleifenrumpfes au er bei Proze datenverarbeitung Ziel ist klar aber Denkfehler bei der Realisierung Funktionale Fehler wie z B Divergenz zwischen Spezifikation und realisierter Funktion Bereits die Annahme ber das Ziel ist falsch Ziel wurde falsch ungenau spezifiziert Ziel Spezifikation wurde vom Programmierer falsch interpretiert 8 2 Entsprechend werden Fehler zu unterschiedlichen Zeitpunkten entdeckt bersetzung Test Abnahme Fehler lassen sich auch aus der Sicht eines bersetzers klassifizieren Lexikalische Fehler wie z B Zeichen entsprechen nicht dem Alphabet der Sprache k reservierte W rter falsch geschrieben Syntaxfehler wie z B falsche Programmiersprachenkonstrukte bzw reservierte W rter an falscher Position im Text d h Programm l t sich nicht aus Syntaxdiagrammen ableiten Fehler der statischen Semantik Verwendung nicht vereinbarter Objekte z B Variablen Zuweisung ungleicher Datentypen angewandtes vor definierendem Auftreten einer Variablen Fehler der dynamischen Semantik Division durch Null ung ltiger Pointer nicht terminierende Schleife Rekursion Formale Fehler k nnen von einem bersetzer sofort erkannt werden bzw k nnen durch Hinzuf gen von zus tzlichem Programmcode gez
151. ung von CASE Tool Pro Mod Hatley D J Pirbhai I A Stategies for Real Time System Specification Dorset House Publ Co New York 1988 Myers Glenford J The Art of Software Testing John Wiley amp Sons 1979 Methodisches Testen von Programmen dt Ubersetzung von Dr M Pieper 4 Aufl R Oldenbourg Verlag 1991 Ott Hans J rgen Software Systementwicklung Praxisorientierte Verfahren und Methoden Hanser Verlag M nchen Wien 1991 10 1 Ros 77 Ross D T Structured Analysis for requirements definition IEEE Tansactions on Software Engineering 3 1 1977 S 6 15 Ros 77a Ross D T Rot 93 Sch 90 Som 92 War 85 Wie 90 You 79 You 89 Structured Analysis SA A Language for Communicating Ideas IEEE Tansactions on Software Engineering 3 1 1977 S 16 34 Rothery Brian Der Leitfaden zur ISO 9000 mit QM Musterhandbuch und Erl uterungen dt bersetzung Michael Preising Hanser Verlag M nchen Wien 1994 Sch nthaler F Ne meth T Software Entwicklungswerkzeuge Methodische Grundlagen B G Teubner Stuttgart 1990 350 S Sommerville lan Software Engineering 4 ed Wokingham Engl u a Addison Wesley 1992 649 S Ward P Mellor S Structured Techniques for Real Time Systems Yourdon Press Prentice Hall New York 1985 Wieken John Harry Software Produktion Ziele Vorgehensweisen Werkzeuge Mc Graw Hill Book Company GmbH Hamburg
152. ungen durchf hrt Parallel dazu werden in der Entwurfsphase die Datenstrukturen die im Data Dictionary beschrieben sind weiter verfeinert Die Mittel dazu bietet das Data Dictionary durch die Notation Darauf wird hier nicht mehr eingegangen Der bergang von der SA zum SD bedeutet dass das Systemmodell serialisiert werden muss In der Analyse wurde ein implementationsfreies Modell des Systems erstellt in dem parallele Prozesse nach dem Datenflussprinzip miteinander kommunizieren D h es werden nur Nachrichten versandt was mit diesen geschieht interessiert den Absender nur wenig Das Designmodell ist an eine bestimmte Implementierungstechnologie gebunden Eine solche Technologie kann selbstverst ndlich auch eine Parallelit t erm glichen aber hier herrscht nun das Auftragsprinzip n mlich dass Auftr ge erteilt werden und Antworten Quittungen Ausk nfte Fehlermeldungen oder sonstige Reaktionen gefordert werden Letztendlich muss das Designmodell ber cksichtigen dass auf einer von Neumann Architektur wie sie heute blich ist alle Programmbefehle sequentiell abgearbeitet werden und damit eine feste Reihenfolge der einzelnen Prozesse auf einer Maschine zwingend ist 6 1 3 Ziele des Entwurfs Warum braucht man aber berhaupt die Entwurfsphase Warum kann man nicht gleich das Analysemodell implementieren Der Unterschied zwischen Analyse und Design besteht weil e die verwendete Technologie zu komplex ist e die Technologie
153. ungsarbeit e Spezialisten f r unterschiedliche Bereiche Betriebssystemangelegenheiten DTP Oberfl chen Datenbankanwendungen PDV Bereich Kommunikation e Spezialisten aus den Anwendungsbereichen z B Chemie Masch Bau Fertigungstechnik Auch auf der Seite des Anwenders m ssen ggf Ma nahmen eingeplant werden e Infrastrukturma nahmen e interne Vorbereitungen f r eine Umstellung von Abl ufen e Schulungsma nahmen In der Regel werden hierbei un bersichtlich viele Einzelaktivit ten von einem Team parallel ausgef hrt Die exakte Planung aller Aktivit ten Termine Meilensteine die Personaldisposition usw erfolgen insbesondere unter Ber cksichtigung des Faktors Zeit mit geeigneter Rechnerunterst tzung Hierbei werden die meisten Termine und insbesondere auch zeit kritische Wege innerhalb von Projekten ermittelt bzw erkannt Netzplanprogramme mit Kapazit ts und Ressourcen Management beispielsweise MS Project Genauso wichtig wie die Planung ist auch die Projektkontrolle durch die berpr fung des tats chlichen aktuellen Projektstandes Projektverfolgung und die berpr fung der Qualit t der erzeugten Produkte Qualit tskontrolle Erst eine m glichst exakte Projektverfolgung und ein damit m gliches fr hzeitiges Einlenken bei Problemen sichert das Erreichen der spezifizierten Projektziele 3 6 3 5 Pflichtenheft Das Ergebnis der Problemanalyse und darin insbesondere der Sollanalyse ist die Pr
154. unterschiedliche Anzahl von Zyklen ben tigen Da exakte Gr en nur von untergeordneter Bedeutung sind beschr nkt man sich bei der Absch tzung des Aufwands obere Grenze auf den Gro O Kalk l Ist die Laufzeit I k f r alle Eingaben der Gr e L nge k bis auf einen konstanten Faktor C4 und einen Absolutbetrag Co gleich so spricht man von einer linearen Laufzeit I k C14 k Co O k Entsprechend spricht man von einer quadratischen Laufzeit bei I k C2 k2 O k2 polynomiellen Laufzeit bei I k Cn Kn C0 O kN der Ordnung n exponentiellen Laufzeit bei I k c 2PM o 2P K p h chstens Polynom logarithmischen Laufzeit bei I k c log k O log k In diesem Sinn hat e A eine lineare Laufzeit O k und e B nur eine logarithmische Laufzeit O log k 7 19 D h selbst wenn Algorithmus A bei kleinen k schneller arbeitet als B so gibt es doch ein ko derart da f r alle k gt k B stets schneller ist als A Laufzeit Alg A O k Alg B O log k Ko Eingabe 7 4 Programmiersprachen Die Wahl einer Implementierungssprache hat wesentlichen Einflu auf Programmlesbarkeit transparenz Selbsterkl rungsf higkeit Programmiergeschwindigkeit Lines of Code h Programmumfang sowie auf die Qualit ten der Software n mlich Effektivit t Zuverl ssigkeit Robustheit Adaptierbarkeit Portabilit t Kompatibilit t Benutzerfreundlichkeit Wartbarkeit Effizie
155. wendung eines Bezeichners fest e vermeidet die mehrmalige Vergabe desselben Bezeichners was bei mittleren Projekten bereits zu Problemen f hrt e legt die Komponenten eines Datenflusses fest e legt die Objekte fest welche sich in einem Speicher befinden d rfen bildet eine zentrale bersicht ber vergebene Bezeichner und ist nicht nur bei Werkzeugunterst tzung sinnvoll Anforderungen an ein DD Keine redundante Datenhaltung wegen Konsistenz Datendefinition mu hierarchische Verfeinerung erlauben Komplexit t Datendefinition mu bestimmter Syntax gen gen formal berpr fbar Das Datenlexikon ist somit ein zentraler Definitionskatalog f r s mtliche Daten und Speicher Es l st Verst ndigungsprobleme durch Festlegung der Struktur und der Bedeutung der Datenfl sse Die meisten Worte und seien sie noch so allt glich sind so vieldeutig dass sie zur Spezifikation nur dann herangezogen werden k nnen wenn ihre Bedeutung vorher festgelegt worden ist 4 6 1 Eintr ge in ein Data Dictionary Eintr ge in das Data Dictionary m ssen einer bestimmten Syntax gen gen die an die erweiterte Backus Naur Form angelehnt ist Die Syntax gestattet es Daten und Kontrolltypen aus anderen Typen zusammenzusetzen Allerdings Datentypen d rfen nicht aus Kontroll und Kontrolltypen d rfen nicht aus Datentypen zusammengesetzt werden Neben den zusammengesetzten Typen k nnen auch terminale primitive Typen definier
156. werden k nnen Dies sollte der Standard sein Quick amp Dirty Q amp D Entwickler geht davon aus da das Programm nur eine kurze Lebensdauer hat so da eine ausf hrliche Vorbereitung und Dokumentation nicht gerechtfertigt ist Eine Problemanalyse ist kaum vorhanden Vorsicht nichts ist so dauerhaft wie ein gut funktionierendes Provisorium Prototyping I m really not sure what I want but Ill know it when I see it Sukzessives Entwickeln verschiedener Versionen des Systems mit Hilfe geeigneter Softwaretools bis schlie lich unter st ndigem Kontakt mit dem Anwender die fertige Version entsteht Diese Vorgehensweise ist sehr teuer und wird daher oft nur f r grafische User Interfaces durchgef hrt bzw ist relevant auch nur f r diesen Anwendungsbereich Wir konzentrieren uns im Folgenden auf die traditionelle Vorgehensweise f r die es eine ganze Reihe von Methoden gibt Vorgestellt wird die Methode Structured Design SD allerdings in einer neueren Version die Elemente des Modular Design MD enth lt 6 1 6 1 bergang von der Analyse zum Entwurf In der Analyse werden in mehreren Iterationen Anforderungen gesammelt beschrieben und analysiert wobei Anforderungen Aussagen ber zu erbringende Leistungen sind Beim Entwurf wird f r die Gesamtfunktionalit t des Systems eine Software Architektur entwickelt bestehend aus Moduln und ihren Schnittstellen sowie den Testbedingungen und Testdaten denen die noch im Rahm
157. wie Modul in seinem Inneren funktioniert Informationen dar ber findet man in der Entwurfsdokumentation Modul Spec soweit dort bereits eine prozedurale Spezifikation des Moduls erfolgt ist D h die Aufgabe des Moduls wurde bereits als Rezept spezifiziert welches angewandt auf die Eingabe gerade die Ausgabe Daten liefert evtl auch nur grob spezifiziert z B in Form von Pseudo Code NS Diagramm Programma blaufplan in der Quellcode Dokumentation Kommentare 9 5 9 1 3 Benutzerdokumentation Die Benutzerdokumentation ist bei komplexen Systemen neben den ausf hrbaren Programmen und erstellten Datenfiles das wichtigste Ergebnis eines Software Projekts Daran messen Endanwender i d R auch die Qualit t des Gesamtsystems Sie umfa t i a die Teildokumente Product ini User Overview Reference Zus tzlich sind eventuell Vertriebsunterlagen notwendig soweit diese nicht von einer eigenen Marketing Verkaufsabteilung erstellt werden Produktbeschreibung Product Overview Sie soll Antwort auf die Frage geben ob das SW Produkt zur L sung eines gegebenen Problems genutzt werden kann Operateurhandbuch Administrator Guide Beschreibt l ckenlos alle zum Betrieb des Programmsystems notwendigen einmaligen und stets wiederkehrenden Arbeiten sowie die notwendigen Systemvoraussetzungen zum Betrieb der Software Systemvoraussetzungen Hardware Rechner CPU Typ Hauptspeicher min alloc Speicher
158. will kann auch verborgen werden beispielsweise Wahl der Datenstrukturen Stack als verkettete Liste Feld oder File Wahl eines Algorithmus Gehaltszahlung Interne Systemzust nde Task Control Block Bit 3 bedeutet Task l uft Entscheidungsstrukturen Gehaltserh hung Daten Drehwinkel eines Roboters Eigenschaften von physikalischen Ger ten Blinken des Bildschirms Der Entwickler entscheidet was verborgen wird und auf welche Weise F r die Benutzung stellt er eine gut dokumentierte Schnittstelle zur Verf gung Black Box Prinzip Der Vorteil des Geheimnisprinzips ist dass verborgene Informationen ge ndert werden k nnen ohne da die Umgebung davon beeinflu t wird Die Gr nde f r eine Ver nderung von verborgenen Information sind vielf ltig beispielsweise Anderung der Technologie Steigerung der Effizienz Erweiterung Verbesserung der Datenstrukturen 6 7 4 Das Kapselungsprinzip Kapselung Encapsulation bedeutet e Zusammenfassen von hnlichen Funktionen in eine logische Einheit die wie ein einzelner Baustein benutzt werden kann e Kontrollierter Zugriff auf die logische Einheit durch genau definierte Schnittstellen Mit Hilfe der Kapselung wird also ein Objekt zur Black Box Ein au enstehender Beobachter sieht nur die u erlich sichtbaren Eigenschaften und das u erlich sichtbare Verhalten eines solchen Objekts Er kann nicht sehen wie die internen 6 24 Informationen strukturiert sind wie inte
159. ysteme kann mit den Mitteln des Strukturierten Designs oder des Modular Designs nicht beschrieben werden Hierf r wird eine weitere Designkomponente ben tigt die als Task bezeichnet wird In neueren Programmiersprachen lassen sich diese direkt realisieren beispielsweise 6 7 durch Tasks in Ada oder Threads in Java Ansonsten besteht die M glichkeit eine Task auf ein ablauff higes Haupt Programm abzubilden was man beispielsweise in C tun w rde Wir werden uns im Folgenden nur mit den statischen Strukturen befassen und Tasks nicht weiter betrachten 6 2 5 Objekt Orientierter Entwurf Der Objekt Orientierte Entwurf OOD entstand Mitte der 80iger Jahre und basiert auf Ideen von G Booch B Meyer und der Smalltalk Schule Er betont neben der Kapselung und der Definition von Schnittstellen den Aufbau von wiederverwendbaren Designkomponenten Wiederverwendbare Klassen werden durch Anwendung des Vererbungsprinzips erstellt Die Konzepte werden durch objekt orientierte Programmiersprachen wie Smalltalk Eiffel C oder Java unterst tzt Neben dem Programming in the Large nimmt die Bedeutung des Programming in the Many immer mehr zu Damit ist gemeint dass man nicht einen Entwurf f r ein System macht sondern dass in vielen Systemen hnliche Probleme zu l sen sind Man versucht f r alle diese hnlichen Probleme einen Entwurf zu machen und ber die objekt orientierten Mechanismen wie Vererbung den Entwurf an konkrete
160. zw die Benutzung von Daten symbolisieren In diesen Diagrammen k nnen nun dar berhinaus auch die Schnittstelle der Aufrufe Parameter spezifiziert werden SD Operationen repr sentieren Funktionen oder Prozeduren einer Programmiersprache Es sind normale und vordefinierte Operationen zu unterscheiden e Eine Operation wird als normale Operation dargestellt wenn sie in diesem Projekt zu erstellen ist und nicht schon vordefiniert ist Eine oder mehrere Operationen k nnen einem Modul zugeordnet werden das in einem Moduldiagramm bearbeitet wird Operationen werden durch ein Rechteck dargestellt in dessen Inneren der Name der Operation steht Zu jeder Operation kann der strukturierte Quellcode Pseudocode oder Struktogramm einer Funktion eingegeben werden e V Vordefinierte Operationen repr sentieren Funktionen oder Prozeduren die bereits vorhanden sind z B in bestehenden Libraries und lediglich in das neue Projekt eingebunden werden m ssen Man spricht deshalb manchmal auch von Bibliotheksoperationen Vordefinierte Operationen werden durch ein Rechteck mit zwei zus tzlichen parallelen Linien dargestellt Im Inneren des Rechtecks steht der Name der Operation Vordefinierte Operationen k nnen vordefinierten Moduln zugeordnet werden Einer vordefinierten Operation kann kein strukturierter Quellcode zugeordnet werden 6 17 SD Daten repr sentieren Datenbereiche einer Programmiersprache wie z B Variablendeklarationen Sie k nnen nur a

Skript - Informationstechnik

Contents

Download Pdf Manuals

Related Search

Related Contents