Startseite   |  Site map   |  A-Z artikel   |  Artikel einreichen   |   Kontakt   |  
  


informatik artikel (Interpretation und charakterisierung)

Richtlinien für den aufbau eines dfd's


1. Java
2. Viren



Bei der Erstellung von DFD's gibt es folgende Richtlinien welche wir genauer erklären werden:

. Aussagekräftige Namen wählen
. Prozesse numerieren

. komplexe DFD's vermeiden
. so oft als nötig neu zeichnen

. logisch konsitente DFD's
2.1 Aussagekräftige Namen wählen
Wenn eine Einzelperson einen Prozeß ausführt, ist es empfehlenswert, anstelle des Namens dieser Person die Funktion anzugeben, die diese Person ausführt. Siehe Abb. A.11. & A.12. Es gibt drei Gründe warum man die Funktion als Name angibt:

. Nach einer gewissen Zeit könnten die Aufgaben von einer anderen Person übernommen werden und somit ist das System veraltet.

. Wenn diese Person mehrere Tätigkeiten innerhalb eines DFD's ausführt, ist es nicht sinnvoll drei Bubbles mit dem selben Namen zu zeichnen.

. Wenn der Name angegeben wird, wird die Aufmerksamkeit darauf gelenkt, wie derjenige seine Aufgabe durchzuführen beliebt, doch sollte man normalerweise mehr Betonung auf die zugrunde liegende Firmenstrategie legen.

Eine gute Art Prozesse zu benennen ist die Verwendung eines Verbs und eines Objektes, d.h. Sie wählen ein aktives Verb und ein passendes Objekt z.B. "errechne Raketenflugbahn". Man sollte keine Verben verwenden wie mache, bearbeite oder verarbeite, sondern genauere Definition der Tätigkeit verwenden. Man sollte Wörter nehmen, welche aus einem Vokabular stammen, das dem Benutzer gut bekannt ist. Es gibt noch zwei Richtlinien, an die sich Ersteller eines DFD's halten sollten.

. Benutzer neigen dazu, spezifische Abkürzungen zu verwenden, mit welchen Laien wenig anzufangen wissen. Eine gute Methode diesen firmenspezifischen Jargon zu vermeiden, ist Objekte und Verben zu wählen, die Personen der selben Branche ebenfalls verstehen würden.

. Wenn ein Programmierer ein DFD erstellt, neigt er dazu, Begriffe wie "Routine", "Prozedur", "Funktion" oder "Untersystem" zu verwenden. Derartige Begriffe sollten allerdings vermieden werden.
2.2 Prozesse numerieren
Um in DFD's besser auf Prozesse verweisen zu können, ist es vorteilhaft, die Bubbles zu numerieren. Es ergibt sich dabei manchmal das Problem, daß flüchtige Leser, eine Reihenfolge in dieser Numerierung sehen, doch die Numerierung der Prozesse hat nichts mit der Reihenfolge ihrer Ausführung zu tun. Ein weiterer Vorteil in der Numerierung liegt darin, das Bubble direkt mit Bubble 1 ansprechen zu können und nicht die ganze Bezeichnung verwenden zu müssen.
2.3 komplexe DFD's vermeiden
Man sollte komplexe DFD's vermeiden, da diese nicht nur vom Systemanalytiker, sondern auch für die Benutzer übersichtlich und leicht verständlich sein sollten. Dazu gibt es eine Richtlinie, die niemals außer acht gelassen werden sollte: erstellen Sie niemals ein DFD mit zu vielen Prozessen, Flüssen, Speichern und Terminatoren. Man sollte sich meistens an folgende Faustregel halten: nie mehr als 6 Prozesse mit den zusammenhängenden Speichern, Flüssen und Terminatoren auf einem Diagramm abbilden. Siehe Abb. A.13.
2.4 Neu zeichnen
Beim Erstellen eines DFD's wird man merken, daß man viele Veränderungen vornehmen muß, bis das Diagramm technisch korrekt ist, vom Benutzer akzeptiert wird und sauber genug gezeichnet ist. Wie man ein DFD ästhetisch gestaltet hängt natürlich vom persönlichen Geschmack ab, doch haben auch manche Organisationen Normen vorgegeben. Nachfolgend noch drei Hilfen zur Gestaltung eines DFD's:


