Strukturierte Analyse

Beispiel eines strukturierten Analyseansatzes.[1]

Im Softwareentwicklung, Strukturierte Analyse (Sa) und strukturiertes Design (SD) sind Methoden zur Analyse des Geschäfts Bedarf und Entwicklung Spezifikationen zum Umwandeln in Praktiken in Computerprogramme, Hardwarekonfigurationen und verwandte manuelle Verfahren.

Strukturierte Analyse- und Designtechniken sind grundlegende Werkzeuge von Systemanalyse. Sie entwickelten sich aus der klassischen Systemanalyse der 1960er und 1970er Jahre.[2]

Ziele der strukturierten Analyse

Die strukturierte Analyse wurde in den 1980er Jahren populär und wird heute noch verwendet. Die strukturierte Analyse besteht darin, die zu interpretieren System Konzept (oder Situationen der realen Welt) in Daten- und Kontrollterminologie, die durch dargestellt werden durch Datenflussdiagramme. Der Datenfluss und die Steuerung von Blase zum Datenspeicher zu Blasen können schwierig zu verfolgen sein und die Anzahl der Blasen kann zunehmen.

Ein Ansatz besteht darin, zuerst Ereignisse aus der Außenwelt zu definieren, die das System reagieren müssen, und dann diesem Ereignis eine Blase zuzuweisen. Blasen, die interagieren müssen, werden dann angeschlossen, bis das System definiert ist. Blasen werden normalerweise in Blasen auf höherer Ebene gruppiert, um die Komplexität zu verringern. Datenwörterbücher werden benötigt, um die Daten und Befehlsflüsse zu beschreiben, und eine Prozessspezifikation ist erforderlich, um die Transaktions-/Transformationsinformationen zu erfassen.[3]

SA und SD werden mit angezeigt Strukturdiagramme, Datenflussdiagramme und Datenmodelldiagrammevon denen es viele Variationen gab, einschließlich derer, die von entwickelt wurden Tom DeMarco, Ken Orr, Larry Constantine, Vaughn Frick, Ed yourdon, Steven Ward, Peter Chen, und andere.

Diese Techniken wurden in verschiedenen veröffentlichten Veröffentlichungen kombiniert Systementwicklungsmethoden, einschließlich Strukturierte Systemanalyse- und Entwurfsmethode, profitable Informationen nach Design (PRIDE), Structured Analysis & Design, SDM/70 und die strukturierte Systementwicklungsmethode für die Struktur der Spektrum.

Geschichte

Die strukturierte Analyse ist Teil einer Reihe strukturierter Methoden, die eine Sammlung von Analysen, Design- und Programmierechniken darstellen, die als Reaktion auf die Probleme der Software -Welt aus den 1960er bis 1980er Jahren entwickelt wurden. In diesem Zeitraum wurde die meisten kommerziellen Programme in durchgeführt Cobol und Forran, dann C und BASIC. Es gab kaum Anleitung zu "guten" Design- und Programmierechniken, und es gab keine Standardtechniken für die Dokumentation von Anforderungen und Designs. Die Systeme wurden größer und komplexer, und die Entwicklung des Informationssystems wurde immer schwieriger. "[4]

Um große und komplexe Software zu verwalten, entstanden die folgenden strukturierten Methoden seit Ende der 1960er Jahre:[4]

Laut Hay (1999) "Informationsingenieurswesen war eine logische Erweiterung der strukturierten Techniken, die in den 1970er Jahren entwickelt wurden. Die strukturierte Programmierung führte zu strukturiertem Design, was wiederum zu einer strukturierten Systemanalyse führte. Diese Techniken wurden durch ihre Verwendung von charakterisiert Diagramme: Strukturdiagramme für strukturiertes Design und Datenflussdiagramme für die strukturierte Analyse, um die Kommunikation zwischen Benutzern und Entwicklern zu unterstützen und die Disziplin des Analysten und der Designerin zu verbessern. In den 1980er Jahren tauchten Tools auf, die beide die Zeichnung der Diagramme automatisierten und die in a gezogenen Dinge im Auge behielten Datenwörterbuch".[10] Nach dem Beispiel von computergestütztes Design und Computergestützte Herstellung (CAD/CAM) wurde die Verwendung dieser Werkzeuge benannt Computergestützte Softwareentwicklung (FALL).

