Softwarekonstruktion

Nicht zu verwechseln mit Software-Entwicklung.

Softwarekonstruktion ist ein Softwareentwicklung Disziplin. Es ist die detaillierte Schaffung von aussagekräftigem Arbeiten Software durch eine Kombination von Codierung, Überprüfung, Unit -Tests, Integrationstests, und Debuggen. Es ist mit allen anderen verbunden Softwareentwicklung Disziplinen am stärksten zu Software-Design und Softwaretest.[1]

Software -Bauwesen

Komplexität minimieren

Die Notwendigkeit, die Komplexität zu verringern, wird hauptsächlich durch die begrenzte Fähigkeit der meisten Menschen angetrieben, komplexe Strukturen und Informationen in ihren Arbeitsgedanken zu halten. Reduziert Komplexität wird erreicht durch Betonung der Schaffung von Code Das ist eher einfach und lesbar als klug. Minimierung Komplexität wird durch Gebrauch von Nutzung erreicht Standardsund durch zahlreiche spezifische Techniken in Codierung. Es wird auch von der unterstützt Konstruktionsorientierte Qualität Techniken.[2]

Veränderung vorwegnehmen

Vorweggenommenes Änderung hilft Software -Ingenieuren, eine erweiterbare Software aufzubauen, was bedeutet, dass sie ein Softwareprodukt verbessern können, ohne die zugrunde liegende Struktur zu stören.[2] Untersuchungen über 25 Jahre zeigten, dass die Kosten für Nacharbeiten 10- bis 100 -mal (5 bis 10 Mal für kleinere Projekte) teurer sein können, als die Anforderungen beim ersten Mal richtig zu machen. Angesichts der Tatsache, dass sich 25% der Anforderungen während des durchschnittlichen Projekts während des durchschnittlichen Projekts ändern, wird die Notwendigkeit, die Kosten für Nacharbeit zu senken, die Notwendigkeit einer Änderung der Erwartung von Veränderungen erläutert. [3]

Zur Überprüfung konstruieren

Konstruktion für Überprüfung bedeutet bauen Software So können Fehler leicht durch die ausgegrenzt werden Software -Ingenieure Schreiben der Softwaresowie während der unabhängigen testen und operative Aktivitäten. Spezifische Techniken, die das Konstruktion für die Konstruktion unterstützen Überprüfung Fügen Sie den folgenden Codierungsstandards zur Unterstützung ein Code -Bewertungen, Unit -Tests, organisieren Code zu unterstützen automatisierte Tests, und eingeschränkten Gebrauch von komplexen oder schwer zu erscheinendenverstehe Sprache Strukturen unter anderem.[2]

Wiederverwendung

Die systematische Wiederverwendung kann eine erhebliche Softwareproduktivität, Qualität und Kostenverbesserungen ermöglichen. Die Wiederverwendung hat zwei eng verwandte Facetten:[2]

  • Konstruktion zur Wiederverwendung: Erstellen Sie wiederverwendbare Software -Vermögenswerte.
  • Bau mit Wiederverwendung: Wiederverwendung von Software -Vermögenswerten beim Bau einer neuen Lösung.

Baustandards

Zu den Standards, ob extern (erstellt von internationalen Organisationen) oder intern (auf Unternehmensebene erstellt), die sich direkt auf Bauprobleme auswirken, gehören:[2]

Konstruktion verwalten

Konstruktionsmodell

Zahlreich Modelle wurden geschaffen, um sich zu entwickeln Softwareeinige davon betonen die Konstruktion mehr als andere. Etwas Modelle sind aus Sicht der Konstruktion linearer, wie die Wasserfall und Lebenszyklusmodelle mit inszeniertem Bereich. Diese Modelle Behandeln Sie die Konstruktion als Aktivität, die erst nach Abschluss erheblicher Voraussetzungstätigkeit auftritt - einschließlich detaillierter detaillierter Voraussetzungen Bedarf Arbeit, umfangreich Entwurf Arbeit und detailliert Planung. Andere Modelle sind mehr iterativ, wie zum Beispiel Evolutionsprototyping, Extremes Programmieren, und Gedränge. Diese Ansätze neigen dazu, die Konstruktion als Aktivität zu behandeln, die gleichzeitig mit anderen auftritt Software-Entwicklung Aktivitäten, einschließlich Bedarf, Entwurf, und Planung, oder überlappt sie.[1]