. Form und Größe der Bubbles
Die Wahl des Symbols ist reine Geschmackssache. Wenn Bubbles in einem DFD unterschiedlich groß sind, werden Benutzer auch leicht irritiert. Diese glauben dann, daß ein größeres Bubble einen wichtigeren Systemteil darstellt.

. Gekrümmter oder geradliniger Datenfluß, siehe Abb. A.14. & A.15.
Dies hängt vor allem von den Benutzern ab, welche das DFD lesen. Manche finden gekrümmte, manche geradlinige Datenflüsse schöner. Das heißt, daß es von Vorteil ist, wenn man schon vorher weiß, welche Form für den Benutzer akzeptabler ist.

. Handgezeichnete Diagramme oder rechnergenerierte Diagramme
Die meisten Diagramme werden heute bereits mit dem Computer gezeichnet. Es gibt jedoch auch Benutzer, welche handgezeichnete Bilder vorziehen, da sie dann nicht das Gefühl haben, das Diagramm wäre schon endgültig und unveränderbar.

2.5 logisch konsistente DFD's
Um sicherzustellen, daß das DFD in sich stimmig ist, gibt es einige Richtlinien. Nachfolgend die Hauptkriterien für die Konsistenz eines DFD's:

. Bubbles, welche einen Eingabefluß haben jedoch ohne Ausgabe sind, sollten vermieden werden. Unter den Systemanalytikern ist der Begriff "schwarzes Loch" für diesen Zustand üblich.
. Ebenfalls sollten Bubbles vermieden werden, welche einen Ausgabefluß haben, jedoch ohne Eingabe sind. Doch gibt es eine Ausnahme, nämlich den Zufallszahlengenerator.
. Sie sollten unbedingt, alle Flüsse und Prozesse bezeichnen. Ein nichtbezeichnetes Element ist meist ein Zeichen für Nachlässigkeit, kann aber auch auf einen tiefergehenden Fehler hinweisen, wenn z.B. einem Systemanalytiker kein entsprechender Name für einen Datenfluß eingefallen ist, weil mehrere elementare Dateneinheiten willkürlich zusammengepackt wurden.
. Man sollte nie nur Lese- oder nur Schreibspeicher verwenden. Ein typischer Speicher sollte immer Eingabe- und Ausgabeflüsse haben. Die einzige Ausnahme sind externe Speicher.

 
 



Datenschutz
Top Themen / Analyse
indicator Aufbau des Computers
indicator Datenkompremierung (File Compression):
indicator Switches
indicator Die Rolle von SQS
indicator Grundlagen der Halbleitertechnik
indicator Warnung vor der Konfigurations-Oberfläche des Filter/Firewall Setup
indicator Kognitivistische Lerntheorien und Tutoren
indicator Ausdrücke und Operatoren in JavaScript
indicator Software:
indicator Programme zur Benutzerverwaltung




Datenschutz
Zum selben thema
icon Netzwerk
icon Software
icon Entwicklung
icon Windows
icon Programm
icon Unix
icon Games
icon Sicherheit
icon Disk
icon Technologie
icon Bildung
icon Mp3
icon Cd
icon Suche
icon Grafik
icon Zahlung
icon Html
icon Internet
icon Hardware
icon Cpu
icon Firewall
icon Speicher
icon Mail
icon Banking
icon Video
icon Hacker
icon Design
icon Sprache
icon Dvd
icon Drucker
icon Elektronisches
icon Geschichte
icon Fehler
icon Website
icon Linux
icon Computer
A-Z informatik artikel:
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z #

Copyright © 2008 - : ARTIKEL32 | Alle rechte vorbehalten.
Vervielfältigung im Ganzen oder teilweise das Material auf dieser Website gegen das Urheberrecht und wird bestraft, nach dem Gesetz.
dsolution