Strukturierte Analysethemen

Einzelabstraktionsmechanismus

Beispiel für strukturiertes Analyse.[11]

Die strukturierte Analyse erzeugt typischerweise eine Hierarchie, die einen einzelnen Abstraktionsmechanismus verwendet. Die strukturierte Analysemethode kann angewendet werden Idef (Siehe Abbildung), wird prozessgetrieben und beginnt mit einem Zweck und einem Standpunkt. Diese Methode identifiziert die Gesamtfunktion und unterteilt iterativ Funktionen in kleinere Funktionen, beibehalten Eingänge, Ausgänge, Steuerelemente und Mechanismen, die zur Optimierung von Prozessen erforderlich sind. Auch bekannt als a funktionale Zersetzung Der Ansatz konzentriert sich auf den Zusammenhalt in Funktionen und die Kopplung zwischen Funktionen, die zu strukturierten Daten führen.[11]

Die funktionelle Zerlegung der strukturierten Methode beschreibt den Prozess ohne das Verhalten des Systems und diktiert die Systemstruktur in Form der erforderlichen Funktionen. Die Methode identifiziert Eingaben und Ausgänge im Zusammenhang mit den Aktivitäten. Ein Grund für die Popularität der strukturierten Analyse ist die intuitive Fähigkeit, hochrangige Prozesse und Konzepte zu kommunizieren, sei es auf einzelnen System- oder Unternehmensebene. Entdecken Sie, wie Objekte Funktionen für kommerziell verbreitete Unterstützung unterstützen können objektorientierter Entwicklung ist unklar. Im Gegensatz zu idef die Uml ist eine Schnittstelle mit mehreren Abstraktionsmechanismen, die bei der Beschreibung nützlich sind Service-orientiert Architekturen (SOAs).[11]

Sich nähern

Die strukturierte Analyse betrachtet ein System aus der Perspektive der durch sie fließenden Daten. Die Funktion des Systems wird durch Prozesse beschrieben, die die Datenflüsse transformieren. Die strukturierte Analyse nutzt Informationen, die sich durch aufeinanderfolgende Zersetzung (oder Top -Down -Analyse) verstecken. Dies ermöglicht die Aufmerksamkeit auf relevante Details und vermeidet Verwirrung durch die Betrachtung irrelevanter Details. Mit zunehmendem Detailniveau wird die Informationsbreite verringert. Das Ergebnis der strukturierten Analyse ist ein Satz verwandter grafischer Diagramme, Prozessbeschreibungen und Datendefinitionen. Sie beschreiben die Transformationen, die stattfinden müssen, und die Daten, die für die Erfüllung eines Systems erforderlich sind funktionale Anforderungen.[12]

Der strukturierte Analyseansatz entwickelt Perspektiven sowohl auf Prozessobjekten als auch auf Datenobjekte.[12]

De Marcos Ansatz[13] besteht aus den folgenden Objekten (siehe Abbildung):[12]