Bauplanung

Die Wahl der Bauarbeiten Methode ist ein wesentlicher Aspekt der Bauplanungstätigkeit. Die Wahl der Bauarbeiten Methode betrifft das Ausmaß, in dem Bauvoraussetzungen (z. Anforderungsanalyse, Software-Design, .. usw.) werden durchgeführt, die Reihenfolge, in der sie durchgeführt werden, und inwieweit sie vor Beginn der Bauarbeiten abgeschlossen werden sollen. Bauplanung definiert auch die Reihenfolge, in der Komponenten werden erstellt und integriert, die Software -Qualitätsmanagement Prozesse, die Zuweisung von Aufgabenzuweisungen zu spezifisch Software -Ingenieureund die anderen Aufgaben nach dem Auserwählten Methode.[1]

Konstruktionsmessung

Zahlreiche Konstruktionsaktivitäten und Artefakte können gemessen werden, darunter Code entwickelt, Code geändert, Code wiederverwendet, Code zerstört, Codekomplexität, Code-Inspektionsstatistik, Fehler-Fix- und Fehlerfindraten, Aufwand und Planung. Diese Messungen können nützlich sein, um den Bau zu verwalten, die Qualität während des Baus zu gewährleisten, den Bauprozess sowie aus anderen Gründen zu verbessern.[1]

Praktische Überlegungen

Die Softwarekonstruktion wird durch viele praktische Überlegungen angetrieben:

Bauentwurf

Um die unerwarteten Lücken in der zu berücksichtigen Software-DesignWährend der Softwarekonstruktion müssen einige Designänderungen in kleinerem oder größerem Maßstab vorgenommen werden, um Details der Software-Design.[4]

Niedrig Ausschwärmen ist eine der Entwurfsmerkmale, die von Forschern von Vorteil sind. Das Verstecken von Informationen erwies sich als nützliche Designtechnik in großen Programmen, die sie um den Faktor 4 leichter machten. [5]

Bausprachen

Zu den Konstruktionssprachen gehören alle Kommunikationsformen, mit denen ein Mensch eine ausführbare Problemlösung für einen Computer angeben kann. Dazu gehören Konfigurationssprachen, Toolkitsprachen und Programmiersprachen:[6]

  • Konfigurationssprachen sind Sprachen, in denen Software -Ingenieure Wählen Sie aus einem begrenzten Satz vordefinierter Optionen, um neue oder benutzerdefinierte Software -Installationen zu erstellen.
  • Toolkitsprachen werden verwendet, um Anwendungen auszubauen Toolkits und sind komplexer als Konfigurationssprachen.
  • Skriptsprachen sind Arten von Anwendungsprogrammiersprachen, die Skripte unterstützen, die häufig eher interpretiert als kompiliert werden.
  • Programmiersprachen sind die flexibelste Art von Konstruktionssprachen, die drei allgemeine Arten von Notation verwenden:
    • Sprachliche Notationen, die insbesondere durch die Verwendung von wortähnlichen Textketten zur Darstellung komplexer Softwarekonstruktionen und die Kombination solcher wortähnlichen Zeichenfolgen in Muster mit einer södlichen Syntax unterschieden werden.
    • Formale Notationen, die weniger auf intuitive, alltägliche Bedeutungen von Wörtern und Text und mehr auf Definitionen beruhen, die durch präzise, ​​eindeutige und formale (oder mathematische) Definitionen unterstützt werden.
    • Visuelle Notationen, die viel weniger auf die textorientierten Notationen sowohl sprachlicher als auch formaler Konstruktion beruhen und stattdessen auf die direkte visuelle Interpretation und Platzierung visueller Entitäten beruhen, die die zugrunde liegende Software darstellen.

Programmierer, die in einer Sprache arbeiten, die sie seit drei Jahren oder mehr verwendet, sind etwa 30 Prozent produktiver als Programmierer mit gleichwertigen Erfahrung, die neu in einer Sprache sind. Hochrangige Sprachen wie C ++, Java, SmallTalk und visuelle Basisrendite 5- bis 15-mal bessere Produktivität, Zuverlässigkeit, Einfachheit und Verständlichkeit als Sprachen mit niedrigem Niveau wie Assemblierung und C. äquivalenter Code benötigen weniger Zeilen zu in Sprachen auf hoher Ebene implementiert werden als in Sprachen auf niedrigerer Ebene.[7]

