Entwicklung von Softwaremodulen für Computersystemsoftware. Das Arbeitsprogramm der Ausbildungspraxis für das Berufsmodul „Entwicklung von Softwaremodulen für Computersysteme“. Name der Übungsergebnisse
MINISTERIUM FÜR BILDUNG UND WISSENSCHAFT
Volksrepublik Donezk
STAATLICHER PROFESSIONELLER
BILDUNGSEINRICHTUNG
"INDUSTRIELLE UND WIRTSCHAFTLICHE HOCHSCHULE VON DONETSK"
ARBEITSPROGRAMM
Pädagogische Praxis UP.01
professional module PM.01 Entwicklung von Softwaremodulen für Computersysteme
Fachgebiet 09.02.03 "Programmieren in Computersystemen"
Zusammengestellt von:
Volkov Vladimir Aleksandrovich, Lehrer für Computerdisziplinen der Qualifikationskategorie "Spezialist der höchsten Kategorie", Staatliche Bildungseinrichtung "Donetsk Industrial and Economic College"
Das Programm wird genehmigt von: Vovk Pavel Andreevich, Direktor von "Smart IT Service"
| 1. PASS DES PRAXISPROGRAMMS | |
| 2. ERGEBNISSE DER PRAXIS | |
| 3. STRUKTUR UND INHALT DER PRAXIS | |
| 4. BEDINGUNGEN FÜR DIE ORGANISATION UND DURCHFÜHRUNG DER PRAXIS | |
| 5. ÜBERWACHUNG UND BEWERTUNG DER PRAXISERGEBNISSE |
1 PASS DES PROGRAMMS FÜR BILDUNGSPRAXIS UP. 01
1.1 Ort der Ausbildungspraxis UP.01
Das Programm der pädagogischen Praxis UP.01 des Berufsmoduls PM.01 „Entwicklung von Software-Softwaremodulen für Computersysteme“ Fachrichtung 09.02.03 „Programmierung in Computersystemen » erweiterte Gruppe 09.00.00 "Informatik u Technische Informatik“, im Hinblick auf die Beherrschung der Hauptberufsart (VPD):
Entwicklung von Softwaremodulen für Computersysteme und zugehörige Fachkompetenzen (PC):
| Führen Sie die Entwicklung von Spezifikationen für einzelne Komponenten durch. |
|
| Codeentwicklung durchführen Softwareprodukt basierend auf vorgefertigten Spezifikationen auf Modulebene. |
|
| Führen Sie das Debuggen von Programmmodulen mit spezialisierten Software-Tools. |
|
| Führen Sie Tests von Softwaremodulen durch. |
|
| Optimierung durchführen Programmcode Modul. |
|
| Entwickeln Sie Design- und technische Dokumentationskomponenten mit grafischen Spezifikationssprachen. |
Das Programm der pädagogischen Praxis UP.01 des Berufsmoduls PM.01 „Entwicklung von Software-Softwaremodulen für Computersysteme“ kann in der beruflichen Zusatzausbildung und Berufsausbildung von Mitarbeitern für die Fachrichtungen 09.02.03 Programmieren in Computersystemen mit Sekundarstufe ( abgeschlossen) Allgemeinbildung. Berufserfahrung ist nicht erforderlich.
1.2 Ziele und Zielsetzungenpädagogische Praxis UP.01
Zur Beherrschung der vorgegebenen Berufstätigkeit und der einschlägigen Berufskompetenzen muss der Studierende im Studiengang Pädagogisches Praktikum UP.01:
praktische Erfahrung haben:
Entwicklung eines Algorithmus für die Aufgabenstellung und dessen Umsetzung mittels Computergestütztes Design;
Entwicklung eines Softwareproduktcodes basierend auf einer fertigen Spezifikation auf Modulebene;
Verwendung von Tools in der Phase des Debuggens eines Softwareprodukts;
Testen eines Softwaremoduls gemäß einem bestimmten Szenario;
in der Lage sein:
die Entwicklung des Programmmodulcodes in modernen Programmiersprachen durchführen;
Erstellen Sie ein Programm gemäß dem entwickelten Algorithmus als separates Modul.
das Programm auf Modulebene debuggen und testen;
Softwaredokumentation erstellen;
Werkzeuge verwenden, um die Vorbereitung der Dokumentation zu automatisieren;
kennt:
Hauptphasen der Softwareentwicklung;
Grundlagen der strukturellen und objektorientierten Programmiertechnik;
Grundprinzipien des Debuggens und Testens von Softwareprodukten;
Methoden und Mittel zur Entwicklung der Technischen Dokumentation.
1.3 Anzahl der Wochen(Std.) für die Entwicklung des Programmspädagogische Praxis UP.01
Nur 1,5 Wochen, 54 Stunden.
2 ERGEBNISSE DER PRAXIS
Das Ergebnis des Bildungspraktikums UP.01 des Berufsmoduls PM.01 „Entwicklung von Software Softwaremodulen für Computersysteme“ ist die Entwicklung allgemeiner Kompetenzen (OK):
| Name des Übungsergebnisses |
|
| - |
|
| OK 2. Organisieren Sie ihre eigenen Aktivitäten, wählen Sie Standardmethoden und Methoden zur Erfüllung beruflicher Aufgaben aus und bewerten Sie deren Wirksamkeit und Qualität. | |
| OK 3. Treffen Sie Entscheidungen in Standard und nicht standardmäßige Situationen und Verantwortung für sie übernehmen. | |
| OK 4. Suchen und verwenden Sie die Informationen, die für die effektive Umsetzung beruflicher Aufgaben, berufliche und persönliche Entwicklung erforderlich sind. | |
| OK 5. Verwenden Sie Informations- und Kommunikationstechnologien bei beruflichen Aktivitäten. | |
| OK 6. Arbeiten Sie im Team und im Team, kommunizieren Sie effektiv mit Kollegen, Management, Verbrauchern. | |
| OK 7. Übernehmen Sie die Verantwortung für die Arbeit der Teammitglieder (Untergebenen) und für das Ergebnis der Erledigung von Aufgaben. | - |
| Qualifikationen |
|
| OK 9. Navigieren Sie unter Bedingungen des häufigen Technologiewechsels in der beruflichen Tätigkeit. |
Fachliche Kompetenzen (PC):
| Art der beruflichen Tätigkeit | Name der Übungsergebnisse |
|
| Beherrschung der Hauptart der beruflichen Tätigkeit | Nutzung von Ressourcen lokaler und globaler Computernetzwerke; Verwaltung von Datendateien auf lokalen Wechselspeichergeräten sowie auf lokalen Festplatten Computernetzwerk und im Internet; Drucken, Replizieren und Kopieren von Dokumenten auf einem Drucker und anderen Bürogeräten. laufende Kontrolle in Form eines Berichtes über jede praktische Arbeit. Modulreifeprüfung. |
|
| Alphabetisierung und Genauigkeit der Arbeit in Anwendungsprogrammen: Text- und Grafikeditoren, Datenbanken, Präsentationseditor; die Geschwindigkeit der Suche nach Informationen in den Inhalten von Datenbanken. |
||
| Genauigkeit und Kompetenz der E-Mail-Einstellungen, Server- und Client-Software: die Geschwindigkeit der Informationssuche unter Verwendung von Technologien und Diensten des Internets; Genauigkeit und Kompetenz bei der Eingabe und Übertragung von Informationen unter Verwendung von Internettechnologien und -diensten. |
||
| Kompetenz in der Verwendung von Methoden und Mitteln zum Schutz von Informationen vor unbefugtem Zugriff; Korrektheit und Genauigkeit der Datensicherung und -wiederherstellung; |
||
| Alphabetisierung und Genauigkeit Dateisysteme, verschiedene Dateiformate, Dateiverwaltungsprogramme; |
||
| Pflege von Berichten und technischen Dokumentationen. |
3 AUFBAU UND INHALT DES PROGRAMMSTRAININGSPRAXIS UP.01
3.1 Themenplan
| Codes generierter Kompetenzen | Name des Berufsmoduls | Umfang der Zeit, der Praxis zugeordnet (in Wochen, Std.) | Termine |
| PC 1.1 - PC 1.6 | PM.01 „Entwicklung von Softwaremodulen für Computersysteme“ | 1,5 Wochen 54 Stunden |
3.2 Inhalte üben
| Aktivitäten | Arten von Jobs | Name der akademischen Disziplinen, interdisziplinäre Lehrveranstaltungen mit Themenangabe, Gewährleistung der Ausführung von Arten von Arbeiten | Stundenzahl (Wochen) |
|
| „Beherrschung der Hauptart der beruflichen Tätigkeit » | Thema 1. Einführung. Algorithmen zur Lösung von Problemen. Die Struktur des linearen Algorithmus. Die Struktur des zyklischen Algorithmus. Algorithmus eines Unterprogramms (Funktion). | Fundiertes Wissen über die Grundlagen der Erstellung von Spezialobjekten | ||
| Thema2 . Umgebung Scratch (Scratch). | Fundiertes Wissen über die Grundlagen von PFundiertes Wissen über die Grundlagen von Animationseffekten an Objekten; Verwendung von Hyperlinks und Schaltflächen; Demo-Setup; Präsentationen in verschiedenen Formaten gespeichert. | MDK.01.01 „Systemprogrammierung“ | ||
| Thema 3 . Erstellen eines Trainingsprogramms (Lektion aus dem Fach). | Fundiertes Wissen über die Grundlagen der Datenanalyse mit Prozessorfunktionen | MDK.01.02 „Angewandte Programmierung“ | ||
| Thema 4. Entwicklung von Spielprogrammen. | Fundiertes Wissen über die Grundlagen der Berechnung der endgültigen Merkmale | MDK.01.01 „Systemprogrammierung“ | ||
| Thema 5. Grafische Programmiersprache LabVIEW. | Fundiertes Wissen über die Grundlagen zur Erstellung eines Prozessortests. | MDK.01.02 „Angewandte Programmierung“ | ||
| Thema 6. Erstellen einer Anwendung mit LabVIEW. | Gebildete Kenntnisse über die Grundlagen des Benutzerdialogs mit dem System | MDK.01.02 „Angewandte Programmierung“ | ||
| Thema 7 Wiederverwendung eines Fragments des Programms. | Fundiertes Wissen über die Bediener und Funktionen des Systems. | MDK.01.02 „Angewandte Programmierung“ | ||
| Thema 8 LabVIEW-Workshop. Arbeitsschutz bei der Arbeit mit einem Computer am Arbeitsplatz des Benutzers. | Fundierte Kenntnisse zur Berechnung elementarer Funktionen. Fundiertes Wissen zum Arbeitsschutz. | MDK.01.02 „Angewandte Programmierung“. OP.18 „Arbeitsschutz“ | ||
| Thema 9 Schlussfolgerungen. Erstellung eines Praxisberichtes. | Analysefähigkeiten ausgebildet Computertechnologie, Problemlösungsfähigkeiten werden gebildet. | MDK.01.01 „Systemprogrammierung“ MDK.01.02 „Angewandte Programmierung“ MDK.04.01 „Office-Software“ |
4 BEDINGUNGEN DER ORGANISATION UND DURCHFÜHRUNG
BILDUNGSPRAXIS AUF. 01
4.1 Dokumentationsanforderungen, für die Praxis notwendig:
Arbeitsprogramm pädagogische Praxis UP.01 des Berufsmoduls PM.01. "Entwicklung von Softwaremodulen für Computersysteme" ist Teil des Ausbildungsprogramms für mittlere Spezialisten durch die staatliche Berufsbildungseinrichtung "Donetsk Industrial and Economic College" gemäß dem staatlichen Bildungsstandard der sekundären Berufsbildung in der Fachrichtung 09.02.03 „Programmieren in Computersystemen“, aufbauend auf dem Curriculum des Fachgebiets, dem Arbeitsprogramm in den Disziplinen MDK.01.01 „Systemprogrammierung“, MDK01.02 „Angewandte Programmierung“, methodische Empfehlungen zur pädagogischen und methodischen Unterstützung der Praxis der Studierenden Mastering Bildungsprogramme der beruflichen Sekundarbildung.
4.2 Anforderungen an die pädagogische und methodische Unterstützung der Praxis:
Liste der genehmigten Aufgaben nach Art der Arbeit, Richtlinien für Studierende zur Durchführung von Arbeiten, Empfehlungen zur Umsetzung von Praxisberichten.
4.3 Logistikanforderungen:
Die Organisation der industriellen Praxis erfordert das Vorhandensein von Klassenzimmern und Labors.
Büroausstattung und Arbeitsplätze:
Sitzplätze entsprechend der Anzahl der Studierenden (Tisch, Computer, Stuhl);
Lehrerarbeitsplatz (Tisch, Computer, Stuhl);
Schrank zur Aufbewahrung von Lehrmitteln und Informationsträgern;
Aufgaben für einen individuellen Lernansatz, Organisation selbstständiger Arbeiten und Übungen, ein Student am Computer;
Referenz- und Methodenliteratur;
eine Reihe von System-, Anwendungs- und Schulungsprogrammen für PCs auf optischen und elektronischen Medien;
Zeitschrift für die Unterweisung von Studenten zum Arbeitsschutz;
eine Reihe von Lehrmitteln.
Technische Trainingshilfen:
Bildungs-PCs;
Reihe von interaktiven Geräten (Projektor, Bildschirm, Lautsprecher);
Feuerlöschmittel (Feuerlöscher).
Klassentafel;
Personalcomputer mit lizenzierter Software;
Laserdrucker;
Ausstattung des Kabinetts und Arbeitsplätze von Entwicklungswerkzeugen: persönliche Computer(Monitor, Systemeinheit, Tastatur, Maus), eine Reihe von pädagogischen und methodischen Dokumentationen, Software in Übereinstimmung mit dem Inhalt der Disziplin (Schalen Programmiersprachen).
Alle Computer im Klassenzimmer sind miteinander verbunden lokales Netzwerk, haben Zugriff auf die Netzwerkspeicherung von Informationen und haben Zugriff auf das Internet.
Kommunikationsausrüstung:
Netzwerkadapter;
Netzwerkkabel;
WiFi-Wireless-Ausrüstung.
Komponenten für die Installation von Netzwerken, Ausrüstung für die Installation.
4.4 Liste der pädagogischen Publikationen, Internet-Ressourcen, weiterführende Literatur
Hauptquelle:
Oliver V.G. Netzwerk Betriebssysteme: Lehrbuch für Universitäten / V. G. Olifer, N. A. Olifer. - 2. Aufl. - St. Petersburg: Peter, 2009,2008. - 668 S.:
E. Tanenbaum. Betriebssysteme. Entwicklung und Umsetzung. St. Petersburg: Piter, 2006. - 568 S.
Pupkov K.A. Beherrschung des Unix-Betriebssystems / K. A. Pupkov, A. S. Chernikov, N. M. Yakusheva. - Moskau: Radio und Kommunikation, 1994. - 112 p.
L. Beck Einführung in die Systemprogrammierung - M.: Mir, 1988.
Grekul V.I., Denishchenko G.N., Korovkina N.L. Gestaltung von Informationssystemen / Moskau: Binom, 2008. - 304 p.
Lipaev, V. V. Software-Engineering. Methodische Grundlagen [Text]: Proc. / V. V. Lipajew; Bundesland. un-t - Wirtschaftshochschule. - M.: TEIS, 2006. - 608 S.
Lavrishcheva E. M., Petrukhin V. A. Methoden und Mittel der Softwareentwicklung. - Lehrbuch
Ian Somerville. Software Engineering, 6. Auflage.: Per. aus dem Englischen. -M. : Williams Publishing House, 2002.–624 p.
Excel 2010: Professionelle Programmierung in VBA.: Per. aus dem Englischen. - M.: LLC „I.D. Williams“, 2012. - 944 S. : krank. - Parallel. Titte. Englisch
Fowler M. Refactoring: Verbesserung des bestehenden Codes. Aus dem Englischen. – St. Petersburg: Symbol Plus, 2003. – 432 p.
Zusätzliche Quellen:
Wolkow V.A. METHODISCHE ANLEITUNG zur Durchführung der praktischen Arbeit in der Disziplin „Systemprogrammierung“, Donetsk: DONPEK, 2015.
Wolkow V.A. Richtlinien zur Durchführung des Kursprojekts, Donetsk: DONPEC, 2015.
Internet- Ressourcen:
Systemprogrammierung [elektronische Ressource] / Zugriffsmodus: http://www.umk3.utmn.ru.
Software und Internetressourcen: http://www.intuit.ru
Literatur nach Disziplinen - http://www.internet-technologies.ru/books/
Elektronisches Lehrbuch "Einführung in die Softwareentwicklung" - http://www.intuit.ru/studies/professional_skill_improvements/1419/info
Elektronisches Lehrbuch "Programmiertechnik" - http://bourabai.kz/alg/pro.htm
4.5 Anforderungen an Praxisleiter einer Bildungseinrichtung und -organisation
Anforderungen an Praxisleiter einer Bildungseinrichtung:
Ingenieur- und Lehrpersonal: Absolventen - Lehrer interdisziplinärer Studiengänge und allgemeiner Fachrichtungen. Erfahrungen in Organisationen des jeweiligen Berufsfeldes sind zwingend erforderlich.
Master of Industrial Training: Verfügbarkeit der Qualifikationskategorie 5-6 mit obligatorischem Praktikum in spezialisierten Organisationen mindestens einmal alle 3 Jahre. Erfahrungen in Organisationen des jeweiligen Berufsfeldes sind zwingend erforderlich.
5 ÜBERWACHUNG UND AUSWERTUNG DER ERGEBNISSE
BILDUNGSPRAXIS AUF. 01
Form des Berichts über die pädagogische Praxis UP.01 - ein Bericht über die Praxis, der gemäß den Anforderungen der methodischen Empfehlungen erstellt wurde.
| Ergebnisse (beherrschte Fachkompetenzen) | Hauptmerkmale Ergebnis der Vorbereitung | Formen und Methoden Kontrolle |
| PC1.1. Führen Sie die Entwicklung von Spezifikationen für einzelne Komponenten durch | Entwicklung eines Algorithmus für die Aufgabenstellung und dessen Umsetzung mittels Computer Aided Design | Fachkundige Beobachtung und Bewertung der studentischen Aktivitäten im Mastering-Prozess Bildungsprogramm im praktischen Unterricht, bei der Durchführung von Arbeiten zur pädagogischen und industriellen Praxis. |
| PC1.2. Führen Sie die Entwicklung von Softwareproduktcode basierend auf vorgefertigten Spezifikationen auf Modulebene durch. | kennen die Grundprinzipien der strukturellen und objektorientierten Programmiertechnik. Die Entwicklung des Programmmodulcodes in modernen Programmiersprachen durchzuführen. |
|
| PC1.3. Führen Sie das Debuggen von Programmmodulen mit speziellen Softwaretools durch | Debuggen und Testen des Programms auf Modulebene durchführen. |
|
| PC1.4. Führen Sie Tests von Softwaremodulen durch. | Erstellen Sie ein Programm nach dem entwickelten Algorithmus als separates Modul. |
|
| PC1.5. Modulcodeoptimierung durchführen | Entwicklung eines Softwareproduktcodes auf Basis einer fertigen Spezifikation auf Modulebene. |
|
| PC1.6. Entwickeln Sie Design- und technische Dokumentationskomponenten mit grafischen Spezifikationssprachen | kennen Methoden und Mittel zur Erstellung technischer Dokumentationen. Bereiten Sie die Softwaredokumentation vor. Verwenden Sie Tools, um die Dokumentation zu automatisieren. |
Formen und Methoden der Lernergebniskontrolle und -evaluation sollen es den Studierenden ermöglichen, nicht nur die Ausbildung beruflicher Kompetenzen, sondern auch die Entwicklung allgemeiner Kompetenzen und der sie vermittelnden Fähigkeiten zu überprüfen.
| Ergebnisse (beherrschte allgemeine Kompetenzen) | Hauptindikatoren für die Bewertung des Ergebnisses | Formen und Methoden der Kontrolle und Auswertung |
| OK 1. Verstehen Sie das Wesen und die gesellschaftliche Bedeutung Ihres zukünftigen Berufes, zeigen Sie stetiges Interesse daran. | Nachweis von ständigem Interesse am zukünftigen Beruf; - die Gültigkeit der Anwendung von gemeisterten beruflichen Kompetenzen; | Fachliche Beobachtung und Beurteilung im praktischen Unterricht bei der Durchführung von Arbeiten zur industriellen Praxis; |
| OK 2. Organisieren Sie ihre eigenen Aktivitäten, bestimmen Sie die Methoden und Wege zur Erfüllung beruflicher Aufgaben, bewerten Sie ihre Wirksamkeit und Qualität. | Begründung der Zielsetzung, Auswahl und Anwendung von Methoden und Methoden zur Lösung beruflicher Probleme; Durchführung einer Selbstanalyse und Korrektur der Ergebnisse der eigenen Arbeit | Bewertung im praktischen Unterricht in der Arbeitsausführung; Beobachtung während des Übens; Selbstbeobachtung |
| OK 3. Probleme lösen, Risiken einschätzen und Entscheidungen in nicht standardmäßigen Situationen treffen. | Die Effektivität der Entscheidungsfindung von Standard- und Nicht-Standard-beruflichen Aufgaben in einer bestimmten Zeit; Die Wirksamkeit des Plans zur Optimierung der Qualität der geleisteten Arbeit | Interpretation der Ergebnisse der Überwachung der Aktivitäten des Schülers bei der Erledigung von Aufgaben |
| OK 4. Suchen, analysieren und bewerten Sie die Informationen, die für die Einstellung und Lösung beruflicher Probleme sowie für die berufliche und persönliche Entwicklung erforderlich sind. | Auswahl und Analyse der notwendigen Informationen zur klaren und schnellen Umsetzung beruflicher Aufgaben, beruflicher und persönlicher Weiterentwicklung | Sachverständigengutachten im Laufe der Arbeit; Selbstbeherrschung beim Stellen und Lösen von Problemen |
| OK 5. Nutzung von Informations- und Kommunikationstechnologien zur Verbesserung beruflicher Aktivitäten. | Fähigkeit, Informations- und Kommunikationstechnologien zur Lösung beruflicher Probleme einzusetzen | Beurteilung der Aufgaben |
| OK 6. Arbeiten Sie in einem Team und Team, sorgen Sie für seinen Zusammenhalt, kommunizieren Sie effektiv mit Kollegen, Management, Verbrauchern. | Fähigkeit zur Interaktion mit einer Gruppe, Lehrern, Meister der industriellen Ausbildung | |
| OK 7. Setzen Sie Ziele, motivieren Sie die Aktivitäten der Untergebenen, organisieren und kontrollieren Sie ihre Arbeit mit der Übernahme der Verantwortung für das Ergebnis der Aufgaben. | - Selbstanalyse und Korrektur der Ergebnisse der eigenen Arbeit und der Arbeit des Teams | Beobachtung des Arbeitsfortschritts in der Gruppe im Prozess der Produktionspraxis |
| OK 8. Aufgaben der fachlichen und persönlichen Weiterentwicklung selbstständig bestimmen, Selbstbildung betreiben, Weiterbildung bewusst planen. | Organisation der unabhängigen Arbeit zur Bildung eines kreativen und professionellen Images; Organisation der Arbeit zur Selbstbildung und Verbesserung Qualifikationen | Beobachtung und Bewertung im Prozess der industriellen Praxis; Reflektierende Analyse (Algorithmus der Schülerhandlungen); Praxistagebuch; Studentische Portfolioanalyse |
| OK 9. Seien Sie bereit, Technologien in beruflichen Aktivitäten zu ändern. | Analyse von Innovationen im Bereich technologischer Verfahren zur Entwicklung und Herstellung von Kleidungsstücken | Bewertung von Lösungen für situative Probleme; Wirtschafts- und organisationspädagogische Spiele; Beobachtung und Auswertung im praktischen Unterricht, im Prozess der Produktionspraxis |
Vorlesung 8. Entwicklung eines Softwaremoduls
Das Verfahren zur Entwicklung eines Softwaremoduls. Strukturprogrammierung und Schritt-für-Schritt-Detaillierung. Das Konzept des Pseudocodes. Softwaremodulsteuerung.
8.1. Das Verfahren zur Entwicklung eines Softwaremoduls.
Bei der Entwicklung eines Softwaremoduls empfiehlt es sich, folgende Reihenfolge einzuhalten:
Studium und Überprüfung der Modulspezifikation, Sprachauswahl
Programmierung;
Wahl des Algorithmus und der Datenstruktur;
Modulprogrammierung;
den Text des Moduls aufpolieren;
Modulprüfung;
Modulzusammenstellung.
Der erste Schritt bei der Entwicklung eines Softwaremoduls ist weitgehend eine durchgängige Kontrolle der Struktur des Programms von unten: Der Entwickler muss sich durch Studium der Spezifikation des Moduls vergewissern, dass sie für ihn verständlich und zur Entwicklung ausreichend ist dieses Modul. Am Ende dieses Schritts wird eine Programmiersprache ausgewählt: Obwohl die Programmiersprache bereits für die gesamte PS vordefiniert sein kann, kann in einigen Fällen (wenn das Programmiersystem dies zulässt) eine andere Sprache ausgewählt werden, die für die Implementierung besser geeignet ist dieses Moduls (z. B. Assemblersprache).
Im zweiten Schritt der Entwicklung eines Softwaremoduls gilt es herauszufinden, ob bereits Algorithmen zur Lösung des gestellten Problems bekannt sind oder diesem nahe kommen. Und wenn es einen geeigneten Algorithmus gibt, dann ist es ratsam, ihn zu verwenden. Die Auswahl geeigneter Datenstrukturen, die verwendet werden, wenn das Modul seine Funktionen ausführt, bestimmt weitgehend die Logik und die Qualitätsindikatoren des zu entwickelnden Moduls und sollte daher als sehr wichtige Entscheidung betrachtet werden.
Im dritten Schritt wird der Text des Moduls in der gewählten Programmiersprache erstellt. Die Fülle aller möglichen Details, die bei der Umsetzung der in der Modulspezifikation spezifizierten Funktionen berücksichtigt werden müssen, kann leicht zu einem sehr unübersichtlichen Text mit vielen Fehlern und Ungenauigkeiten führen. Das Auffinden von Fehlern in einem solchen Modul und das Vornehmen der erforderlichen Änderungen daran kann eine sehr zeitaufwändige Aufgabe sein. Daher ist es sehr wichtig, eine technologisch begründete und praktisch erprobte Programmierdisziplin zu verwenden, um den Text des Moduls aufzubauen. Erstmals machte Dijkstra darauf aufmerksam und formulierte und begründete die Grundprinzipien der strukturierten Programmierung. Viele der in der Praxis weit verbreiteten Programmierdisziplinen basieren auf diesen Prinzipien. Am gebräuchlichsten ist die Drill-Down-Disziplin, die in den Abschnitten 8.2 und 8.3 ausführlich besprochen wird.
Der nächste Schritt in der Entwicklung des Moduls besteht darin, den Text des Moduls gemäß der PS-Qualitätsspezifikation in die endgültige Form zu bringen. Bei der Programmierung eines Moduls konzentriert sich der Entwickler auf die korrekte Implementierung der Funktionen des Moduls, lässt Kommentare unvollendet und lässt einige Verstöße gegen die Anforderungen an den Stil des Programms zu. Wenn er den Text eines Moduls aufpoliert, sollte er die Kommentare im Text bearbeiten und möglicherweise zusätzliche Kommentare einfügen, um die erforderlichen Qualitätsprimitive bereitzustellen. Zum gleichen Zweck wird der Programmtext stilistisch aufbereitet.
Der Modulverifizierungsschritt ist eine manuelle Überprüfung der internen Logik des Moduls, bevor es (durch Ausführen auf dem Computer) debuggt, implementiert wird allgemeines Prinzip, formuliert für die diskutierte Programmiertechnologie, über die Notwendigkeit, die Entscheidungen zu kontrollieren, die in jeder Phase der Entwicklung des PS getroffen werden (siehe Vortrag 3). Modulvalidierungsmethoden werden in Abschnitt 8.4 besprochen.
Der letzte Schritt der Entwicklung eines Moduls schließlich besteht darin, die Modulvalidierung (mithilfe des Compilers) abzuschließen und mit dem Debugging-Prozess des Moduls fortzufahren.
8.2. Strukturelle Programmierung.
Beim Programmieren eines Moduls sollte berücksichtigt werden, dass das Programm nicht nur für einen Computer, sondern auch für eine Person verständlich sein muss: sowohl für den Modulentwickler als auch für die Personen, die das Modul prüfen, und die Texter, die Tests für die Fehlersuche vorbereiten Modul, und die PS-Betreuer, die die erforderlichen Änderungen am Modul vornehmen, müssen die Logik des Moduls wiederholt parsen. In modernen Programmiersprachen gibt es genügend Werkzeuge, um diese Logik beliebig durcheinanderzubringen, wodurch das Modul für einen Menschen schwer verständlich und in der Folge unzuverlässig oder schwer wartbar wird. Daher muss darauf geachtet werden, geeignete Sprachwerkzeuge auszuwählen und einer bestimmten Programmierdisziplin zu folgen. Erstmals machte Dijkstra darauf aufmerksam und schlug vor, ein Programm als Zusammensetzung mehrerer Arten von Kontrollstrukturen (Strukturen) aufzubauen, was die Verständlichkeit der Logik des Programms stark erhöhen kann. Die Programmierung nur mit solchen Konstrukten wurde als strukturelle Programmierung bezeichnet.
Die Hauptkonstrukte der strukturierten Programmierung sind: Folgen, Verzweigen und Wiederholen (siehe Abbildung 8.1). Bestandteile dieser Konstruktionen sind verallgemeinerte Operatoren (Verarbeitungsknoten) S, S1, S2 und eine Bedingung (Prädikat) P. Als verallgemeinerter Operator kann entweder ein einfacher Operator der verwendeten Programmiersprache (Zuweisung, Eingabe, Ausgabe, Prozedur Aufrufe) oder ein Programmfragment, das eine Zusammensetzung der wichtigsten Kontrollstrukturen der strukturierten Programmierung ist. Wesentlich ist, dass jede dieser Strukturen steuerungstechnisch nur einen Eingang und einen Ausgang hat. Somit hat auch der verallgemeinerte Operator nur einen Eingang und einen Ausgang.
Es ist auch sehr wichtig, dass diese Konstruktionen bereits mathematische Objekte sind (was im Wesentlichen den Grund für den Erfolg der strukturierten Programmierung erklärt). Es ist bewiesen, dass es für jedes unstrukturierte Programm möglich ist, ein funktional äquivalentes (dh das gleiche Problem lösendes) strukturiertes Programm zu konstruieren. Bei strukturierten Programmen können einige Eigenschaften mathematisch bewiesen werden, was es ermöglicht, einige Fehler im Programm zu entdecken. Diesem Thema wird ein eigener Vortrag gewidmet sein.
Die strukturierte Programmierung wird manchmal auch als „Programmierung ohne GEHE ZU“ bezeichnet. Hier geht es jedoch nicht um die GO TO-Anweisung, sondern um deren willkürliche Verwendung. Sehr oft wird bei der Implementierung einer strukturierten Programmierung in einigen Programmiersprachen (z. B. in FORTRAN) der Übergangsoperator (GO TO) verwendet, um strukturelle Strukturen zu implementieren, ohne die Hauptvorteile der strukturierten Programmierung zu beeinträchtigen. Es sind die "nicht-strukturellen" Sprunganweisungen, die das Programm verwirren, insbesondere der Sprung zu einer Anweisung, die sich im Modultext über (früher) der ausgeführten Sprunganweisung befindet. Versuchen Sie jedoch, die Sprunganweisung in einigen zu vermeiden einfache Fälle kann zu schwerfällig strukturierten Programmen führen, was deren Übersichtlichkeit nicht verbessert und die Gefahr birgt, zusätzliche Fehler in den Text des Moduls einzubringen. Daher kann empfohlen werden, die Verwendung der Sprunganweisung wo immer möglich zu vermeiden, jedoch nicht auf Kosten der Programmübersichtlichkeit.
Nützliche Fälle der Verwendung des Übergangsoperators umfassen das Verlassen einer Schleife oder Prozedur unter einer speziellen Bedingung, die die Arbeit dieser Schleife oder dieser Prozedur "früh" beendet, d.h. Beenden der Arbeit irgendeiner Struktureinheit (generalisierter Operator) und dadurch nur lokal Verletzung der Strukturiertheit des Programms. Große Schwierigkeiten (und Verkomplizierung der Struktur) bereitet die strukturelle Umsetzung der Reaktion auf außergewöhnliche (oftmals fehlerhafte) Situationen, da dies nicht nur ein frühzeitiges Ausscheiden aus der strukturellen Einheit, sondern auch die notwendige Verarbeitung (Exklusion) dieser Situation erfordert (z. B. Ausgabe einer geeigneten Diagnoseinformation). Der Ausnahmebehandler kann sich auf jeder Ebene der Programmstruktur befinden, und es kann von verschiedenen niedrigeren Ebenen aus auf ihn zugegriffen werden. Aus technologischer Sicht durchaus akzeptabel ist die folgende „nicht-strukturelle“ Umsetzung der Reaktion auf Ausnahmesituationen. Ausnahmebehandler werden an das Ende der einen oder anderen Struktureinheit gestellt, und jeder solcher Behandler ist so programmiert, dass er nach Beendigung seiner Arbeit die Struktureinheit verlässt, an deren Ende er angeordnet ist. Ein solcher Handler wird vom Sprungoperator aus der gegebenen Struktureinheit (einschließlich jeder verschachtelten Struktureinheit) aufgerufen.
8.3. Schritt-für-Schritt-Detaillierung und das Konzept des Pseudocodes.
Die strukturierte Programmierung gibt Empfehlungen, wie der Text eines Moduls aussehen sollte. Es stellt sich die Frage, wie ein Programmierer vorgehen sollte, um einen solchen Text zu konstruieren. Manchmal beginnt die Programmierung eines Moduls mit dem Aufbau seines Blockdiagramms, das allgemein die Logik seines Betriebs beschreibt. Jedoch Moderne Technologie Die Programmierung empfiehlt dies nicht. Obwohl Flussdiagramme eine sehr anschauliche Darstellung der Logik eines Moduls liefern, entsteht, wenn sie in einer Programmiersprache codiert sind, eine ganz spezifische Fehlerquelle: Das Abbilden von im Wesentlichen zweidimensionalen Strukturen, wie etwa Flussdiagrammen, auf linearen Text, der ein Modul darstellt, enthält die Gefahr, die Logik des Moduls zu verzerren, mehr als psychologisch ziemlich schwer einzuhalten hohes Niveau Aufmerksamkeit bei der Überprüfung. Eine Ausnahme kann der Fall sein, wenn zum Erstellen von Flussdiagrammen ein grafischer Editor verwendet wird und diese so formalisiert werden, dass daraus automatisch Text in einer Programmiersprache generiert wird (wie dies beispielsweise in der R-Technologie möglich ist).
Als Hauptmethode zum Aufbau von Modultexten empfiehlt die moderne Programmiertechnik eine schrittweise Detaillierung. Der Kern dieser Methode besteht darin, den Prozess der Entwicklung des Modultextes in mehrere Schritte zu unterteilen. Der erste Schritt beschreibt allgemeines Schema die Bedienung des Moduls in einer sichtbaren linearen Textform (d. h. unter Verwendung sehr großer Konzepte), und diese Beschreibung ist nicht vollständig formalisiert und konzentriert sich auf die menschliche Wahrnehmung. Bei jedem nächsten Schritt wird eines der Konzepte (wir nennen es verfeinert) verfeinert und detailliert, das (in der Regel nicht formalisiert) in jeder Beschreibung verwendet wird, die in einem der vorherigen Schritte entwickelt wurde. Als Ergebnis dieses Schritts wird eine Beschreibung des ausgewählten Konzepts, das verfeinert wird, entweder in Bezug auf die Basisprogrammiersprache (d. h. das zur Darstellung ausgewählte Modul) oder in der gleichen Form wie im ersten Schritt unter Verwendung neuer zu verfeinernder Konzepte erstellt . Dieser Prozess endet, wenn alle zu verfeinernden Konzepte schließlich in der zugrunde liegenden Programmiersprache ausgedrückt werden. Der letzte Schritt besteht darin, den Text des Moduls in der Basisprogrammiersprache zu erhalten, indem alle Vorkommen der verfeinerten Konzepte durch ihre spezifizierten Beschreibungen ersetzt werden und alle Vorkommen strukturierter Programmierkonstrukte unter Verwendung dieser Programmiersprache ausgedrückt werden.
Das schrittweise Drill-down beinhaltet die Verwendung einer teilweise formalisierten Sprache zur Darstellung dieser Beschreibungen, die als Pseudocode bezeichnet wird. Diese Sprache ermöglicht die Verwendung aller strukturierten Programmierkonstrukte, die formalisiert sind, zusammen mit informellen Fragmenten natürlicher Sprache, um generische Anweisungen und Bedingungen darzustellen. Entsprechende Fragmente in der Basisprogrammiersprache können auch als verallgemeinerte Operatoren und Bedingungen angegeben werden.
Die Kopfbeschreibung im Pseudocode kann als äußeres Design des Moduls in der Basisprogrammiersprache betrachtet werden, die
der Beginn des Moduls in der Ausgangssprache, d.h. der erste Satz oder die Überschrift (Spezifikation) dieses Moduls;
ein Abschnitt (Satz) von Beschreibungen in der Basissprache und anstelle von Beschreibungen von Verfahren und Funktionen - nur deren äußeres Design;
informelle Bezeichnung der Folge von Modulrumpfanweisungen als eine verallgemeinerte Anweisung (su), sowie informelle Bezeichnung der Folge von Rumpfanweisungen jeder Prozedur- oder Funktionsbeschreibung als eine verallgemeinerte Anweisung;
der letzte Satz (Ende) des Moduls in der Ausgangssprache.
Ähnlich stellt sich die äußere Gestaltung der Beschreibung einer Prozedur oder Funktion dar. In Anlehnung an Dijkstra wäre es jedoch besser, den Abschnitt der Beschreibungen hier auch mit einer informellen Notation darzustellen und ihn als separate Beschreibung zu detaillieren.
Eine informelle Bezeichnung eines verallgemeinerten Operators im Pseudocode erfolgt in natürlicher Sprache durch einen willkürlichen Satz, der seinen Inhalt allgemein verrät. Die einzige formale Vorgabe für die Gestaltung einer solchen Bezeichnung ist folgende: Dieser Satz muss in seiner Gesamtheit eine oder mehrere grafische (gedruckte) Zeilen einnehmen und mit einem Punkt enden.
Für jeden informellen verallgemeinerten Operator muss eine separate Beschreibung erstellt werden, die die Logik seiner Arbeit (mit genauer Angabe seines Inhalts) unter Verwendung der Zusammensetzung der Hauptstrukturen der strukturierten Programmierung und anderer verallgemeinerter Operatoren zum Ausdruck bringt. Die Überschrift einer solchen Beschreibung sollte die informelle Bezeichnung des zu verfeinernden verallgemeinerten Operators sein. Die Grundkonstrukte der strukturierten Programmierung lassen sich wie folgt darstellen (siehe Abbildung 8.2). Hier kann die Bedingung entweder explizit in der zugrunde liegenden Programmiersprache als boolescher Ausdruck angegeben oder informell in natürlicher Sprache durch ein Fragment dargestellt werden, das die Bedeutung dieser Bedingung umreißt. Im letzteren Fall sollte eine separate Beschreibung dieses Zustands erstellt werden, in der die Bezeichnung dieses Zustands (Fragment in natürlicher Sprache) als Titel angegeben ist.
Reis. 8.2. Grundkonstruktionen der strukturierten Programmierung in Pseudocode.
Reis. 8.3. Sonderfälle des Übergangsoperators als verallgemeinerter Operator.
Als verallgemeinerter Operator im Pseudocode können Sie die obigen Sonderfälle des Übergangsoperators verwenden (siehe Abb. 8.3). Die Reihenfolge der Ausnahmebehandler (Ausnahmen) wird am Ende einer Modul- oder Prozedur-(Funktions-)Beschreibung angegeben. Jeder dieser Handler sieht folgendermaßen aus:
AUSNAHME Ausnahmename
generischer_operator
ALLE AUSNAHME
Der Unterschied zwischen einer Ausnahmebehandlungsroutine und einer Prozedur ohne Parameter ist wie folgt: Nachdem die Prozedur ausgeführt wurde, kehrt die Steuerung zu der Anweisung zurück, die auf ihren Aufruf folgt, und nachdem die Ausnahme ausgeführt wurde, kehrt die Steuerung zu der Anweisung zurück, die auf den Aufruf des Moduls folgt oder Prozedur (Funktion), an deren Ende ( which) diese Ausnahme steht.
Es empfiehlt sich, bei jedem Detaillierungsschritt eine ausreichend aussagekräftige, aber gut sichtbare (visuelle) Beschreibung zu erstellen, die auf einer Textseite platziert wird. In der Regel bedeutet dies, dass eine solche Beschreibung aus fünf oder sechs strukturierten Programmierkonstrukten zusammengesetzt sein sollte. Es empfiehlt sich auch, verschachtelte Strukturen um mehrere Positionen nach rechts verschoben zu platzieren (siehe Abb. 8.4). Als Ergebnis erhalten Sie eine Beschreibung der Arbeitslogik in Bezug auf die Sichtbarkeit, die mit Flussdiagrammen durchaus konkurrenzfähig ist, aber einen erheblichen Vorteil hat – die Linearität der Beschreibung bleibt erhalten.
LÖSCHEN SIE IN DER AKTE AUFZEICHNUNGEN VOR DEM ERSTEN,
GEEIGNET FÜR DEN SET-FILTER:
FESTLEGEN SIE DEN ANFANG DER DATEI.
WENN EIN ANDERER RECORD ZUFRIEDEN IST
FILTERN NACH
LÖSCHEN SIE EINEN ANDEREN DATENSATZ AUS DER DATEI.
ALLES WENN
WIEDERSEHEN
WENN EINTRAG NICHT GELÖSCHT WIRD
GEBEN SIE „AUFZEICHNUNGEN NICHT GELÖSCHT“ EIN.
DRUCKEN SIE „ENTFERNT n AUFZEICHNUNGEN“.
ALLES WENN
Die Idee der schrittweisen Detaillierung wird manchmal Dijkstra zugeschrieben. Dijkstra schlug jedoch eine grundlegend andere Methode zum Aufbau des Modultextes vor, die uns tiefer und erfolgsversprechender erscheint. Erstens schlug er zusammen mit der Verfeinerung der Operatoren vor, die verwendeten Datenstrukturen schrittweise (Schritt für Schritt) zu verfeinern (zu detaillieren). Zweitens schlug er vor, bei jedem Schritt eine bestimmte virtuelle Maschine zur Detaillierung zu erstellen und in ihren Begriffen alle verfeinerten Konzepte zu detaillieren, für die diese Maschine dies ermöglicht. So schlug Dijkstra im Wesentlichen eine Detaillierung durch horizontale Schichten vor, was die Übertragung seiner Idee von Schichtsystemen (siehe Vortrag 6) auf die Ebene der Modulentwicklung darstellt. Diese Methode der Modulentwicklung wird derzeit von ADA-Sprachpaketen und objektorientierten Programmierwerkzeugen unterstützt.
8.4. Softwaremodulsteuerung.
Sich bewerben folgenden Methoden Programmmodulsteuerung:
statische Prüfung des Modultextes;
End-to-End-Verfolgung;
Nachweis der Eigenschaften des Softwaremoduls.
Bei der statischen Prüfung des Textes eines Moduls wird dieser Text von Anfang bis Ende gelesen, um Fehler im Modul zu finden. Üblicherweise sind neben dem Modulentwickler noch ein oder mehrere Programmierer an einer solchen Prüfung beteiligt. Es wird empfohlen, Fehler, die bei einer solchen Überprüfung festgestellt werden, nicht sofort zu korrigieren, sondern nach Abschluss des Lesens des Modultexts.
End-to-End-Tracking ist eine der Arten der dynamischen Steuerung des Moduls. Es sind auch mehrere Programmierer beteiligt, die die Ausführung des Moduls (Anweisung für Anweisung in der Reihenfolge, die sich aus der Logik des Moduls ergibt) bei einem bestimmten Satz von Tests manuell durchlaufen.
Die nächste Vorlesung widmet sich dem Beweis der Eigenschaften von Programmen. An dieser Stelle sei nur angemerkt, dass diese Methode noch sehr selten angewendet wird.
Literatur zur Vorlesung 8.
8.2. E. Dijkstra. Hinweise zur strukturierten Programmierung // W. Dahl, E. Dijkstra, K. Hoor. Strukturelle Programmierung. - M.: Mir, 1975. - S. 24-97.
8.3. N.Wirth. Systematische Programmierung. - M.: Mir, 1977. - S. 94-164.
Vortrag 9
Das Konzept der Programmbegründung. Formalisierung von Programmeigenschaften, Triade von Hoor. Regeln zum Festlegen der Eigenschaften eines Zuweisungsoperators, Bedingungsoperators und zusammengesetzten Operators. Regeln zum Festlegen der Eigenschaften eines Schleifenoperators, das Konzept einer Schleifeninvariante. Beendigung der Programmausführung.
9.1. Programmbegründungen. Formalisierung von Programmeigenschaften.
Um die Zuverlässigkeit von Software zu verbessern, ist es sehr sinnvoll, Programme mit zusätzlichen Informationen zu versorgen, mit deren Hilfe Sie die Kontrolle über die Software deutlich erhöhen können. Solche Informationen können in Form von informellen oder formalisierten Aussagen gegeben werden, die an verschiedene Programmfragmente gebunden sind. Wir nennen solche Behauptungen Programmbegründungen. Nicht-formalisierte Begründungen von Programmen können beispielsweise die Motive für bestimmte Entscheidungen erklären, was die Suche und Behebung von Fehlern sowie das Studium von Programmen während ihrer Wartung erheblich erleichtern kann. Formalisierte Begründungen ermöglichen es, einige Eigenschaften von Programmen sowohl manuell nachzuweisen als auch automatisch zu kontrollieren (einzustellen).
Eines der derzeit verwendeten Konzepte zur formalen Begründung von Programmen ist die Verwendung der sogenannten Hoorschen Triaden. Sei S ein verallgemeinerter Operator über die Informationsumgebung IS, P und Q - einige Prädikate (Aussagen) über diese Umgebung. Dann heißt die Notation (P)S(Q) Hoor-Triade, in der das Prädikat P die Vorbedingung und das Prädikat Q die Nachbedingung in Bezug auf den Operator S heißt. Der Operator (insbesondere das Programm) S soll die Eigenschaft (P)S(Q) haben, wenn immer dann, wenn das Prädikat P wahr ist, bevor S ausgeführt wird, das Prädikat Q wahr ist, nachdem S ausgeführt wurde.
Einfache Beispiele für Programmeigenschaften:
(9.1) (n=0) n:=n+1 (n=1),
(9.2) (n
(9.3) (Anm
(9.4) (n>0) p:=1; m:=1;
WÄHREND m /= n TUN
WIEDERSEHEN
Um die Eigenschaft des Programms S zu beweisen, verwenden wir die Eigenschaften einfacher Operatoren der Programmiersprache (hier beschränken wir uns auf den Leeroperator und den Zuweisungsoperator) und die Eigenschaften von Kontrollstrukturen (Kompositionen), aus denen das Programm aufgebaut ist einfache Operatoren (wir beschränken uns hier auf die drei Hauptkompositionen der strukturierten Programmierung, siehe Vorlesung acht). Diese Eigenschaften werden normalerweise als Programmüberprüfungsregeln bezeichnet.
9.2. Eigenschaften einfacher Operatoren.
Für einen leeren Operator gilt
Satz 9.1. Sei P ein Prädikat über die Informationsumgebung. Dann gilt die Eigenschaft (P)(P).
Der Beweis dieses Theorems ist offensichtlich: Der leere Operator ändert den Zustand der Informationsumgebung (entsprechend seiner Semantik) nicht, seine Vorbedingung bleibt also nach seiner Ausführung wahr.
Für den Zuweisungsoperator
Satz 9.2. Die Informationsumgebung IS bestehe aus der Variablen X und dem Rest der Informationsumgebung RIS:
Dann das Grundstück
(Q(F(X, RIS), RIS)) X:= F(X, RIS) (Q(X, RIS)) ,
wobei F(X, RIS) eine einwertige Funktion ist, Q ein Prädikat ist.
Nachweisen. Das Prädikat Q(F(X0, RIS0), RIS0) sei vor der Ausführung des Zuweisungsoperators wahr, wobei (X0, RIS0) ein beliebiger Zustand der Informationsumgebung IS ist, dann nach der Ausführung des Zuweisungsoperators das Prädikat Q(X, RIS) wird wahr sein, also wie X den Wert F(X0, RIS0) erhält und der Zustand von RIS nicht durch die gegebene Zuweisungsanweisung geändert wird, und daher in diesem Fall nach der Ausführung dieser Zuweisungsanweisung
Q(X, RIS)=Q(F(X0, RIS0), RIS0).
Aufgrund der Willkür der Wahl des Zustands der Informationsumgebung ist das Theorem bewiesen.
Ein Beispiel für eine Eigenschaft eines Zuweisungsoperators ist Beispiel 9.1.
9.3. Eigenschaften der Grundstrukturen der strukturellen Programmierung.
Betrachten Sie nun die Eigenschaften der Hauptstrukturen der strukturierten Programmierung: Folgen, Verzweigung und Wiederholung.
Die Sukzessionseigenschaften werden wie folgt ausgedrückt
Satz 9.3. Seien P, Q und R Prädikate über die Informationsumgebung und S1 und S2 verallgemeinerte Operatoren, die jeweils die Eigenschaften haben
(P)S(Q) und (Q)S2(R).
Dann für den zusammengesetzten Operator
S1; S2<.blockquote>
es gibt eine Eigenschaft
(P) S1; S2(R) .
Nachweisen. Wenn das Prädikat P für einen Zustand der Informationsumgebung vor der Ausführung des Operators S1 wahr ist, dann wird aufgrund der Eigenschaft des Operators S1 nach seiner Ausführung das Prädikat Q wahr sein, indem der Operator S2 ausgeführt wird. Folglich wird das Prädikat R nach der Ausführung des Operators S2 aufgrund seiner Eigenschaft wahr sein, und da der Operator S2 die Ausführung der zusammengesetzten Anweisung (gemäß seiner Semantik) abschließt, wird das Prädikat R danach wahr sein die Ausführung dieser zusammengesetzten Aussage, die bewiesen werden musste.
Wenn zum Beispiel die Eigenschaften (9.2) und (9.3) gelten, dann
Ort und Besitz
(n
Die Verzweigungseigenschaft wird wie folgt ausgedrückt
Satz 9.4. Seien P, Q und R Prädikate über die Informationsumgebung und S1 und S2 verallgemeinerte Operatoren, die jeweils die Eigenschaften haben
(P,Q)S1(R) und (`P,Q)S2(R).
Dann für den Bedingungsoperator
WENN P DANN S1 SONST S2 ALLE WENN
es gibt eine Eigenschaft
(Q) WENN P DANN S1 SONST S2 ALLE WENN (R) .
Nachweisen. Sei das Prädikat Q für einen Zustand der Informationsumgebung vor der Ausführung des Bedingungsoperators wahr.Wenn das Prädikat P ebenfalls wahr ist, dann reduziert sich die Ausführung des Bedingungsoperators gemäß seiner Semantik auf die Ausführung des Operators S1 . Aufgrund der Eigenschaft des Operators S1 wird nach seiner Ausführung (und in diesem Fall nach der Ausführung des Bedingungsoperators) das Prädikat R wahr sein, wenn jedoch vor der Ausführung des Bedingungsoperators das Prädikat P falsch ist (und Q immer noch wahr ist), dann reduziert sich die Ausführung des Bedingungsoperators gemäß seiner Semantik auf die Ausführung des Operators S2. Aufgrund der Eigenschaft des Operators S2 wird nach seiner Ausführung (und in diesem Fall nach der Ausführung des Bedingungsoperators) das Prädikat R wahr sein, womit der Satz vollständig bewiesen ist.
Bevor zu der Eigenschaft der Wiederholungskonstruktion übergegangen wird, sollte angemerkt werden, dass sie für weitere Zwecke nützlich ist
Satz 9.5. Seien P, Q, P1 und Q1 Prädikate über die Informationsumgebung, für die die Implikationen gelten
P1=>P und Q=>Q1,
und es gelte die Eigenschaft (P)S(Q) für den Operator S. Dann gilt die Eigenschaft (P1)S(Q1).
Dieser Satz wird auch Schwächungssatz genannt.
Nachweisen. Das Prädikat P1 sei wahr für einen Zustand der Informationsumgebung vor der Ausführung des Operators S. Dann ist auch das Prädikat P wahr (wegen der Implikation P1=>P). Folglich wird aufgrund der Eigenschaft des Operators S nach seiner Ausführung das Prädikat Q wahr sein und somit das Prädikat Q1 (aufgrund der Implikation Q=>Q1). Damit ist der Satz bewiesen.
Die Wiederholungseigenschaft wird durch das Folgende ausgedrückt
Satz 9.6. Seien I, P, Q und R Prädikate über die Informationsumgebung, für die die Implikationen gelten
P=>I und (I,`Q)=>R ,
und sei S ein verallgemeinerter Operator mit der Eigenschaft (I)S(I).
Dann für den Schleifenoperator
BYE Q IST ALLES BYE
es gibt eine Eigenschaft
(P) Tschüss, Q tut alles Tschüss (R) .
Das Prädikat I heißt die Invariante des Schleifenoperators.
Nachweisen. Um diesen Satz zu beweisen, genügt es, die Eigenschaft zu beweisen
(I) BYE Q DO S ALL BYE (I,`Q)
(nach Theorem 9.5 aufgrund der Implikationen in den Bedingungen dieses Theorems). Sei das Prädikat I wahr für einen Zustand der Informationsumgebung vor der Ausführung des Zyklusoperators. Wenn in diesem Fall das Prädikat Q falsch ist, dann ist der Zyklusoperator (gemäß seiner Semantik) äquivalent zu einem leeren Operator. und aufgrund von Satz 9.1 nach Ausführung des Zyklusoperators die Aussage (I ,`Q). Wenn das Prädikat Q vor der Ausführung des Schleifenoperators wahr ist, dann kann der Schleifenoperator gemäß seiner Semantik als zusammengesetzter Operator S dargestellt werden; BYE Q IST ALLES BYE
Aufgrund der Eigenschaft des Operators S wird nach seiner Ausführung das Prädikat I wahr sein, und es entsteht die Ausgangssituation für den Beweis der Eigenschaft des Zyklusoperators: Das Prädikat I ist vor der Ausführung des Zyklusoperators wahr, aber für ein anderer (veränderter) Zustand der Informationsumgebung (für den das Prädikat Q entweder wahr oder falsch sein kann). Wenn die Ausführung der Schleifenanweisung endet, werden wir durch Anwendung der Methode der mathematischen Induktion in einer endlichen Anzahl von Schritten zu einer Situation kommen, in der die Aussage (I,`Q) vor ihrer Ausführung wahr sein wird. Und in diesem Fall gilt, wie oben bewiesen, diese Aussage auch nach der Ausführung der Zyklusanweisung. Der Satz ist bewiesen.
Beispielsweise findet für den Schleifenoperator aus Beispiel (9.4) die Eigenschaft statt
m:= m+1; p:= p*m
ALLES NOCH (p= n.!}
Dies folgt aus Satz 9.6, denn die Invariante dieses Schleifenoperators ist das Prädikat p=m! und die Implikationen (n>0, p=1, m=1) => p=m! und (p=m!, m=n) => p=n!
9.4. Beendigung der Programmausführung.
Eine der Programmeigenschaften, die uns interessieren könnten, um mögliche Fehler im PS zu vermeiden, ist seine Beendigung, d.h. das Fehlen von Radfahren darin für bestimmte Anfangsdaten. In den betrachteten strukturierten Programmen kann nur das Wiederholungskonstrukt die Quelle der Schleife sein. Um die Beendigung eines Programms zu beweisen, genügt es daher, die Beendigung eines Schleifenoperators beweisen zu können. Dazu ist folgendes hilfreich.
Satz 9.7. Sei F eine ganzzahlige Funktion, die vom Zustand der Informationsumgebung abhängt und die folgenden Bedingungen erfüllt:
(1) wenn das Prädikat Q für einen gegebenen Zustand der Informationsumgebung wahr ist, dann ist sein Wert positiv;
(2) sie nimmt ab, wenn sich der Zustand der Informationsumgebung infolge der Ausführung des Operators S ändert.
Dann die Ausführung der Schleifenanweisung
WÄHREND Q TUN S ALLES WÄHREND abgeschlossen ist.
Nachweisen. Sei sei der Zustand der Informationsumgebung vor der Ausführung der Zyklusanweisung und sei F(ist)=k. Wenn das Prädikat Q(ist) falsch ist, endet die Ausführung der Schleifenanweisung. Wenn Q(is) wahr ist, dann nach Annahme des Theorems k>0. In diesem Fall wird die Anweisung S einmal oder mehrmals ausgeführt. Nach jeder Ausführung des Operators S nimmt gemäß der Bedingung des Satzes der Wert der Funktion F ab, und da vor der Ausführung des Operators S das Prädikat Q wahr sein muss (gemäß der Semantik des Zyklusoperators) , muss der Wert der Funktion F in diesem Moment positiv sein (gemäß der Bedingung des Theorems). Aufgrund der Ganzzahligkeit der Funktion F kann daher der Operator S in diesem Zyklus mehr als k Mal ausgeführt werden. Der Satz ist bewiesen.
Beispielsweise werden für das oben betrachtete Beispiel des Kreisoperators die Bedingungen von Theorem 9.7 durch die Funktion f(n, m)= n-m erfüllt. Da vor der Ausführung der Schleifenanweisung m=1, wird der Rumpf dieser Schleife (n-1) mal ausgeführt, d.h. diese Schleifenanweisung wird beendet.
9.5. Ein Beispiel für einen Programmeigenschaftsbeweis.
Basierend auf den bewährten Regeln zur Programmverifikation ist es möglich, die Eigenschaften von Programmen zu beweisen, die aus Zuweisungsanweisungen und leeren Anweisungen bestehen und drei grundlegende Zusammensetzungen der strukturierten Programmierung verwenden. Um dies zu tun, ist es notwendig, die Struktur des Programms zu analysieren und seine Vor- und Nachbedingungen zu verwenden, und in jedem Schritt der Analyse eine geeignete Verifikationsregel anzuwenden. Im Falle einer Wiederholungskomposition ist es notwendig, eine geeignete Zyklusinvariante zu wählen.
Als Beispiel wollen wir die Eigenschaft (9.4) beweisen. Dieser Beweis besteht aus den folgenden Schritten.
(Schritt 1). n>0 => (n>0, p - beliebig, m - beliebig).
(Schritt 2). Tritt ein
(n>0, p - beliebig, m - beliebig) p:=1 (n>0, p=1, m - beliebig).
Nach Satz 9.2.
(Schritt 3). Tritt ein
(n>0, p=1, m - beliebig) m:=1 (n>0, p=1, m=1).
Nach Satz 9.2.
(Schritt 4). Tritt ein
(n>0, p - beliebig, m - beliebig) p:=1; m:=1 (n>0, p=1, m=1).
Nach Satz 9.3 aufgrund der Ergebnisse der Schritte 2 und 3.
Beweisen wir, dass das Prädikat p=m! ist eine Zyklusinvariante, d.h. (p=m m:=m+1; p:=p*m {p=m!}.!}
(Schritt 5). Findet statt (p=m m:=m+1 {p=(m-1)!}.!}
Stellen wir nach Satz 9.2 die Vorbedingung in der Form (p=((m+1)-1).!}
(Schritt 6). Findet statt (p=(m-1) p:=p*m {p=m!}.!}
Wenn wir nach Satz 9.2 die Vorbedingung in der Form (p*m=m.!}
(Schritt 7). Es gibt einen unveränderlichen Zyklus
(p=m m:=m+1; p:=p*m {p=m!}.!}
Nach Theorem 9.3 aufgrund der Ergebnisse der Schritte 5 und 6.
(Schritt 8). Tritt ein
(n>0, p=1, m=1) WÄHREND m /= n TUN
m:= m+1; p:= p*m
ALLES NOCH (p= n.!}
Nach Theorem 9.6, aufgrund des Ergebnisses von Schritt 7 und unter Berücksichtigung, dass (n>0, p=1, m= 1)=>p=m!; (p=m!, m=n)=>p=n!.
(Schritt 9). Tritt ein
(n>0, p - beliebig, m - beliebig) p:=1; m:=1;
WÄHREND m /= n TUN
m:= m+1; p:= p*m
ALLES NOCH (p= n.!}
Nach Theorem 9.3 aufgrund der Ergebnisse der Schritte 3 und 8.
(Schritt 10). Eigenschaft (9.4) gilt nach Satz 9.5 aufgrund der Ergebnisse der Schritte 1 und 9.
Literatur zur Vorlesung 9.
9.1. S.A. Abramov. Elemente der Programmierung. - M.: Nauka, 1982. S. 85-94.
9.2. M. Zelkovets, A. Shaw, J. Gannon. Prinzipien der Softwareentwicklung. - M.: Mir, 1982. S. 98-105.
Vortrag 10
Grundlegendes Konzept. Designstrategie testen. Debugging-Gebote. Offline Debuggen und Testen eines Softwaremoduls. Umfassendes Debuggen und Testen von Software.
10.1. Grundlegendes Konzept.
Das Debuggen des PS ist eine Aktivität, die darauf abzielt, Fehler im PS unter Verwendung der Prozesse zum Ausführen seiner Programme zu erkennen und zu korrigieren. PS-Testing ist der Prozess der Ausführung seiner Programme auf einem bestimmten Datensatz, für den das Ergebnis der Anwendung im Voraus bekannt ist oder die Regeln für das Verhalten dieser Programme bekannt sind. Der angegebene Datensatz wird als Test oder nur als Test bezeichnet. Somit kann das Debugging als wiederholte Wiederholung von drei Prozessen dargestellt werden: Testen, wodurch das Vorliegen eines Fehlers in der PS festgestellt werden kann, Suchen einer Fehlerstelle in den Programmen und Dokumentationen der PS, und Editieren von Programmen und Dokumentationen, um den festgestellten Fehler zu beseitigen. Mit anderen Worten:
Debuggen = Testen + Fehler finden + Bearbeiten.
In der ausländischen Literatur wird Debugging oft nur als Prozess des Auffindens und Behebens von Fehlern (ohne Testen) verstanden, dessen Vorhandensein während des Testens festgestellt wird. Manchmal werden Testen und Debuggen synonym betrachtet. In unserem Land beinhaltet das Debugging-Konzept normalerweise Tests, also werden wir der etablierten Tradition folgen. Die gemeinsame Betrachtung dieser Prozesse in dieser Vorlesung lässt die aufgezeigte Diskrepanz jedoch nicht so stark ins Gewicht fallen. Es ist jedoch zu beachten, dass das Testen auch im Rahmen des PS-Zertifizierungsprozesses verwendet wird (siehe Vorlesung 14).
10.2. Prinzipien und Arten des Debuggens.
Der Erfolg des Debuggens wird maßgeblich durch die rationale Organisation des Testens bestimmt. Beim Debuggen werden hauptsächlich solche Fehler gefunden und beseitigt, deren Vorhandensein im PS beim Testen festgestellt wird. Wie bereits erwähnt, kann das Testen die Korrektheit des PS nicht beweisen, bestenfalls kann es das Vorhandensein eines Fehlers darin nachweisen. Mit anderen Worten, es kann nicht garantiert werden, dass durch das Testen der Software mit einem praktisch durchführbaren Satz von Tests das Vorhandensein aller in der Software vorhandenen Fehler festgestellt werden kann. Daher treten zwei Probleme auf. Bereiten Sie zunächst eine solche Reihe von Tests vor und wenden Sie PS darauf an, um so viele Fehler wie möglich darin zu erkennen. Je länger jedoch der Testprozess (und das Debuggen im Allgemeinen) andauert, desto höher werden die Kosten der Software. Daher die zweite Aufgabe: Den Zeitpunkt zu bestimmen, an dem das Debuggen des PS (oder seiner einzelnen Komponenten) abgeschlossen ist. Ein Zeichen für das mögliche Ende des Debuggens ist die Vollständigkeit der Abdeckung durch die Tests, die durch das PS gelaufen sind (d. h. die Tests, auf die das PS angewendet wird), von vielen verschiedenen Situationen, die während der Ausführung von PS-Programmen auftreten, und der relativ seltene Manifestation von Fehlern im PS im letzten Abschnitt des Testprozesses. Letzteres bestimmt sich nach dem geforderten Zuverlässigkeitsgrad des PS, der in der Spezifikation seiner Qualität angegeben ist.
Um die Testsuite zu optimieren, d.h. Um eine solche Reihe von Tests vorzubereiten, die es einer bestimmten Anzahl von ihnen (oder einem bestimmten für das Testen zugeteilten Zeitintervall) ermöglichen würde, eine größere Anzahl von Fehlern zu erkennen, ist es notwendig, erstens diese Reihe im Voraus zu planen und zweitens , um eine rationale Planungsstrategie (Design) Tests zu verwenden. Das Testdesign kann unmittelbar nach Abschluss der Phase der externen Beschreibung des PS beginnen. Für die Entwicklung einer Testdesignstrategie gibt es unterschiedliche Ansätze, die sich grafisch (siehe Abbildung 9.1) bedingt zwischen den beiden folgenden extremen Ansätzen einordnen lassen. Der linke extreme Ansatz besteht darin, dass Tests nur auf der Grundlage des Studiums der PS-Spezifikationen (externe Beschreibung, Architekturbeschreibung und Modulspezifikation) entworfen werden. Die Struktur der Module wird in keiner Weise berücksichtigt, d.h. Sie werden als Black Boxes behandelt. Tatsächlich erfordert dieser Ansatz eine vollständige Aufzählung aller Eingabedatensätze, da, wenn nur ein Teil dieser Sätze als Tests verwendet wird, einige Abschnitte der PS-Programme möglicherweise bei keinem Test funktionieren und daher die darin enthaltenen Fehler nicht funktionieren erscheinen. Das Testen des PS mit einem vollständigen Satz von Eingabedatensätzen ist jedoch praktisch unmöglich. Der rechte extreme Ansatz besteht darin, dass Tests auf der Grundlage des Studiums von Programmtexten entwickelt werden, um alle Arten zu testen, auf die jedes PS-Programm ausgeführt wird. Berücksichtigt man das Vorhandensein von Zyklen mit variabler Wiederholungszahl in Programmen, dann kann es auch eine extrem große Anzahl unterschiedlicher Möglichkeiten geben, PS-Programme auszuführen, so dass auch deren Test praktisch unmöglich sein wird.
Die optimale Testdesignstrategie liegt im Intervall zwischen diesen extremen Ansätzen, aber näher links. Es beinhaltet die Gestaltung eines wesentlichen Teils der Tests gemäß Spezifikationen, basierend auf den Prinzipien: Für jede verwendete Funktion oder jedes verwendete Merkmal - mindestens ein Test, für jeden Bereich und für jede Änderungsgrenze eines Eingabewerts - mindestens ein Test , für jeden ein Sonderfall oder für jede in den Spezifikationen angegebene Ausnahme mindestens eine Prüfung. Aber es erfordert auch die Gestaltung einiger Tests und der Texte von Programmen, basierend auf dem Prinzip (mindestens): Jeder Befehl jedes PS-Programms muss mindestens einen Test bearbeiten.
Die optimale Testdesignstrategie kann nach folgendem Prinzip festgelegt werden: Für jedes Programmdokument (einschließlich Programmtexte), das Teil des PS ist, sollten eigene Tests entworfen werden, um Fehler darin zu identifizieren. In jedem Fall ist dieser Grundsatz entsprechend der Definition von Software und den Inhalten des Begriffs der Programmiertechnik als Technologie zur Entwicklung zuverlässiger Software zu beachten (siehe Vorlesung 1). In dieser Hinsicht definiert Myers sogar verschiedene Typen Testen abhängig von der Art des Programmdokuments, auf dessen Grundlage die Tests aufgebaut sind. In unserem Land gibt es zwei Haupttypen des Debuggens (einschließlich Testen): eigenständiges und komplexes Debuggen. Offline-Debugging bedeutet, nur einen Teil des im PS enthaltenen Programms zu testen, wobei die Suche und Korrektur von Fehlern während des Tests aufgezeichnet werden. Es beinhaltet tatsächlich das Debuggen jedes Moduls und das Debuggen der Modulpaarung. Umfassendes Debugging bedeutet das Testen des PS als Ganzes mit der Suche und Behebung von Fehlern, die während des Tests in allen Dokumenten (einschließlich Texten von PS-Programmen), die sich auf das PS als Ganzes beziehen, festgestellt wurden. Zu diesen Dokumenten gehören die Definition von Anforderungen an das PS, die Qualitätsspezifikation des PS, die funktionale Spezifikation des PS, die Beschreibung der PS-Architektur und die Texte der PS-Programme.
10.3. Debugging-Gebote.
Dieser Abschnitt enthält allgemeine Richtlinien zum Organisieren des Debuggens. Zunächst sei aber auf ein Phänomen hingewiesen, das die Bedeutung der Fehlervermeidung in vorangegangenen Entwicklungsstadien bestätigt: Mit zunehmender Anzahl erkannter und korrigierter Fehler in der Software steigt auch die relative Wahrscheinlichkeit für das Vorhandensein unerkannter Fehler darin. Dies erklärt sich aus der Tatsache, dass mit zunehmender Anzahl der im PS erkannten Fehler unser Verständnis der Gesamtzahl der darin gemachten Fehler und damit in gewissem Maße auch der Anzahl der noch nicht erkannten Fehler verfeinert wird. Dieses Phänomen bestätigt die Bedeutung der Früherkennung von Fehlern und die Notwendigkeit einer sorgfältigen Kontrolle der Entscheidungen, die in jeder Phase der Softwareentwicklung getroffen werden.
Gebot 1. Betrachten Sie das Testen als eine Schlüsselaufgabe der Softwareentwicklung, vertrauen Sie es den qualifiziertesten und begabtesten Programmierern an; Es ist unerwünscht, Ihr eigenes Programm zu testen.
Gebot 2. Ein guter Test ist einer, der mit hoher Wahrscheinlichkeit einen Fehler findet, nicht einer, der die korrekte Funktionsweise des Programms demonstriert.
Gebot 3. Bereiten Sie Tests sowohl für richtige als auch für falsche Daten vor.
Gebot 4. Vermeiden Sie nicht reproduzierbare Tests, dokumentieren Sie ihren Durchlauf durch den Computer; Studieren Sie die Ergebnisse jedes Tests im Detail.
Gebot 5. Verbinden Sie jedes Modul nur einmal mit dem Programm; Verändern Sie niemals ein Programm, um es leichter testen zu können.
Gebot 6. Überspringen Sie erneut alle Tests, die sich auf die Überprüfung des Betriebs eines PS-Programms oder seiner Interaktion mit anderen Programmen beziehen, wenn Änderungen daran vorgenommen wurden (z. B. als Ergebnis der Behebung eines Fehlers).
10.4. Offline-Modul-Debugging.
Beim Offline-Debugging wird jedes Modul tatsächlich in einer Programmierumgebung getestet, es sei denn, das zu debuggende Programm besteht nur aus einem Modul. Diese Umgebung besteht aus anderen Modulen, von denen einige Module des zu debuggenden Programms sind, die bereits debuggt sind, und einige Module, die das Debuggen steuern (Debug-Module, siehe unten). Daher wird während des Offline-Debuggens immer ein Programm getestet, das speziell zum Testen des zu debuggenden Moduls erstellt wurde. Dieses Programm stimmt nur teilweise mit dem zu debuggenden Programm überein, außer wenn das letzte Modul des zu debuggenden Programms debuggt wird. Wenn das Debuggen des Programms fortschreitet, besteht ein zunehmender Teil der Umgebung des nächsten zu debuggenden Moduls bereits aus debuggten Modulen dieses Programms, und beim Debuggen des letzten Moduls dieses Programms besteht die Umgebung des zu debuggenden Moduls vollständig aus alle anderen (bereits debuggten) Module des zu debuggenden Programms (ohne irgendwelche) Debugging-Module Module, d.h. in diesem Fall wird das debuggte Programm selbst getestet. Dieser Vorgang des Aufbauens eines ausgetesteten Programms mit ausgetesteten und ausgetesteten Modulen wird als Programmintegration bezeichnet.
Die Debug-Module, die in der Umgebung des zu debuggenden Moduls enthalten sind, hängen von der Reihenfolge ab, in der die Module dieses Programms debuggt werden, welches Modul debuggt wird und möglicherweise welcher Test übersprungen wird.
Beim Bottom-Up-Testen (siehe Kapitel 7) enthält diese Umgebung immer nur ein Debug-Modul (außer wenn das letzte Modul des zu debuggenden Programms debuggt wird), das der Kopf des zu testenden Programms ist und aufgerufen wird der Meister (oder Fahrer). Das führende Debugging-Modul bereitet die Informationsumgebung zum Testen des zu debuggenden Moduls vor (d. h. es bildet seinen zum Testen dieses Moduls erforderlichen Zustand, insbesondere kann es einige Testdaten eingeben), ruft das zu debuggende Modul auf und beendet seine Arbeit abgeschlossen, gibt die erforderlichen Meldungen aus. Beim Debuggen eines Moduls können verschiedene Master-Debug-Module für verschiedene Tests kompiliert werden.
Beim Abwärtstesten (siehe Kapitel 7) enthält die Umgebung des zu debuggenden Moduls als Debug-Module Simulatoren aller Module, auf die das zu debuggende Modul zugreifen kann, sowie Simulatoren jener Module, auf die das debuggte Modul zugreifen kann Module des zu debuggenden Programms (in dieser Umgebung enthalten), die jedoch noch nicht debuggt wurden. Einige dieser Simulatoren können sich für verschiedene Tests beim Debuggen eines Moduls ändern.
Tatsächlich kann die Umgebung des zu debuggenden Moduls aus den folgenden Gründen in vielen Fällen beide Typen von Debug-Modulen enthalten. Sowohl Aufwärts- als auch Abwärtstests haben ihre Vor- und Nachteile.
Zu den Vorteilen von Bottom-up-Tests gehören:
einfache Vorbereitung von Tests und
die Fähigkeit, den Modultestplan vollständig umzusetzen.
Dies liegt daran, dass der Testzustand der Informationsumgebung unmittelbar vor dem Aufruf des zu debuggenden Moduls (führendes Debugging-Modul) vorbereitet wird. Die Nachteile des Bottom-Up-Testens sind die folgenden Merkmale:
Testdaten werden in der Regel nicht in der Form aufbereitet, die für den Benutzer bestimmt ist (außer wenn das letzte Kopfmodul des zu debuggenden Programms debuggt wird);
eine große Menge an Debugging-Programmierung (wenn Sie ein Modul debuggen, müssen Sie oft viele führende Debugging-Module für verschiedene Tests zusammenstellen);
die Notwendigkeit spezieller Tests von Schnittstellenmodulen.
Zu den Vorteilen des Top-Down-Testens gehören die folgenden Merkmale:
die meisten Tests werden in einer für den Benutzer entworfenen Form vorbereitet;
in vielen Fällen relativ wenig Debugging-Programmierung (Modulsimulatoren sind in der Regel sehr einfach und jeder für eine große Anzahl, oft für alle Tests geeignet);
Es besteht keine Notwendigkeit, die Paarung von Modulen zu testen.
Der Nachteil des Top-down-Testens besteht darin, dass der Testzustand der Informationsumgebung vor dem Zugriff auf das zu debuggende Modul indirekt vorbereitet wird – es ist das Ergebnis der Anwendung bereits debuggter Module auf Testdaten oder von Simulatoren ausgegebene Daten. Dies macht es erstens schwierig, Tests vorzubereiten, erfordert hochqualifizierte Testausführer und macht es zweitens schwierig oder sogar unmöglich, einen vollständigen Testplan für das zu debuggende Modul zu implementieren. Dieser Mangel zwingt Entwickler manchmal dazu, Bottom-Up-Tests zu verwenden, sogar im Fall einer Top-Down-Entwicklung. Häufiger wird jedoch eine Modifikation des Top-down-Testens oder eine Kombination aus Top-down- und Bottom-up-Tests verwendet.
Ausgehend von der Tatsache, dass Top-Down-Tests im Prinzip vorzuziehen sind, wollen wir uns mit Techniken befassen, die es uns ermöglichen, diese Schwierigkeiten bis zu einem gewissen Grad zu überwinden. Zunächst einmal ist es notwendig, das Debugging des Programms so zu organisieren, dass die Module, die die Dateneingabe durchführen, so schnell wie möglich debuggt werden - dann können die Testdaten in einer für den Benutzer konzipierten Form aufbereitet werden, was sehr hilfreich ist vereinfachen die Vorbereitung nachfolgender Tests. Diese Eingabe erfolgt keineswegs immer im Kopfmodul, so dass Sie zunächst die Modulketten debuggen müssen, die zu den Modulen führen, die die angegebene Eingabe ausführen (vgl. mit der Methode der gezielten konstruktiven Umsetzung in Vorlesung 7). Bis zur Fehlerbeseitigung der Eingabemodule werden von einigen Simulatoren Testdaten geliefert: Sie sind entweder als Teil des Simulators im Simulator enthalten oder werden von diesem Simulator eingegeben.
Beim Testen von oben nach unten können einige Informationsumgebungszustände, unter denen es erforderlich ist, das zu debuggende Modul zu testen, während der Ausführung des Programms, das debuggt wird, für irgendeine Eingabe nicht auftreten. In diesen Fällen wäre es möglich, das zu debuggende Modul überhaupt nicht zu testen, da die in diesem Fall gefundenen Fehler nicht auftreten, wenn das zu debuggende Programm unter irgendwelchen Eingabedaten ausgeführt wird. Dies wird jedoch nicht empfohlen, da bei einer Änderung des zu debuggenden Programms (z. B. bei der Wartung des PS) bereits Zustände der Informationsumgebung auftreten können, die nicht zum Testen des zu debuggenden Moduls verwendet wurden, was zusätzliche erfordert Testen dieses Moduls (und dies könnte mit einer rationalen Organisation des Debuggens nicht durchgeführt werden, wenn das Modul selbst sich nicht geändert hat). Um das zu debuggende Modul in diesen Situationen zu testen, werden manchmal geeignete Simulatoren verwendet, um den gewünschten Zustand der Informationsumgebung zu erzeugen. Häufiger wird eine modifizierte Version des Top-Down-Testens verwendet, bei der die zu debuggenden Module separat vorgetestet werden, bevor sie integriert werden (in diesem Fall erscheint ein führendes Debugging-Modul in der Umgebung des zu debuggenden Moduls zusammen mit module Simulatoren, auf die das zu debuggende Modul zugreifen kann). Eine andere Modifikation des Top-Down-Testens scheint jedoch angemessener zu sein: Nachdem das Top-Down-Testen des zu debuggenden Moduls auf erreichbare Testzustände der Informationsumgebung abgeschlossen ist, sollte es separat auf die verbleibenden erforderlichen Zustände der Informationen getestet werden Umgebung.
Häufig wird auch eine Kombination aus Bottom-up- und Bottom-up-Testing verwendet, die als Sandwich-Methode bezeichnet wird. Die Essenz dieser Methode liegt in der gleichzeitigen Implementierung sowohl des Aufwärts- als auch des Abwärtstestens, bis sich diese beiden Testprozesse in einem Modul irgendwo in der Mitte der Struktur des zu debuggenden Programms treffen. Diese Methode ermöglicht es, mit einem vernünftigen Ansatz, die Vorteile sowohl des Bottom-up- als auch des Top-down-Testens zu nutzen und deren Mängel weitgehend zu neutralisieren. Dieser Effekt ist eine Manifestation eines allgemeineren Prinzips: Der größte technologische Effekt kann durch die Kombination von Top-down- und Bottom-up-Methoden der COP-Programmierung erzielt werden. Um diese Methode zu unterstützen, soll der architektonische Ansatz zur Softwareentwicklung dienen (siehe Vorlesung 7): Eine Schicht gut konzipierter und sorgfältig getesteter Module erleichtert die Implementierung einer Familie von Programmen im entsprechenden Fachgebiet und deren anschließende Modernisierung erheblich.
Sehr wichtig beim Offline-Debugging ist das Testen der Modulpaarung. Tatsache ist, dass die Spezifikation jedes Programmmoduls, mit Ausnahme des Kopfmoduls, in diesem Programm in zwei Situationen verwendet wird: erstens bei der Entwicklung des Textes (manchmal heißt es: der Hauptteil) dieses Moduls und zweitens beim Schreiben eines dieses Modul in anderen Programmmodulen ansprechen. In beiden Fällen kann durch einen Fehler die geforderte Einhaltung einer vorgegebenen Modulspezifikation verletzt werden. Solche Fehler müssen erkannt und korrigiert werden. Dies ist der Zweck, die Paarung von Modulen zu testen. Beim Top-Down-Testen wird nebenbei bei jedem übersprungenen Test ein Paarungstest durchgeführt, der als größter Vorteil des Top-Down-Testens gilt. Während des Bottom-Up-Testens wird auf das debuggte Modul nicht von den Modulen des zu debuggenden Programms zugegriffen, sondern von dem führenden Debugging-Modul. In dieser Hinsicht besteht die Gefahr, dass sich das letzte Modul an einige "Missverständnisse" des zu debuggenden Moduls anpassen kann. Daher ist es beim Starten (im Prozess der Programmintegration) des Debuggens eines neuen Moduls erforderlich, jeden Aufruf eines zuvor debuggten Moduls zu testen, um Inkonsistenzen zwischen diesem Aufruf und dem Rumpf des entsprechenden Moduls zu erkennen (und es ist möglich, dass das zuvor debuggte Modul ist daran schuld). So ist es notwendig, das Testen eines zuvor debuggten Moduls teilweise unter neuen Bedingungen zu wiederholen, wobei die gleichen Schwierigkeiten auftreten wie beim Top-down-Testen.
Der autonome Test des Moduls sollte in vier aufeinanderfolgenden Schritten durchgeführt werden.
Schritt 1: Bereiten Sie basierend auf der Spezifikation des Moduls, das Sie debuggen, einen Test für jede Möglichkeit und Situation vor, für jede Grenze der Bereiche aller Eingaben, für jeden Bereich von Datenänderungen, für jeden ungültigen Bereich aller Eingaben und für jeden ungültige Bedingung.
Schritt 2. Überprüfen Sie den Text des Moduls, um sicherzustellen, dass jede Richtung eines beliebigen Zweigs mindestens einen Test besteht. Fehlende Tests hinzufügen.
Schritt 3. Überprüfen Sie anhand des Modultexts, dass es für jede Schleife einen Test gibt, für den der Schleifenrumpf nicht ausgeführt wird, einen Test, für den der Schleifenrumpf einmal ausgeführt wird, und einen Test, für den der Schleifenrumpf maximal ausgeführt wird mal. Fehlende Tests hinzufügen.
Schritt 4. Überprüfen Sie den Text des Moduls auf seine Empfindlichkeit gegenüber einzelnen speziellen Eingabedatenwerten – alle diese Werte sollten in die Tests einbezogen werden. Fehlende Tests hinzufügen.
10.5. Komplexes Debugging der Software.
Wie oben erwähnt, wird beim komplexen Debugging das PS als Ganzes getestet, und Tests werden für jedes der PS-Dokumente vorbereitet. Das Testen dieser Dokumente erfolgt in der Regel in umgekehrter Reihenfolge ihrer Entstehung (Ausnahme ist lediglich das Testen von Anwendungsdokumentationen, die gemäß der externen Beschreibung parallel zur Entwicklung von Programmtexten entwickelt werden; dieses Testen erfolgt am besten nach dem Testen von die äußere Beschreibung ist abgeschlossen). Testen im komplexen Debugging ist die Anwendung des PS auf bestimmte Daten, die grundsätzlich vom Benutzer stammen können (insbesondere werden alle Tests in einer für den Benutzer entworfenen Form vorbereitet), möglicherweise jedoch in einem simulierten (und nicht realen) Umgebung. Beispielsweise können einige Eingabe- und Ausgabegeräte, die während des komplexen Debugging nicht zugänglich sind, durch ihre Software-Simulatoren ersetzt werden.
Testen der PS-Architektur. Der Zweck des Testens besteht darin, eine Diskrepanz zwischen der Beschreibung der Architektur und dem Satz von Programmen des PS zu finden. Zu Beginn des Testens der PS-Architektur sollte das autonome Debugging jedes Subsystems bereits abgeschlossen sein. Akönnen hauptsächlich mit der Interaktion dieser Teilsysteme zusammenhängen, insbesondere mit der Implementierung von Architekturfunktionen (falls vorhanden). Daher möchte ich alle Möglichkeiten der Interaktion zwischen den PS-Subsystemen überprüfen. Da es jedoch möglicherweise zu viele davon gibt, wäre es wünschenswert, zumindest alle Ausführungsketten von Subsystemen ohne Wiedereintritt der letzteren zu testen. Wenn die gegebene Architektur das PS als ein kleines System ausgewählter Subsysteme darstellt, dann wird die Anzahl solcher Ketten gut sichtbar sein.
Testen externer Funktionen. Der Zweck des Testens besteht darin, Diskrepanzen zwischen der funktionalen Spezifikation und dem Satz von Softwareprogrammen des PS zu finden. Trotz der Tatsache, dass alle diese Programme bereits unabhängig voneinander debuggt wurden, können diese Abweichungen beispielsweise auf eine Diskrepanz zwischen den internen Spezifikationen der Programme und ihrer Module (auf deren Grundlage autonome Tests durchgeführt wurden) und der externen Funktionsspezifikation zurückzuführen sein der MS. Das Testen externer Funktionen erfolgt in der Regel im ersten Schritt wie das Testen von Modulen, d.h. wie eine Blackbox.
PS-Qualitätsprüfung. Zweck der Prüfung ist die Suche nach Verstößen gegen die in der PS-Qualitätsspezifikation formulierten Qualitätsanforderungen. Dies ist die schwierigste und am wenigsten erforschte Art der Prüfung. Klar ist nur, dass nicht jedes PS-Qualitätsprimitive durch Testen getestet werden kann (siehe nächste Vorlesung zur PS-Qualitätsbewertung). Bereits beim Testen externer Funktionen wird die Vollständigkeit des PS geprüft. In diesem Stadium kann das Testen dieses Qualitätsgrundelements fortgesetzt werden, wenn es erforderlich ist, um eine probabilistische Schätzung des Zuverlässigkeitsgrads des PS zu erhalten. Die Methodik für solche Tests muss jedoch noch entwickelt werden. Genauigkeit, Robustheit, Sicherheit, zeitliche Effizienz, teilweise Speichereffizienz, Geräteeffizienz, Erweiterbarkeit und teilweise Geräteunabhängigkeit können getestet werden. Jede dieser Testarten hat ihre eigenen Besonderheiten und verdient eine gesonderte Betrachtung. Wir beschränken uns hier auf deren Aufzählung. Die Benutzerfreundlichkeit des PS (ein Qualitätskriterium, das mehrere Qualitätsprimitive umfasst, siehe Vorlesung 4) wird beim Testen der Dokumentation zur Verwendung des PS bewertet.
Prüfdokumentation zur Anwendung des PS. Der Zweck des Testens besteht darin, nach Inkonsistenzen zwischen der Dokumentation der Anwendung und dem Satz von Softwareprogrammen sowie nach Unannehmlichkeiten bei der Verwendung der Software zu suchen. Diese Phase geht unmittelbar der Verbindung des Benutzers mit dem Abschluss der Entwicklung des PS voraus (Testen der Anforderungen für den PS und Zertifizierung des PS), daher ist es für Entwickler sehr wichtig, den PS zunächst selbst so zu verwenden, wie es der Benutzer tun wird es. Alle Tests in dieser Phase werden ausschließlich auf der Grundlage der Dokumentation über die Anwendung des PS vorbereitet. Zunächst sollte die Leistungsfähigkeit der Software wie beim Testen externer Funktionen getestet werden, jedoch nur anhand der Anwendungsdokumentation. Alle unklaren Stellen in der Dokumentation sollten getestet werden, ebenso alle in der Dokumentation verwendeten Beispiele. Als nächstes werden die schwierigsten Anwendungsfälle des PS getestet, um einen Verstoß gegen die Anforderungen an die Relativität der Benutzerfreundlichkeit des PS zu erkennen.
Testen der Anforderungsdefinition für das PS. Ziel des Testens ist es herauszufinden, inwieweit die Software nicht der vorgestellten Anforderungsdefinition an sie entspricht. Die Besonderheit dieser Art des Testens besteht darin, dass es von der Einkaufsorganisation oder der Nutzerorganisation des PS als eine der Möglichkeiten durchgeführt wird, die Barriere zwischen dem Entwickler und dem Benutzer zu überwinden (siehe Vortrag 3). Üblicherweise wird diese Prüfung mit Hilfe von Kontrollaufgaben durchgeführt – typische Aufgaben, bei denen das Ergebnis der Lösung bekannt ist. In den Fällen, in denen der entwickelte PS eine andere Version des PS ersetzen soll, die zumindest einen Teil der Aufgaben des entwickelten PS löst, werden Tests durchgeführt, indem gemeinsame Probleme sowohl mit dem alten als auch mit dem neuen PS gelöst werden, gefolgt von einem Vergleich der Ergebnisse erhalten. Manchmal wird als eine Form solcher Tests der Probebetrieb des PS verwendet - eine begrenzte Anwendung eines neuen PS mit einer Analyse der Verwendung der Ergebnisse in der Praxis. Diese Art des Testens hat im Wesentlichen viel mit dem Testen des PS während seiner Zertifizierung gemeinsam (siehe Vorlesung 14), wird jedoch vor der Zertifizierung und manchmal anstelle der Zertifizierung durchgeführt.
Literatur zur Vorlesung 10.
10.1. G. Myers. Software-Zuverlässigkeit. - M.: Mir, 1980. - S. 171-262.
10.2. D. Van Quaste. Stil, Entwicklung, Effizienz, Debugging und Testprogramme. - M.: Mir, 1985. - S. 179-295.
10.3. J. Hughes, J. Michtom. Struktureller Ansatz zum Programmieren. - M.: Mir, 1980. - S. 254-268.
10.4. J. Fuchs. Software und ihre Entwicklung. - M.: Mir, 1985. - S. 227-241.
10.5. M. Zelkowitz, A. Shaw, J. Gannon. Prinzipien der Softwareentwicklung. - M.: Mir, 1982. - S. 105-116.
10.6. Yu.M. Bezborodov. Individuelles Debugging von Programmen. - M.: Nauka, 1982. - S. 9-79.
10.7. VV Lipaev. Programmtest. - M.: Funk und Kommunikation, 1986. - S. 15-47.
10.8. E.A. Schogolev. Einführung in die Programmiertechnik (Skript). - M.: "DIALOG-MGU", 1994.
10.9. E. Dijkstra. Hinweise zur strukturierten Programmierung. //U. Dahl, E. Dijkstra, K. Hoor. Strukturelle Programmierung. - M.: Mir, 1975. - S. 7-13.
Vortrag 11
11.1. Funktionalität und Zuverlässigkeit als zwingende Kriterien für die Qualität von Software.
In den vorangegangenen Vorträgen haben wir alle Stadien der Entwicklung des PS mit Ausnahme seiner Zertifizierung betrachtet. Dabei haben wir die Fragen der Qualitätssicherung des PS gemäß seiner Qualitätsspezifikation (siehe Vortrag 4) nicht angesprochen. Zwar haben wir bei der Umsetzung der funktionalen Spezifikation des PS dabei die Hauptfragen zur Sicherstellung des Kriteriums der Funktionalität diskutiert. Nachdem wir die Softwarezuverlässigkeit als Hauptattribut deklariert haben (siehe Vortrag 1), haben wir die Fehlervermeidung als Hauptansatz gewählt, um die Softwarezuverlässigkeit sicherzustellen (siehe Vortrag 3) und ihre Implementierung in verschiedenen Phasen der Softwareentwicklung diskutiert. Damit wurde die These über die obligatorische Funktionalität und Zuverlässigkeit des PS als Qualitätskriterium manifestiert.
In der PS-Qualitätsspezifikation kann es jedoch sein zusätzliche Eigenschaften diese Kriterien, deren Bereitstellung einer besonderen Erörterung bedarf. Diese Fragen stehen im Mittelpunkt dieses Vortrags. Auf die Sicherstellung weiterer Qualitätskriterien wird in der nächsten Vorlesung eingegangen.
Die Bereitstellung der MS-Qualitätsprimitive, die die Kriterien für die Funktionalität und Zuverlässigkeit der MS ausdrücken, wird unten diskutiert.
11.2. Gewährleistung der Vollständigkeit der Software.
Die Vollständigkeit des PS ist ein allgemeines Primitiv der PS-Qualität, um sowohl die Funktionalität als auch die Zuverlässigkeit des PS auszudrücken, und für die Funktionalität ist es das einzige Primitiv (siehe Vorlesung 4).
Die Funktionalität des PS wird durch seine funktionale Spezifikation bestimmt. Die Vollständigkeit eines PS als Grundelement seiner Qualität ist ein Maß dafür, wie diese Spezifikation in einem gegebenen PS implementiert ist. Die vollständige Bereitstellung dieses Primitivs bedeutet die Implementierung jeder der in der Funktionsspezifikation definierten Funktionen mit allen dort angegebenen Details und Merkmalen. Alle bisher besprochenen technologischen Verfahren zeigen, wie dies bewerkstelligt werden kann.
In der PS-Qualitätsspezifikation können jedoch mehrere Implementierungsebenen der Funktionalität des PS definiert werden: Es können einige vereinfachte (Anfangs- oder Start-)Versionen definiert werden, die zuerst implementiert werden müssen, und es können auch mehrere Zwischenversionen definiert werden. In diesem Fall tritt ein zusätzliches technologisches Problem auf: die Organisation der Erhöhung der Funktionalität des PS. Es ist hier wichtig zu beachten, dass die Entwicklung einer vereinfachten Version des PS nicht die Entwicklung seines Prototyps ist. Der Prototyp wird entwickelt, um die Bedingungen für die Verwendung des zukünftigen PS besser zu verstehen und seine äußere Beschreibung zu verdeutlichen. Es ist für ausgewählte Benutzer konzipiert und kann daher nicht nur in den ausgeführten Funktionen, sondern auch in den Eigenschaften der Benutzeroberfläche stark von dem erforderlichen PS abweichen. Eine vereinfachte Version des erforderlichen PS sollte für die praktische Verwendung durch alle Benutzer, für die es bestimmt ist, entworfen werden. Daher besteht das Hauptprinzip zur Gewährleistung der Funktionalität eines solchen Betriebssystems darin, das Betriebssystem von Anfang an so zu entwickeln, als ob das gesamte Betriebssystem benötigt wird, bis sich die Entwickler mit diesen Teilen oder Details des Betriebssystems, der Implementierung, befassen die gemäß ihrer Qualitätsspezifikation aufgeschoben werden kann. Daher müssen sowohl die externe Beschreibung als auch die Beschreibung der PS-Architektur vollständig entwickelt werden. Es ist möglich, nur die Implementierung der in der Architektur des entwickelten PS definierten Software-Subsysteme zu verschieben, deren Funktionieren nicht erforderlich ist erste Version dieses PS. Die Implementierung der Softwaresubsysteme selbst erfolgt am besten durch die Methode der gezielten konstruktiven Implementierung, wobei in der Ausgangsversion des PS geeignete Simulatoren derjenigen Softwaremodule belassen werden, die in dieser Version nicht benötigt werden. Eine vereinfachte Implementierung einiger Softwaremodule ist auch akzeptabel, wobei die Implementierung einiger Details der entsprechenden Funktionen weggelassen wird. Aus technologischer Sicht ist es jedoch besser, solche Module als ihre ursprünglichen (wenn auch weit fortgeschrittenen) Nachahmer zu betrachten.
Aufgrund von Fehlern im entwickelten PS kann die Vollständigkeit, die bei der Sicherstellung seiner Funktionalität (gemäß der Spezifikation seiner Qualität) erreicht wird, tatsächlich nicht wie erwartet sein. Wir können nur sagen, dass diese Vollständigkeit mit einer gewissen Wahrscheinlichkeit erreicht wurde, die durch den Umfang und die Qualität der Tests bestimmt wird. Um diese Wahrscheinlichkeit zu erhöhen, ist es notwendig, das PS weiter zu testen und zu debuggen. Die Schätzung einer solchen Wahrscheinlichkeit ist jedoch eine sehr spezifische Aufgabe (unter Berücksichtigung der Tatsache, dass die Manifestation des Fehlers im PS eine Funktion der Ausgangsdaten ist), die noch auf geeignete theoretische Studien wartet.
11.3. Gewährleistung der Genauigkeit des Softwaretools.
Die Bereitstellung dieses Primitivs ist mit Operationen an Werten realer Typen verbunden (genauer gesagt mit Werten, die mit einem gewissen Fehler dargestellt werden). Um die erforderliche Genauigkeit bei der Berechnung des Werts einer bestimmten Funktion sicherzustellen, muss dieser Wert mit einem Fehler erhalten werden, der die angegebenen Grenzen nicht überschreitet. Die Arten von Fehlern, Methoden zu ihrer Schätzung und Methoden zum Erreichen der erforderlichen Genauigkeit (die sogenannten Näherungsrechnungen) werden von der Computermathematik behandelt. Hier achten wir nur auf eine bestimmte Struktur des Fehlers: Der Fehler hängt vom berechneten Wert (Gesamtfehler) ab
auf den Fehler der verwendeten Berechnungsmethode (in die wir die Ungenauigkeit des verwendeten Modells einbeziehen),
aus dem Fehler bei der Darstellung der verwendeten Daten (aus dem sogenannten fatal error),
aus dem Rundungsfehler (Ungenauigkeit bei der Ausführung der im Verfahren verwendeten Operationen).
11.4. Gewährleistung der Autonomie der Software.
Dieses Qualitätsprimitive wird auf der Stufe der Qualitätsspezifikation bereitgestellt, indem eine Entscheidung getroffen wird, ob irgendeine geeignete zugrunde liegende Software in dem entwickelten PS verwendet werden soll oder keine zugrunde liegende Software darin verwendet werden soll. Gleichzeitig müssen sowohl seine Zuverlässigkeit als auch die für seine Nutzung erforderlichen Ressourcen berücksichtigt werden. Bei gestiegenen Anforderungen an die Zuverlässigkeit der entwickelten PS kann sich die Zuverlässigkeit der den Entwicklern zur Verfügung stehenden Basissoftware als unbefriedigend herausstellen, so dass auf deren Einsatz verzichtet und die Implementierung ihrer Funktionen im geforderten Umfang mit einbezogen werden muss das PS. Ähnliche Entscheidungen müssen unter strengen Einschränkungen der eingesetzten Ressourcen getroffen werden (nach dem PS-Effizienzkriterium).
11.5. Sicherstellung der Nachhaltigkeit der Software.
Dieses Qualitätsprimitive wird mit Hilfe der sogenannten defensiven Programmierung bereitgestellt. Im Allgemeinen wird eine defensive Programmierung verwendet, um die Zuverlässigkeit der MS zu verbessern, wenn das Modul im weiteren Sinne programmiert wird. Wie Myers feststellt: „Defensive Programmierung basiert auf einer wichtigen Prämisse: Das Schlimmste, was ein Modul tun kann, ist, schlechte Eingaben zu akzeptieren und dann ein falsches, aber plausibles Ergebnis zurückzugeben.“ Um dies zu vermeiden, enthält der Text des Moduls Prüfungen seiner Ein- und Ausgabedaten auf ihre Korrektheit gemäß der Spezifikation dieses Moduls, insbesondere die Erfüllung der Beschränkungen für die Ein- und Ausgabedaten und die Beziehungen zwischen ihnen in der Modulspezifikation angegeben sind, zu überprüfen. Bei einem negativen Ergebnis der Prüfung wird die entsprechende Ausnahme ausgelöst. Dazu gehören am Ende dieses Moduls Fragmente zweiter Art - Behandler der entsprechenden Ausnahmesituationen, die neben der Ausgabe der notwendigen diagnostischen Informationen Maßnahmen ergreifen können, um entweder Fehler in den Daten zu beseitigen (z. deren erneute Eingabe erfordern) oder um die Auswirkungen des Fehlers abzumildern (z. B. Sanftstopp von Geräten, die vom PS gesteuert werden, um deren Ausfall im Falle einer Notbeendigung der Programmausführung zu vermeiden).
Die Verwendung einer Schutzprogrammierung von Modulen führt zu einer Verringerung der Effizienz des PS sowohl in Bezug auf die Zeit als auch auf den Speicher. Daher ist es notwendig, den Grad der Anwendung der defensiven Programmierung in Abhängigkeit von den Anforderungen an die Zuverlässigkeit und Effizienz der PS, formuliert in der Qualitätsspezifikation der entwickelten PS, sinnvoll zu regeln. Die Eingabedaten des entwickelten Moduls können entweder direkt vom Benutzer oder von anderen Modulen stammen. Der häufigste Fall der Verwendung einer defensiven Programmierung ist ihre Verwendung für die erste Gruppe von Daten, was die Realisierung der PS-Stabilität bedeutet. Dies sollte immer dann erfolgen, wenn die Qualitätsspezifikation des PS eine Anforderung zur Gewährleistung der Stabilität des PS enthält. Die Verwendung von defensiver Programmierung für die zweite Gruppe von Eingangsdaten bedeutet einen Versuch, einen Fehler in anderen Modulen während der Ausführung des entwickelten Moduls zu erkennen, und für die Ausgangsdaten des entwickelten Moduls einen Versuch, einen Fehler im Modul selbst zu erkennen während seiner Ausführung. Im Wesentlichen bedeutet dies eine partielle Implementierung des Fehlerselbsterkennungsansatzes zur Sicherstellung der Zuverlässigkeit der Software, der in Vorlesung 3 besprochen wurde. Dieser Fall der defensiven Programmierung wird äußerst selten verwendet – nur bei Anforderungen an die Zuverlässigkeit der Software sind extrem hoch.
11.6. Gewährleistung der Sicherheit von Software.
Es gibt die folgenden Arten von PS-Schutz gegen Informationsverzerrung:
Schutz vor Hardwareausfällen;
Schutz vor dem Einfluss eines "fremden" Programms;
Schutz vor Ausfällen des "eigenen" Programms;
Schutz vor Bedienungsfehlern (Benutzer);
Schutz vor unbefugtem Zugriff;
Schutz gegen Schutz.
Der Schutz vor Hardwareausfällen ist derzeit keine sehr dringende Aufgabe (unter Berücksichtigung der erreichten Computerzuverlässigkeit). Aber es ist trotzdem nützlich, ihre Lösung zu kennen. Dies wird durch die Organisation der sogenannten "Doppel-Dreifach-Fehlkalkulationen" gewährleistet. Dazu der ganze Prozess Datenverarbeitung, bestimmt durch die PS, wird durch die sogenannten "Referenzpunkte" zeitlich in Intervalle unterteilt. Die Länge dieses Intervalls sollte die Hälfte der durchschnittlichen Betriebszeit des Computers nicht überschreiten. Eine Kopie des bei diesem Vorgang geänderten Zustands des Speichers für jeden Referenzpunkt wird mit einigen in den sekundären Speicher geschrieben Prüfsumme(eine als Funktion dieses Zustands berechnete Zahl) in dem Fall, in dem davon ausgegangen wird, dass die Verarbeitung von Daten vom vorherigen Bezugspunkt zu diesem (d. h. eine "Fehlberechnung") korrekt durchgeführt wurde (ohne Computerfehler). Um das herauszufinden, werden zwei solcher "Fehlkalkulationen" gemacht. Nach der ersten „Berechnung“ wird die vorgegebene Prüfsumme berechnet und gespeichert, dann wird der Speicherzustand für den vorherigen Referenzpunkt wiederhergestellt und die zweite „Berechnung“ durchgeführt. Nach der zweiten „Fehlberechnung“ wird die angegebene Prüfsumme erneut berechnet, die dann mit der Prüfsumme der ersten „Fehlberechnung“ verglichen wird. Stimmen diese beiden Prüfsummen überein, gilt die zweite Berechnung als korrekt, ansonsten wird die Prüfsumme der zweiten "Berechnung" ebenfalls gespeichert und die dritte "Berechnung" durchgeführt (mit vorläufiger Wiederherstellung des Speicherzustandes für den vorherigen Bezugspunkt). Stimmt die Prüfsumme der dritten „Fehlkalkulation“ mit der Prüfsumme einer der ersten beiden „Fehlkalkulationen“ überein, so gilt die dritte Fehlkalkulation als korrekt, andernfalls ist eine technische Überprüfung des Rechners erforderlich.
Der Schutz vor dem Einfluss eines "fremden" Programms bezieht sich in erster Linie auf Betriebssysteme oder Programme, die teilweise ihre Funktionen erfüllen. Es gibt zwei Arten dieses Schutzes:
Ausfallschutz,
Schutz vor böswilliger Beeinflussung durch ein "fremdes" Programm.
Beim Auftreten einer Multiprogramming-Betriebsart eines Computers können mehrere Programme gleichzeitig in seinem Speicher ablaufen, die durch Unterbrechungen abwechselnd die Kontrolle erhalten (die sogenannte quasi-parallele Ausführung von Programmen). Eines dieser Programme (normalerweise: das Betriebssystem) verarbeitet Interrupts und verwaltet Multiprogramming. In jedem dieser Programme können Fehler auftreten (Fehler werden angezeigt), die die Leistung von Funktionen anderer Programme beeinträchtigen können. Daher muss das Steuerprogramm (Betriebssystem) sich und andere Programme vor solchen Einflüssen schützen. Dazu muss die Computerhardware folgende Features implementieren:
Speicherschutz,
zwei Modi des Computerbetriebs: privilegiert und Arbeit (Benutzer),
zwei Arten von Transaktionen: privilegierte und gewöhnliche,
korrekte Ausführung von Interrupts und Erstinbetriebnahme des Rechners,
vorübergehende Unterbrechung.
Speicherschutz bedeutet die Fähigkeit, für jedes Programm programmgesteuert Speicherbereiche festzulegen, auf die es nicht zugreifen kann. Im privilegierten Modus können alle Operationen (sowohl gewöhnliche als auch privilegierte) ausgeführt werden, und im Ausführungsmodus nur gewöhnliche. Ein Versuch, eine privilegierte Operation auszuführen sowie im Betriebsmodus auf geschützten Speicher zuzugreifen, verursacht den entsprechenden Interrupt. Darüber hinaus umfassen privilegierte Operationen Operationen zum Ändern des Speicherschutzes und des Betriebsmodus sowie den Zugriff auf die externe Informationsumgebung. Das anfängliche Einschalten des Computers und jede Unterbrechung sollten automatisch den privilegierten Modus aktivieren und den Speicherschutz außer Kraft setzen. In diesem Fall kann sich das Steuerungsprogramm (Betriebssystem) vollständig vor dem Einfluss anderer Programme schützen, wenn alle Steuerungsübergabepunkte beim erstmaligen Einschalten und bei Unterbrechungen diesem Programm gehören, wenn es kein anderes Programm einarbeiten lässt privilegierten Modus (wenn die Steuerung auf ein anderes Programm übertragen wird, schaltet das Programm nur den Betriebsmodus ein) und wenn es seinen Speicher (der insbesondere alle seine Steuerinformationen enthält, einschließlich der sogenannten Interrupt-Vektoren) vollständig vor anderen Programmen schützt. Dann wird es niemand daran hindern, alle darin implementierten Schutzfunktionen für andere Programme auszuführen (einschließlich des Zugriffs auf die externe Informationsumgebung). Um die Lösung dieses Problems zu erleichtern, wird ein Teil eines solchen Programms in einen permanenten Speicher gestellt, d. h. untrennbar mit dem Computer selbst. Das Vorhandensein eines temporären Interrupts ermöglicht es dem Steuerprogramm, sich selbst vor Schleifen in anderen Programmen zu schützen (ohne einen solchen Interrupt könnte es einfach die Fähigkeit zur Steuerung verlieren).
Der Schutz vor Ausfällen des "eigenen" Programms wird durch die Zuverlässigkeit dieses Programms gewährleistet, die im Mittelpunkt der gesamten in dieser Vorlesung behandelten Programmiertechnik steht.
Der Schutz vor Benutzerfehlern (zusätzlich zu Eingabedatenfehlern, siehe Gewährleistung der PS-Stabilität) wird durch die Ausgabe von Warnmeldungen über Versuche, den Zustand der externen Informationsumgebung zu ändern, mit der Aufforderung, diese Aktionen zu bestätigen, sowie die Möglichkeit zur Wiederherstellung der Zustand einzelner Komponenten der externen Informationsumgebung. Letzteres basiert auf der Implementierung der Archivierung von Änderungen im Zustand der externen Informationsumgebung.
Der Schutz vor unbefugtem Zugriff erfolgt durch die Verwendung geheimer Wörter (Passwörter). In diesem Fall werden jedem Benutzer bestimmte Informationen und Verfahrensressourcen (Dienste) zur Verfügung gestellt, deren Nutzung die Vorlage eines Passworts bei der PS erfordert, das zuvor von diesem Benutzer in der PS registriert wurde. Mit anderen Worten, der Benutzer "hängt" gewissermaßen ein "Schloss" an die ihm zugewiesenen Ressourcen, den "Schlüssel", zu dem nur dieser Benutzer verfügt. Allerdings kann im Einzelfall hartnäckig versucht werden, diesen Schutz zu durchbrechen, wenn die geschützten Ressourcen für jemanden von außerordentlichem Wert sind. In einem solchen Fall müssen zusätzliche Maßnahmen zum Schutz vor Sicherheitsverletzungen ergriffen werden.
Der Schutz vor Sicherheitsverletzungen ist mit der Verwendung spezieller Programmiertechniken im PS verbunden, die es schwierig machen, den Schutz vor unbefugtem Zugriff zu überwinden. Verwendungszweck normale Passwörter reicht nicht aus, wenn es um einen äußerst hartnäckigen Wunsch (z. B. krimineller Natur) geht, Zugang zu wertvollen Informationen zu erhalten. Zum einen, weil die Informationen über Passwörter, die die PS zum Schutz vor unbefugtem Zugriff verwendet, relativ einfach von einem "Cracker" dieses Schutzes erlangt werden können, wenn er selbst Zugriff auf diese PS hat. Zweitens ist es möglich, mit Hilfe eines Computers eine ausreichend große Aufzählung möglicher Passwörter durchzuführen, um ein geeignetes für den Zugriff auf die interessierenden Informationen zu finden. Sie können sich auf folgende Weise vor einem solchen Hack schützen. Das geheime Wort (Passwort) oder nur die geheime ganze Zahl X ist nur dem Eigentümer der geschützten Informationen bekannt, und zur Überprüfung der Zugriffsrechte wird eine weitere Zahl Y=F(X) im Computer gespeichert, die vom eindeutig berechnet wird PS jedes Mal, wenn versucht wird, auf diese Informationen zuzugreifen, wenn das geheime Wort vorgelegt wird. Gleichzeitig kann die Funktion F allen PS-Benutzern gut bekannt sein, aber sie hat eine solche Eigenschaft, dass das Wiederherstellen des Wortes X aus Y praktisch unmöglich ist: Bei einer ausreichend großen Länge des Wortes X (z. B. mehrere hundert Zeichen ), erfordert dies astronomische Zeit. Eine solche Zahl Y wird als elektronische (Computer-)Signatur des Eigentümers des geheimen Wortes X (und damit der geschützten Information) bezeichnet.
Eine andere Art eines solchen Schutzes bezieht sich auf den Schutz von Nachrichten, die über Computernetzwerke gesendet werden, vorsätzliche (oder böswillige) Verzerrung. Eine solche Nachricht kann an "Umschlagspunkten" des Computernetzes abgefangen und durch eine andere Nachricht des Urhebers der abgefangenen Nachricht ersetzt werden. Diese Situation tritt hauptsächlich bei der Durchführung von Bankgeschäften unter Verwendung eines Computernetzwerks auf. Durch das Ersetzen einer solchen Nachricht, bei der es sich um eine Anweisung des Inhabers eines Bankkontos zur Ausführung von Bankgeschäften handelt, kann Geld von seinem Konto auf das Konto eines "Hacker" -Schutzes (eine Art Computer-Banküberfall) überwiesen werden. Schutz vor einer solchen Sicherheitsverletzung kann wie folgt erfolgen. Neben der Funktion F, die die Computersignatur des Besitzers des geheimen Wortes X ermittelt, die dem Adressaten der geschützten Nachricht bekannt ist (sofern nur sein Besitzer Kunde dieses Adressaten ist), ist in der eine weitere Stamp-Funktion definiert PS, aus der der Absender der Nachricht mit dem geheimen Wort X und dem Text der übermittelten Nachricht R die Zahl S=Stamp(X,R ) errechnen muss eine Eigenschaft, dass es praktisch unmöglich ist, die Nummer X von S zurückzugewinnen oder eine andere Nachricht R mit der entsprechenden Computersignatur auszuwählen. Die übertragene Nachricht selbst (zusammen mit ihrem Schutz) sollte wie folgt aussehen:
Darüber hinaus ermöglicht Y (Computersignatur) dem Adressaten, die Wahrheit des Kunden festzustellen, und S befestigt sozusagen die geschützte Nachricht R mit der Computersignatur Y. In diesem Zusammenhang nennen wir die Nummer S eine elektronische (Computer ) Siegel. Der PS definiert eine weitere Notarfunktion, nach der der Empfänger der geschützten Nachricht die Wahrheit der übermittelten Nachricht überprüft:
Damit können Sie eindeutig feststellen, dass die Nachricht R dem Besitzer des geheimen Wortes X gehört.
Schutz vor Schutz ist notwendig für den Fall, dass der Benutzer sein Passwort vergessen (oder verloren) hat. Für einen solchen Fall sollte es einem speziellen Benutzer (PS-Administrator), der für das Funktionieren des Schutzsystems verantwortlich ist, möglich sein, den Schutz vor unbefugtem Zugriff für den Eigentümer vorübergehend aufzuheben Passwort vergessen um ihm die Möglichkeit zu geben, ein neues Passwort festzulegen.
Literatur zur Vorlesung 11.
11.1. IST. Berezin, N.P. Schidkow. Berechnungsmethoden, Bd. 1 und 2. - M.: Fizmatgiz, 1959.
11.2. N.S. Bakhvalov, N.P. Zhidkov, G. M. Kobelkov. Numerische Methoden. -M.: Nauka, 1987.
11.3. G. Myers. Software-Zuverlässigkeit. - M.: Mir, 1980. S. 127-154.
11.4. EIN. Lebedew. Schutz von Bankinformationen und moderne Kryptografie//Fragen der Informationssicherheit, 2(29), 1995.
Vorlesung 12. Software-Qualitätssicherung
12.1. Allgemeine Merkmale des Software-Qualitätssicherungsprozesses.
Wie bereits in Vorlesung 4 angemerkt, definiert die Qualitätsvorgabe die wesentlichen Leitlinien (Ziele), die in allen Stadien der Entwicklung der PS auf die eine oder andere Weise die Wahl der geeigneten Option bei verschiedenen Entscheidungen beeinflussen. Jedoch hat jedes Qualitätsprimitiv seine eigenen Merkmale eines solchen Einflusses, daher kann die Sicherstellung seiner Anwesenheit im PS seine eigenen Ansätze und Methoden für die Entwicklung des PS oder seiner einzelnen Teile erfordern. Außerdem wurde auch die Inkonsistenz der PS-Qualitätskriterien und der sie ausdrückenden Qualitätsgrundelemente festgestellt: Eine gute Bereitstellung eines der PS-Qualitätsgrundelemente kann die Bereitstellung einiger anderer dieser Grundelemente erheblich erschweren oder unmöglich machen. Daher besteht ein wesentlicher Teil des Prozesses zur Gewährleistung der Qualität von PS darin, akzeptable Kompromisse zu finden. Diese Kompromisse sollten teilweise bereits in der PS-Qualitätsspezifikation definiert werden: das PS-Qualitätsmodell sollte den erforderlichen Präsenzgrad im PS jedes seiner Qualitätsprimitive spezifizieren und die Prioritäten zum Erreichen dieser Grade festlegen.
Qualitätssicherung findet in jedem technologischen Prozess statt: Die darin getroffenen Entscheidungen wirken sich mehr oder weniger auf die Qualität der Software als Ganzes aus. Insbesondere deshalb, weil ein erheblicher Teil der Qualitätsgrundelemente nicht so sehr mit den Eigenschaften der im PS enthaltenen Programme, sondern mit den Eigenschaften der Dokumentation verbunden ist. Aufgrund der festgestellten Inkonsistenz von Qualitätsprimitiven ist es sehr wichtig, die gewählten Prioritäten bei ihrer Bereitstellung einzuhalten. Aber in jedem Fall ist es sinnvoll, sich an zwei allgemeine Grundsätze zu halten:
Zunächst ist es notwendig, die erforderliche Funktionalität und Zuverlässigkeit des PS sicherzustellen und dann die verbleibenden Qualitätskriterien auf ein akzeptables Niveau ihrer Präsenz im PS zu bringen.
es besteht keine Notwendigkeit, und es kann sogar schädlich sein, im PS einen höheren Grad an Präsenz irgendeines Qualitätsprimitivs zu suchen als das, das in der PS-Qualitätsspezifikation definiert ist.
Die Sicherstellung der Funktionalität und Zuverlässigkeit des PS wurde in der vorherigen Vorlesung betrachtet. Die Bereitstellung anderer OS-Qualitätskriterien wird unten diskutiert.
12.2.. Gewährleistung einer einfachen Bedienbarkeit des Softwaretools
Die P-Dokumentation der PS bestimmt den Aufbau der Benutzerdokumentation
In der vorherigen Vorlesung wurde bereits die Bereitstellung von zwei der fünf Qualitätsprimitiven (Stabilität und Sicherheit) betrachtet, die die Benutzerfreundlichkeit des PS bestimmen.
P-Dokumentation und Aussagekraft bestimmen den Aufbau und die Qualität der Benutzerdokumentation (siehe nächste Vorlesung).
Die Geselligkeit wird durch die Schaffung einer geeigneten Benutzeroberfläche und die angemessene Umsetzung von Ausnahmesituationen sichergestellt. Was ist hier das Problem?
12.3. Sicherstellung der Effektivität der Software.
Die Wirksamkeit des PS wird sichergestellt, indem in verschiedenen Stadien seiner Entwicklung geeignete Entscheidungen getroffen werden, beginnend mit der Entwicklung seiner Architektur. Die Wahl der Datenstruktur und -darstellung wirkt sich besonders stark auf die Effizienz von PS aus (insbesondere in Bezug auf den Speicher). Aber die Wahl der in bestimmten Softwaremodulen verwendeten Algorithmen sowie die Merkmale ihrer Implementierung (einschließlich der Wahl der Programmiersprache) können die Effektivität des PS erheblich beeinflussen. Gleichzeitig muss man den Widerspruch zwischen Zeiteffizienz und Erinnerungseffizienz immer wieder auflösen. Daher ist es sehr wichtig, dass die Qualitätsspezifikation die quantitative Beziehung zwischen den Indikatoren dieser Qualitätsgrundelemente explizit angibt oder zumindest quantitative Grenzen für einen dieser Indikatoren festlegt. Und doch wirken sich unterschiedliche Softwaremodule unterschiedlich auf die Effizienz des PS als Ganzes aus: sowohl in Bezug auf ihren Beitrag zu den Gesamtkosten des PS in Bezug auf Zeit und Speicher als auch in Bezug auf die Auswirkungen auf unterschiedliche Qualitätsprimitive (Einige Module können das Erreichen der Zeiteffizienz stark beeinträchtigen und wirken sich praktisch nicht auf die Speichereffizienz aus, während andere den Gesamtspeicherverbrauch erheblich beeinflussen können, ohne die Betriebszeit des PS erheblich zu beeinträchtigen). Zudem kann diese Auswirkung (vor allem in Bezug auf die Zeiteffizienz) im Vorfeld (vor Abschluss der Umsetzung des PS) nicht immer richtig eingeschätzt werden.
Sie müssen zunächst einen zuverlässigen PS entwickeln und erst dann die erforderliche Effizienz gemäß der Qualitätsspezifikation dieses PS erreichen.
Um die Effizienz des PS zu verbessern, verwenden Sie zunächst einen Optimierungscompiler - dies kann die erforderliche Effizienz bieten.
wenn die erzielte Effizienz des PS die Spezifikation seiner Qualität nicht erfüllt, dann finde die kritischsten Module in Bezug auf die erforderliche Effizienz des PS (im Fall der zeitlichen Effizienz erfordert dies den Erhalt der Verteilung nach Modulen des PS Betriebszeit durch geeignete Messungen während der Ausführung des PS); diese Module und versuchen Sie, sie zuerst zu optimieren, indem Sie sie manuell modifizieren;
Optimieren Sie das Modul nicht, wenn es nicht erforderlich ist, um die erforderliche Effizienz des PS zu erreichen.
12.4. Gewährleistung der Wartbarkeit.
C-Dokumentation, Informationsgehalt und Verständlichkeit bestimmen den Aufbau und die Qualität der Instandhaltungsdokumentation (siehe nächste Vorlesung). Darüber hinaus können folgende Empfehlungen zu den Texten von Studiengängen (Modulen) gegeben werden.
Verwenden Sie Kommentare im Text des Moduls, die die Merkmale der getroffenen Entscheidungen verdeutlichen und erläutern. Kommentare (zumindest in Kurzform) möglichst schon in der frühesten Entwicklungsphase des Modultextes einbeziehen;
verwenden Sie aussagekräftige (mnemonische) und dauerhaft unterscheidbare Namen (die optimale Länge des Namens beträgt 4-12 Buchstaben, Zahlen stehen am Ende), verwenden Sie keine ähnlichen Namen und Schlüsselwörter;
Seien Sie vorsichtig, wenn Sie Konstanten verwenden (eine eindeutige Konstante muss im Modultext einmal vorkommen: wenn sie deklariert wird oder in extremen Fällen, wenn die Variable als Konstante initialisiert wird);
Scheuen Sie sich nicht, optionale Klammern zu verwenden (Klammern sind billiger als Fehler ;
Platzieren Sie nicht mehr als eine Aussage pro Zeile; Um die Struktur des Moduls zu verdeutlichen, verwenden Sie zusätzliche Leerzeichen (Einrückungen) am Anfang jeder Zeile ;
vermeide Tricks, d.h. solche Programmiertechniken, wenn Fragmente eines Moduls erstellt werden, deren Hauptwirkung nicht offensichtlich oder verborgen (verschleiert) ist, z. B. Nebeneffekte von Funktionen.
Die Erweiterbarkeit wird durch die Erstellung eines geeigneten Installers sichergestellt.
Strukturiertheit und Modularität vereinfachen sowohl das Verständnis von Programmtexten als auch deren Modifikation.
12.5. Mobilität sicherstellen.
Literatur zur Vorlesung 12.
12.1. Ian Somerville. Softwareentwicklung. - Addison-Wesley Publishing Company, 1992. S.
12.3. D. Van Quaste. Stil, Entwicklung, Effizienz, Debugging und Testprogramme. - M.: Mir, 1985. S. 8-44, 117-178.
12.4. Software-Benutzerdokumentation/ANSI/IEEE-Standard 1063-1987.
Vortrag 13
13.1. Dokumentation, die während des Softwareentwicklungsprozesses erstellt wurde.
Bei der Entwicklung einer PS wird eine Vielzahl unterschiedlicher Dokumentationen erstellt. Es ist notwendig, um Informationen zwischen den Entwicklern des PS zu übertragen, um die Entwicklung des PS zu verwalten und um den Benutzern die Informationen zu übermitteln, die für die Anwendung und Wartung des PS erforderlich sind. Die Erstellung dieser Dokumentation macht einen großen Teil der Kosten des PS aus.
Diese Dokumentation kann in zwei Gruppen unterteilt werden:
Dokumente des PS-Entwicklungsmanagements.
Dokumente im PS enthalten.
PS-Entwicklungsmanagementdokumente (Prozessdokumentation) zeichnen die Prozesse der Entwicklung und Wartung des PS auf und sorgen für die Kommunikation innerhalb des Entwicklungsteams und zwischen dem Entwicklungsteam und Managern (Managern) - Personen, die die Entwicklung leiten. Diese Dokumente können folgender Art sein:
Pläne, Schätzungen, Zeitpläne. Diese Dokumente werden von Managern erstellt, um Entwicklungs- und Wartungsprozesse vorherzusehen und zu verwalten.
Berichte zur Ressourcennutzung während der Entwicklung. Erstellt von Managern.
Normen. Diese Dokumente schreiben den Entwicklern vor, welche Prinzipien, Regeln und Vereinbarungen sie bei der Entwicklung des PS befolgen müssen. Diese Standards können entweder international oder national sein oder speziell für die Organisation geschaffen werden, in der dieser PS entwickelt wird.
Arbeitsunterlagen. Dies sind die wichtigsten technischen Dokumente, die die Kommunikation zwischen Entwicklern ermöglichen. Sie enthalten eine Fixierung von Ideen und Problemen, die während des Entwicklungsprozesses auftreten, eine Beschreibung der verwendeten Strategien und Vorgehensweisen sowie funktionierende (temporäre) Versionen von Dokumenten, die in die PS aufgenommen werden sollten.
Notizen und Korrespondenz. Diese Dokumente erfassen verschiedene Details der Interaktion zwischen Managern und Entwicklern.
Die in der PS (Produktdokumentation) enthaltenen Dokumente beschreiben die PS-Programme sowohl aus der Sicht ihrer Nutzung durch die Benutzer als auch aus der Sicht ihrer Entwickler und Betreuer (entsprechend dem Zweck der PS). Hierbei ist zu beachten, dass diese Dokumente nicht nur in der Phase des Betriebs des PS (in der Anwendungs- und Wartungsphase), sondern auch in der Entwicklungsphase zur Verwaltung des Entwicklungsprozesses (zusammen mit den Arbeitsdokumenten) verwendet werden - in jedem Fall In diesem Fall sollten sie auf Übereinstimmung mit PS-Programmen überprüft (getestet) werden. Diese Dokumente bilden zwei Sätze mit unterschiedlichen Zwecken:
PS-Anwenderdokumentation (P-Dokumentation).
Dokumentation zur Unterstützung des PS (C-Dokumentation).
13.2. Software-Benutzerdokumentation.
Die Benutzerdokumentation der PS (Benutzerdokumentation) erklärt den Benutzern, wie sie vorgehen müssen, um diese PS anzuwenden. Es ist erforderlich, wenn das PS eine Interaktion mit Benutzern beinhaltet. Diese Dokumentation umfasst Dokumente, die den Benutzer bei der Installation des PS (bei der Installation des PS mit der geeigneten Einstellung für die Umgebung zur Verwendung des PS), bei der Verwendung des PS zur Lösung seiner Probleme und bei der Verwaltung des PS (z. B. wenn dieses PS interagiert mit anderen Systemen). Diese Dokumente decken teilweise die Probleme des Software-Supports ab, behandeln jedoch keine Probleme im Zusammenhang mit der Änderung von Programmen.
In dieser Hinsicht sollten zwei Kategorien von PS-Benutzern unterschieden werden: normale PS-Benutzer und PS-Administratoren. Ein gewöhnlicher Benutzer des PS (Endbenutzer) verwendet den PS, um seine Probleme (in seinem Fachgebiet) zu lösen. Das kann ein Ingenieur sein, der ein technisches Gerät entwirft, oder ein Kassierer, der Bahntickets mit einem PS verkauft. Er kennt möglicherweise nicht viele Details des Computerbetriebs oder der Programmierprinzipien. Der PS-Administrator (Systemadministrator) verwaltet die Verwendung des PS durch normale Benutzer und stellt Unterstützung für das PS bereit, die nicht mit der Modifikation von Programmen zusammenhängt. Beispielsweise kann es die Zugriffsrechte auf das Betriebssystem zwischen normalen Benutzern regeln, mit den Anbietern des Betriebssystems kommunizieren oder bestimmte Aktionen ausführen, um das Betriebssystem funktionsfähig zu halten, wenn es Teil eines anderen Systems ist.
Die Zusammensetzung der Benutzerdokumentation hängt von den Zielgruppen der Benutzer ab, an die sich diese PS richten, und von der Art der Verwendung der Dokumente. Unter Publikum wird hier das Kontingent von Benutzern der PS verstanden, das Bedarf an einer bestimmten Benutzerdokumentation der PS hat. Ein erfolgreiches Benutzerdokument hängt wesentlich von der genauen Definition der Zielgruppe ab, für die es bestimmt ist. Die Benutzerdokumentation sollte die für jede Zielgruppe erforderlichen Informationen enthalten. Die Art der Verwendung eines Dokuments bezieht sich auf die Art und Weise, in der das Dokument verwendet wird. Üblicherweise benötigt der Nutzer ausreichend großer Softwaresysteme entweder Unterlagen zum Studium der PS (Nutzung in Form einer Anleitung) oder zur Verdeutlichung einiger Informationen (Nutzung in Form eines Nachschlagewerks).
Entsprechend den Arbeiten kann folgender Aufbau der Benutzerdokumentation für ausreichend große PS als typisch angesehen werden:
Allgemein Funktionsbeschreibung PS. Gibt eine kurze Beschreibung der Funktionalität des PS. Es ist für Benutzer gedacht, die entscheiden müssen, wie viel sie dieses PS benötigen.
PS-Installationsanleitung. Entwickelt für Systemadministratoren. Es sollte detailliert vorschreiben, wie Systeme in einer bestimmten Umgebung zu installieren sind. Es muss eine Beschreibung des maschinenlesbaren Mediums enthalten, auf dem die MS geliefert wird, die Dateien, die die MS darstellen, und die Anforderungen an die Mindesthardwarekonfiguration.
Gebrauchsanweisung für PS. Entwickelt für normale Benutzer. Enthält die notwendigen Informationen zur Anwendung des PS, die in einer für das Studium geeigneten Form angeordnet sind.
Nachschlagewerk zur Anwendung von PS. Entwickelt für normale Benutzer. Enthält die notwendigen Informationen zur Anwendung des PS, die in einer Form angeordnet sind, die für die selektive Suche nach einzelnen Details geeignet ist.
Handbuch PS-Verwaltung. Entwickelt für Systemadministratoren. Es sollte die Nachrichten beschreiben, die erzeugt werden, wenn die MS mit anderen Systemen interagiert, und wie auf diese Nachrichten zu antworten ist. Wenn die MS Systemhardware verwendet, kann dieses Dokument außerdem erläutern, wie diese Hardware gewartet wird.
Wie bereits erwähnt (siehe Vorlesung 4), beginnt die Entwicklung der Benutzerdokumentation unmittelbar nach der Erstellung einer externen Beschreibung. Die Qualität dieser Dokumentation kann maßgeblich über den Erfolg einer PS entscheiden. Es sollte ziemlich einfach und benutzerfreundlich sein (andernfalls war es im Allgemeinen nicht wert, dieses PS zu erstellen). Obwohl Entwurfsversionen (Entwürfe) von Benutzerdokumenten von den Hauptentwicklern des PS erstellt werden, sind daher häufig professionelle technische Redakteure an der Erstellung ihrer endgültigen Versionen beteiligt. Um die Qualität der Benutzerdokumentation zu gewährleisten, wurden außerdem eine Reihe von Standards entwickelt (siehe beispielsweise), die das Verfahren zur Erstellung dieser Dokumentation vorschreiben, Anforderungen an jede Art von Benutzerdokumentation formulieren und deren Struktur und Inhalt festlegen .
13.3. Software-Support-Dokumentation.
Dokumentation zur Pflege der PS (Systemdokumentation) beschreibt die PS aus Sicht ihrer Entwicklung. Diese Dokumentation ist erforderlich, wenn die PS die Untersuchung ihrer Anordnung (Gestaltung) und die Modernisierung ihrer Programme beinhaltet. Wie bereits erwähnt, ist die Wartung eine fortlaufende Entwicklung. Wenn es daher erforderlich ist, das PS zu aktualisieren, ist ein spezielles Team von begleitenden Entwicklern an dieser Arbeit beteiligt. Dieses Team muss sich mit der gleichen Dokumentation befassen, die die Aktivitäten des Teams der ursprünglichen (Haupt-)Entwickler des PS bestimmt hat, mit dem einzigen Unterschied, dass diese Dokumentation in der Regel jemand anderes für das Entwicklungsteam des Betreuers sein wird ( es wurde von einem anderen Team erstellt). Das Entwicklungsteam des Betreuers muss diese Dokumentation studieren, um die Struktur und den Entwicklungsprozess des aktualisierten Betriebssystems zu verstehen, und die erforderlichen Änderungen an dieser Dokumentation vornehmen, die sich weitgehend wiederholen technologische Prozesse, mit der das ursprüngliche PS erstellt wurde.
Die Dokumentation zur Unterstützung von PS kann in zwei Gruppen unterteilt werden:
(1) Dokumentation, die die Struktur von Programmen und Datenstrukturen des PS und die Technologie für ihre Entwicklung definiert;
(2) Dokumentation zur Unterstützung von Änderungen am PS.
Die Dokumentation der ersten Gruppe enthält die Abschlussdokumente jeder technologischen Stufe der Entwicklung des PS. Es umfasst folgende Dokumente:
Externe Beschreibung des PS (Requirements document).
Beschreibung der Systemarchitektur des PS, einschließlich der externen Spezifikation jedes seiner Programme.
Für jedes PS-Programm eine Beschreibung seiner modularen Struktur, einschließlich einer externen Spezifikation für jedes darin enthaltene Modul.
Für jedes Modul - seine Spezifikation und Beschreibung seiner Struktur (Designbeschreibung).
Modultexte in der gewählten Programmiersprache (Programm-Quellcode-Listings).
OS-Validierungsdokumente, die beschreiben, wie die Gültigkeit jedes OS-Programms festgestellt wurde und wie die Validierungsinformationen mit den Anforderungen für das OS verknüpft wurden.
Softwareverifizierungsdokumente umfassen in erster Linie Testdokumentation (Testdesign und Beschreibung der Testsuite), können aber auch die Ergebnisse anderer Arten der Softwarevalidierung enthalten, wie z. B. Nachweise von Programmeigenschaften.
Die Dokumentation der zweiten Gruppe enthält
Der Systemwartungsleitfaden, der bekannte Probleme zusammen mit der Software beschreibt, beschreibt, welche Teile des Systems hardware- und softwareabhängig sind und wie die Entwicklung der Software in ihrer Struktur (Design) berücksichtigt wird.
Ein häufiges Wartungsproblem für einen PS besteht darin, sicherzustellen, dass alle seine Darstellungen Schritt halten (konsistent bleiben), wenn sich der PS ändert. Um dies zu unterstützen, müssen Beziehungen und Abhängigkeiten zwischen Dokumenten und ihren Teilen in der Koerfasst werden.
Literatur zur Vorlesung 13.
13.1. Ian Somerville. Softwareentwicklung. - Addison-Wesley Publishing Company, 1992. S.
13.2. ANSI/IEEE Std 1063-1988, IEEE-Standard für Software-Benutzerdokumentation.
13.3. ANSI/IEEE Std 830-1984, IEEE Guide for Software Requirements Specification.
13.4. ANSI/IEEE Std 1016-1987, IEEE Recommended Practice for Software Design Description.
13.5. ANSI/IEEE Std 1008-1987, IEEE-Standard für das Testen von Softwareeinheiten.
13.6. ANSI/IEEE Std 1012-1986, IEEE-Standard für Softwareverifizierungs- und -validierungspläne.
13.7. ANSI/IEEE Std 983-1986, IEEE Guide for Software Quality Assurance Planning.
13.8. ANSI/IEEE Std 829-1983, IEEE-Standard für die Dokumentation von Softwaretests.
Vortrag 14
Ernennung der Software-Zertifizierung. Testen und Bewerten der Softwarequalität. Arten von Tests und Methoden zur Bewertung der Qualität von Software.
14.1. Ernennung der Software-Zertifizierung.
Die PS-Zertifizierung ist eine maßgebliche Bestätigung der Qualität des PS. Üblicherweise wird für die Zertifizierung eines Softwaresystems eine repräsentative (Atestierungs-)Kommission gebildet, die sich aus Experten, Vertretern des Kunden und Vertretern des Entwicklers zusammensetzt. Diese Kommission führt Tests des PS durch, um die notwendigen Informationen zur Beurteilung seiner Qualität zu erhalten. Unter Prüfung der PS verstehen wir den Prozess der Durchführung eines Maßnahmenbündels, das die Eignung der PS für ihren erfolgreichen Betrieb (Einsatz und Wartung) gemäß den Anforderungen des Kunden prüft. Dieser Komplex umfasst die Überprüfung der Vollständigkeit und Richtigkeit der Softwaredokumentation, das Studium und die Besprechung ihrer sonstigen Eigenschaften sowie die erforderlichen Tests der im Softwarepaket enthaltenen Programme und insbesondere die Übereinstimmung dieser Programme mit der verfügbaren Dokumentation.
Anhand der bei der Prüfung des PS gewonnenen Informationen muss zunächst festgestellt werden, dass das PS die deklarierten Funktionen erfüllt und inwieweit das PS die deklarierten Primitiven und Qualitätskriterien aufweist. Somit ist die Bewertung der Qualität des PS der Hauptinhalt des Zertifizierungsprozesses. Die Beurteilung der Qualität des PS wird im entsprechenden Beschluss der Bescheinigungskommission festgehalten.
14.2. Arten von Softwaretests.
Die folgenden Arten von PS-Tests sind bekannt, die zum Zweck der Zertifizierung von PS durchgeführt werden:
Prüfung von PS-Komponenten;
Systemtests;
Akzeptanztests;
Feldversuche;
industrielle Tests.
Der PS-Komponententest ist eine Überprüfung (Prüfung) der Funktionsfähigkeit einzelner Subsysteme des PS. Wird nur in Ausnahmefällen durchgeführt besondere Entscheidung Zertifizierungsausschuss.
Der Systemtest der PS ist eine Überprüfung (Prüfung) der Funktionsfähigkeit der PS als Ganzes. Es kann die gleichen Testarten beinhalten wie beim komplexen Debugging des PS (siehe Vorlesung 10). Es wird durch Beschluss der Bescheinigungskommission durchgeführt, wenn Zweifel an der Qualität der Fehlersuche durch die Entwickler des PS bestehen.
Abnahmetests sind die wichtigste Art von Tests für die Zertifizierung von PS. Mit diesen Prüfungen beginnt die Zertifizierungskommission ihre Arbeit. Diese Tests beginnen mit dem Studium der eingereichten Dokumentation, einschließlich der Dokumentation zum Testen und Debuggen des PS. Enthält die Dokumentation keine ausreichend vollständigen Ergebnisse von Softwaretests, kann der Zertifizierungsausschuss entscheiden, eine Systemprüfung der Software durchzuführen oder den Zertifizierungsprozess mit einer Empfehlung an den Entwickler zu beenden, zusätzliche (vollständigere) Tests der Software durchzuführen. Darüber hinaus können bei diesen Tests Entwicklertests gezielt übersprungen werden, sowie Benutzerkontrollaufgaben (siehe Vortrag 10) und zusätzliche von der Kommission vorbereitete Tests zur Beurteilung der Qualität des zertifizierten PS.
Der Feldtest des PS ist eine Demonstration des PS zusammen mit dem von diesem PS gesteuerten technischen System einem engen Kundenkreis unter realen Bedingungen, und das Verhalten des PS wird sorgfältig überwacht. Kunden soll die Möglichkeit gegeben werden, eigene Testfälle, insbesondere von Ausgängen bis hin zu kritischen Betriebsweisen des technischen Systems, sowie beim Aufruf von Notfallsituationen darin einzustellen. Dies sind zusätzliche Prüfungen, die auf Beschluss der Bescheinigungskommission nur für einige PS durchgeführt werden, die bestimmte technische Systeme steuern.
Die industrielle Erprobung der PS ist der Prozess der Überführung der PS in den dauerhaften Betrieb für Benutzer. Es handelt sich um eine Testphase des PS (siehe Vortrag 10) durch Benutzer mit der Sammlung von Informationen über das Verhalten des PS und seine Betriebseigenschaften. Dies sind die abschließenden Prüfungen des PS, die auf Beschluss der Bescheinigungskommission durchgeführt werden, wenn bei den vorangegangenen Prüfungen nicht ausreichend vollständige oder verlässliche Informationen zur Beurteilung der Qualität des zertifizierten PS gewonnen wurden.
14.3. Methoden zur Bewertung der Qualität von Software.
Die Bewertung der Qualität des PS für jedes der Kriterien wird auf die Bewertung jedes der diesem Kriterium der Qualität des PS zugeordneten Primitiven gemäß ihrer Spezifikation, die in der Qualitätsspezifikation dieses PS vorgenommen wird, reduziert. Verfahren zur Bewertung von PS-Qualitätsprimitiven können in vier Gruppen eingeteilt werden:
direkte Messung von primitiven Qualitätsindikatoren;
Verarbeitung von Programmen und Dokumentation der PS mit speziellen Softwaretools (Prozessoren);
Testen von PS-Programmen;
Expertenbewertung auf der Grundlage des Studiums von Programmen und Dokumentationen der PS.
Die direkte Messung von primitiven Qualitätsindikatoren erfolgt durch Zählen der Häufigkeit des Auftretens von charakteristischen Einheiten, Objekten, Strukturen usw. in einem bestimmten Programmdokument sowie durch Messen der Betriebszeit verschiedener Geräte und der Menge des belegten Computerspeichers Testfälle durchführen. Beispielsweise kann ein Maß für die Speichereffizienz die Anzahl der Zeilen eines Programms in einer Programmiersprache sein, und ein Maß für die Zeiteffizienz kann die Antwortzeit auf eine Abfrage sein. Die Verwendung beliebiger Indikatoren für Qualitätsprimitive kann in der Qualitätsspezifikation des MS definiert werden. Die Methode der direkten Messung von primitiven Qualitätsindikatoren kann mit der Verwendung von Programmtests kombiniert werden.
Bestimmte Softwarewerkzeuge können verwendet werden, um zu bestimmen, ob eine MS bestimmte Qualitätsgrundelemente hat. Solche Softwaretools verarbeiten Programmtexte bzw Programmdokumentation um irgendwelche Qualitätsgrundelemente zu kontrollieren oder einige Indikatoren dieser Qualitätsgrundelemente zu erhalten. Um die Strukturiertheit von PS-Programmen zu beurteilen, wenn sie in einem geeigneten strukturellen Dialekt der Basisprogrammiersprache programmiert wurden, würde es ausreichen, sie durch einen Konverter für strukturierte Programme zu leiten, der eine syntaktische und einige semantische Kontrolle dieses Dialekts durchführt und die Texte übersetzt diese Programme in die Eingabesprache des Basisübersetzers. Allerdings kann derzeit nur eine kleine Anzahl von Qualitätsprimitiven auf diese Weise kontrolliert werden, und selbst dann in seltenen Fällen. In einigen Fällen ist es sinnvoller, anstelle von Softwaretools, die die Qualität der Software kontrollieren, Tools zu verwenden, die die Präsentation von Programmen oder die Programmdokumentation verändern. Dies ist zum Beispiel ein Programmformatierer, der Programmtexte in eine lesbare Form bringt – die Verarbeitung von Texten von PS-Programmen mit einem solchen Werkzeug kann automatisch sicherstellen, dass das PS eine geeignete Qualitätsprimitive hat.
Das Testen wird verwendet, um einige Grundelemente der PS-Qualität zu bewerten. Solche Primitiven umfassen hauptsächlich die Vollständigkeit des PS sowie seine Genauigkeit, Stabilität, Sicherheit und andere Qualitätsprimitive. In einigen Fällen wird das Testen in Kombination mit anderen Verfahren verwendet, um einzelne PS-Qualitätsprimitive zu bewerten. Zur Beurteilung der Qualität der Dokumentation über die Verwendung von PS (P-Dokumentation) wird daher eine Prüfung in Kombination mit einer Expertenbewertung dieser Dokumentation verwendet. Wurde beim aufwendigen Debugging des PS ein hinreichend vollständiger Test durchgeführt, so können die gleichen Tests bei der Zertifizierung des PS verwendet werden. In diesem Fall kann das Zertifizierungskomitee die Testprotokolle verwenden, die während der komplexen Fehlersuche durchgeführt wurden. Aber auch in diesem Fall ist es notwendig, einige neue Tests durchzuführen oder zumindest einige der alten zu wiederholen. Wenn sich herausstellt, dass das Testen während des komplexen Debuggings nicht vollständig genug ist, dann ist es notwendig, ein vollständigeres Testen durchzuführen. In diesem Fall kann eine Entscheidung getroffen werden, Komponententests oder Systemtests des PS durchzuführen, sowie das PS zur Überarbeitung an die Entwickler zurückzugeben. Es ist sehr wichtig, dass zur Bewertung des PS nach dem Kriterium der Benutzerfreundlichkeit (während des Debuggens und der Zertifizierung des PS) vollständige Tests an Tests durchgeführt werden, die auf der Grundlage der Dokumentation für die Anwendung erstellt wurden, und entsprechend zum Kriterium der Wartbarkeit - auf Tests, die für jedes der zur Wartung vorgeschlagenen Dokumente vorbereitet wurden PS.
Zur Bewertung der meisten PS-Qualitätsprimitive kann derzeit nur die Methode der Expertenbewertung verwendet werden. Diese Methode besteht aus Folgendem: Eine Expertengruppe wird ernannt, jeder dieser Experten gibt nach dem Studium der eingereichten Unterlagen seine Meinung zum Besitz des PS nach der erforderlichen Primitivqualität ab und bewertet dann die erforderliche Qualitätsprimitiv des PS wird durch Abstimmung der Mitglieder dieser Gruppe festgelegt. Diese Bewertung kann sowohl auf einem Zwei-Punkte-System erfolgen ("besitzt" - "hat nicht") als auch den Besitzgrad des PS durch dieses Qualitätsprimitiv berücksichtigen (z. B. kann es auf einer Fünf erfolgen -punkte System). Gleichzeitig sollte sich die Expertengruppe an der Spezifikation dieses Primitivs und einem Hinweis auf die Methode zu seiner Bewertung orientieren, die in der Qualitätsspezifikation des zertifizierten PS formuliert sind.
Literatur zur Vorlesung 14.
14.2. V. W. Lipaev. Programmtest. - M.: Funk und Kommunikation, 1986. - S. 231-245.
14.3. D. Van Quaste. Stil, Entwicklung, Effizienz, Debugging und Testprogramme. - M.: Mir, 1985. - S. 281-283.
14.4. B. Schneidermann. Psychologie des Programmierens. - M.: Funk und Kommunikation, 1984. - S. 99-127.
Vorlesung 15. Objektansatz in der Softwareentwicklung
15.1. Objekte und Beziehungen in der Programmierung. Die Essenz des Objektansatzes in der Softwareentwicklung.
Die Welt um uns herum besteht aus Objekten und Beziehungen zwischen ihnen. Ein Objekt verkörpert eine Entität und hat einen Zustand, der sich im Laufe der Zeit als Ergebnis des Einflusses anderer Objekte ändern kann, die in irgendeiner Weise mit den Daten verbunden sind. Das hat er vielleicht Interne Struktur: aus anderen Objekten bestehen, die ebenfalls in irgendeiner Beziehung zueinander stehen. Davon ausgehend ist es möglich, aus Objekten eine hierarchische Struktur der Welt aufzubauen. Für jede spezifische Betrachtung der Welt um uns herum gelten jedoch einige Objekte als unteilbar ("Punkt"), und je nach Ziel der Betrachtung können solche (unteilbaren) Objekte unterschiedlicher Hierarchieebenen akzeptiert werden. Eine Beziehung verbindet einige Objekte: Wir können davon ausgehen, dass die Vereinigung dieser Objekte eine Eigenschaft hat. Verbindet eine Relation n Objekte, so wird eine solche Relation n-stellig (n-stellig) genannt. An jeder Assoziationsstelle von Objekten, die durch eine beliebige spezifische Beziehung verbunden werden können, können verschiedene Objekte stehen, aber ganz bestimmte (in diesem Fall heißt es: Objekte einer bestimmten Klasse). Eine einstellige Relation wird als Eigenschaft eines Objekts (der entsprechenden Klasse) bezeichnet. Der Zustand eines Objekts kann durch den Wert der Eigenschaften dieses Objekts oder implizit durch den Wert der Eigenschaften der Vereinigungen von Objekten untersucht werden, die durch eine gegebene Beziehung miteinander verbunden sind.
Beim Erkennen oder Verändern der Welt um uns herum berücksichtigen wir immer das eine oder andere vereinfachte Modell der Welt (Modellwelt), in das wir einige der Objekte und einige der Beziehungen der Welt um uns herum einbeziehen und, in der Regel eine Hierarchieebene. Jedes Objekt, das eine interne Struktur hat, kann seine eigene Modellwelt darstellen, einschließlich der Objekte dieser Struktur und der Beziehungen, die sie verbinden. Somit kann die Welt um uns herum (in gewisser Annäherung) als betrachtet werden hierarchische Struktur Modellwelten.
Gegenwärtig wird Computertechnologie im Prozess des Lernens oder der Veränderung der Welt um uns herum weit verbreitet verwendet, um verschiedene Arten von Informationen zu verarbeiten. In dieser Hinsicht wird eine Computer-(Informations-)Darstellung von Objekten und Relationen verwendet. Jedes Objekt kann informativ durch eine Datenstruktur dargestellt werden, die seinen Zustand anzeigt. Die Eigenschaften dieses Objekts können direkt als separate Komponenten dieser Struktur oder durch spezielle Funktionen auf dieser Datenstruktur festgelegt werden. N-stellige Relationen für N>1 können entweder in aktiver Form oder in passiver Form dargestellt werden. In seiner aktiven Form wird eine N-Stellen-Beziehung durch ein Programmfragment dargestellt, das entweder eine N-Stellen-Funktion (die den Wert der Eigenschaft der entsprechenden Vereinigung von Objekten bestimmt) oder eine Prozedur implementiert, die die Zustände einiger von ihnen basierend ändert über den Zustand von Repräsentationen von Objekten, die durch die Repräsentationsbeziehung verbunden sind. In einer passiven Form kann eine solche Relation durch eine bestimmte Datenstruktur dargestellt werden (die Repräsentationen von Objekten enthalten kann, die durch diese Relation verbunden sind), interpretiert auf der Grundlage akzeptierter Vereinbarungen über allgemeine Verfahren, die von bestimmten Relationen unabhängig sind (z relationale Datenbank). In beiden Fällen definiert die Darstellung der Beziehung einige Datenverarbeitungsaktivitäten.
Beim Erkunden der Modellwelt kann der Benutzer auf unterschiedliche Weise Informationen vom Computer erhalten (oder erhalten wollen). Bei einem Ansatz kann er daran interessiert sein, Informationen über die individuellen Eigenschaften der ihn interessierenden Objekte oder die Ergebnisse irgendeiner Interaktion zwischen einigen Objekten zu erhalten. Zu diesem Zweck befiehlt er die Entwicklung des einen oder anderen PS, der die für ihn interessanten Funktionen ausführt, oder eines Informationssystems, das in der Lage ist, Informationen über die für ihn interessanten Beziehungen unter Verwendung der entsprechenden Datenbank auszugeben. In der Anfangszeit der Entwicklung der Computertechnologie (mit nicht genügend hoher Computerleistung) war eine solche Herangehensweise an die Verwendung von Computern ganz natürlich. Er war es, der den funktionalen (relationalen) Ansatz zur Entwicklung von PS provozierte, der in früheren Vorträgen ausführlich besprochen wurde. Die Essenz dieses Ansatzes ist die systematische Verwendung der Zerlegung von Funktionen (Relationen), um die Struktur des PS und der darin enthaltenen Programmtexte aufzubauen. Gleichzeitig wurden die Objekte selbst, auf die die bestellten und implementierten Funktionen angewendet wurden, fragmentarisch (in dem für die Ausführung dieser Funktionen erforderlichen Umfang) und in einer für die Implementierung dieser Funktionen geeigneten Form präsentiert. Somit wurde eine vollständige und angemessene Computerdarstellung der für den Benutzer interessanten Modellwelt nicht bereitgestellt: Die Anzeige auf dem verwendeten PS könnte sich als eine ziemlich mühsame Aufgabe für den Benutzer herausstellen, ein Versuch, den Umfang und die Art etwas zu erweitern Informationen über die für den Benutzer interessante Modellwelt. die von einer solchen Unterstation empfangen werden, könnten zu ihrer ernsthaften Modernisierung führen. Dieser Ansatz zur Entwicklung von PS wird von den meisten verwendeten Programmiersprachen unterstützt, die von Assemblersprachen und prozeduralen Sprachen (FORTRAN, Pascal) bis hin zu funktionalen Sprachen (LISP) und logischen Programmiersprachen ( PROLOG).
Bei einem anderen Ansatz zum Studium der Modellwelt unter Verwendung eines Computers könnte der Benutzer daran interessiert sein, die Änderung der Zustände von Objekten als Ergebnis ihrer Interaktionen zu beobachten. Dies erfordert eine ziemlich solide Darstellung des für den Benutzer interessanten Objekts im Computer, und die Softwarekomponenten, die die Beziehungen implementieren, an denen dieses Objekt teilnimmt, sind ausdrücklich damit verbunden. Um diesen Ansatz umzusetzen, war es notwendig, Softwaretools zu bauen, die die Prozesse der Interaktion zwischen Objekten (Modellwelt) simulieren. Mit Hilfe herkömmlicher Entwicklungstools stellte sich dies als recht mühsame Aufgabe heraus. Zwar sind Programmiersprachen erschienen, die sich speziell auf eine solche Modellierung konzentrieren, dies vereinfachte jedoch nur teilweise die Aufgabe, das erforderliche PS zu entwickeln. Die vollständigste Lösung dieses Problems ist der Objektansatz für die Entwicklung von PS. Sein Wesen liegt in der systematischen Verwendung der Zerlegung von Objekten bei der Konstruktion der Struktur des PS und der darin enthaltenen Texte von Programmen. Gleichzeitig wurden die von einem solchen PS ausgeführten Funktionen (Relationen) durch die Relationen von Objekten verschiedener Ebenen ausgedrückt, d.h. ihre Zerlegung hing maßgeblich von der Zerlegung von Objekten ab.
Wenn man über den Objektansatz spricht, sollte man auch klar verstehen, über welche Art von Objekten wir sprechen: Objekte der Modellwelt des Benutzers, ihre Informationsrepräsentation, Programmobjekte, mit deren Hilfe das PS gebaut wird. Außerdem sollte zwischen den eigentlichen Objekten („passive“ Objekte) und Subjekten („aktive“ Objekte) unterschieden werden.
15.2. Objekte und Subjekte in der Programmierung.
15.3. Objektive und subjektive Ansätze zur Softwareentwicklung.
Descartes stellte fest, dass Menschen normalerweise eine objektorientierte Sicht auf die Welt haben (c).
Sie glauben, dass objektorientiertes Design auf folgenden Prinzipien basiert:
Abstraktionen hervorheben,
Zugangsbeschränkung,
Modularität,
Hierarchie,
tippen,
Parallelität,
Nachhaltigkeit.
Aber all dies kann in einem funktionalen Ansatz angewendet werden.
Es ist notwendig, zwischen den Vor- und Nachteilen des allgemeinen Objektansatzes und seinem Spezialfall, dem subjektorientierten Ansatz, zu unterscheiden.
Vorteile des allgemeinen objektiven Ansatzes:
Natürliche Abbildung der realen Welt auf die PS-Struktur (natürliche menschliche Wahrnehmung der PS-Fähigkeiten, keine Notwendigkeit, die PS-Struktur zu "erfinden", sondern natürliche Analogien verwenden).
Die Verwendung ausreichend sinnvoller Struktureinheiten der PS (ein Objekt wie die Integrität von nicht-redundanten Assoziationen, informationsstarke Module).
Verringerung der Komplexität der Softwareentwicklung durch die Verwendung einer neuen Abstraktionsebene (unter Verwendung einer Hierarchie von "nicht-programmbezogenen" Abstraktionen in der Softwareentwicklung: Klassifizierung von Objekten der realen Welt, die Methode der Analogien in der Natur) als eine neue Ebene von Nachlass.
15.4. Ein Objektansatz zur Entwicklung einer externen Beschreibung und Softwarearchitektur.
Objektorientiertes Design ist eine Methode, die Objektzerlegung verwendet; Der objektorientierte Ansatz hat sein eigenes System von Konventionen und bietet eine Fülle von logischen und physikalische Modelle zum Entwerfen von Systemen mit hoher Komplexität. .
Die objektorientierte Analyse (OOA) hat den Objektansatz gerendert. OOA zielt darauf ab, realitätsnähere Modelle mit einem objektorientierten Ansatz zu erstellen; Es ist eine Methodik, bei der Anforderungen auf der Grundlage der Konzepte von Klassen und Objekten gebildet werden, die das Vokabular des Fachgebiets bilden. .
Merkmale der objektorientierten Programmierung.
Objekte, Klassen, Objektverhalten, Eigenschaften, Ereignisse.
Literatur zur Vorlesung 15.
15.1. K. Futi, N. Suzuki. Programmiersprachen und VLSI-Schaltungen. - M.: Mir, 1988. S. 85-98.
15.2. Ian Somerville. Softwareentwicklung. - Addison-Wesley Publishing Company, 1992. S. ?-?
15.3. G. Butsch. Objektorientiertes Design mit Anwendungsbeispielen: per. aus dem Englischen. -M.: Concord, 1992.
15.4. V. Sh. Kaufmann. Programmiersprachen. Konzepte und Prinzipien. Moskau: Radio und Kommunikation, 1993.
J. Hughes, J. Michtom. Struktureller Ansatz zur Programmierung. - M.: Mir, 1980. - p. 29-71.
V. Türkei. Programmiermethodik. - M.: Mir, 1981. - S. 90-164.
E.A. Schogolev. Technologische Grundlagen der modularen Programmierung // Programmierung, 1980, Nr. 2. - S.44-49.
RC Holt. Struktur von Computerprogrammen: Eine Übersicht // Proceedings of the IEEE, 1975, 63(6). - p. 879-893.
G. Myers. Software-Zuverlässigkeit. - M.: Mir, 1980. - p. 92-113.
I.Pyle. ADA ist eine eingebettete Systemsprache. M.: Finanzen und Statistik, 1984. - p. 67-75.
M. Zelkovets, A. Shaw, J. Gannon. Prinzipien der Softwareentwicklung. -M.: Mir, 1982, p. 65-71.
AL Fuksman. Technologische Aspekte der Erstellung von Softwaresystemen. M.: Statistik, 1979. - p. 79-94.
Reis. 8.4. Ein Beispiel für einen Detaillierungsschritt in Pseudocode.
„Entwicklung von Software
Softwaremodule
Software für Computer
Systeme"
MDK
SystemprogrammierungAnwendungsprogrammierung
Ziele und Ziele des Moduls
kennt:Hauptphasen der Softwareentwicklung
Sicherheit;
Grundlagen der Bautechnik
und objektorientiert
Programmierung;
Grundprinzipien des Debuggens und Testens
Softwareprodukte;
Methoden und Mittel zur technischen Entwicklung
Dokumentation.
Ziele und Ziele des Moduls
in der Lage sein:Softwarecode entwickeln
Module in modernen Programmiersprachen;
Erstellen Sie ein Programm gemäß dem entwickelten Algorithmus
als separates Modul;
debuggen und testen Sie das Programm
Modulebene;
Softwaredokumentation erstellen
Mittel;
Werkzeuge verwenden für
Automatisierung von Papierkram;
Ziele und Ziele des Moduls
praktische Erfahrung haben:Entwicklung eines Algorithmus für die Aufgabe und
Umsetzung mittels
automatisiertes Design;
Entwicklung von Softwareproduktcodes
basierend auf der fertigen Spezifikation auf der Ebene
Modul;
Einsatz von Werkzeugen auf
Debugging-Phase des Softwareprodukts;
Softwaretest
Modul nach einem bestimmten Szenario;
Berufliche Kompetenzen
PC1.1. Führen Sie die Entwicklung von Spezifikationen für Einzelpersonen durchKomponente.
PC1.2. Führen Sie die Entwicklung des Softwareproduktcodes durch
basierend auf vorgefertigten Spezifikationen auf Modulebene.
PC1.3. Debuggen von Programmmodulen mit durchführen
mit spezialisierter Software.
PC1.4. Führen Sie Tests von Softwaremodulen durch.
PC1.5. Zur Optimierung des Programmcodes des Moduls.
PC1.6. Design und technische Komponenten entwickeln
Dokumentation mit grafischen Sprachen
Spezifikationen.
Interdisziplinäre Verbindungen
Informatik und IKT;Informationstechnologie;
Architektur von Computersystemen;
Grundlagen der Programmierung;
Betriebssysteme.
Studienphasen
HörunterrichtWerkstätten
Selbstständige Arbeit
Kursprojekt
Pädagogische Praxis
Praktikum
Eignungsprüfung (Verteidigung
Bestand)
Anwendungsprogrammierung
Abschnitt 1. Grundprinzipien der Anwendungsentwicklung
Thema 1.1. Grundlegendes KonzeptAnwendungsprogrammierung
Fragen
SoftwareklassifizierungSoftware-Lebenszyklus
Phasen der Programmentwicklung
Programmdokumentation Was ist Programmieren? Programmieren - im weitesten Sinne
steht für alle technischen
Operationen, die zum Erstellen erforderlich sind
Programme, einschließlich Anforderungsanalyse und
alle Phasen der Entwicklung und Umsetzung. BEI
engen Sinn ist Codierung und
Programmtests innerhalb
ein bestimmtes Projekt. Was ist Software? Software (Software) (Software)
- allgemeiner Begriff für
"immateriell" (im Gegensatz zu physisch)
Komponenten eines Computersystems.
In den meisten Fällen bezieht es sich auf
Programme laufen
Computersystem zu
betonen ihren Unterschied zur Hardware
Mittel des gleichen Systems. Welche Klassen von Software
du weißt? System: Betriebssysteme; Fahrer
Geräte; verschiedene Dienstprogramme;
für Entwickler: Programmierumgebungen;
Übersetzer und Dolmetscher; CASE-Werkzeuge;
Programmbibliotheken;
für Endbenutzer: Text
Prozessoren; Tabellenkalkulationen; Grafik
Redakteure; Löser mathematischer Probleme;
Ausbildungs- und Kontrollsysteme;
Computerspiele; Anwendungsprogramme. Was ist eine angewandte
Programm? Anwendungsprogramm (Anwendung
Programm) - beliebiges Programm,
Beitrag zur Aufgabe,
innerhalb dieser dem Rechner zugeordnet
Organisation und einen direkten Beitrag leisten
Umsetzung dieser Aufgabe. Was kann man ein Softwaresystem nennen? Das Softwaresystem repräsentiert
ist eine Menge von Lösungen für die Menge
anders, aber verwandt
Aufgaben (OS, DBMS).
Höher spezialisiert
Programme werden nicht Systeme genannt
(Texteditor, Compiler usw.)
Software-Lebenszyklus (Software-Lebenszyklus) der gesamte Zeitraum des Bestehens
Softwaresysteme,
ausgehend von der Entwicklung des Anfangs
Konzept dieses Systems und dessen Beendigung
Veralten
SOFTWARE-LEBENSZYKLUS
STUFEN DER ERSTELLUNG VON PROGRAMMEN
Systemanalyse.Eine Analyse der Anforderungen an
Softwaresystem basierend auf
primäre Untersuchung aller Informationsflüsse
während der traditionellen Arbeit und wird durchgeführt
in folgender Reihenfolge:
a) Klärung von Art und Ablauf aller Arbeiten;
b) Definition von Zielen, die sein sollten
erreicht durch das entwickelte Programm;
c) Identifizierung von Analoga, die die Leistung sicherstellen
ähnliche Ziele, ihre Vor- und Nachteile.
STUFEN DER ERSTELLUNG VON PROGRAMMEN
Externe SpezifikationBesteht aus der Definition externer Spezifikationen, d.h.
Beschreibungen von Eingabe- und Ausgabeinformationen,
Formen ihrer Präsentation und Verarbeitung von Informationen.
Implementiert in der folgenden Reihenfolge:
a) eine Entwicklungsaufgabe stellen neues Programm;
b) Bewertung der erreichten Ziele der entwickelten
Softwareprodukt.
Außerdem können die Schritte 1-2 bei Bedarf wiederholt werden, bis
Erreichen eines zufriedenstellenden Erscheinungsbildes des Programms
System mit einer Beschreibung der Funktionen, die es ausführt und einige
Klarheit der Umsetzung seiner Funktionsweise.
STUFEN DER ERSTELLUNG VON PROGRAMMEN
ProgrammdesignEine Reihe von Arbeiten wird durchgeführt, um eine Beschreibung des Programms zu erstellen.
Die Ausgangsdaten für diese Phase sind die festgelegten Anforderungen
in der im vorherigen Schritt entwickelten Spezifikation. akzeptiert
Entscheidungen darüber, wie Anforderungen erfüllt werden
Spezifikationen. Diese Phase der Programmentwicklung ist in zwei Phasen unterteilt:
a) architektonisches Design. Es ist eine Entwicklung
allgemeine Beschreibung des Programms. Diese Beschreibung enthält
Information über Optionen konstruktiver Aufbau
Softwareprodukt (entweder in Form mehrerer Programme oder in Form von
mehrere Teile eines Programms), sowie über das Hauptprogramm
Algorithmen und Datenstrukturen. Die Ergebnisse dieser Arbeit sind
die endgültige Version der Softwaresystemarchitektur,
Anforderungen an die Struktur des Individuums Softwarekomponenten und
Organisation von Dateien für den Datenaustausch zwischen Programmen;
b) Arbeitsdesign. In diesem Stadium die architektonische Beschreibung
Programm ist detailliert auf ein Niveau, das macht
mögliche Arbeit an seiner Implementierung (Codierung und Montage). Zum
Dies erfolgt durch das Zusammenstellen und Prüfen der Spezifikationen der Module,
Zusammenstellung von Beschreibungen der Logik von Modulen, Zusammenstellung des Finales
Programmdurchführungsplan.
STUFEN DER ERSTELLUNG VON PROGRAMMEN
Codieren und TestenImplementiert für einzelne Module und
Sammlung fertiger Module bis zu
Erhalt des fertigen Programms.
Umfassende Prüfung
Entwicklung des Betriebs
Dokumentation
Akzeptanz und andere Arten
Prüfungen
STUFEN DER ERSTELLUNG VON PROGRAMMEN
ProgrammkorrekturBasierend auf Ergebnissen
vorherige Prüfungen.
Lieferung an den Kunden
Endgültige Lieferung im Gange
Softwareprodukt an den Kunden.
Reproduzieren
STUFEN DER ERSTELLUNG VON PROGRAMMEN
ProgrammunterstützungBeinhaltet alle erforderlichen technischen Operationen
dieses Programm in der Arbeit zu verwenden
Modus. Das Programm wird geändert
Korrekturen an der Arbeitsdokumentation vornehmen,
Programmverbesserung usw.
Aufgrund des breiten Umfangs solcher
Die Betriebsunterstützung ist iterativ
Prozess, den man durchführen möchte
so viel nach wie vor Software-Release
Produkte für den allgemeinen Gebrauch.
Fragen
1. Grundkonzepte der Programmierung.Software-Klassen.
2. Softwarelebenszyklus
dafür sorgen
3. Phasen der Erstellung von Programmen
PROGRAMMDOKUMENTATION
Jede Designphasemündet in die Ausarbeitung
relevante Dokumente, so
ein wichtiges Gestaltungselement
Softwareanwendungen ist
Erstellung der Softwaredokumentation.
PROGRAMMDOKUMENTATION
Programmspezifikation (programSpezifikation) - eine genaue Beschreibung davon
zu erzielendes Ergebnis
mit dem Programm. Diese Beschreibung
muss genau angeben was
ein Programm erstellen, ohne anzugeben, wie es ist
Sollte es tun.
PROGRAMMDOKUMENTATION
Für Programme, die ihre Arbeit mit einem Ergebnis beenden, normalerweise kompiliertE/A-Spezifikationen, die beschreiben
gewünschte Zuordnung des Eingabesatzes
Mengen in eine Menge von Ausgangsgrößen.
Für zyklische Programme (in denen Nr
den Endpunkt angeben), entwickeln
Spezifikationen, wo der Fokus liegt
konzentriert sich auf einzelne Funktionen,
zyklisch vom Programm implementiert
Operationen.
PROGRAMMDOKUMENTATION
Die primäre Spezifikation beschreibt:Objekte, die an der Aufgabe beteiligt sind (was das Programm tut
und was macht die Person, die mit diesem Programm arbeitet);
Prozesse und Aktivitäten (Projektverfahren und -aktivitäten
Mensch, Algorithmen zur Lösung von Problemen in einer Maschine,
Reihenfolge der Informationsverarbeitung, die Größe des Betriebs
für das Funktionieren des Programms erforderlicher Speicher);
Eingabe- und Ausgabedaten sowie deren Organisation
(zum Beispiel ein Dialogskript mit Masken,
Organisation von Dateien, die die Längen von Datensatzfeldern angeben und
maximale Informationsmenge in Dateien);
Anweisungen zur Verwendung des zukünftigen Programms.
PROGRAMMDOKUMENTATION
Unterscheiden Sie zwischen externer SoftwareDokumentation, die im Einklang steht
Kunde und Zwischenhändler
interne Projektdokumentation.
Beim Kompilieren eines Programms
Dokumentation wird zuerst entwickelt
externe Spezifikationen und dann -
intern.
PROGRAMMDOKUMENTATION
Externe Spezifikationen umfassenEingabe- und Ausgabespezifikationen
Daten, ihre Organisation, Reaktionen auf
Ausnahmen, Definition,
Was macht eine Person (durch welche Algorithmen
es funktioniert und woher es Informationen bekommt) und
diese Maschine.
PROGRAMMDOKUMENTATION
Interne Spezifikationen umfassenBeschreibung interner Programmdaten
(Variablen, insbesondere strukturierte) und
Beschreibungen der Algorithmen des gesamten Programms und seiner
Teile.
Interne Spezifikationen werden einheitlich angegeben
mit einer Beschreibung der Softwarearchitektur
komplexe und interne Struktur
Erstellen separater Software
Komponente.
Hausaufgaben
Erstellen Sie eine Liste der Arten von Dokumenten fürGewährleistung des Software-Lebenszyklus.
Inklusionsprinzip, das das vorsieht
Anforderungen an die Erstellung, den Betrieb und die Entwicklung
Software ist bestimmt von der Seite komplexer,
das System, das es enthält;
das Prinzip der systemischen Einheit, das heißt
dass in allen Phasen der Erstellung, des Betriebs und
Softwareentwicklung wird deren Integrität sichergestellt
Verbindungen zwischen Subsystemen und
Funktionsweise des Steuerungssubsystems;
Entwicklungsprinzip, das Software vorsieht
Möglichkeit zu erweitern und zu verbessern
Komponenten und Verbindungen zwischen ihnen;
SYSTEMWEITE GRUNDSÄTZE ZUR ERSTELLUNG VON PROGRAMMEN
das Prinzip der Komplexitätist, dass die Software bietet
Konnektivität der Informationsverarbeitung
einzelne Elemente und für das gesamte Volumen
Daten im Allgemeinen in allen Phasen der Verarbeitung;
das Prinzip der Informationseinheit, das heißt
in allen Subsystemen, Hilfsmittel und
Softwarekomponenten verwenden gemeinsam
Begriffe, Symbole, Konventionen und
Präsentationsmethoden;
SYSTEMWEITE GRUNDSÄTZE ZUR ERSTELLUNG VON PROGRAMMEN
Das Prinzip der Kompatibilität ist dasSprache, Symbole, Codes und Softwaretools
Bereitstellung vereinbart, bereitstellen
gemeinsames Funktionieren aller
Subsysteme und behalten eine offene Struktur bei
Systeme als Ganzes;
das Prinzip der Invarianz definiert
Invarianz von Softwaresubsystemen und -komponenten
zu den verarbeiteten Informationen, d. h. sie sind universell oder typisch.
Programmiertechnologien sind
bewährte Strategien für die Erstellung
Programme, die in Form von Methoden präsentiert werden
mit Informationsmitteln, Beschreibungen
Entwurfsverfahren und Entwurfsoperationen.
Es gibt eine Technologie der Struktur
Programmierung, Technik
Programme entwerfen mit rational
Datenstruktur, objektorientierte Programmiertechnik,
visuelle Programmiertechnologie.
TECHNOLOGIEN UND PROGRAMMIERPARADIGMEN
Programmierparadigmen (Konzepte,Glaubenssysteme) sind unterschiedlich
Ansätze zum Schreiben von Programmen.
Es gibt vier Hauptparadigmen
die die meisten der heutigen beschreiben
Programmiermethoden: Imperativ,
anwendungsorientiert, regelbasiert
und objektorientiert.
TECHNOLOGIEN UND PROGRAMMIERPARADIGMEN
zwingendes ParadigmaDieses Modell ergibt sich aus den Eigenschaften der Hardware
ein Standardcomputer, der Anweisungen ausführt
(Befehle) nacheinander.
Die Hauptart der dabei verwendeten Abstraktion
Paradigma, sind Algorithmen. Basierend darauf entwickelt
viele bedienerorientierte Sprachen
Programmierung.
Ein Programm in einer solchen Sprache besteht aus der Sequenz
Operatoren, deren Ausführung jeweils zur Folge hat
Ändern des Werts in einer oder mehreren Speicherzellen. BEI
Im Allgemeinen lautet die Syntax einer solchen Sprache:
Bediener_1:
Bediener_2:
...
TECHNOLOGIEN UND PROGRAMMIERPARADIGMEN
Applikatives ParadigmaDieses Paradigma basiert auf der Überlegung
die Funktion, die das Programm ausführt.
Die Frage ist: Welche Funktion wird benötigt?
gelten für den Ausgangszustand der Maschine (durch
Auswählen eines anfänglichen Satzes von Variablen und
sie auf eine bestimmte Weise kombinieren) zu
das gewünschte Ergebnis erhalten?
Sprachen, die diese Ansicht betonen
Berechnungen werden als applikativ oder bezeichnet
funktionell. Die Syntax einer Sprache wie
Regel sieht so aus:
Funktion_n (... Funktion_2 (Funktion_1 (Daten))...)
TECHNOLOGIEN UND PROGRAMMIERPARADIGMEN
Regelbasiertes ParadigmaSprachen, die auf diesem Paradigma basieren, überprüfen
das Vorhandensein der erforderlichen Zulassungsbedingung, und im Falle dessen
Erkennungen führen die entsprechende Aktion aus.
Das Ausführen eines Programms in einer ähnlichen Sprache ist wie
Ausführung eines in einer imperativen Sprache geschriebenen Programms.
Die Anweisungen werden jedoch nicht in der Reihenfolge ausgeführt, in der sie sind
denen sie im Programm definiert sind. Reihenfolge der Ausführung
zulässige Bedingungen definieren. Die Syntax solcher Sprachen
folgendermaßen:
zulässig Bedingung_1 -> Aktion_1 zulässig
Bedingung_2 -> Aktion__2
Bedingung_n zulassen -> Aktion _n
Manchmal werden Regeln geschrieben als „if action
zulässige Bedingung", wenn die Aktion ausgeführt werden soll
links geschrieben.
TECHNOLOGIEN UND PROGRAMMIERPARADIGMEN
Objektorientiertes ParadigmaDieses Modell erstellt komplexe Datenobjekte.
Für Operationen an ihnen, einige
begrenzte Auswahl an Methoden. Erstellt
Objekte können einfachere Eigenschaften erben
Objekte.
Aufgrund dieser Fähigkeit haben objektorientierte Programme einen hohen Stellenwert
die Wirksamkeit der Programme
in imperativen Sprachen geschrieben. Wahrscheinlichkeit
Entwicklung verschiedener Klassen, die verwenden
begrenzter Satz von Datenobjekten,
bietet Flexibilität und Zuverlässigkeit, die
Merkmal einer Anwendungssprache.
Sendung (Zusammenstellung)
Es ist eine Methode zum Übersetzen von Programmen, die in geschrieben wurden
Hochsprachen, zu Äquivalenten
verwendete Maschinensprachenprogramme
Computer.
Danach wird der Interpreter eingebaut
Mikroprozessorhardware,
führt das übersetzte direkt aus
Maschinencode-Programm. Der Vorteil dabei
Methode - sehr schnelle Programmausführung
nach Abschluss des Übersetzungsprozesses.
ÜBERTRAGUNG UND ÜBERSETZUNG VON PROGRAMMEN
Ein Übersetzer ist ein Sprachprozessor, derakzeptiert Programme auf irgendeiner Quelle
Sprache als Input und als Output
in ihrer Funktionalität gleichwertig produziert
Programme, sondern bereits auf einem anderen, sog
Objektsprache (die auch sein kann
beliebige Ebene).
Ein Assembler ist ein Übersetzer, dessen Quelle
Sprache ist eine symbolische Darstellung
Maschinencode (Assembler) und Objektsprache
ist eine Art Maschinensprache
jeder echte Computer.
ÜBERTRAGUNG UND ÜBERSETZUNG VON PROGRAMMEN
Ein Compiler ist ein Übersetzer, für den die Quelleist eine Hochsprache und ihre Objektsprache
nah an der Maschinensprache eines echten Computers. Das
entweder Assemblersprache oder eine Variante
Maschinensprache.
Der Linker (Linker) ist ein Übersetzer,
deren Quellsprache aus Programmen in besteht
Maschinensprache in verschiebbarer Form und Tabellen
Daten, die die Punkte angeben, an denen
verschiebbarer Code muss geändert werden,
ausführbar zu werden. Die Objektsprache besteht aus
bereit, Maschinenbefehle auszuführen. Aufgabe
Linker soll eine einzelne ausführbare Datei erstellen
Programm, das vereinbart verwendet
Adressen wie in der Tabelle angegeben.
ÜBERTRAGUNG UND ÜBERSETZUNG VON PROGRAMMEN
Der Präprozessor (Makroprozessor) istÜbersetzer, dessen Ausgangssprache
ist eine erweiterte Form von
Hochsprache (wie Java bzw
C++) und die Objektsprache - der Standard
Version dieser Sprache. Objektprogramm,
vom Präprozessor erstellt, bereit für
Übersetzung und Ausführung des Üblichen
Prozessoren des ursprünglichen Standards
Sprache
ÜBERTRAGUNG UND ÜBERSETZUNG VON PROGRAMMEN
Interpretation (Softwaresimulation)Dies ist die Methode, wenn Sie das Programm verwenden
(Dolmetscher) hingerichtet am
Hardware-Computer, erstellt
Virtueller Computer in Maschinensprache
hohes Level. Der Interpreter entschlüsselt und
führt jede Anweisung im Programm aus
Hochsprache in der jeweiligen
Sequenzen und erzeugen eine Ausgabe
daraus resultierenden Daten definiert
Programm.
ÜBERTRAGUNG UND ÜBERSETZUNG VON PROGRAMMEN
Gemischte ImplementierungssystemeZuerst wird das Programm aus seinem Original übersetzt
Formulare in eine Form, die für die Ausführung bequemer ist.
Dies geschieht normalerweise durch das Erstellen mehrerer
unabhängige Teile des Programms, genannt
Module.
Während der Ladephase werden diese unabhängigen Teile kombiniert
mit einer Reihe von Laufzeitprogrammen,
Implementierung von Software-simuliert
(interpretierte) Operationen. Es führt zu
Erstellen einer ausführbaren Form eines Programms, Anweisungen
die mittels ihrer entschlüsselt und ausgeführt werden
Deutung.
UMGEBUNGEN UND IMPLEMENTIERUNGEN VON PROGRAMMIERSPRACHEN
Die Programmierumgebung ist ein SetWerkzeuge, die in der Entwicklung verwendet werden
Software.
Dieser Satz besteht normalerweise aus einer Datei
Systeme, Texteditor, Editor
Links und Compiler. Außerdem hat er
kann eine große Zahl umfassen
Instrumentalkomplexe mit
einheitliche Benutzeroberfläche
Übung
Nenne und beschreibe die verschiedenenProgrammierumgebungen.
Bericht zur pädagogischen Praxis PM.01 „Entwicklung von Softwaremodulen für Computersysteme“. Staatliche Haushaltsfachbildungseinrichtung der Republik Krim "Feodosia Polytechnic College". 2015.
Das Softwaretool „Actions on matrices“ wurde konzipiert und implementiert; GUI in der C#-Umgebung von Microsoft Visual Studio Ultimate 2013. Das Softwareprodukt ermöglicht das Studium der Struktur und Syntax neuer Programmiersprachen.
Schlüsselwörter: Software, technische Spezifikation, funktionaler Test, Evaluierungstest, struktureller Test, Entwicklungsumgebung, Debugging, Algorithmus, Schnittstelle
- EINLEITUNG
- SCHLUSSFOLGERUNGEN
- LISTE DER LINKS
- BLINDDARM
EINLEITUNG
Jedes Softwareprodukt besteht aus Modulen. Das Modul kann separat entwickelt werden und somit das Softwaretool erweitern und seine Funktionalität verbessern.
Das Ziel der Praxis ist:
Vertiefung der erworbenen theoretischen Kenntnisse in den Disziplinen Angewandte Programmierung, Systemprogrammierung, Theorie der Algorithmen, Grundlagen der Programmierung und Algorithmische Sprachen";
Sammlung, Analyse und Synthese von Materialien zur Erstellung eines Praxisberichts.
Die Aufgaben der pädagogischen Praxis werden durch die individuelle Aufgabe bestimmt:
Analyse der Aufgabe;
Methodenauswahl und Entwicklung grundlegender Lösungsalgorithmen;
Wahl der Technologie und Programmierumgebung;
Erstellen des Anwendungsframeworks und Entwerfen der Benutzeroberfläche;
Entwicklung des Softwareproduktcodes auf der Grundlage der fertigen Spezifikation;
Wahl der Teststrategie und Testentwicklung;
Verwenden der von der Benutzeroberfläche bereitgestellten Debugging-Tools;
Durchführung von Tests eines Softwaremoduls gemäß einem bestimmten Szenario;
Erstellung der Softwaredokumentation.
Basierend auf den Ergebnissen der Praxis wurde ein Bericht erstellt. Der Bericht wird gemäß GOST 7.32-2001 erstellt. Der Praxisbericht besteht aus fünf Abschnitten.
Der erste Abschnitt beschreibt die Entwicklung eines Algorithmus für die Aufgabenstellung und dessen Umsetzung mittels Computer Aided Design.
Im zweiten Abschnitt wird die Wahl der Programmierumgebungstechnologie begründet, die gestaltete Benutzeroberfläche beschrieben und der Code des Softwareprodukts entwickelt.
Der dritte Abschnitt beschreibt den Einsatz von Werkzeugen während der Debugging-Phase eines Programmoduls.
Der vierte Abschnitt beschreibt das Testen eines Softwaremoduls, charakterisiert funktionales, strukturelles und bewertendes Testen.
Der fünfte Abschnitt widmet sich der Vorbereitung der Dokumentation für das Softwaretool.
Testen von Matrix-Software-Tools
1. ENTWICKLUNG EINES ALGORITHMUS FÜR DAS SET-PROBLEM UND SEINE UMSETZUNG DURCH AUTOMATISIERTE ENTWURFSWERKZEUGE
1.1 Analyse der Aufgabe
Es ist notwendig, ein Programm zu schreiben, das Operationen an Matrizen ausführt: Multiplikation, Addition, Subtraktion, Transposition. Das Programm muss die manuell eingegebene Matrix in das Formular lösen. Zur Bequemlichkeit des Benutzers sollte das Programm eine intuitive Schnittstelle haben.
1.2 Methodenauswahl und Entwicklung grundlegender Lösungsalgorithmen
Das Programm verwendet den folgenden Arbeitsalgorithmus: Das Programm hat Formulare, in die Matrixelemente eingegeben werden, die Elemente werden vom Typ String in Integer übertragen. Dann müssen Sie die entsprechende Aktionstaste drücken. Der Matrixlösungsalgorithmus wird ausgeführt und das Ergebnis im DataGridView-Element angezeigt.
Zum Erstellen von Flussdiagrammen wurde Microsoft Office Visio 2013 verwendet, mit dessen Hilfe Sie verschiedene Diagramme und Diagramme erstellen können, einschließlich Flussdiagramme.
Abbildung 1.1 – Blockdiagramm zum Lesen und Schreiben von Daten aus einem Datensatz in ein Array
Abbildung 1.2 – Überprüfung der Verfügbarkeit für Eingaben
Abbildung 1.3 – Blockdiagramm zum Eingeben von Daten in ein Textfeld und Vergleichen mit einem vorhandenen Array
Abbildung 1.4 – Aufruf der Vizov-Methode mit Parametern
2. ENTWICKLUNG DES SOFTWAREPRODUKTCODES AUF BASIS DER FERTIGEN SPEZIFIKATION AUF MODULEBENE
Der Matrixrechner ist implementiert in der Programmiersprache C# in der Programmierumgebung Microsoft Visual Studio Ultimate 2013. Die Wahl der Sprache C# beruht auf der Tatsache, dass es sich um eine moderne und beliebte objektorientierte Programmiersprache handelt, und dem Microsoft Visual Studio Ultimate 2013-Umgebung ist ein leistungsstarkes Tool, mit dem Sie schnell ein Programm mit grafischer Fensteroberfläche erstellen können.
Das Fensterlayout ist in Abbildung 2.1 dargestellt
Abbildung 2.1 - Fensteroberfläche der zukünftigen Anwendung
Das Formular enthält 3 DataGridView-Elemente, in denen Matrizen platziert werden. Auch 4 Schaltfläche zum Ausführen von Aktionen auf Matrizen.
3. VERWENDUNG VON TOOLS IN DER PHASE DES DEBUGINGS DES SOFTWAREMODULS
Verwenden Sie beim Debuggen eines Softwareprodukts den Menübefehl Debuggen (Abb. 3.1). Es gibt eine Reihe von Befehlen im Debug-Menü, deren Zweck unten dargestellt wird.
Abbildung 3.1 - Debug-Menüfenster
Windows – Öffnet das Breakpoints-Fenster im Framework, das Ihnen Zugriff auf alle Breakpoints in dieser Lösung gibt. Zeigt das Ausgabefenster im Framework an.
Das Ausgabefenster ist ein laufendes Protokoll der vielen Meldungen, die von Framework, Compiler und Debugger erzeugt werden. Daher gelten diese Informationen nicht nur für die Debugging-Sitzung, sondern öffnen auch das Interpretationsfenster in der integrierten Umgebung, mit dem Sie Befehle ausführen können: Debugging starten - startet die Anwendung im Debugging-Modus;
An Prozess anhängen - Ermöglicht das Anhängen des Debuggers an einen laufenden Prozess (ausführbare Datei). Wenn beispielsweise eine Anwendung ohne Debugging ausgeführt wird, können Sie sich an diesen laufenden Prozess anhängen und mit dem Debuggen beginnen.
Ausnahmen – öffnet das Dialogfeld Ausnahmen, in dem Sie auswählen können, wie der Debugger für jede Ausnahmebedingung gestoppt werden soll;
Step in - startet die Anwendung im Debug-Modus. Bei den meisten Projekten bedeutet die Auswahl des Step-In-Befehls, dass der Debugger in der ersten ausführbaren Zeile der Anwendung aufgerufen wird. Sie können also die Anwendung von der ersten Zeile aus eingeben;
Herumgehen – Wenn Sie sich nicht in einer Debug-Sitzung befinden, führt der Schrittbefehl „Walk around“ die Anwendung einfach aus, genau wie die Schaltfläche „Ausführen“.
Haltepunkt – Aktiviert oder deaktiviert einen Haltepunkt in der aktuellen (aktiven) Zeile des Texteditorcodes. diese Option ist ausgegraut, wenn das Framework kein aktives Codefenster hat;
Haltepunkt erstellen – aktiviert das Dialogfeld Haltepunkt erstellen, in dem Sie den Namen der Funktion angeben können, für die Sie einen Haltepunkt erstellen möchten;
Alle Haltepunkte entfernen – entfernt alle Haltepunkte aus der aktuellen Lösung;
Alle Datenhinweise löschen - deaktiviert (ohne zu löschen) alle Haltepunkte der aktuellen Lösung;
Optionen und Einstellungen – Unterbrechung der Ausführung, wenn Ausnahmen eine Anwendungsdomänengrenze oder eine Grenze zwischen verwaltetem und nativem Code überschreiten.
4. TESTEN DER SOFTWAREEINHEIT GEMÄSS EINEM BESTIMMTEN SZENARIO
Evaluierungstests, auch als "Tests des gesamten Systems" bezeichnet, deren Zweck darin besteht, das Programm anhand der grundlegenden Anforderungen zu testen. Diese Testphase ist besonders wichtig für Softwareprodukte. Enthält die folgenden Typen:
Usability-Testing - konsequente Überprüfung der Übereinstimmung des Softwareprodukts und seiner Dokumentation mit den Hauptbestimmungen der Leistungsbeschreibung;
Testen auf Grenzvolumen - Überprüfen der Leistung des Programms auf möglichst große Datenmengen, z. B. Textmengen, Tabellen, eine große Anzahl von Dateien usw.;
Testen auf Grenzlasten - Überprüfen der Programmausführung auf die Möglichkeit, eine große Menge empfangener Daten in kurzer Zeit zu verarbeiten;
Usability-Testing - Analyse psychologischer Faktoren, die bei der Arbeit mit Software auftreten; Mit diesem Test können Sie feststellen, ob die Benutzeroberfläche bequem ist, ob die Farb- oder Tonbegleitung störend ist usw.;
Sicherheitstests – Überprüfung des Schutzes, beispielsweise gegen unbefugten Zugriff auf Informationen;
Leistungstest – Bestimmung der Bandbreite für eine gegebene Konfiguration und Last;
Testen der Speicheranforderungen - Bestimmen des tatsächlichen Bedarfs an RAM und externem Speicher;
Testen der Hardwarekonfiguration – Überprüfung der Funktionalität der Software auf unterschiedlicher Hardware;
Kompatibilitätstests - Überprüfung der Kontinuität von Versionen: In Fällen, in denen die nächste Version des Systems Datenformate ändert, muss sie spezielle Konvektoren bereitstellen, die die Möglichkeit bieten, mit Dateien zu arbeiten, die von der vorherigen Version des Systems erstellt wurden;
Installationskomfortprüfung - Überprüfung der Installationsfreundlichkeit;
Zuverlässigkeitsprüfung - Zuverlässigkeitsprüfung mit mathematischen Modellen;
Wiederherstellungstest – Überprüfung der Wiederherstellung von Software, beispielsweise eines Systems einschließlich einer Datenbank, nach Hardware- und Programmausfällen;
Betriebsfähigkeitstest - Überprüfung der in der Software enthaltenen Einrichtungen;
Dokumentationstest - eine gründliche Überprüfung der Dokumentation, zum Beispiel, wenn die Dokumentation Beispiele enthält, dann müssen alle ausprobiert werden;
Testverfahren - Überprüfung der im System angenommenen manuellen Prozesse.
Ziel all dieser Kontrollen ist es natürlich, Unstimmigkeiten mit der Leistungsbeschreibung zu finden. Es wird davon ausgegangen, dass das Softwareprodukt erst nach Abschluss aller Arten von Tests dem Benutzer oder der Implementierung präsentiert werden kann. In der Praxis werden jedoch normalerweise nicht alle Arten von Evaluationstests durchgeführt, da sie sehr teuer und zeitaufwändig sind. In der Regel werden für jede Art von Software diejenigen Testarten durchgeführt, die für sie am wichtigsten sind. Datenbanken werden also zwangsläufig mit maximalem Volumen und Echtzeitsysteme mit maximaler Belastung getestet.
5. DOKUMENTATION FÜR DIE SOFTWARE
Das erstellte Softwareprodukt ist darauf ausgelegt, arithmetische Operationen an Matrizen durchzuführen.
Um das Programm auszuführen, müssen Sie die Anwendung ausführen.
Um Matrizen zu erstellen, müssen Sie die Abmessungen der Matrix eingeben und auf die Schaltfläche "Erstellen" klicken. Geben Sie dann die Daten in die Matrix ein und wählen Sie die gewünschte Aktion aus.
Abbildung 5.1 – Laufende Anwendung
Das Programm hat Benutzerfreundliches Bedienfeld und bietet die Möglichkeit, Matrizen beliebiger Dimensionen einfach zu lösen.
Während der Trainingspraxis wurde eine individuelle Aufgabe erledigt:
Die Analyse des Themenbereichs wurde durchgeführt;
Der gewählte und entwickelte Lösungsalgorithmus wird begründet;
Die Technologie wird definiert und die Programmierumgebung ausgewählt;
Das Anwendungsframework wurde erstellt und die Benutzeroberfläche entworfen;
Programmmodulcode entwickelt;
Die beim Testen verwendeten Debugging-Tools werden beschrieben;
Das Softwaremodul wurde nach einem bestimmten Szenario getestet;
Menüpunkt mit einer kurzen Beschreibung der Arbeit mit dem Programm hinzugefügt.
Die gesetzten Ziele wurden erreicht.
LISTE DER LINKS
1 Cyber Forum [Elektronische Ressource]: http://CyberForum.ru
2 Microsoft Developer [Offizielle Microsoft-Dokumentation zu C#] ttps://msdn.microsoft.com
3 http://programming-edu.ru/ Hilfeblog für C#-Anfänger
BLINDDARM
Programmcode
mit System.Linq;
mit System.Text;
mit System.Windows.Forms;
Namespace-Matrix
int[,] a=neues int;
//Werte übergeben
public void Set(int i, int j, int znach)
a = znach;
//Zusatz
öffentlicher statischer MyMatrix-Operator +(MyMatrix-Matrix1, MyMatrix-Matrix2)
für (int i = 0; i< 3; i++)
für (int j = 0; j< 3; j++)
NeueMatrix.a = Matrix1.a + Matrix2.a;
geben Sie NewMatrix zurück;
// Ausgabematrix
öffentliche Zeichenfolge Visual (int i, int j)
gib a.ToString();
// alles auf einmal ausgeben.Xd
öffentliches DataGridView FullVisual(DataGridView dt)
für (int i = 0; i< 3; i++)
für (int j = 0; j< 3; j++)
dt.Zeilen[j].Zellen[i].Wert = a;
//Subtraktion
öffentlicher statischer MyMatrix-Operator -(MyMatrix-Matrix1, MyMatrix-Matrix2)
MeineMatrix NeueMatrix = neue MeineMatrix();
für (int i = 0; i< 3; i++)
für (int j = 0; j< 3; j++)
NeueMatrix.a = matrix1.a - matrix2.a;
geben Sie NewMatrix zurück;
//transponieren
öffentlich MyMatrix Trans()
MeineMatrix NeueMatrix = neue MeineMatrix();
für (int i = 0; i< 3; i++)
für (int j = 0; j< 3; j++)
NeueMatrix.a = a;
geben Sie NewMatrix zurück;
//Multiplikation
öffentlicher statischer MyMatrix-Operator *(MyMatrix-Matrix1, MyMatrix-Matrix2)
MeineMatrix NeueMatrix = neue MeineMatrix();
für (int i = 0; i< 3; i++)
für (int k = 0; k< 3; k++)
für (int j = 0; j< 3; j++)
//a += Matrix1.a * Matrix2.a;
NeueMatrix.a+= matrix1.a * matrix2.a;
//NeueMatrix.a = a;
geben Sie NewMatrix zurück;
//Füllung
öffentliche Lückenfüllung (DataGridView-Raster)
für (int i = 0; i< 3; i++)
für (int j = 0; j< 3; j++)
a = Convert.ToInt32(grid.Rows[j].Cells[i].Value);
mit System.Collections.Generic;
mit System.ComponentModel;
mit System.Data;
mit System.Drawing;
mit System.Linq;
mit System.Text;
mit System.Windows.Forms;
Namespace-Matrix
öffentliche Teilklasse Form1: Form
Initialisieren der Komponente();
private void Form1_Load(object sender, EventArgs e)
für (int i = 0; i< 3; i++)
dataGridView1.Rows.Add();
dataGridView2.Rows.Add();
dataGridView3.Rows.Add();
//dataGridView1.Rows[i].Cells.Value = i.ToString();
private void button1_Click(object sender, EventArgs e)
MyMatrix-Matrix3;
Matrix3 = (Matrix1 + Matrix2);
private void button2_Click(object sender, EventArgs e)
MeineMatrix Matrix1 = neue MeineMatrix();
MeineMatrix Matrix2 = neue MeineMatrix();
MyMatrix-Matrix3;
matrix1.Fill (dataGridView1);
matrix2.Fill (dataGridView2);
Matrix3 = (Matrix1 - Matrix2);
matrix3.FullVisual (dataGridView3);
private void button3_Click(object sender, EventArgs e)
MeineMatrix Matrix1 = neue MeineMatrix();
MyMatrix-Matrix3;
matrix1.Fill (dataGridView1);
Matrix3 = Matrix1.Trans ();
matrix3.FullVisual (dataGridView3);
private void button4_Click(object sender, EventArgs e)
MeineMatrix Matrix1 = neue MeineMatrix();
MeineMatrix Matrix2 = neue MeineMatrix();
MyMatrix-Matrix3;
matrix1.Fill (dataGridView1);
matrix2.Fill (dataGridView2);
Matrix3 = (Matrix1 * Matrix2);
matrix3.FullVisual (dataGridView3);
Ähnliche Dokumente
Entwicklung eines Algorithmus für die Aufgabenstellung und Umsetzung mittels Computer Aided Design. Erstellen eines Softwareprodukts auf Basis einer fertigen Spezifikation auf Modulebene, Testen mit Werkzeugen.
Test, hinzugefügt am 01.05.2015
Vergleichende Analyse von Testtechnologien. Entwicklung des Programmmoduls „Intellektuelles Bildungssystem für ein breites Studienangebot“. Begründung der Notwendigkeit und Bedeutung der Debugging-Phase bei der Entwicklung dieser Software.
Dissertation, hinzugefügt am 17.06.2011
Strukturdiagramm eines Softwaremoduls. Entwicklung des Schemas des Softwaremoduls und der Benutzeroberfläche. Implementierung des Programmmoduls: Programmcode; Beschreibung der verwendeten Operatoren und Funktionen. Ansicht des Benutzerformulars mit der gefüllten Matrix.
Seminararbeit, hinzugefügt am 01.09.2010
Strukturdiagramm eines Softwaremoduls. Finden der Summe der Elemente über der Hauptdiagonalen. Implementierung des Programmmoduls: Programmcode; Beschreibung der verwendeten Operatoren und Funktionen. Merkmale des Testens von Softwaremodulen.
Seminararbeit, hinzugefügt am 01.09.2010
Ausstattung des Unternehmens mit Systemsoftware zur Organisation des Produktionsprozesses. Design, Implementierung und Betrieb von System- und Anwendungssoftware. Testen und Debuggen von Softwareprodukten.
Praxisbericht, hinzugefügt am 29.12.2014
Merkmale der Delphi-Programmierumgebung bei der Entwicklung einer Anwendung mit einer visuellen Oberfläche. Debugging von Programmmodulen mit spezialisierten Softwaretools. Softwaretest. Optimierung des Programmcodes.
Seminararbeit, hinzugefügt am 21.12.2016
Merkmale der Delphi-Programmierumgebung bei der Entwicklung einer Anwendung mit einer visuellen Oberfläche. Entwicklung einer Softwarespezifikation und darauf aufbauend eines Softwareproduktcodes. Debuggen des Programms durch "Tracing", dessen Testen und Optimieren.
Seminararbeit, hinzugefügt am 07.12.2016
Gestaltung der Programmmodule: Quellensammlung; Beschreibung von Eingabe- und Ausgabedaten; Wahl der Software. Beschreibung der Datentypen und Implementierung der Programmschnittstelle. Testen von Softwaremodulen und Entwicklung von Hilfesystemen.
Hausarbeit, hinzugefügt am 18.08.2014
Entwicklung eines Softwaremoduls, das die Erstellung einer Kartei von Abonnenten unter Verwendung der Klassenvorlage "Binärbaum" ermöglicht, die Informationen über Telefone und ihre Besitzer enthält. Wahl der Technologie, Sprache und Programmierumgebung. Auswahl einer Programmteststrategie.
Seminararbeit, hinzugefügt am 11.12.2010
Funktional-modularer Aufbau der Intercom Controller Software. Elektronische Schaltung des elektronischen Schlosses, Mikrofon- und Lautsprechermodul. Wahl der kombinierten Stromversorgung. Entwicklung eines Softwaremoduls. Intercom-Steuerungsprogramm.
Der Übergang vom Informellen zum Formellen ist im Wesentlichen informell.
Vortrag 8
ENTWICKLUNG VON SOFTWAREMODULEN
Das Verfahren zur Entwicklung eines Softwaremoduls. Strukturprogrammierung und Schritt-für-Schritt-Detaillierung. Das Konzept des Pseudocodes. Softwaremodulsteuerung.
8.1. Das Verfahren zur Entwicklung eines Softwaremoduls.
Bei der Entwicklung eines Softwaremoduls empfiehlt es sich, folgende Reihenfolge einzuhalten:
Studium und Überprüfung von Modulspezifikationen, Wahl der Programmiersprache;
Wahl des Algorithmus und der Datenstruktur;
Programmierung (Codierung) des Moduls;
den Text des Moduls aufpolieren;
Überprüfung des Moduls
Modulzusammenstellung.
Der erste Schritt bei der Entwicklung eines Softwaremoduls ist weitgehend eine durchgängige Kontrolle der Struktur des Programms von unten: Der Entwickler muss sich durch Studium der Spezifikation des Moduls vergewissern, dass sie für ihn verständlich und zur Entwicklung ausreichend ist dieses Modul. Am Ende dieses Schritts wird eine Programmiersprache ausgewählt: Obwohl die Programmiersprache bereits für die gesamte PS vordefiniert sein kann, kann in einigen Fällen (wenn das Programmiersystem dies zulässt) eine andere Sprache ausgewählt werden, die für die Implementierung besser geeignet ist dieses Moduls (z. B. Assemblersprache).
Im zweiten Schritt der Entwicklung eines Softwaremoduls gilt es herauszufinden, ob bereits Algorithmen zur Lösung des gestellten Problems bekannt sind oder diesem nahe kommen. Und wenn es einen geeigneten Algorithmus gibt, dann ist es ratsam, ihn zu verwenden. Die Auswahl geeigneter Datenstrukturen, die verwendet werden, wenn das Modul seine Funktionen ausführt, bestimmt weitgehend die Logik und die Qualitätsindikatoren des zu entwickelnden Moduls und sollte daher als sehr wichtige Entscheidung betrachtet werden.
Im dritten Schritt wird der Text des Moduls in der gewählten Programmiersprache erstellt. Die Fülle aller möglichen Details, die bei der Umsetzung der in der Modulspezifikation spezifizierten Funktionen berücksichtigt werden müssen, kann leicht zu einem sehr unübersichtlichen Text mit vielen Fehlern und Ungenauigkeiten führen. Das Auffinden von Fehlern in einem solchen Modul und das Vornehmen der erforderlichen Änderungen daran kann eine sehr zeitaufwändige Aufgabe sein. Daher ist es sehr wichtig, eine technologisch begründete und praktisch erprobte Programmierdisziplin zu verwenden, um den Text des Moduls aufzubauen. Erstmals machte Dijkstra darauf aufmerksam und formulierte und begründete die Grundprinzipien der strukturierten Programmierung. Viele der in der Praxis weit verbreiteten Programmierdisziplinen basieren auf diesen Prinzipien. Am gebräuchlichsten ist die Drill-Down-Disziplin, die in den Abschnitten 8.2 und 8.3 ausführlich besprochen wird.
Der nächste Schritt in der Entwicklung des Moduls besteht darin, den Text des Moduls gemäß der PS-Qualitätsspezifikation in die endgültige Form zu bringen. Bei der Programmierung eines Moduls konzentriert sich der Entwickler auf die korrekte Implementierung der Funktionen des Moduls, lässt Kommentare unvollendet und lässt einige Verstöße gegen die Anforderungen an den Stil des Programms zu. Wenn er den Text des Moduls aufpoliert, sollte er die Kommentare im Text bearbeiten und möglicherweise darin einfügen zusätzliche Kommentare um die erforderlichen Qualitätsgrundelemente bereitzustellen. Zum gleichen Zweck wird der Programmtext stilistisch aufbereitet.
Der Modulverifizierungsschritt ist eine manuelle Prüfung der internen Logik des Moduls vor seiner Fehlersuche (unter Verwendung seiner Ausführung auf einem Computer), implementiert das allgemeine Prinzip, das für die diskutierte Programmiertechnologie formuliert wurde, über die Notwendigkeit, die in jeder Phase des Moduls getroffenen Entscheidungen zu kontrollieren PS-Entwicklung (siehe Vorlesung 3). Modulvalidierungsmethoden werden in Abschnitt 8.4 besprochen.
Der letzte Schritt der Entwicklung eines Moduls schließlich besteht darin, die Modulvalidierung (mithilfe des Compilers) abzuschließen und mit dem Debugging-Prozess des Moduls fortzufahren.
8.2. Strukturelle Programmierung.
Beim Programmieren eines Moduls sollte berücksichtigt werden, dass das Programm nicht nur für einen Computer, sondern auch für eine Person verständlich sein muss: sowohl der Modulentwickler als auch die Personen, die das Modul überprüfen, und die Tester, die Tests zum Debuggen des Moduls vorbereiten , und die PS-Betreuer, die die erforderlichen Änderungen am Modul vornehmen, werden gezwungen, die Logik des Moduls wiederholt zu parsen. In modernen Programmiersprachen gibt es genügend Werkzeuge, um diese Logik beliebig durcheinanderzubringen, wodurch das Modul für einen Menschen schwer verständlich und in der Folge unzuverlässig oder schwer wartbar wird. Daher muss darauf geachtet werden, geeignete Sprachwerkzeuge auszuwählen und einer bestimmten Programmierdisziplin zu folgen. In diesem Zusammenhang schlug Dijkstra vor, ein Programm als Zusammensetzung mehrerer Arten von Kontrollstrukturen (Strukturen) aufzubauen, was die Verständlichkeit der Logik des Programms erheblich verbessern kann. Eine Programmierung, die nur solche Konstrukte verwendet, wird aufgerufen strukturell.
Reis. 8.1. Grundlegende Kontrollstrukturen der strukturierten Programmierung.
Die Hauptkonstrukte der strukturierten Programmierung sind: Folgen, Verzweigen und Wiederholen (siehe Abbildung 8.1). Bestandteile dieser Konstruktionen sind verallgemeinerte Operatoren (Verarbeitungsknoten) S, S1, S2 und eine Bedingung (Prädikat) P. Als verallgemeinerter Operator kann entweder ein einfacher Operator der verwendeten Programmiersprache (Zuweisung, Eingabe, Ausgabe, Prozedur Aufrufe) oder ein Programmfragment, das eine Zusammensetzung der wichtigsten Kontrollstrukturen der strukturierten Programmierung ist. Wesentlich ist, dass jede dieser Strukturen steuerungstechnisch nur einen Eingang und einen Ausgang hat. Somit hat auch der verallgemeinerte Operator nur einen Eingang und einen Ausgang.
Es ist auch sehr wichtig, dass diese Konstruktionen bereits mathematische Objekte sind (was im Wesentlichen den Grund für den Erfolg der strukturierten Programmierung erklärt). Es ist bewiesen, dass es für jedes unstrukturierte Programm möglich ist, ein funktional äquivalentes (dh das gleiche Problem lösendes) strukturiertes Programm zu konstruieren. Bei strukturierten Programmen können einige Eigenschaften mathematisch bewiesen werden, was es ermöglicht, einige Fehler im Programm zu entdecken. Diesem Thema wird ein eigener Vortrag gewidmet sein.
Die strukturierte Programmierung wird manchmal auch als „Programmierung ohne GEHE ZU“ bezeichnet. Hier geht es jedoch nicht um die GO TO-Anweisung, sondern um deren willkürliche Verwendung. Sehr oft wird bei der Implementierung der strukturellen Programmierung in einigen Programmiersprachen (z. B. in FORTRAN) der Übergangsoperator (GO TO) verwendet, um strukturelle Konstruktionen zu implementieren, was nicht gegen die Prinzipien der strukturellen Programmierung verstößt. Es sind die "nicht-strukturellen" Sprunganweisungen, die das Programm verwirren, insbesondere der Sprung zu einer Anweisung, die sich im Modultext über (vor) der ausgeführten Sprunganweisung befindet. Der Versuch, die Sprunganweisung in manchen einfachen Fällen zu vermeiden, kann jedoch zu schwerfällig strukturierten Programmen führen, was deren Übersichtlichkeit nicht verbessert und die Gefahr zusätzlicher Fehler im Text des Moduls birgt. Daher kann empfohlen werden, die Verwendung der Sprunganweisung wo immer möglich zu vermeiden, jedoch nicht auf Kosten der Programmübersichtlichkeit.
Nützliche Fälle der Verwendung des Übergangsoperators umfassen das Verlassen einer Schleife oder Prozedur unter einer speziellen Bedingung, die die Arbeit dieser Schleife oder dieser Prozedur "früh" beendet, d. h. die Arbeit einer strukturellen Einheit (generalisierter Operator) beendet und dadurch nur lokal verletzt Strukturiertheit des Programms. Große Schwierigkeiten (und Verkomplizierung der Struktur) bereitet die strukturelle Umsetzung der Reaktion auf außergewöhnliche (oftmals fehlerhafte) Situationen, da dies nicht nur ein frühzeitiges Ausscheiden aus der strukturellen Einheit, sondern auch die notwendige Verarbeitung (Exklusion) dieser Situation erfordert (z. B. Ausgabe einer geeigneten Diagnoseinformation). Der Ausnahmebehandler kann sich auf jeder Ebene der Programmstruktur befinden, und es kann von verschiedenen niedrigeren Ebenen aus auf ihn zugegriffen werden. Aus technologischer Sicht durchaus akzeptabel ist die folgende „nicht-strukturelle“ Umsetzung der Reaktion auf Ausnahmesituationen. Ausnahmebehandler werden an das Ende der einen oder anderen Struktureinheit gestellt, und jeder solcher Behandler ist so programmiert, dass er nach Beendigung seiner Arbeit die Struktureinheit verlässt, an deren Ende er angeordnet ist. Ein solcher Handler wird vom Sprungoperator aus der gegebenen Struktureinheit (einschließlich jeder verschachtelten Struktureinheit) aufgerufen.
8.3. Schritt-für-Schritt-Detaillierung und das Konzept des Pseudocodes.
Die strukturierte Programmierung gibt Empfehlungen, wie der Text eines Moduls aussehen sollte. Es stellt sich die Frage, wie ein Programmierer vorgehen sollte, um einen solchen Text zu konstruieren. Häufig beginnt die Programmierung eines Moduls mit dem Aufbau seines Blockdiagramms, das allgemein die Logik seiner Arbeitsweise beschreibt. Die moderne Programmiertechnik empfiehlt dies jedoch nicht ohne geeignete Computerunterstützung. Obwohl Flussdiagramme eine sehr visuelle Darstellung der Logik eines Moduls bieten, tritt bei ihrer manuellen Codierung in einer Programmiersprache eine sehr spezifische Fehlerquelle auf: das Abbilden von im Wesentlichen zweidimensionalen Strukturen wie Flussdiagrammen auf linearen Text, der ein Modul darstellt, birgt die Gefahr, die Logik des Moduls zu verzerren, zumal es psychologisch recht schwierig ist, bei der Wiederholung eine hohe Aufmerksamkeit aufrechtzuerhalten. Eine Ausnahme kann der Fall sein, wenn ein grafischer Editor zum Erstellen von Flussdiagrammen verwendet wird und sie so formalisiert werden, dass daraus automatisch Text in einer Programmiersprache generiert wird (wie dies beispielsweise in der R-Technologie geschieht).
Als Hauptmethode zum Aufbau des Modultextes empfiehlt sich moderne Programmiertechnik Schritt für Schritt im Detail. Der Kern dieser Methode besteht darin, den Prozess der Entwicklung des Modultextes in mehrere Schritte zu unterteilen. Am ersten
Der Schritt beschreibt das allgemeine Schema der Moduloperation in einer sichtbaren linearen Textform (d. h. unter Verwendung sehr großer Konzepte), und diese Beschreibung ist nicht vollständig formalisiert und konzentriert sich auf die menschliche Wahrnehmung. Bei jedem nächsten Schritt wird eines der Konzepte verfeinert und detailliert (wir nennen es spezifizierten) in jeder Beschreibung, die in einem der vorherigen Schritte entwickelt wurde. Als Ergebnis dieses Schritts wird eine Beschreibung des ausgewählten Konzepts, das verfeinert wird, entweder in Bezug auf die Basisprogrammiersprache (d. h. das zur Darstellung ausgewählte Modul) oder in der gleichen Form wie im ersten Schritt unter Verwendung neuer zu verfeinernder Konzepte erstellt . Dieser Prozess endet, wenn alle angegebenen Konzepte vorhanden sind Klarstellungen(d. h. schließlich in der zugrunde liegenden Programmiersprache ausgedrückt werden). Der letzte Schritt besteht darin, den Text des Moduls in der Basisprogrammiersprache zu erhalten, indem alle Vorkommen der verfeinerten Konzepte durch ihre spezifizierten Beschreibungen ersetzt werden und alle Vorkommen strukturierter Programmierkonstrukte unter Verwendung dieser Programmiersprache ausgedrückt werden.
Die schrittweise Verfeinerung ist mit der Verwendung einer teilweise formalisierten Sprache zur Darstellung der angegebenen Beschreibungen verbunden, die aufgerufen wird Pseudocode. Diese Sprache ermöglicht die Verwendung aller strukturierten Programmierkonstrukte, die formalisiert sind, zusammen mit informellen Fragmenten natürlicher Sprache, um generische Anweisungen und Bedingungen darzustellen. Entsprechende Fragmente in der Basisprogrammiersprache können auch als verallgemeinerte Operatoren und Bedingungen angegeben werden.
· der Beginn des Moduls in der Basissprache, d. h. der erste Satz oder die Überschrift (Spezifikation) dieses Moduls;
Abschnitt (Satz) von Beschreibungen in der Basissprache und anstelle von Beschreibungen von Verfahren und Funktionen - nur deren äußeres Design;
· informelle Bezeichnung der Folge von Modulrumpf-Operatoren als ein verallgemeinerter Operator (su), sowie informelle Bezeichnung des Körpers jeder Prozedur- oder Funktionsbeschreibung als ein verallgemeinerter Operator;
· der letzte Satz (Ende) des Moduls in der Ausgangssprache.
Ähnlich stellt sich die äußere Gestaltung der Beschreibung einer Prozedur oder Funktion dar. In Anlehnung an Dijkstra wäre es jedoch besser, den Abschnitt der Beschreibungen hier auch mit einer informellen Notation darzustellen und ihn als separate Beschreibung zu detaillieren.
Eine informelle Bezeichnung eines verallgemeinerten Operators im Pseudocode erfolgt in natürlicher Sprache durch einen willkürlichen Satz, der seinen Inhalt allgemein verrät. Die einzige formale Voraussetzung für die Gestaltung einer solchen Bezeichnung ist folgende: Dieser Satz muss vollständig eine oder mehrere grafische (gedruckte) Zeilen einnehmen und mit einem Punkt (oder einem anderen speziell dafür vorgesehenen Zeichen) enden.
Reis. 8.2. Grundkonstruktionen der strukturierten Programmierung in Pseudocode.
Für jeden informellen verallgemeinerten Operator muss eine separate Beschreibung erstellt werden, die die Logik seiner Arbeit (mit genauer Angabe seines Inhalts) unter Verwendung der Zusammensetzung der Hauptstrukturen der strukturierten Programmierung und anderer verallgemeinerter Operatoren zum Ausdruck bringt. Die Überschrift einer solchen Beschreibung sollte die informelle Bezeichnung des zu verfeinernden verallgemeinerten Operators sein. Die Grundkonstrukte der strukturierten Programmierung lassen sich wie folgt darstellen (siehe Abbildung 8.2). Hier kann die Bedingung entweder explizit in der zugrunde liegenden Programmiersprache als boolescher Ausdruck angegeben oder informell in natürlicher Sprache durch ein Fragment dargestellt werden, das die Bedeutung dieser Bedingung umreißt. Im letzteren Fall sollte eine separate Beschreibung dieses Zustands erstellt werden, in der die Bezeichnung dieses Zustands (Fragment in natürlicher Sprache) als Titel angegeben ist.
Verlassen der Wiederholung (Schleife): Exit-Prozedur (Funktion): |