Hiermit der Datenflussdiagramme (DFDS) sind gerichtete Graphen. Die Bögen repräsentieren Datenund die Knoten (Kreise oder Blasen) repräsentieren Prozesse, die die Daten transformieren. Ein Prozess kann weiter zu einer detaillierteren DFD zerlegt werden, die die darin enthaltenen Unterprozesse und Datenflüsse zeigt. Die Unterprozesse können wiederum mit einem anderen Satz von DFDs weiter zersetzt werden, bis ihre Funktionen leicht verstanden werden können. Funktionelle Primitive sind Prozesse, die nicht weiter zersetzt werden müssen. Funktionelle Primitive werden durch eine Prozessspezifikation (oder Mini-Spec) beschrieben. Die Prozessspezifikation kann aus Pseudo-Code bestehen, Flussdiagramme, oder strukturiertes Englisch. Das DFDS modelliert die Struktur des Systems als Netzwerk von miteinander verbundenen Prozessen aus funktionalen Primitiven. Das Datenwörterbuch ist eine Reihe von Einträgen (Definitionen) von Datenfluss, Datenelementen, Dateien und Datenbanken. Die Datenwörterbucheinträge werden oben nach unten aufgeteilt. Sie können in anderen Datenwörterbucheinträgen und in Datenflussdiagrammen verwiesen werden.[12]

Kontextdiagramm

Beispiel eines Systemkontextdiagramms.[14]

Kontextdiagramme sind Diagramme, die die Akteure außerhalb eines Systems darstellen, die mit diesem System interagieren könnten.[15] Dieses Diagramm ist die höchste Sichtweise von a System, ähnlich zu Blockdiagramm, möglicherweise a, möglicherweise Software-Basiert, System als Ganzes und seine Eingänge und Ausgänge von/bis externer Faktoren.

Diese Art von Diagramm nach Kossiakoff (2003) "bildet das System in der Mitte normalerweise ein, ohne dass die Innenstruktur von all seinen interagierenden Systemen, Umgebungen und Aktivitäten umgeben ist. Das Ziel eines Systemkontextdiagramms ist es, die Aufmerksamkeit zu konzentrieren Externe Faktoren und Ereignisse, die bei der Entwicklung eines vollständigen Satzes von Systemanforderungen und -beschränkungen berücksichtigt werden sollten. "[15] Systemkontextdiagramme beziehen sich auf Datenflussdiagrammund zeigen die Wechselwirkungen zwischen einem System und anderen Akteuren, denen das System ausgelegt ist. Systemkontextdiagramme können hilfreich sein, um den Kontext zu verstehen, in dem das System Teil davon sein wird Softwareentwicklung.

Datenwörterbuch

Entity-Relationship-Diagrammwichtig für das Design von Datenbanktabellen, Extrakten und Metadaten.[16]

A Datenwörterbuch oder Datenbankwörterbuch ist eine Datei, die die grundlegende Organisation von a definiert Datenbank.[16] Ein Datenbankwörterbuch enthält eine Liste aller Dateien in der Datenbank, die Anzahl der Datensätze in jeder Datei und die Namen und Typen jedes Datenfeldes. Die meisten Datenbankmanagementsystem Halten Sie das Datenwörterbuch vor den Benutzern versteckt, um zu verhindern, dass sie den Inhalt versehentlich zerstören. Datenwörterbücher enthalten keine tatsächlichen Daten aus der Datenbank, sondern nur Buchhaltungsinformationen für die Verwaltung. Ohne ein Datenwörterbuch kann ein Datenbankverwaltungssystem jedoch nicht aus der Datenbank auf Daten zugreifen.[16]

Datenbankbenutzer und Anwendung Entwickler können von einem maßgeblichen Datenwörterbuchdokument profitieren, das die Organisation, den Inhalt und die Konventionen eines oder mehrerer Datenbanken katalogisiert.[17] Dies enthält typischerweise die Namen und Beschreibungen verschiedener Tische und Felder in jeder Datenbank sowie zusätzliche Details wie die Typ und Länge von jedem Datenelement. Es gibt keinen universellen Standard in Bezug Metadaten um Datenbankstruktur, nicht die Daten selbst. Ein Data Dictionary -Dokument kann auch weitere Informationen enthalten, die beschreiben, wie Datenelemente codiert werden. Einer der Vorteile gut entwickelter Datenwörterbuchdokumentation besteht darin, dass sie dazu beiträgt, Konsistenz in einer komplexen Datenbank oder in einer großen Sammlung von zu ermitteln Föderierte Datenbanken.[18]