Codierung

Hauptartikel: Computerprogrammierung

Die folgenden Überlegungen gelten für die Softwarekonstruktionscodierungsaktivität:[8]

  • Techniken zum Erstellen verständlicher Quellcode, einschließlich Benennung und Quellcode -Layout. Eine Studie zeigte, dass der Aufwand für das Debuggen eines Programms minimiert wird, wenn die Namen der Variablen zwischen 10 und 16 Zeichen liegen.[9]
  • Gebrauch von Klassen, Aufzählte Typen, Variablen, genannt Konstantenund andere ähnliche Einheiten:
    • Eine von der NASA durchgeführte Studie zeigte, dass der Code in gut geeigneten Klassen den Code verdoppeln kann Wiederverwendbarkeit Im Vergleich zu dem Code, der unter Verwendung des Funktionsdesigns entwickelt wurde.[10][11]
    • Ein Experiment zeigte, dass Designs, die auf Arrays auf Arrays zugreifen, und nicht zufällig zu weniger Variablen und weniger variablen Referenzen führen.[12]
  • Verwendung von Kontrollstrukturen:
    • Ein Experiment ergab, dass Schleifen mit Exit verständlicher sind als andere Arten von Schleifen.[13]
    • In Bezug auf den Nestnesting in Schleifen und Bedingungen haben Studien gezeigt, dass Programmierer Schwierigkeiten haben, mehr als drei Nistnesteln zu verstehen.[13][14]
    • Es wurde gezeigt, dass die Komplexität des Kontrollflusss mit geringer Zuverlässigkeit und häufigen Fehlern korreliert.[14]
  • Umgang mit Fehlerbedingungen - sowohl geplante Fehler und Ausnahmen (Eingabe von schlechten Daten zum Beispiel)
  • Prävention von Sicherheitsverletzungen auf Code-Ebene (Pufferüberschreitungen oder Array -Index zum Beispiel Überläufe)
  • Ressource Verwendung durch Verwendung von Ausschlussmechanismen und Disziplin beim Zugriff auf seriell wiederverwendbar Ressourcen (einschließlich Themen oder Datenbankschlösser)
  • Quellcode Organisation (in Aussagen und Routinen):[11]
    • Höchst zusammenhängend Routinen erwiesen sich als weniger fehleranfällig als Routinen mit geringem Zusammenhalt. Eine Studie mit 450 Routinen ergab, dass 50 Prozent der stark kohäsiven Routinen fehlerfrei waren, verglichen mit nur 18 Prozent der Routinen mit geringer Kohäsion. Eine weitere Studie mit anderen 450 Routinen ergab, dass Routinen mit den höchsten Kupplung-To-Kohäsionsverhältnisse hatten 7-mal so viele Fehler wie diejenigen mit den niedrigsten Kopplung zu Kohäsionsverhältnissen und waren 20-mal so teuer für die Behebung.
    • Obwohl Studien nicht schlüssige Ergebnisse bezüglich der Korrelation zwischen Routinegrößen und der Fehlerrate in ihnen zeigten, fand jedoch eine Studie fest, dass Routinen mit weniger als 143 Codezeilen 2,4 -mal günstiger waren als größere Routinen. Eine andere Studie zeigte, dass der Code am wenigsten geändert werden musste, wenn Routinen durchschnittlich 100 bis 150 Codezeilen lagen. Eine andere Studie ergab, dass die strukturelle Komplexität und Datenmenge in einer Routine unabhängig von ihrer Größe mit Fehlern korreliert wurden.
    • Schnittstellen zwischen Routinen gehören zu den fehleranfälligsten Bereichen eines Programms. Eine Studie zeigte, dass 39 Prozent aller Fehler Fehler in der Kommunikation zwischen Routinen waren.
    • Unbenutzte Parameter korrelieren mit einer erhöhten Fehlerrate. In einer Studie hatten nur 17 bis 29 Prozent der Routinen mit mehr als einer nicht referenzierten Variablen keine Fehler, verglichen mit 46 Prozent in Routinen ohne ungenutzte Variablen.
    • Die Anzahl der Parameter einer Routine sollte maximal 7 sein, da die Forschung ergeben hat, dass Menschen im Allgemeinen mehr als etwa sieben Informationsbrocken gleichzeitig im Auge behalten können.
  • Quellcode Organisation (in Klassen, Paketeoder andere Strukturen). Unter Berücksichtigung von EindämmungDie maximale Anzahl von Datenmitgliedern in einer Klasse sollte 7 ± 2 nicht überschreiten. Untersuchungen haben gezeigt, dass diese Zahl die Anzahl diskreter Elemente ist, an die sich an eine Person bei der Ausführung anderer Aufgaben erinnern kann. Unter Berücksichtigung von NachlassDie Anzahl der Ebenen im Vererbungsbaum sollte begrenzt sein. Es wurde festgestellt, dass tiefe Vererbungsbäume signifikant mit erhöhten Fehlerraten verbunden sind. Bei der Betrachtung der Anzahl der Routinen in einer Klasse sollte sie so klein wie möglich gehalten werden. Eine Studie zu C ++ - Programmen hat einen Zusammenhang zwischen der Anzahl der Routinen und der Anzahl der Fehler festgestellt.[10]
  • Codedokumentation
  • Code -Abstimmung

Bauuntersuchungen

Der Zweck von Konstruktionstests besteht darin, die Lücke zwischen dem Zeitpunkt zu verringern, zu dem Fehler in den Code eingefügt werden, und der Zeit, die diese Fehler erkannt werden. In einigen Fällen werden Bauuntersuchungen durchgeführt, nachdem Code geschrieben wurde. Im Test-First-ProgrammierungEs werden Testfälle erstellt, bevor der Code geschrieben wird. Die Konstruktion umfasst zwei Testformen, die häufig von der durchgeführt werden Softwareentwickler wer schrieb das Code:[1]

Wiederverwendung

Implementierung Wiederverwendung von Software beinhaltet mehr als das Erstellen und Gebrauch Bibliotheken von Vermögenswerten. Es erfordert die Formalisierung der Praxis von Wiederverwendung Durch Integration von Wiederverwendungsprozessen und -aktivitäten in die Software -Lebenszyklus. Die Aufgaben im Zusammenhang mit der Wiederverwendung in der Softwarekonstruktion während Codierung und testen sind:[1]

  • Die Auswahl der wiederverwendbaren Einheiten, Datenbanken, Testverfahren, oder Testdaten.
  • Die Bewertung von Code oder Wiederverwendbarkeit testen.
  • Die Berichterstattung von Wiederverwendungsinformationen zu neuen Code, Testverfahren oder Testdaten.

Bauqualität

Die primären Techniken, die verwendet wurden, um die Qualität von zu gewährleisten Code Da es konstruiert ist, gehören:[15]

  • Unit -Tests und Integrationstests. Eine Studie ergab, dass die durchschnittlichen Defekt -Erkennungsraten der Test- und Integrationstests in Einheiten 30% bzw. 35% betragen.[16]
  • Test-First-Entwicklung
  • Gebrauch von Behauptungen und Defensivprogrammierung
  • Debuggen
  • Inspektionen. Eine Studie ergab, dass die durchschnittliche Erkennungsrate für formale Codeinspektionen von Defekte 60%beträgt. In Bezug auf die Kosten für die Suche nach Defekten ergab eine Studie, dass Code -Lesart 80% mehr Fehler pro Stunde als Tests erkannte. Eine andere Studie ergab, dass es sechsmal mehr kostet, Designfehler durch Tests zu erkennen als durch Inspektionen. Eine Studie von IBM zeigte, dass nur 3,5 Stunden erforderlich sind, um einen Defekt durch Codeinspektionen gegenüber 15–25 Stunden durch Tests zu finden. Microsoft hat festgestellt, dass es 3 Stunden dauert, einen Defekt zu finden und zu beheben, indem Codeinspektionen und 12 Stunden verwendet werden, um einen Defekt mit Tests zu finden und zu beheben. In einem 700.000-Tausend-Zeilen-Programm wurde berichtet, dass Code-Bewertungen mehrmals so kostengünstig waren wie die Tests.[16] Studien ergaben, dass Inspektionen zu 20% - 30% weniger Mängel pro 1000 Code -Zeilen als weniger formale Überprüfungspraktiken führen und die Produktivität um etwa 20% erhöhen. Formale Inspektionen dauern in der Regel 10% - 15% des Projektbudgets und senken die Gesamtprojektkosten. Die Forscher fanden heraus, dass mehr als 2 bis 3 Gutachter bei einer formalen Inspektion die Anzahl der gefundenen Mängel nicht erhöht, obwohl die Ergebnisse je nach Art des inspizierten Materials zu variieren scheinen.[17]
  • Technische Bewertungen. Eine Studie ergab, dass die durchschnittlichen Erkennungsraten für den Fehler informell Code -Bewertungen und Schreibtischprüfung sind 25% bzw. 40%.[16] Walkthroughs Es wurde festgestellt, dass eine Defekt -Erkennungsrate von 20% bis 40% aufweist, jedoch auch teuer ist, insbesondere wenn der Projektdruck steigt. Die NASA -Lesung wurde gefunden, um 3,3 Defekte pro Stunde des Aufwands gegenüber 1,8 Defekten pro Stunde zum Testen zu erkennen. Es findet auch 20% - 60% mehr Fehler über die Lebensdauer des Projekts als verschiedene Arten von Tests. Eine Studie mit 13 Bewertungen zu Überprüfungsversammlungen ergab, dass in Vorbereitung auf das Überprüfungssitzung 90% der Mängel festgestellt wurden, während während des Treffens nur rund 10% festgestellt wurden.[17]
  • Statische Analyse (IEEE1028)