Datenflussdiagramme

Beispiel für Datenflussdiagramm.[19]

A Datenflussdiagramm (DFD) ist eine grafische Darstellung des "Flusses" von Daten durch ein Informationssystem. Es unterscheidet sich vom System Flussdiagramm Da zeigt es den Datenfluss durch Prozesse anstelle von Prozessen Computerhardware. Datenflussdiagramme wurden von erfunden von Larry Constantine, Entwickler von strukturiertes Designbasierend auf dem "Datenflussdiagramm" von Martin und Estrins Berechnungsmodell.[20]

Es ist üblich, a zu zeichnen Systemkontextdiagramm Erstens zeigt die Wechselwirkung zwischen System und externen Einheiten. Die DFD soll zeigen, wie ein System in kleinere Teile unterteilt ist, und um den Datenfluss zwischen diesen Teilen hervorzuheben. Dieses Datenflussdiagramm auf Kontextebene wird dann "explodiert", um mehr Details des zu modellierten Systems zu zeigen.

Datenflussdiagramme (DFDs) sind eine der drei wesentlichen Perspektiven von Strukturierte Systemanalyse- und Entwurfsmethode (SSADM). Der Sponsor eines Projekts und die Endbenutzer müssen in allen Phasen der Entwicklung eines Systems informiert und konsultiert werden. Mit einem Datenflussdiagramm können Benutzer visualisieren, wie das System funktioniert, was das System erreicht und wie das System implementiert wird. Die Datenflussdiagramme des alten Systems können erstellt und mit den Datenflussdiagrammen des neuen Systems verglichen werden, um Vergleiche zu zeichnen, um ein effizienteres System zu implementieren. Datenflussdiagramme können verwendet werden, um dem Endbenutzer eine physische Vorstellung davon zu geben, wo die von ihnen eingegebenen Daten letztendlich einen Einfluss auf die Struktur des gesamten Systems haben, von der Bestellung bis zum Versand bis zum Rückblick. Wie jedes System entwickelt wird, kann durch ein Datenflussdiagramm bestimmt werden.

Strukturdiagramm

Ein Konfigurationssystemstrukturdiagramm.[21]

A Strukturdiagramm (SC) ist ein Diagramm, das die Aufschlüsselung der zeigt Konfigurationssystem zu den niedrigsten überschaubaren Ebenen.[21] Dieses Diagramm wird in verwendet Strukturierte Programmierung Um die Programmmodule in einer Baumstruktur anzuordnen. Jedes Modul wird durch eine Box dargestellt, die den Namen der Module enthält. Die Baumstruktur visualisiert die Beziehungen zwischen den Modulen.[22]

Strukturdiagramme werden in der strukturierten Analyse verwendet, um das hochrangige Design oder die Architektur von a zu spezifizieren Computer Programm. Als Design -Tool helfen sie dem Programmierer, ein großes Softwareproblem zu teilen und zu erobern, dh rekursiv ein Problem in Teile, die klein genug sind, um von einem menschlichen Gehirn verstanden zu werden. Der Prozess wird genannt Top-Down-Design, oder funktionale Zersetzung. Programmierer verwenden ein Strukturdiagramm, um ein Programm auf ähnliche Weise zu erstellen, wie ein Architekt einen Blaupause zum Bau eines Hauses verwendet. In der Entwurfsphase wird das Diagramm gezeichnet und als eine Möglichkeit für den Kunden und die verschiedenen Software -Designer verwendet, um zu kommunizieren. Während des tatsächlichen Aufbaus des Programms (Implementierung) wird das Diagramm kontinuierlich als Masterplan bezeichnet.[23]

Strukturiertes Design

Structured Design (SD) befasst sich mit der Entwicklung von Modulen und der Synthese dieser Module in einer sogenannten "Modulhierarchie".[24] Um eine optimale Modulstruktur und die Schnittstellen zu entwerfen, sind zwei Prinzipien von entscheidender Bedeutung:

  • Zusammenhalt Das "befasst sich mit der Gruppierung funktional verwandter Prozesse in ein bestimmtes Modul",[12] und
  • Kupplung bezieht sich auf "den Informationsfluss oder Parameter, der zwischen Modulen übergeben wird. Die optimale Kopplung reduziert die Schnittstellen von Modulen und die daraus resultierende Komplexität der Software".[12]

Strukturiertes Design wurde von entwickelt von Larry Constantine In den späten 1960er Jahren verfeinert und veröffentlicht in den 1970er Jahren mit Mitarbeitern;[5][6] sehen Larry Constantine: Strukturiertes Design für Details. Page-Jones (1980) hat seinen eigenen Ansatz vorgeschlagen, der aus drei Hauptzielen besteht:

  • Strukturdiagramme
  • Modulspezifikationen
  • Datenwörterbuch.

Das Strukturdiagramm Ziel ist es, "die Modulhierarchie- oder Aufrufsequenzbeziehung von Modulen zu zeigen. Es gibt eine Modulspezifikation für jedes im Strukturdiagramm gezeigte Modul. Die Modulspezifikationen können aus Pseudo-Code oder einer Programmdesignsprache bestehen. Datenwörterbuch ist wie die der strukturierten Analyse. Zu diesem Zeitpunkt in der SoftwareentwicklungslebenszyklusNachdem die Analyse und das Design durchgeführt wurden, ist es möglich, automatisch Datentypdeklarationen zu generieren ".[25] und Prozedur- oder Unterprogrammvorlagen.[12]

Kritik

Probleme mit Datenflussdiagrammen haben Folgendes enthalten:[3]

  1. Blasen entsprechend wählen
  2. Bubbles in einer sinnvollen und sich gegenseitig vereinbarten Art und Weise, wie sie die Art und Weise vereinbart haben,
  3. Dokumentationsgröße erforderlich, um die Datenflüsse zu verstehen,
  4. Datenflussdiagramme sind stark funktional und unterliegen somit einer häufigen Änderung
  5. Obwohl der "Datenerfluss" betont wird, ist die Modellierung von "Daten" nicht, daher gibt es kaum das Verständnis des Gegenstands des Systems
  6. Kunden haben Schwierigkeiten, zu folgen, wie das Konzept in Datenflüsse und Blasen zugeordnet wird
  7. Designer müssen die DFD -Organisation in ein implementierbares Format verschieben

Siehe auch