Studien haben gezeigt, dass eine Kombination dieser Techniken verwendet werden muss, um eine hohe Defekt -Nachweisrate zu erreichen. Andere Studien zeigten, dass verschiedene Menschen dazu neigen, unterschiedliche Mängel zu finden. Eine Studie ergab, dass die extremes Programmieren Praktiken von Paar-Programmierung, Schreibtischprüfung, Unit -Tests, Integrationstests, und Regressionstests kann eine 90% ige Defekterkennungsrate erreichen.[16] Ein Experiment mit erfahrenen Programmierern ergab, dass sie im Durchschnitt 5 Fehler (bestenfalls von 15 Fehlern durch Testen) finden konnten.[18]

80% der Fehler konzentrieren sich in 20% der Klassen und Routinen des Projekts. 50% der Fehler finden sich in 5% der Projektklassen. IBM konnte den von den Kunden gemeldeten Mängeln um den Faktor zehn zu eins reduzieren und ihr Wartungsbudget in seinem IMS -System um 45% reduzieren, indem nur 31 von 425 Klassen repariert oder neu geschrieben wurden. Rund 20% der Routinen eines Projekts tragen zu 80% der Entwicklungskosten bei. Eine klassische Studie von IBM ergab, dass nur wenige fehleranfällige Routinen von OS/360 die teuersten Einheiten waren. Sie hatten rund 50 Defekte pro 1000 Codezeilen und kosteten die Kosten zehnmal so viel wie die Entwicklung des gesamten Systems.[18]

Integration

Eine Schlüsselaktivität während der Konstruktion ist die Integration von separat konstruierten Routinen, Klassen, Komponentenund Subsysteme. Darüber hinaus eine bestimmte Software System Möglicherweise muss in andere Software- oder Hardware -Systeme integriert werden. Bedenken im Zusammenhang mit der Konstruktionsintegration umfassen die Planung der Reihenfolge, in der Komponenten wird integriert sein und Gerüst erstellen, um Interim zu unterstützen Versionen des Software, feststellen, den Grad von testen und Qualität Arbeiten ausgeführt Komponenten Bevor sie integriert werden und Punkte in dem Projekt vorliegen, bei dem vorläuft Versionen des Software werden getestet.[1]

Konstruktionstechnologien

Objektorientierte Laufzeitprobleme

Objektorientierte Sprachen unterstützen eine Reihe von Laufzeitmechanismen, die die Flexibilität und Anpassungsfähigkeit der Programme vergrößern Datenabstraktion, Verkapselung, Modularität, Nachlass, Polymorphismus, und Betrachtung.[19][20]

Datenabstraktion ist der Prozess, durch den Daten und Programme mit einer ähnlichen Darstellung in Form ihrer Bedeutung definiert werden, während die Implementierungsdetails versteckt werden.[21] Die akademische Forschung zeigte, dass Datenabstraktion Programme etwa 30% einfacher zu verstehen als Funktionsprogramme.[10]

Behauptungen, Design nach Vertrag und Verteidigungsprogrammierung

Behauptungen sind ausführbare Prädikate, die in einem Programm platziert werden, das Laufzeitprüfungen des Programms ermöglicht.[19] Entwurf durch Vertrag ist ein Entwicklungsansatz, bei dem für jede Routine Voraussetzungen und Postkonditionen enthalten sind. Defensivprogrammierung Ist der Schutz eine Routine, wenn sie durch ungültige Eingaben unterbrochen werden.[22]

Fehlerhandhabung, Ausnahmebehandlung und Fehlertoleranz

Die Fehlerbehandlung bezieht sich auf die Programmierungspraxis, die Fehlerbedingungen zu antizipieren und zu kodieren, die bei der Ausführung des Programms auftreten können. Ausnahmebehandlung ist ein programmierübergreifendes Konstrukt oder Hardware-Mechanismus, das für das Auftreten von Ausnahmen ausgelegt ist, spezielle Bedingungen, die den normalen Programmausführung verändern.[23] Fehlertoleranz ist eine Sammlung von Techniken, die die Softwarezuverlässigkeit erhöhen, indem Fehler erfasst und dann nach Möglichkeit wiederhergestellt werden oder ihre Auswirkungen enthalten, wenn die Wiederherstellung nicht möglich ist.[22]

Staatliche und tabelletriebene Konstruktionstechniken

Staatliche Programmierung ist eine Programmierungstechnologie, die endliche Zustandsmaschinen verwendet, um das Programmverhalten zu beschreiben.[22] Eine tabellangesteuerte Methode ist ein Schema, das Tabellen verwendet, um Informationen zu suchen, anstatt logische Anweisungen zu verwenden (z. B. wenn und der Fall).[24]

Laufzeitkonfiguration und Internationalisierung

Die Laufzeitkonfiguration ist eine Technik, die variable Werte und Programmeinstellungen bindet, wenn das Programm ausgeführt wird, normalerweise durch Aktualisieren und Lesen von Konfigurationsdateien im Just-in-Time-Modus. Internationalisierung ist die technische Aktivität der Vorbereitung eines Programms, in der Regel interaktiver Software, um mehrere Orte zu unterstützen. Die entsprechende Aktivität, Lokalisierung, ist die Aktivität der Änderung eines Programms zur Unterstützung einer bestimmten Landessprache.[24]

Siehe auch

Anmerkungen

  1. ^ a b c d e f g Swebok Pierre Bourque; Robert Dupuis; Alain Abran; James W. Moore, Hrsg. (2004). "Kapitel 4: Softwarekonstruktion". Leitfaden für die Software -Engineering -Karosserie. IEEE Computer Society. S. 4–1–4–5. ISBN 0-7695-2330-7.
  2. ^ a b c d e Swebok 2014, p. 3-3.
  3. ^ McConnell 2004, Kapitel 3.
  4. ^ Swebok 2014, p. 3-5.
  5. ^ McConnell 2004, Kapitel 5.
  6. ^ Swebok 2014, p. 3-5-3-6.
  7. ^ McConnell 2004, Kapitel 4.
  8. ^ Swebok 2014, p. 3-6.
  9. ^ McConnell 2004, Kapitel 11.
  10. ^ a b c McConnell 2004, Kapitel 6.
  11. ^ a b McConnell 2004, Kapitel 7.
  12. ^ McConnell 2004, Kapitel 12.
  13. ^ a b McConnell 2004, Kapitel 16.
  14. ^ a b McConnell 2004, Kapitel 19.
  15. ^ Swebok 2014, p. 3-7.
  16. ^ a b c d McConnell 2004, Kapitel 20.
  17. ^ a b McConnell 2004, Kapitel 21.
  18. ^ a b McConnell 2004, Kapitel 22.
  19. ^ a b Swebok 2014, p. 3-8.
  20. ^ Thayer 2013, S. 140–141.
  21. ^ Thayer 2013, p. 140.
  22. ^ a b c Swebok 2014, p. 3-9.
  23. ^ Thayer 2013, p. 142.
  24. ^ a b Swebok 2014, p. 3-10.

Verweise

Externe Links