Verweise

  1. ^ Tricia Gilbert (2006) FCS -Bewertungskritera für die Bewertung der Technologie Archiviert 2008-09-18 bei der Wayback -Maschine
  2. ^ Edward Yourdon (1986). Verwaltung der strukturierten Techniken: Strategien für die Softwareentwicklung in den neunziger Jahren. YourDon Press. S.35.
  3. ^ a b FAA (2000). FAA System Sicherheitshandbuch, Anhang D.. 30. Dezember 2000.
  4. ^ a b Dave Levitt (2000). "Einführung in die strukturierte Analyse und das Design." bei Fakultät.inverhills.edu/dlevitt. Abgerufen am 21. September 2008. Nicht mehr online 2017.
  5. ^ a b Stevens, Myers & Constantine 1974.
  6. ^ a b Yourdon & Constantine 1979.
  7. ^ McMenamin, Stephen M.; Palmer, John F. (1984). Essentielle Systeme Analyse. YourDon Press. ISBN 978-0-13-287905-7.
  8. ^ Gavriel Salvendy (2001). Handbuch für Industrie -Engineering: Technologie und Betriebsmanagement.. P.508.
  9. ^ Yourdon, Edward (1989). Moderne strukturierte Analyse. Prentice-Hall. ISBN 978-0-13-598632-5.
  10. ^ David C. Hay (1999) Erreichung der Einhaltung der Schlagwortwörter in der Objektorientierung Archiviert 2008-10-20 bei der Wayback -Maschine Essential Strategies, Inc.
  11. ^ a b c DOD Architecture Framework Working Group (2003). Dodaf 1.5 Volumen 2, 15. August 2003.
  12. ^ a b c d e f g Alan Hecht und Andy Simmons (1986) Integration automatisierter strukturierter Analyse und Design in ADA -Programmierunterstützungsumgebungen NASA 1986.
  13. ^ Tom DeMarco (1978). Strukturierte Analyse und Systemspezifikation. Yourdon Press, New York, 1978.
  14. ^ NDE -Projektmanagement Archiviert 2008-11-07 bei der Wayback -Maschine (NPOess) Datennutzungswebsite. 2008.
  15. ^ a b Alexander Kossiakoff, William N. Sweet (2003). Systemtechnik: Prinzipien und Praktiken p. 413.
  16. ^ a b c Datenintegration Glossar Archiviert 2012-02-18 bei der Wayback -Maschine, US -Verkehrsministerium, August 2001.
  17. ^ TechTarget, SearchSOA, Was ist ein Datenwörterbuch?
  18. ^ Ahima Practice Brief, Richtlinien für die Entwicklung eines Datenwörterbuchs, Journal of Ahima 77, Nr. 2 (Februar 2006): 64a-d.
  19. ^ John Azzolini (2000). Einführung in Systemtechnikpraktiken. Juli 2000.
  20. ^ W. Stevens, G. Myers, L. Constantine, "Structured Design", IBM Systems Journal, 13 (2), 115-139, 1974.
  21. ^ a b "Konfigurationsmanagement" Im: IRS -Ressourcen Teil 2. Informationstechnologie Kapitel 27. Konfigurationsmanagement. Zugriff am 14. November 2008.
  22. ^ James Martin, Carma L. McClure (1988). Strukturierte Techniken: Die Grundlage für den Fall.Prentice Hall.S. 56.
  23. ^ David Wolber "Strukturdiagramme Archiviert 2009-02-19 bei der Wayback -Maschine: Ergänzende Notizen-Strukturdiagramme und Bottom-up-Implementierung: Java-Version.
  24. ^ Page-Jones 1980.
  25. ^ Belkhouche, B. und J. E. Urban.(1986)."Direkte Implementierung abstrakter Datentypen aus abstrakten Spezifikationen".Im: IEEE -Transaktionen auf Software -Engineering S. 549-661, Mai 1986.

Weitere Lektüre

  • Stevens, W. P.; Myers, G. J.; Konstantin, L. L. (Juni 1974). "Strukturiertes Design". IBM Systems Journal. 13 (2): 115–139. doi:10.1147/sj.132.0115.
  • Yourdon, Edward; Konstantin, Larry L. (1979) [1975]. Strukturiertes Design: Grundlagen einer Disziplin des Computerprogramms und des Systemdesigns. YourDon Press. ISBN 0-13-854471-9.
  • Tom DeMarco (1978). Strukturierte Analyse und Systemspezifikation. Yourdon. ISBN0-91-707207-3
  • Page-Jones, M (1980), Der praktische Leitfaden für strukturierte Systeme Design, New York: Yourdon Press
  • Derek J. Hatley, Imtiaz A. Pirbhai (1988). Strategien für die Echtzeit -Systemspezifikation. John Wiley und Sons Ltd. ISBN0-932633-04-8
  • Stephen J. Mellor und Paul T. Ward (1986). Strukturierte Entwicklung für Echtzeitsysteme: Implementierungsmodellierungstechniken: 003. Prentice Hall. ISBN0-13-854803-x
  • Edward Yourdon (1989). Moderne strukturierte Analyse, YourDon Press Computing Series, 1989, ISBN0-13-598624-9
  • Keith Edwards (1993). Strukturierte Echtzeit-Methoden, Systemanalyse. Wiley. ISBN0-471-93415-1

Externe Links