Ανάπτυξη μονάδας λογισμικού. Δομικός προγραμματισμός. Pm.01. Ανάπτυξη μονάδων λογισμικού για το πρόγραμμα λογισμικού συστήματος υπολογιστών Ανάπτυξη προγραμμάτων λογισμικού λογισμικού

Σχολιασμός του προγράμματος εργασίας της επαγγελματικής ενότητας

Όνομα επαγγελματικής ενότητας

1. Πεδίο εφαρμογής του προγράμματος

Το πρόγραμμα εργασίας της επαγγελματικής ενότητας είναι μέρος του προγράμματος ειδικού μεσαίου επιπέδου σύμφωνα με το GEF SPO 09.02.07 πληροφοριακά συστήματα και τον προγραμματισμό που περιλαμβάνονται στην ολοκληρωμένη ομάδα ειδικοτήτων 09.00.00 Πληροφορική και Υπολογιστών

και σχετικές επαγγελματικές ικανότητες (PC):

Το πρόγραμμα εργασίας της επαγγελματικής ενότητας μπορεί να χρησιμοποιηθεί στην προετοιμασία ειδικών στο μάθημα "Ανάπτυξη λογισμικών λογισμικού λογισμικού για συστήματα υπολογιστών" με βάση τη βασική γενική εκπαίδευση. Δεν απαιτείται εργασιακή εμπειρία.

Το πρόγραμμα εργασίας καταρτίζεται για πλήρη απασχόληση, αλληλογραφία, αλληλογραφία με στοιχεία απομακρυσμένων εκπαιδευτικών τεχνολογιών για εκπαιδευτικές μορφές.

2. Στόχοι και στόχοι της ενότητας - Απαιτήσεις για τα αποτελέσματα της μονάδας

Ως αποτέλεσμα της ανάπτυξης του υποχρεωτικού μέρους της ενότητας, ο φοιτητής πρέπει να έχει πρακτική εμπειρία:

Να αναπτύσσουν έναν αλγόριθμο για την εργασία και τις εφαρμογές με τα μέσα αυτοματοποιημένης σχεδίασης ·

Ανάπτυξη του κώδικα λογισμικού που βασίζεται στην τελική προδιαγραφή στο επίπεδο της μονάδας.

Χρήση εργαλείων στο στάδιο εντοπισμού εντοπισμού εντοπισμού του προγράμματος.

Δοκιμάζοντας μια ενότητα λογισμικού για ένα συγκεκριμένο σενάριο.

Ως αποτέλεσμα της ανάπτυξης του υποχρεωτικού μέρους της ενότητας, ο φοιτητής πρέπει να είναι σε θέση να:

Για να αναπτύξετε έναν κωδικό μονάδας λογισμικού στις σύγχρονες γλώσσες προγραμματισμού.

Δημιουργήστε ένα πρόγραμμα σε έναν ανεπτυγμένο αλγόριθμο ως ξεχωριστή μονάδα.

Εκτελέστε την εντοπισμό σφαλμάτων και τη δοκιμή του προγράμματος στο επίπεδο της μονάδας ·

Συμπληρώστε την τεκμηρίωση για το λογισμικό.

Χρησιμοποιήστε εργαλεία εργαλείων για την αυτοματοποίηση της τεκμηρίωσης.

Ως αποτέλεσμα της ανάπτυξης του υποχρεωτικού μέρους της ενότητας, ο φοιτητής πρέπει να γνωρίζει:

Τα κύρια στάδια της ανάπτυξης λογισμικού ·

Βασικές αρχές της τεχνολογίας προγραμματισμού των δομικών και αντικειμενικών προσανατολισμένων ·

Βασικές αρχές των προϊόντων λογισμικού εντοπισμού σφαλμάτων και δοκιμών.

Μέθοδοι και μέσα ανάπτυξης τεχνικής τεκμηρίωσης.

6. Ανάπτυξη κώδικα λογισμικού χρησιμοποιώντας διαρθρωτικό προγραμματισμό

7. Ανάπτυξη κωδικού προγράμματος χρησιμοποιώντας λεπτομέρειες βήμα προς βήμα

8. Ανάπτυξη του κώδικα λογισμικού χρησιμοποιώντας τον αρθρωτό προγραμματισμό

9. Αρχικοποίηση των όπλων

10. Εφαρμογή δυναμικών δομών με συστοιχίες

11. Ανάπτυξη κώδικα λογισμικού χρησιμοποιώντας δομές

12. Ανάπτυξη κώδικα λογισμικού χρησιμοποιώντας λειτουργίες

13. Ανάπτυξη κώδικα λογισμικού χρησιμοποιώντας σήμανση

14. Εφαρμογή του I / O

15. Ρεύματα αρχείων

16. Δεδομένα συμβολοσειράς

17. Ανάπτυξη στατικής κλάσης

18. Ανάπτυξη δυναμικών τάξεων

19. Ανάπτυξη αφηρημένων τάξεων

20. Ανάπτυξη προτύπων τάξεων

21. Εκτέλεση εντοπισμού εντοπισμού κώδικα προγράμματος

22. Εκτέλεση ταξινόμησης με φούσκα

23. Εκτέλεση ταξινόμησης με εισαγωγή με τη μέθοδο

24. Εκτελώντας μια ταξινόμηση από τον Hoare

25. Διεξάγετε τη δοκιμή του κώδικα προγράμματος με την αρχή του "λευκού κουτιού"

26. Διεξάγετε μια δοκιμή κώδικα προγράμματος με μια αρχή "γκρίζου κιβωτίου"

27. Διεξάγετε μια δοκιμή κώδικα προγράμματος από την αρχή "Black Box"

28. Εφαρμογή της βελτιστοποίησης του κώδικα προγράμματος

29. Εφαρμογή της βελτιστοποίησης μηχανών αναζήτησης του κώδικα προγράμματος

30. Κατάρτιση τεχνικής τεκμηρίωσης

31. Αντιμετώπιση αλγορίθμων για εργασία με γραφικά

32. Αρχικοποίηση του συστήματος γραφικών

33. Εργασία με παράθυρα και συντεταγμένες

34. Εργασία με γραφικά πρωταρχικά

35. Δημιουργία εικόνας κινούμενης εικόνας

36. Σχεδίαση τεκμηρίωσης χρήστη

Υπουργείο Παιδείας και Επιστήμης

Ντόνετσκ Λαϊκή Δημοκρατία

Κρατικός επαγγελματίας

ΕΚΠΑΙΔΕΥΤΙΚΟ ΙΔΡΥΜΑ

"Βιομηχανικό και Οικονομικό Κολλέγιο Ντόνετσκ"

Πρόγραμμα εργασίας

Εκπαιδευτική πρακτική UE.01

Επαγγελματική Μονάδα PM.01 Ανάπτυξη μονάδων λογισμικού για συστήματα υπολογιστών

Ειδικότητα 09.02.03 "Προγραμματισμός σε συστήματα υπολογιστών"

Μεταγλωττιστές:

Volkov Vladimir Alexandrovich, δάσκαλος των κλάδων υπολογιστών της κατηγορίας προσόντων "Ειδικός της ανώτερης κατηγορίας", GPO "Ντόνετσκ Βιομηχανικό και Οικονομικό Κολλέγιο"

Το πρόγραμμα συμφωνείται: Pavel Andreevich VKV, Διευθυντής "Smart It Service"


1. Πρακτική πρακτική διαβατήριο
2. Αποτελέσματα πρακτικής
3. Δομή και περιεχόμενο της πρακτικής
4. Όροι οργάνωσης και διεξαγωγή πρακτικής
5. Έλεγχος και αξιολόγηση των αποτελεσμάτων της πρακτικής

1 Διαβατήριο του προγράμματος πρακτικής κατάρτισης UE. 01.

1.1 Τόπος εκπαιδευτικής πρακτικής ue.01

Το πρόγραμμα πρακτικής κατάρτισης της UD.01 Επαγγελματική Ενότητα PM.01 "Ανάπτυξη μονάδων λογισμικού λογισμικού για συστήματα υπολογιστών" Specialty 09.02.03 "Προγραμματισμός σε συστήματα υπολογιστών » Μεγέθυνση της ομάδας 09.00.00 "Τεχνική πληροφορικής και υπολογιστών", όσον αφορά την καταβολή του κύριου τύπου επαγγελματικής δραστηριότητας (VDD):

Ανάπτυξη μονάδων λογισμικού για συστήματα υπολογιστών και σχετικές επαγγελματικές ικανότητες (PC):

	Εκτελέστε την ανάπτυξη των προδιαγραφών των μεμονωμένων εξαρτημάτων.
	Εφαρμογή της ανάπτυξης ενός κωδικού προϊόντος λογισμικού που βασίζεται σε έτοιμες προδιαγραφές στο επίπεδο της μονάδας.
	Μονάδες προγράμματος μηχανής χρησιμοποιώντας εξειδικευμένο λογισμικό.
	Δοκιμαστικές μονάδες λογισμικού.
	Βελτιστοποιήστε τον κωδικό λογισμικού της μονάδας.
	Ανάπτυξη εξαρτημάτων έργου και τεχνικής τεκμηρίωσης χρησιμοποιώντας προδιαγραφές γραφικής γλώσσας.

Το πρόγραμμα Εκπαιδευτικής πρακτικής του UE.01 Επαγγελματική Ενότητα PM.01 "Ανάπτυξη μονάδων λογισμικού λογισμικού για συστήματα υπολογιστών" μπορεί να χρησιμοποιηθεί στην πρόσθετη επαγγελματική εκπαίδευση και επαγγελματική κατάρτιση των εργαζομένων για ειδικότητες 09.02.03 Προγραμματισμός σε συστήματα υπολογιστών παρουσία α Μεσαίο (πλήρες) Γενική Εκπαίδευση. Δεν απαιτείται εργασιακή εμπειρία.

1.2 Στόχοι και εργασίεςΕκπαιδευτική πρακτική UE.01

Προκειμένου να καταρρεύσει τον καθορισμένο τύπο επαγγελματικής δραστηριότητας και τις σχετικές επαγγελματικές αρμοδιότητες, ο φοιτητής κατά τη διάρκεια της πρακτικής κατάρτισης του UD.01 πρέπει:

Έχετε μια πρακτική εμπειρία:

ανάπτυξη ενός αλγορίθμου για την εργασία και την εφαρμογή του μέσω αυτοματοποιημένου σχεδίου ·

Ανάπτυξη του κώδικα λογισμικού που βασίζεται στην τελική προδιαγραφή στο επίπεδο της μονάδας.

Χρήση εργαλείων στο στάδιο εντοπισμού εντοπισμού εντοπισμού του προγράμματος.

δοκιμάζοντας τη μονάδα προγράμματος σε ένα συγκεκριμένο σενάριο.

ικανός για:

Για να αναπτύξετε έναν κωδικό μονάδας λογισμικού στις σύγχρονες γλώσσες προγραμματισμού.

Δημιουργήστε ένα πρόγραμμα σε έναν ανεπτυγμένο αλγόριθμο ως ξεχωριστή μονάδα.

εκτελέστε την εντοπισμό σφαλμάτων και τη δοκιμή του προγράμματος στο επίπεδο της μονάδας ·

Συμπληρώστε την τεκμηρίωση για το λογισμικό.

χρησιμοποιήστε όργανα εργαλείων για την αυτοματοποίηση της τεκμηρίωσης ·

ξέρω:

Τα κύρια στάδια της ανάπτυξης λογισμικού ·

Βασικές αρχές της τεχνολογίας προγραμματισμού των δομικών και αντικειμενικών προσανατολισμένων ·

Βασικές αρχές των προϊόντων λογισμικού εντοπισμού σφαλμάτων και δοκιμών.

Μέθοδοι και μέσα ανάπτυξης τεχνικής τεκμηρίωσης.

1.3 Αριθμός εβδομάδων(παρακολουθώ) Για την ανάπτυξη του προγράμματοςΕκπαιδευτική πρακτική UE.01

Μόνο 1,5 εβδομάδες, 54 ώρες.

2 αποτελέσματα πρακτικής

Το αποτέλεσμα της πρακτικής κατάρτισης της UD.01 Επαγγελματική Ενότητα PM.01 "Ανάπτυξη μονάδων λογισμικού λογισμικού για συστήματα υπολογιστών" είναι η ανάπτυξη γενικών ικανοτήτων (OK):

	Όνομα του αποτελέσματος της πρακτικής
	-
OK 2. Οργανώστε τη δική σας δραστηριότητα, επιλέξτε τυπικές μεθόδους και μεθόδους για την εκτέλεση επαγγελματικών καθηκόντων, αξιολογήστε την αποτελεσματικότητά τους και την ποιότητά τους.
OK 3. Να λαμβάνει αποφάσεις σε τυποποιημένες και μη τυποποιημένες καταστάσεις και να είναι υπεύθυνος για αυτούς.
OK 4. Για να αναζητήσετε και να χρησιμοποιήσετε τις πληροφορίες που απαιτούνται για την αποτελεσματική εκπλήρωση επαγγελματικών καθηκόντων, επαγγελματικής και προσωπικής ανάπτυξης.
OK 5. Χρησιμοποιήστε τεχνολογίες πληροφοριών και επικοινωνιών σε επαγγελματικές δραστηριότητες.
OK 6. Εργαστείτε στην ομάδα και την ομαδική εργασία, επικοινωνούν αποτελεσματικά με τους συναδέλφους, τη διαχείριση, τους καταναλωτές.
OK 7. Να αναλάβει την ευθύνη για το έργο των μελών της ομάδας (υφισταμένους), για το αποτέλεσμα των καθηκόντων.	-
	Προσόντα
OK 9. Εστίαση σε συνθήκες συχνής αλλαγής της τεχνολογίας στις επαγγελματικές δραστηριότητες.

Επαγγελματικές ικανότητες (PC):

Είδος επαγγελματικής δραστηριότητας		Όνομα των αποτελεσμάτων της πρακτικής
Να γνωρίζετε τον κύριο τύπο επαγγελματικής δραστηριότητας		Χρήση πόρων τοπικών και παγκόσμιων δικτύων υπολογιστών. Διαχείριση αρχείων δεδομένων σε τοπικές, αφαιρούμενες συσκευές αποθήκευσης, καθώς και στους δίσκους του τοπικού δικτύου υπολογιστών και στο Διαδίκτυο. Έγγραφα εκτύπωσης, αντιγραφής και αντιγραφής στον εκτυπωτή και άλλος εξοπλισμός γραφείου. Τρέχον έλεγχο με τη μορφή μιας έκθεσης για κάθε πρακτική εργασία. Ενότητα προκριματικών εξετάσεων.
		Γραμματισμός και ακρίβεια της εργασίας σε εφαρμογές: Συντάκτες κειμένου και γραφιστών, βάσεις δεδομένων, συντάκτης παρουσίασης. Ταχύτητα αναζήτησης για πληροφορίες στο περιεχόμενο των βάσεων δεδομένων.
		Ρυθμίσεις email ακρίβειας και αλφαβητισμού, λογισμικό διακομιστή και πελάτη: ταχύτητα αναζήτησης πληροφοριών χρησιμοποιώντας τεχνολογίες και υπηρεσίες διαδικτύου · Ακρίβεια και γραμματισμός της εισόδου και μετάδοσης πληροφοριών με τη χρήση τεχνολογιών και υπηρεσιών διαδικτύου.
		Γραφείο της χρήσης μεθόδων και μέσων προστασίας των πληροφοριών από μη εξουσιοδοτημένη πρόσβαση. την ορθότητα και την ακρίβεια της εφεδρικής και της ανάκτησης δεδομένων.
		Γραμματεία και ακρίβεια της εργασίας με τα συστήματα αρχείων, διάφορες μορφές αρχείων, προγράμματα διαχείρισης αρχείων.
		Διατήρηση αναφοράς και τεχνικής τεκμηρίωσης.

3 Δομή και περιεχόμενο του προγράμματοςΕκπαιδευτική πρακτική UE.01

3.1 Θεματικό σχέδιο

Οι κωδικοί σχημάτισαν ικανότητες

Όνομα επαγγελματικής ενότητας

Όγκος χρόνου, Που μετακινείται για την πρακτική

(σε εβδομάδες, ρολόι)

Ημερομηνίες μεταφοράς

PC 1.1 - PC 1.6

PM.01 "Ανάπτυξη μονάδων λογισμικού για συστήματα υπολογιστών"

1,5 εβδομάδες,

54 ώρες

3.2 Πρακτική περιεχομένου

Δραστηριότητες	Τύποι θέσεων εργασίας		Όνομα εκπαιδευτικών κλάδων, Διεπιστημονικά μαθήματα που δείχνουν, Παροχή επιδόσεων	Αριθμός ωρών (εβδομάδες)
"Να γνωρίζετε τον κύριο τύπο επαγγελματικής δραστηριότητας »	Θέμα 1. Εισαγωγή Εργασίες Επίλυση αλγορίθμων. Δομή ενός γραμμικού αλγορίθμου. Τη δομή του κυκλικού αλγορίθμου. Αλγόριθμος υπορουτίνας (λειτουργίες).	Γνώση για τα βασικά στοιχεία της δημιουργίας ειδικών αντικειμένων
	Θέμα2 . Τετάρτη Skratch (μηδέν).	Οι γνώσεις σχετικά με τα βασικά της διαδικασίας αυτοματοποίησης της διαδικασίας σχηματίζονται από τη γνώση σχετικά με τα βασικά στοιχεία των επιδράσεων κινούμενων σχεδίων στα αντικείμενα. Χρησιμοποιώντας υπερσυνδέσμους και κουμπιά. Ορίζοντας την επίδειξη. Παρουσιάσεις που είναι αποθηκευμένες σε διαφορετικές μορφές.	MDC.01.01 "Προγραμματισμός συστήματος"
	Θέμα 3 . Δημιουργώντας ένα εκπαιδευτικό πρόγραμμα (μάθημα από το θέμα).	Γνώση των βασικών ανάλυσης γνώσεων χρησιμοποιώντας λειτουργίες επεξεργαστή	MDK.01.02 "Προγραμματισμός εφαρμογών"
	Θέμα 4. Ανάπτυξη προγράμματος τυχερών παιχνιδιών.	Γνώση των βασικών υπολογιστικών υπολογίζονται τα τελικά χαρακτηριστικά.	MDC.01.01 "Προγραμματισμός συστήματος"
	Θέμα 5. Γλώσσα γραφικού προγραμματισμού LABVIEW.	Γνώση βασισμένη στα βασικά στοιχεία του δοκιμαστικού επεξεργαστή.	MDK.01.02 "Προγραμματισμός εφαρμογών"
	Θέμα 6. Δημιουργία μιας εφαρμογής χρησιμοποιώντας το LabView.	Δημιουργήθηκε γνώση των βασικών στοιχείων του διαλόγου χρηστών με το σύστημα	MDK.01.02 "Προγραμματισμός εφαρμογών"
	Θέμα 7 Πολλαπλή χρήση του θραύσματος του προγράμματος.	Γνώση των χειριστών και των λειτουργιών του συστήματος σχηματίζονται.	MDK.01.02 "Προγραμματισμός εφαρμογών"
	Θέμα 8 Εργαστήριο στο LabView. Προστασία εργασίας όταν εργάζεστε με υπολογιστή στο χώρο εργασίας του χρήστη.	Γνώση των υπολογισμών των στοιχειωδών λειτουργιών σχηματίζονται. Διαμόρφωσε τη γνώση της προστασίας της εργασίας.	MDK.01.02 "Προγραμματισμός εφαρμογών". OP.18 "Προστασία εργασίας"
	Θέμα 9 Συμπεράσματα. Κατάρτιση μιας έκθεσης για την πρακτική.	Η δυνατότητα ανάλυσης των σχηματισμένων τεχνολογιών υπολογιστών, οι λύσεις εργασιών σχημάτισαν δεξιότητες.	MDC.01.01 "Προγραμματισμός συστήματος" MDK.01.02 "Προγραμματισμός εφαρμογών" MDK.04.01 "Λογισμικό γραφείου"

4 Όροι Οργανισμού και Συμπεριφοράς

Εκμάθηση πρακτικής UE. 01.

4.1 Απαιτήσεις για τεκμηρίωση, αναγκαία για την πρακτική:

Πρόγραμμα εργασίας της εκπαιδευτικής πρακτικής UE.01 Επαγγελματική ενότητα PM.01. "Ανάπτυξη μονάδων λογισμικού για τα συστήματα ηλεκτρονικών υπολογιστών" είναι μέρος του προγράμματος κατάρτισης των ειδικών μεσαίου επιπέδου από το κρατικό επαγγελματικό εκπαιδευτικό ίδρυμα "Ντόνετσκ Βιομηχανικό και Οικονομικό Κολλέγιο" σύμφωνα με το κρατικό εκπαιδευτικό πρότυπο της δευτεροβάθμιας επαγγελματικής εκπαίδευσης στην ειδικότητα 09.02.03 " Προγραμματισμός στα συστήματα υπολογιστών ", με βάση το πρόγραμμα σπουδών στην ειδικότητα, το πρόγραμμα εργασίας για τους κλάδους MDC.01.01" Προγραμματισμός συστήματος ", MDK01.02" Εφαρμοσμένος προγραμματισμός ", μεθοδολογικές συστάσεις για την εκπαιδευτική και μεθοδική υποστήριξη των φοιτητών, την ανάπτυξη εκπαιδευτικών προγραμμάτων Δευτερεύουσα επαγγελματική εκπαίδευση.

4.2 Απαιτήσεις για την εκπαιδευτική πρακτική:

Ο κατάλογος των εγκεκριμένων εργασιών ανά τύπο εργασίας, κατευθυντήριες γραμμές για τους σπουδαστές για την εκπλήρωση της εργασίας, συστάσεις για την εφαρμογή των εκθέσεων υποβολής εκθέσεων.

4.3 Υλικές απαιτήσεις:

Η οργάνωση της βιομηχανικής πρακτικής απαιτεί τη διαθεσιμότητα ντουλαπιών και εργαστηρίου.

Υπουργικό συμβούλιο και θέσεις εργασίας:

καθίσματα στον αριθμό των φοιτητών (τραπέζι, υπολογιστής, καρέκλα).

χώρο εργασίας του δασκάλου (τραπέζι, υπολογιστής, καρέκλα)?

Υπουργικό συμβούλιο για την αποθήκευση εκπαιδευτικών και οπτικών οφελών και μέσων ενημέρωσης.

Καθήκοντα για μια μεμονωμένη προσέγγιση στη μάθηση, την οργάνωση ανεξάρτητης εργασίας και ασκήσεων, φοιτητή σε έναν υπολογιστή ·

Αναφορά και μεθοδική λογοτεχνία.

ένα σύνολο συστημάτων, εφαρμοσμένων και εκπαιδευτικών προγραμμάτων για υπολογιστές σε οπτικά και ηλεκτρονικά μέσα.

Εφημερίδα των φοιτητών για την ενημέρωση των εργαζομένων.

Ένα σύνολο εκπαιδευτικών και οπτικών βοηθημάτων.

Τεχνικά εργαλεία μάθησης:

πίνακα ελέγχου ·

προσωπικός υπολογιστής με εξουσιοδοτημένο λογισμικό.

εκτυπωτής με λέιζερ;

Εκπαίδευση υπολογιστών.
Σετ διαδραστικού εξοπλισμού (προβολέας, οθόνη, στήλες).
Μέσα πυρόσβεσης (πυροσβεστήρα).

Εξοπλισμός του Υπουργικού Συμβουλίου και των χώρων εργασίας των εργαλείων ανάπτυξης: προσωπικοί υπολογιστές (οθόνη, μπλοκ συστήματος, πληκτρολόγιο, ποντίκι), ένα σύνολο εκπαιδευτικής και μεθοδολογικής τεκμηρίωσης, λογισμικό σύμφωνα με το περιεχόμενο της πειθαρχίας (κέλυφος γλώσσας προγραμματισμού).

Όλοι οι υπολογιστές στην τάξη συνδυάζονται στο τοπικό δίκτυο, έχουν πρόσβαση στην αποθήκευση πληροφοριών δικτύου και έχουν πρόσβαση στο Διαδίκτυο.

Εξοπλισμός επικοινωνίας:

Προσαρμογείς δικτύου.

Καλώδια δικτύου.

wiFi ασύρματο εξοπλισμό.

Εξαρτήματα τοποθέτησης, εξοπλισμός εγκατάστασης.

4.4 Κατάλογος Εκπαιδευτικών Εκδόσεων, Πόροι Διαδικτύου, Πρόσθετη βιβλιογραφία

Κύριες πηγές:

Olifer V.G. Λειτουργικά συστήματα δικτύου: Tutorial για πανεπιστήμια / V.G. Volifer, Ν.Α. Volifer. - 2η έκδοση. - Αγία Πετρούπολη: Πέτρος, 2009.2008. - 668 σελ.:

Ε. Tannbaum. Os. Ανάπτυξη και εφαρμογή. Αγία Πετρούπολη: Πέτρος, 2006. - 568 σ.

Pupkov k.a. Η ανάπτυξη του λειτουργικού συστήματος Unix / K.A. Pupkov, Α. Chernikov, Ν.Μ. Yakushev. - Μόσχα: Ραδιόφωνο και επικοινωνία, 1994. - 112 σ.

L. Beck Εισαγωγή στον προγραμματισμό του συστήματος - M.: MIR, 1988.

Grekul V.I., Denischenko G.N., Korovkina N.L. Σχεδιασμός συστημάτων πληροφοριών / Μόσχα: Binom, 2008. - 304 σελ.

Lipaev, V.V. Μηχανική λογισμικού. Μεθοδολογικά θεμέλια [Κείμενο]: Μελέτες. / V. V. Lipaev; κατάσταση Πανεπιστήμιο - Ανώτατη Σχολή Οικονομικών. - M.: Theis, 2006. - 608 σελ.

LAVRYSHCHEVA Ε. Μ., Petrukhin V. A. Μέθοδοι και μέσα λογισμικού μηχανικής. - φροντιστήριο

Ian sommerville. Λογισμικό μηχανικής, 6η έκδοση: ανά. από τα Αγγλικά -Μ. : Εκδοτικός Οίκος "Williams", 2002.-624 σελ.

Excel 2010: Επαγγελματικός προγραμματισμός στο VBA: Per. από τα Αγγλικά - M.: LLC "I.D. Williams, 2012. - 944 σελ. : Il. - παραλιακή. Χτύπημα. Αγγλικά

Fowler M. Refactoring: Βελτίωση ενός υπάρχοντος κώδικα. Στυλό. Από το English-SPB: σύμβολο-συν, 2003.-432 s.

Πρόσθετες πηγές:

Volkov v.a. Μεθοδικές οδηγίες για την εφαρμογή πρακτικών εργασιών στον προγραμματισμό του συστήματος πειθαρχίας, Ντόνετσκ: Donpek, 2015.

Volkov v.a. Μεθοδικές οδηγίες για την εφαρμογή του έργου του μαθήματος, Ντόνετσκ: Donpek, 2015.

Το διαδίκτυο- πόροι:

Προγραμματισμός συστήματος [ηλεκτρονικός πόρος] / Λειτουργία πρόσβασης: http://www.umk3.utmn.ru.

Πόροι λογισμικού και Internet: http://www.intuit.ru

Λογοτεχνία για την πειθαρχία - http://www.internet-technologies.ru/books/

Ηλεκτρονικό εγχειρίδιο "Εισαγωγή στη Μηχανική Λογισμικού" - http://www.intuit.ru/studies/professional_skill_improvements/1419/info

Ηλεκτρονικό εγχειρίδιο "Τεχνολογία προγραμματισμού" -http: //bourabai.kz/alg/pro.htm

4.5 Απαιτήσεις για χειροκίνητα στελέχη από εκπαιδευτικό ίδρυμα και οργάνωση

Απαιτήσεις για χειροκίνητα στελέχη από το εκπαιδευτικό ίδρυμα:

Μηχανική και Παιδαγωγική Σύνθεση: Πιστοποιημένοι ειδικοί - Καθηγητές διεπιστημονικών μαθημάτων και γενικών επαγγελματικών κλάδων. Η εμπειρία σε οργανισμούς της σχετικής επαγγελματικής σφαίρας είναι υποχρεωτική.

Master of Production Training: Η παρουσία 5-6 προκριματικών απόρριψης με υποχρεωτική πρακτική άσκηση σε εξειδικευμένους οργανισμούς τουλάχιστον 1 φορά σε 3 χρόνια. Η εμπειρία σε οργανισμούς της σχετικής επαγγελματικής σφαίρας είναι υποχρεωτική.

5 Έλεγχος και αξιολόγηση των αποτελεσμάτων

Εκμάθηση πρακτικής UE. 01.

Η μορφή αναφοράς για την εκπαιδευτική πρακτική UE.01 είναι μια έκθεση πρακτικής, διακοσμημένη σύμφωνα με τις απαιτήσεις των μεθοδολογικών συστάσεων.

Αποτελέσματα (αναπτυγμένες επαγγελματικές ικανότητες)	Κύριοι παράγοντες Προετοιμασία αποτελεσμάτων	Έντυπα και μέθοδοι Ελεγχος
PC 1.1. Εκτελέστε την ανάπτυξη των προδιαγραφών των μεμονωμένων εξαρτημάτων	Ανάπτυξη ενός αλγορίθμου για την εργασία και την εφαρμογή των μέσων αυτοματοποιημένου σχεδιασμού	Ειδική παρατήρηση και αξιολόγηση των δραστηριοτήτων των φοιτητών στη διαδικασία καταγωγής του εκπαιδευτικού προγράμματος σε πρακτικές τάξεις, κατά την εκτέλεση εργασιών για την εκπαιδευτική και βιομηχανική πρακτική.
PC 1.2. Εφαρμογή της ανάπτυξης ενός κωδικού προϊόντος λογισμικού που βασίζεται σε έτοιμες προδιαγραφές στο επίπεδο της μονάδας.	Γνωρίστε τις βασικές αρχές της τεχνολογίας προγραμματισμού των δομικών και αντικειμενικών προσανατολισμένων. Εφαρμόστε τον κωδικό μονάδας λογισμικού στις σύγχρονες γλώσσες προγραμματισμού.
PC 1.3. Για να διορθώσετε τις ενότητες προγραμματισμού χρησιμοποιώντας εξειδικευμένο λογισμικό	Δημιουργία εντοπισμού σφαλμάτων και δοκιμής του προγράμματος στο επίπεδο της μονάδας.
PC 1.4. Δοκιμαστικές μονάδες λογισμικού.	Δημιουργήστε ένα πρόγραμμα σύμφωνα με τον ανεπτυγμένο αλγόριθμο ως ξεχωριστή μονάδα.
PC 1.5. Βελτιστοποιήστε τον κωδικό προγράμματος της μονάδας	Ανάπτυξη του κώδικα λογισμικού που βασίζεται στην τελική προδιαγραφή στο επίπεδο της μονάδας.
PC 1.6. Ανάπτυξη των στοιχείων του έργου και της τεχνικής τεκμηρίωσης χρησιμοποιώντας τις προδιαγραφές γραφικής γλώσσας	Γνωρίστε τις μεθόδους και τα μέσα ανάπτυξης τεχνικής τεκμηρίωσης. Εγγραφή τεκμηρίωσης για λογισμικό. Χρησιμοποιήστε εργαλεία εργαλείων για την αυτοματοποίηση της τεκμηρίωσης.

Τα έντυπα και οι μέθοδοι παρακολούθησης και αξιολόγησης των μαθησιακών αποτελεσμάτων θα πρέπει να σας επιτρέπουν να επαληθεύσετε όχι μόνο το σχηματισμό επαγγελματικών ικανοτήτων, αλλά και την ανάπτυξη γενικών ικανοτήτων και τη διασφάλιση των δεξιοτήτων τους.

Αποτελέσματα (Κατακτηθέντα γενικές αρμοδιότητες)	Τους κύριους δείκτες της αξιολόγησης του αποτελέσματος	Έντυπα και μέθοδοι ελέγχου και αξιολόγησης
Εντάξει 1. Κατανοήστε την ουσία και την κοινωνική σημασία του μελλοντικού σας επαγγέλματος, για να δείξετε βιώσιμο ενδιαφέρον.	Εκδήλωση συνεχούς ενδιαφέροντος για το μελλοντικό επάγγελμα. - την εγκυρότητα της χρήσης των ανεπτυγμένων επαγγελματικών ικανοτήτων ·	Εμπειρογνωμοσύνη και αξιολόγηση σε πρακτικές τάξεις κατά την εκτέλεση εργασίας για τη βιομηχανική πρακτική ·
OK 2. Οργανώστε τις δικές σας δραστηριότητες, προσδιορίστε τις μεθόδους και τις μεθόδους για την εκτέλεση επαγγελματικών καθηκόντων, αξιολογήστε την αποτελεσματικότητα και την ποιότητά τους.	Αιτιολόγηση του σκοπού του σκοπού, της επιλογής και της εφαρμογής μεθόδων και μεθόδων για την επίλυση επαγγελματικών καθηκόντων · Τη διεξαγωγή αυτο-ανάλυσης και διόρθωσης των αποτελεσμάτων της δικής τους εργασίας	Αξιολόγηση σε πρακτικές τάξεις κατά την εκτέλεση εργασίας · Παρατήρηση κατά τη διάρκεια της πρακτικής · Ατομική ανάλυση
OK 3. Επίλυση προβλημάτων, αξιολογήστε τους κινδύνους και λαμβάνουν αποφάσεις σε μη τυποποιημένες καταστάσεις.	Την αποτελεσματικότητα της λήψης αποφάσεων των τυποποιημένων και μη τυποποιημένων επαγγελματικών καθηκόντων για ορισμένο χρόνο · Εκτέλεση του σχεδίου βελτιστοποίησης της ποιότητας της εργασίας που εκτελείται	Ερμηνεία των αποτελεσμάτων της παρατήρησης της δραστηριότητας της μελέτης στη διαδικασία εκτέλεσης εργασιών
OK 4. Για να αναζητήσετε, να αναλύσετε και να αξιολογήσετε τις απαραίτητες πληροφορίες για τη ρύθμιση και την επίλυση επαγγελματικών καθηκόντων, επαγγελματικής και προσωπικής ανάπτυξης.	Επιλογή και ανάλυση των απαραίτητων πληροφοριών για μια σαφή και ταχεία απόδοση επαγγελματικών καθηκόντων, επαγγελματικής και προσωπικής ανάπτυξης	Αξιολόγηση εμπειρογνωμόνων κατά τη διάρκεια της εργασίας · Αυτοέλεγχος κατά τη διάρκεια της διαμόρφωσης και της επίλυσης προβλημάτων
OK 5. Χρησιμοποιήστε πληροφορίες και επικοινωνιακές τεχνολογίες για τη βελτίωση των επαγγελματικών δραστηριοτήτων.	Η δυνατότητα χρήσης τεχνολογιών πληροφοριών και επικοινωνιών για την επίλυση επαγγελματικών καθηκόντων	Αξιολόγηση των καθηκόντων
OK 6. Εργασία στην ομάδα και την ομάδα, εξασφαλίζουν τη συνοχή της, επικοινωνούν αποτελεσματικά με τους συναδέλφους, τη διαχείριση, τους καταναλωτές.	Δυνατότητα αλληλεπίδρασης με μια ομάδα, εκπαιδευτικούς, εργαστήριο κατάρτισης παραγωγής
OK 7. Ορίστε στόχους, παρακινήστε τις δραστηριότητες των υφισταμένων, οργανώνουν και ελέγχουν την εργασία τους με την υιοθέτηση ευθύνης για το αποτέλεσμα των καθηκόντων.	- Τη διεξαγωγή αυτο-ανάλυσης και διόρθωσης των αποτελεσμάτων της δικής τους εργασίας και του έργου της ομάδας	Παρατήρηση της πορείας εργασίας στον Όμιλο στη διαδικασία της βιομηχανικής πρακτικής
OK 8. Ανεξάρτητα προσδιορίστε τα καθήκοντα της επαγγελματικής και προσωπικής ανάπτυξης, να συμμετάσχουν στην αυτο-εκπαίδευση, συνειδητά σχέδιο να σχεδιάσει προηγμένη κατάρτιση.	Οργάνωση ανεξάρτητης εργασίας για το σχηματισμό δημιουργικής και επαγγελματικής εικόνας. Οργάνωση της εργασίας για την αυτο-εκπαίδευση και την αύξηση Προσόντα	Παρατήρηση και αξιολόγηση στη διαδικασία βιομηχανικής πρακτικής · Αντανακλαστική ανάλυση (αλγόριθμος δράσης μάθησης) · Πρακτική ημερολόγιο. Ανάλυση του χαρτοφυλακίου φοιτητών
OK 9. Είναι έτοιμη για μεταβαλλόμενη τεχνολογία σε επαγγελματικές δραστηριότητες.	Ανάλυση της καινοτομίας στον τομέα των τεχνολογικών διαδικασιών ανάπτυξης και κατασκευή ραπτομηχανών	Αξιολόγηση λύσεων λήψης αποφάσεων. Επιχειρηματικά και οργανωτικά και εκπαιδευτικά παιχνίδια. Παρατήρηση και αξιολόγηση σε πρακτικές τάξεις, στη διαδικασία της βιομηχανικής πρακτικής

ΕΚΘΕΣΗ ΙΔΕΩΝ

Έλεγχος έργου εργασίας PM.01 "Ανάπτυξη μονάδων λογισμικού για συστήματα υπολογιστών". Κρατικός Προϋπολογισμός Επαγγελματικό Εκπαιδευτικό Ίδρυμα της Δημοκρατίας της Κριμαίας "Φεοδοσία Πολυτεχνική Τεχνική Ακαδημία". 2015 -20 δευτερόλεπτα., Εικονογραφήσεις 7, προσάρτημα 1, βιβλιογραφικές πηγές 3.

Σχεδιασμένο και υλοποιημένο εργαλείο λογισμικού "Ενέργειες σε πίνακες", ανέπτυξε μια γραφική διεπαφή στο μέσοMicrosoft Visual Studio Ultimate 2013 C # Το προϊόν λογισμικού σάς επιτρέπει να μελετήσετε τη δομή και τη σύνταξη νέων γλωσσών προγραμματισμού.

Λογισμικό, Τεχνική εργασία, Λειτουργικές δοκιμές, εκτιμώμενες δοκιμές, δομικές δοκιμές, ανάπτυξη, αποσύνδεση, αλγόριθμος, διεπαφή

Εισαγωγή

1 Ανάπτυξη του αλγορίθμου του έργου και την εφαρμογή των μέσων αυτοματοποιημένου σχεδιασμού

1.1 Ανάλυση της εργασίας

1.2 Επιλογή μεθόδων και ανάπτυξη βασικών λύσεων Αλγορίθμοι

2 Ανάπτυξη του κώδικα λογισμικού που βασίζεται στην τελική προδιαγραφή στο επίπεδο της μονάδας

3. Χρησιμοποιώντας εργαλεία οργάνων στο στάδιο της εντοπισμού σφαλμάτων της μονάδας λογισμικού

4 Διεξάγετε μια ενότητα λογισμικού για ένα συγκεκριμένο σενάριο

5 Εγγραφή τεκμηρίωσης λογισμικού

Κατάλογος συνδέσμων

Παράρτημα Α.

Εισαγωγή

Κάθε προϊόν λογισμικού αποτελείται από μονάδες. Η ενότητα μπορεί να αναπτυχθεί ξεχωριστά και, επομένως, να αναβαθμίσει το λογισμικό, βελτιώνοντας τη λειτουργικότητά του.

Ο σκοπός της εργασίας είναι:

Να στερέχω τις προκύπτουσες θεωρητικές γνώσεις σχετικά με τους κλάδους. Προγραμματισμός εφαρμογών, προγραμματισμός συστήματος, θεωρία αλγορίθμων, βασικά στοιχεία προγραμματισμού και αλγοριθμικών γλωσσών ".
Συλλογή, ανάλυση και γενίκευση υλικών για την προετοιμασία της έκθεσης πρακτικής.

Τα καθήκοντα της εργασίας οφείλονται στην μεμονωμένη εργασία:

Ανάλυση της εργασίας ·
την επιλογή των μεθόδων και την ανάπτυξη βασικών λύσεων αλγόριθμων ·
επιλογή τεχνολογίας και περιβάλλοντος προγραμματισμού ·
Δημιουργία πλαισίου εφαρμογής και σχεδιασμού διεπαφής χρήστη.
Ανάπτυξη κωδικού προϊόντος λογισμικού βάσει της τελικής προδιαγραφής.
Επιλογή στρατηγικών δοκιμών και δοκιμών.
Χρήση εργαλείων σφαλμάτων που υποβάλλονται από τη διεπαφή χρήστη.
διεξαγωγή της δοκιμής της μονάδας λογισμικού σε ένα συγκεκριμένο σενάριο.
Εγγραφή τεκμηρίωσης λογισμικού.

Η εργασία αποτελείται από πέντε τμήματα.

Το πρώτο τμήμα περιγράφει την ανάπτυξη ενός αλγορίθμου για την εργασία και την εφαρμογή των μέσων αυτοματοποιημένου σχεδιασμού.

Στο δεύτερο τμήμα, η επιλογή του περιβάλλοντος προγραμματισμού περιγράφεται από τη σχεδιαστεί διεπαφή χρήστη και έχει αναπτυχθεί ο κωδικός προϊόντος του λογισμικού.

Στο τρίτο τμήμα περιγράφεται η χρήση εργαλείων στη μονάδα στερέωσης.

Στο τέταρτο τμήμα, περιγράφεται ο έλεγχος της μονάδας δοκιμών, χαρακτηριζόμενη λειτουργική, δομική, εκτιμώμενη δοκιμή.

Το πέμπτο τμήμα είναι αφιερωμένο στο σχεδιασμό της τεκμηρίωσης για το λογισμικό.

1 Ανάπτυξη του αλγορίθμου του έργου και την εφαρμογή των μέσων αυτοματοποιημένου σχεδιασμού

1.1 Ανάλυση της εργασίας

Είναι απαραίτητο να γράψετε ένα πρόγραμμα που θα εκτελέσει ενέργειες σε μήτρες: πολλαπλασιασμό, προσθήκη, αφαίρεση, μεταφορές. Το πρόγραμμα πρέπει να λύσει τη μήτρα που εισάγεται με το χέρι στη φόρμα. Για την ευκολία των χρηστών, το πρόγραμμα πρέπει να έχει μια διαισθητική διεπαφή.

1.2 Επιλογή μεθόδων και ανάπτυξη βασικών λύσεων Αλγορίθμοι

Το πρόγραμμα χρησιμοποιεί τον ακόλουθο αλγόριθμο εργασίας: Στο πρόγραμμα υπάρχουν μορφές στις οποίες εισάγονται τα στοιχεία των πινάκων, τα στοιχεία μεταφράζονται απόΤύπος συμβολοσειράς σε ακέραιο . Στη συνέχεια, πρέπει να πατήσετε το αντίστοιχο κουμπί δράσης. Ο αλγόριθμος διαλύματος μήτρας εκτελείται και το αποτέλεσμα εμφανίζεται στο στοιχείο.Datagridview.

Για την κατασκευή ροής, χρησιμοποιήθηκε ένα πρόγραμμαVisio του Microsoft Office. 2013. Με τη βοήθειά του, μπορείτε να αποτελέσετε διάφορα διαγράμματα και συστήματα, συμπεριλαμβανομένων των διαγραμμάτων μπλοκ.

Εικόνα 1.1 - Διάγραμμα μπλοκ ανάγνωσης και γραφής δεδομένων από ένα αρχείο συστοιχίας

Εικόνα 1.2 - Ελέγξτε την προσβασιμότητα για την είσοδο

Εικόνα 1.3 - Διαγράμματα εισόδου μπλοκΠλαίσιο κειμένου. και συγκρίσεις με μια υπάρχουσα συστοιχία

Εικόνα 1.4 - κλήση μεθόδουVizov με παραμέτρους

2 Ανάπτυξη του κώδικα λογισμικού που βασίζεται στην τελική προδιαγραφή στο επίπεδο της μονάδας

Ο υπολογιστής Matrix υλοποιείται στη γλώσσα προγραμματισμού C # στο Microsoft Visual Studio Ultimate 2013 Περιβάλλον προγραμματισμού 2013. Η επιλογή C # οφείλεται στο γεγονός ότι είναι μια σύγχρονη και δημοφιλής γλώσσα προγραμματισμένη αντικειμενοστρεφής, και το Microsoft Visual Studio Ultimate 2013 Το περιβάλλον είναι ένα ισχυρό εργαλείο που σας επιτρέπει να δημιουργήσετε γρήγορα ένα πρόγραμμα με ένα ισχυρό εργαλείο. Γραφική διεπαφή παραθύρου.

Η διάταξη παραθύρου παρουσιάζεται στο Σχήμα 2.1

Εικόνα 2.1 - Μελλοντική διεπαφή παραθύρου παραθύρου

3 στοιχεία βρίσκονται στη φόρμαDatagridview. Οι μήτρες θα τοποθετηθούν σε αυτά. Επίσης 4Κουμπί. Να εκτελέσει δράσεις στις μήτρες.

3. Χρησιμοποιώντας εργαλεία οργάνων στο στάδιο της εντοπισμού σφαλμάτων της μονάδας λογισμικού

Κατά την αποσύνδεση ενός προϊόντος λογισμικού, πρέπει να χρησιμοποιήσετε την εντολή μενού εντοπισμού σφαλμάτων (Εικ. 3.1). Το μενού Debug υπάρχει μια σειρά εντολών, ο σκοπός του οποίου παρουσιάζεται παρακάτω.

Σχήμα 3.1- Σφάλμα παραθύρου μενού

Το παράθυρο ανοίγει το σημείο διακοπής στο ενσωματωμένο περιβάλλον, το οποίο παρέχει πρόσβαση σε όλα τα σημεία της στάσης αυτής της λύσης. Εμφανίζει ένα παράθυρο εξόδου σε ένα ενσωματωμένο μέσο.

Το παράθυρο εξόδου είναι το τρέξιμο καταγραφικό ενός συνόλου μηνυμάτων που εκδίδονται από το ενσωματωμένο μέσο, \u200b\u200bτον μεταγλωττιστή και το πρόγραμμα εντοπισμού σφαλμάτων. Επομένως, αυτές οι πληροφορίες αναφέρονται όχι μόνο για τη συνεδρίαση εντοπισμού σφαλμάτων και ανοίγει επίσης ένα παράθυρο ερμηνείας σε ένα ολοκληρωμένο περιβάλλον που επιτρέπει εντολές:

Έναρξη εντοπισμού σφαλμάτων - ξεκινά την εφαρμογή σε λειτουργία εντοπισμού σφαλμάτων.
Συμμετοχή στη διαδικασία - σας επιτρέπει να επισυνάψετε το πρόγραμμα εντοπισμού σφαλμάτων στη διαδικασία εκτελέσιμη διαδικασία (εκτελέσιμο αρχείο). Για παράδειγμα, αν η εφαρμογή ξεκινήσει χωρίς σφαλμάτωση, τότε μπορείτε στη συνέχεια να επισυνάψετε σε αυτή την εκτελέσιμη διαδικασία και να αρχίσετε να κάνετε σφάλματα.
Εξαιρέσεις, ανοίγει ένα παράθυρο διαλόγου εξαίρεσης που σας επιτρέπει να επιλέξετε μια μέθοδο Stop Debugger για κάθε εξαιρετική κατάσταση.
Ένα βήμα με μια πληρότητα εκτελεί την εφαρμογή στη λειτουργία εντοπισμού σφαλμάτων. Για τα περισσότερα έργα, η επιλογή του βήμα εντολών με μια περίσταση σημαίνει να καλεί το πρόγραμμα εντοπισμού σφαλμάτων στην πρώτη εκτελέσιμη γραμμή της εφαρμογής. Έτσι, μπορείτε να εισάγετε την εφαρμογή από την πρώτη γραμμή.
Βήμα με παράκαμψη - Όταν δεν βρίσκεστε στην περίοδο εντοπισμού σφαλμάτων, τότε η ομάδα της κοινωνίας απλώς εγκαινιάζει την εφαρμογή ακριβώς όπως θα έκανε το κουμπί Run.
Το σημείο σταματά - περιλαμβάνει ή απενεργοποιεί το σημείο διακοπής στην τρέχουσα (ενεργή) συμβολοσειρά του κώδικα επεξεργαστή κειμένου. Αυτή η επιλογή είναι ανενεργή εάν δεν υπάρχει ενεργό παράθυρο κώδικα στο ολοκληρωμένο περιβάλλον.
Η δημιουργία ενός σημείου σταματάει - ενεργοποιεί το παράθυρο διαλόγου Δημιουργία διαλόγου που σας επιτρέπει να καθορίσετε το όνομα της λειτουργίας για τον οποίο θέλετε να δημιουργήσετε ένα σημείο διακοπής.
Διαγράψτε όλα τα σημεία παραμένει - αφαιρεί όλα τα σημεία διακοπής από την τρέχουσα λύση.
Διαγράψτε όλες τις προτροπές σύμφωνα με τα δεδομένα - απενεργοποιημένα (χωρίς διαγραφή) όλα τα σημεία διακοπής της τρέχουσας λύσης.
Παράμετροι και ρυθμίσεις - Διακοπή εκτέλεσης Όταν οι εξαιρέσεις διασχίζουν το περίγραμμα τομέα εφαρμογής ή τα σύνορα μεταξύ του ελεγχόμενου και του κώδικα μηχανής.

4 Διεξάγετε μια ενότητα λογισμικού για ένα συγκεκριμένο σενάριο

Εκτιμώμενες δοκιμές, ο οποίος ονομάζεται επίσης "δοκιμή του συστήματος ως σύνολο"Σκοπός του οποίου είναι η δοκιμή του προγράμματος για τη συμμόρφωση με τις βασικές απαιτήσεις. Αυτό το στάδιο δοκιμής είναι ιδιαίτερα σημαντικό για τα προϊόντα λογισμικού.Περιλαμβάνει τους ακόλουθους τύπους:

Δοκιμή χρησιμότητας - ένας συνεπής έλεγχος για τη συμμόρφωση του προϊόντος και την τεκμηρίωση του λογισμικού σχετικά με τις βασικές διατάξεις του τεχνικού έργου.
Δοκιμές σε περιθώρια - Έλεγχος της απόδοσης του προγράμματος στο μέγιστο ποσό των δεδομένων, για παράδειγμα, κείμενα, πίνακες, μεγάλος αριθμός αρχείων κ.λπ.
Δοκιμές σε οριακούς φορτία - έλεγχος της εκτέλεσης του προγράμματος για τη διαχείριση ενός μεγάλου ποσού δεδομένων που λαμβάνονται για μικρό χρονικό διάστημα.
Δοκιμή εγκατάστασης - Ανάλυση ψυχολογικών παραγόντων που προκύπτουν όταν εργάζεστε με λογισμικό. Αυτός ο έλεγχος σάς επιτρέπει να προσδιορίσετε αν η διεπαφή είναι βολική, αν το έγχρωμο ή το ηχητικό στήριγμα είναι ενοχλημένο, κλπ.
Δοκιμές προστασίας - έλεγχος προστασίας, για παράδειγμα, από μη εξουσιοδοτημένη πρόσβαση στις πληροφορίες.
Δοκιμές απόδοσης - ο ορισμός του εύρους ζώνης για μια δεδομένη διαμόρφωση και φορτίο.
Δοκιμές απαιτήσεων μνήμης - ορισμός των πραγματικών αναγκών σε επιχειρησιακή και εξωτερική μνήμη.
Διαμόρφωση εξοπλισμού δοκιμών - Δοκιμές απόδοσης λογισμικού σε διαφορετικό εξοπλισμό.
Δοκιμές συμβατότητας - Έλεγχος της συνέχειας των εκδόσεων: Σε περιπτώσεις όπου η επόμενη έκδοση του συστήματος αλλάζει τις μορφές δεδομένων, θα πρέπει να περιλαμβάνει ειδικά συσσωματώματα, παρέχοντας τη δυνατότητα εργασίας με αρχεία που δημιουργούνται από την προηγούμενη έκδοση έκδοσης.
Εγκαταστάσεις δοκιμών Εγκατάσταση - Έλεγχος της ευκολίας εγκατάστασης.
Δοκιμή αξιοπιστίας - Επαλήθευση αξιοπιστίας χρησιμοποιώντας μαθηματικά μοντέλα.
Δοκιμές ανάκτησης - Έλεγχος ανάκτησης λογισμικού, όπως συστήματα, συμπεριλαμβανομένης μιας βάσης δεδομένων, μετά από αποτυχίες και πρόγραμμα εξοπλισμού.
Δοκιμή ευκολίας εξυπηρέτησης - Έλεγχος των εγκαταστάσεων συντήρησης που περιλαμβάνονται στο λογισμικό.
Η τεκμηρίωση τεκμηρίωσης είναι ένας διεξοδικός έλεγχος τεκμηρίωσης, για παράδειγμα, εάν η τεκμηρίωση περιέχει παραδείγματα, τότε όλοι πρέπει να δοκιμάσουν.
Διαδικασίες δοκιμών - Έλεγχος των χειρωνακτικών διαδικασιών που υποτίθεται στο σύστημα.

Φυσικά, ο σκοπός όλων αυτών των ελέγχων είναι να βρουν ασυνέπειες όσον αφορά την τεχνική ανάθεση. Πιστεύεται ότι μόνο μετά την εκτέλεση όλων των τύπων δοκιμών, το προϊόν λογισμικού μπορεί να υποβληθεί στον χρήστη ή να εφαρμόσει. Ωστόσο, στην πράξη, δεν πραγματοποιούνται συνήθως όλοι οι τύποι δοκιμών αξιολόγησης, καθώς είναι πολύ ακριβό και επίπονο. Κατά κανόνα, για κάθε τύπο λογισμικού, εκτελούνται αυτοί οι τύποι δοκιμών που είναι πιο σημαντικοί για αυτό. Έτσι, οι βάσεις δεδομένων δοκιμάζονται αναγκαστικά στους μέγιστους όγκους και τα συστήματα σε πραγματικό χρόνο βρίσκονται στα μέγιστα φορτία.

5 Εγγραφή τεκμηρίωσης λογισμικού

Το δημιουργημένο προϊόν λογισμικού έχει σχεδιαστεί για να εκτελεί αριθμητική δράση σε μήτρες.

Για να ξεκινήσετε το πρόγραμμα, πρέπει να ξεκινήσετε την εφαρμογή.

Για να δημιουργήσετε μήτρες, πρέπει να εισαγάγετε τη διάσταση της μήτρας και πατήστε τα κουμπιά "Δημιουργία". Στη συνέχεια, εισάγετε τα δεδομένα στη μήτρα και επιλέξτε την επιθυμητή ενέργεια.

Εικόνα 5.1 - Εφαρμογή εργασίας

Το πρόγραμμα έχει μια βολική διεπαφή και παρέχει την ευκαιρία να λύσει εύκολα τις μήτρες αυθαίρετων διαστάσεων.

Συμπεράσματα

Κατά τη διάρκεια της εργασίας, ολοκληρώθηκε ένα άτομο:

Πραγματοποιήθηκε ανάλυση του θέματος.
Οι επιλεγμένες και αναπτυγμένες λύσεις που αναπτύχθηκαν και αναπτύχθηκαν από τον αλγόριθμο.
Επιλέγεται ο καθορισμένο περιβάλλον τεχνολογίας και προγραμματισμού.
Το πλαίσιο εφαρμογής είναι κατασκευασμένο και σχεδιάστηκε η διεπαφή χρήστη.
Έχει αναπτυχθεί ένας κωδικός μονάδας λογισμικού.
Περιγράφονται τα εργαλεία εντοπισμού σφαλμάτων που χρησιμοποιούνται κατά τη διάρκεια των δοκιμών.
Η μονάδα λογισμικού ελέγχεται σε ένα συγκεκριμένο σενάριο.
Προστέθηκε στοιχείο μενού με μια σύντομη περιγραφή της εργασίας με το πρόγραμμα.

Τους στόχους που επιτεύχθηκαν.

Κατάλογος συνδέσμων

1 Φόρουμ Cyber \u200b\u200b[Ηλεκτρονικός πόρος]:http: // cyberforum. Ru

2 Microsoft Developer. [Επίσημη τεκμηρίωση της MicrosoftC #] TTPS: // MSDN. Η Microsoft. Com.

3 http://programming-edu.ru/ Βοήθεια Blog για αρχάριους με #

Παράρτημα Α.

Κωδικός προγράμματος

Mymatrix. Cs.

χρησιμοποιώντας το σύστημα.

Χρησιμοποιώντας το system.linq;

Χρησιμοποιώντας το σύστημα .Text;

χρησιμοποιώντας το system.windows.forms;

matrix ονομάτων.

Τάξη mymatrix.

Int [,] a \u003d νέα int;

// Μεταφορά τιμών

Δημόσιο κενό (int i, int j, int znach)

A \u003d znach;

// Πρόσθεση

Δημόσιο στατικό MyMatrix χειριστής + (MyMatrix Matrix1, MyMatrix Matrix2)

Για (int i \u003d 0; i< 3; i++)

Για (int j \u003d 0; j< 3; j++)

Newmatrix.a \u003d matrix1.a + matrix2.a;

Επιστρέψτε το NewMatrix;

// Συμπέρασμα της μήτρας

Δημόσια συμβολοσειρά Visual (int i, int j)

Επιστροφή A.TOSTRING ();

// Συμπέρασμα για το σύνολο και αμέσως. Ουσία

Δημόσια DatagridView Fullvisual (DataGridView DT)

Για (int i \u003d 0; i< 3; i++)

Για (int j \u003d 0; j< 3; j++)

Dt.rows [j] .cells [i] .Value \u003d a;

Επιστρέψτε dt;

// υποδιαίρεση

Δημόσιος στατικός χειριστής MyMatrix - (MyMatrix Matrix1, MyMatrix Matrix2)

Mymatrix newmatrix \u003d νέο mymatrix ();

Για (int i \u003d 0; i< 3; i++)

Για (int j \u003d 0; j< 3; j++)

Newmatrix.a \u003d matrix1.a - matrix2.α;

Επιστρέψτε το NewMatrix;

// Μεταφορά

Δημόσιο mymatrix trans ()

Mymatrix newmatrix \u003d νέο mymatrix ();

Για (int i \u003d 0; i< 3; i++)

Για (int j \u003d 0; j< 3; j++)

Newmatrix.a \u003d a;

Επιστρέψτε το NewMatrix;

// πολλαπλασιασμός

Δημόσιο στατικό MyMatrix χειριστής * (MyMatrix Matrix1, MyMatrix Matrix2)

Mymatrix newmatrix \u003d νέο mymatrix ();

Για (int i \u003d 0; i< 3; i++)

Για (int k \u003d 0; k< 3; k++)

// int a \u003d 0;

Για (int j \u003d 0; j< 3; j++)

// a + \u003d matrix1.a * matrix2.a;

Newmatrix.a + \u003d matrix1.a * matrix2.a;

//Newmatrix.a \u003d a;

Επιστρέψτε το NewMatrix;

// συμπλήρωση

Δημόσιο κενό Zapoln (δίκτυο DataGridView)

Για (int i \u003d 0; i< 3; i++)

Για (int j \u003d 0; j< 3; j++)

A \u003d convert.toint32 (grid.rows [j] .cells [i].

Form1.cs.

χρησιμοποιώντας το σύστημα.

χρησιμοποιώντας το σύστημα.collections.genic;

χρησιμοποιώντας το system.componentmodel;

Χρησιμοποιώντας το system.data;

Χρησιμοποιώντας το σύστημα.

Χρησιμοποιώντας το system.linq;

Χρησιμοποιώντας το σύστημα .Text;

χρησιμοποιώντας το system.windows.forms;

matrix ονομάτων.

Δημόσια Μερική Κλάση Μορφή1: Μορφή

Δημόσιο Μορφή1 ()

Αρχικός υπολογιστής ();

Ιδιωτικό κενό Form1_Load (αποστολέας αντικειμένων, eventargs e)

Για (int i \u003d 0; i< 3; i++)

Datagridview1.rows.add ();

Datagridview2.rows.add ();

DataGridView3.ROWS.ADD ();

//DatagridView1.RELES[I.Cells.Value \u003d i.Tostring ();

Private Void Button1_Click (αποστολέας αντικειμένων, eventargs e)

Mymatrix matrix3;

Matrix3 \u003d (matrix1 + matrix2);

Private Void Button2_Click (αποστολέας αντικειμένων, eventargs e)

Mymatrix matrix1 \u003d νέο mymatrix ();

Mymatrix matrix2 \u003d νέο mymatrix ();

Mymatrix matrix3;

Matrix1.zapoln (datagridview1);

Matrix2.zapoln (datagridview2);

Matrix3 \u003d (Matrix1 - Matrix2);

Matrix3.Fullisual (DataGridView3);

Private Void Button3_Click (αποστολέας αντικειμένων, eventargs e)

Mymatrix matrix1 \u003d νέο mymatrix ();

Mymatrix matrix3;

Matrix1.zapoln (datagridview1);

Matrix3 \u003d Matrix1.Trans ();

Matrix3.Fullisual (DataGridView3);

Ιδιωτικό κουμπί Void4_Click (αποστολέας αντικειμένων, eventargs e)

Mymatrix matrix1 \u003d νέο mymatrix ();

Mymatrix matrix2 \u003d νέο mymatrix ();

Mymatrix matrix3;

Matrix1.zapoln (datagridview1);

Matrix2.zapoln (datagridview2);

Matrix3 \u003d (Matrix1 * Matrix2);

Matrix3.Fullisual (DataGridView3);

Σελίδα \\ * MERGEFORMAT 3

J. Hughes, J. Micht. Διαρθρωτική προσέγγιση στον προγραμματισμό. - m.: Mir, 1980. - s. 29-71.

Β. Tursky. Μεθοδολογία προγραμματισμού. - m.: Mir, 1981. - P.90-164.

Ε.Α. Zhogolev. Τεχνολογικές βάσεις του αρθρωτού προγραμματισμού // Προγραμματισμός, 1980, # 2. - P.44-49.

R.c.holt. Δομή προγραμμάτων υπολογιστών: έρευνα // διαδικασία του IEEE, 1975, 63 (6). - Π. 879-893.

Gmaers. Αξιοπιστία λογισμικού. - m.: Mir, 1980. - s. 92-113.

Ι. Piel. Η ADA είναι η γλώσσα των ενσωματωμένων συστημάτων. M.: Χρηματοδότηση και στατιστικές, 1984. - με. 67-75.

Μ. Zelkovts, Α. Show, J. Gannon. Αρχές ανάπτυξης λογισμικού. - m.: Mir, 1982, σ. 65-71.

A.L. Fuksman. Τεχνολογικές πτυχές της δημιουργίας συστημάτων λογισμικού. M.: Στατιστικά, 1979. - Με. 79-94.

Διάλεξη 8. Ανάπτυξη μίας μονάδας λογισμικού
Τη διαδικασία ανάπτυξης μιας μονάδας λογισμικού. Δομικός προγραμματισμός και λεπτομέρειες βήμα προς βήμα. Η έννοια του ψευδοκώδικα. Μονάδα λογισμικού ελέγχου.
8.1. Τη διαδικασία ανάπτυξης μιας μονάδας λογισμικού.
Κατά την ανάπτυξη μιας ενότητας λογισμικού, συνιστάται να ακολουθήσετε την ακόλουθη σειρά:
Εκμάθηση και έλεγχο προδιαγραφές μονάδας, επιλογή γλώσσας
προγραμματισμός;
Επιλέξτε τον αλγόριθμο και τη δομή δεδομένων.
Μονάδα προγραμματισμού.
λείανση του κειμένου της ενότητας.
Έλεγχος της ενότητας.
Συλλογή της μονάδας.
Το πρώτο βήμα της ανάπτυξης μιας μονάδας λογισμικού είναι σε μεγάλο βαθμό παρακείμενο έλεγχο της δομής του προγράμματος από κάτω: μελετώντας την προδιαγραφή της μονάδας, ο προγραμματιστής πρέπει να βεβαιωθεί ότι είναι σαφής και επαρκής για την ανάπτυξη αυτής της ενότητας. Στο τέλος αυτού του βήματος επιλέγεται η γλώσσα προγραμματισμού: αν και η γλώσσα προγραμματισμού μπορεί ήδη να προκαθοριστεί για όλα τα PS, αλλά σε ορισμένες περιπτώσεις σε ορισμένες περιπτώσεις (εάν το σύστημα προγραμματισμού επιτρέπει) μια άλλη γλώσσα μπορεί να επιλεγεί μια άλλη γλώσσα, πιο κατάλληλη για την εφαρμογή αυτής της ενότητας (για παράδειγμα, γλώσσα συναρμολόγησης).
Στο δεύτερο βήμα της ανάπτυξης μιας ενότητας λογισμικού, είναι απαραίτητο να μάθετε αν οι αλγόριθμοι είναι γνωστοί για να λύσουν και να κλείσουν το έργο της. Και αν υπάρχει ένας κατάλληλος αλγόριθμος, είναι σκόπιμο να το χρησιμοποιήσετε. Η επιλογή των κατάλληλων δομών δεδομένων που θα χρησιμοποιηθούν κατά την εκτέλεση της μονάδας των λειτουργιών τους, σε μεγάλο βαθμό προκαθορισμένων των λογικών και ποιοτικών δεικτών της ενότητας που αναπτύσσεται, οπότε θα πρέπει να θεωρηθεί ως μια πολύ υπεύθυνη απόφαση.
Το τρίτο βήμα είναι η κατασκευή του κειμένου της ενότητας στην επιλεγμένη γλώσσα προγραμματισμού. Η αφθονία όλων των ειδών εξαρτημάτων που πρέπει να ληφθούν υπόψη κατά την εφαρμογή των λειτουργιών που καθορίζονται στην προδιαγραφή των μονάδων μπορούν εύκολα να οδηγήσουν στη δημιουργία ενός πολύ συγκεχυμένους κειμένου που περιέχει πολλά σφάλματα και ανακρίβειες. Αναζητήστε σφάλματα σε μια τέτοια μονάδα και για να κάνετε τις απαιτούμενες αλλαγές μπορεί να είναι μια πολύ χρονοβόρα εργασία. Ως εκ τούτου, είναι πολύ σημαντικό να οικοδομήσουμε το κείμενο της ενότητας να χρησιμοποιεί τεχνολογικά λογική και πρακτικά αποδεδειγμένη πειθαρχία προγραμματισμού. Για πρώτη φορά, η Daekstra πληρώθηκε για αυτό, διατύπωση και τεκμηρίωση των βασικών αρχών του διαρθρωτικού προγραμματισμού. Αυτές οι αρχές βασίζονται σε πολλούς κλάδους προγραμματισμού, που χρησιμοποιούνται ευρέως στην πράξη. Το πιο συνηθισμένο είναι μια πειθαρχία των λεπτομερειών βήμα προς βήμα, η οποία συζητείται λεπτομερώς στα τμήματα 8.2 και 8.3.
Το επόμενο βήμα ανάπτυξης της ενότητας συνδέεται με την εμφάνιση του κειμένου της ενότητας στην ολοκληρωμένη προβολή σύμφωνα με τις προδιαγραφές της ποιότητας του PS. Κατά τον προγραμματισμό της μονάδας, ο προγραμματιστής επικεντρώνεται στην ορθότητα της εφαρμογής των λειτουργιών των μονάδων, αφήνοντας τις παρατηρήσεις που είναι λανθασμένες και επιτρέποντας κάποιες παραβιάσεις των απαιτήσεων του στυλ προγράμματος. Κατά την άλεση του κειμένου της μονάδας, πρέπει να επεξεργαστείτε τα σχόλια που είναι διαθέσιμα στο κείμενο και ενδέχεται να περιλαμβάνουν πρόσθετα σχόλια σε αυτήν, προκειμένου να παράσχει τα απαιτούμενα πρωταρχικά ποιοτικά. Για τον ίδιο σκοπό, γίνεται η επεξεργασία του κειμένου του προγράμματος για την εκτέλεση στυλιστικών απαιτήσεων.
Το βήμα ελέγχου της ενότητας είναι ένας χειροκίνητος έλεγχος της εσωτερικής λογικής της μονάδας πριν από την έναρξη της εντοπίσσής του (χρησιμοποιώντας την εκτέλεση του στον υπολογιστή), εφαρμόζει τη γενική αρχή που διατυπώνεται για την τεχνολογία προγραμματισμού υπό συζήτηση, σχετικά με την ανάγκη ελέγχου των αποφάσεων σε κάθε στάδιο της φάσης ανάπτυξης PS (βλέπε διάλεξη 3). Οι μέθοδοι επαλήθευσης ενότητας συζητούνται το τμήμα 8.4.
Τέλος, το τελευταίο βήμα της ανάπτυξης των μονάδων σημαίνει την ολοκλήρωση του ελέγχου της μονάδας (χρησιμοποιώντας τον μεταγλωττιστή) και τη μετάβαση στη διαδικασία εντοπισμού σφαλμάτων της μονάδας.
8.2. Δομικός προγραμματισμός.
Κατά τον προγραμματισμό της ενότητας πρέπει να ληφθεί υπόψη ότι το πρόγραμμα πρέπει να είναι κατανοητό όχι μόνο στον υπολογιστή, αλλά και ένα άτομο: και τον προγραμματιστή της ενότητας και τα άτομα που ελέγχουν την ενότητα και τα κείμενα που προετοιμάζουν δοκιμές για την εντοπισμό σφαλμάτων της ενότητας, Και οι συνοδίες PS που πραγματοποιούν τις απαιτούμενες αλλαγές ενότητας θα αναγκαστούν να αποσυναρμολογήσουν πολλαπλασιασμό της λογικής της μονάδας. Στις σύγχρονες γλώσσες προγραμματισμού, αρκετά κεφάλαια αρκούν για να συγχέουν αυτή τη λογική πόσο είναι ισχυρή, καθιστώντας έτσι ότι η ενότητα είναι δύσκολη η κατανόηση για ένα άτομο και, ως αποτέλεσμα αυτού, το καθιστούν αναξιόπιστο ή δύσκολο να συνοδεύσει. Ως εκ τούτου, πρέπει να ληφθούν μέτρα για την επιλογή κατάλληλων γλωσσικών εργαλείων και να ακολουθήσουν μια συγκεκριμένη πειθαρχία προγραμματισμού. Για πρώτη φορά, η Daekstra έδωσε προσοχή σε αυτό και πρότεινε να δημιουργήσει ένα πρόγραμμα ως σύνθεση πολλών τύπων δομών ελέγχου (δομές) που σας επιτρέπουν να αυξήσετε σημαντικά την κατανόηση της λογικής εργασίας του προγράμματος. Προγραμματισμός χρησιμοποιώντας μόνο τέτοιες δομές που ονομάζονται δομικά.
Οι κύριες δομικές δομές προγραμματισμού είναι: Ακολουθούν, διακλάδωση και επανάληψη (βλέπε εικ. 8.1). Τα εξαρτήματα αυτών των σχεδίων είναι γενικευμένοι χειριστές (οι κόμβοι επεξεργασίας) S, S1, S2 και κατάσταση (πρόβατα) P. Ως γενικευμένος φορέας εκμετάλλευσης, είτε ένας απλός χειριστής της χρησιμοποιούμενης γλώσσας προγραμματισμού (φορέων εκχώρησης, είσοδος, έξοδος, διαδικασία προσφυγής), ή Ένα κομμάτι του προγράμματος που αποτελεί σύνθεση των κύριων στελεχών του διαρθρωτικού προγραμματισμού. Είναι σημαντικό η κάθε μία από αυτές τις δομές να έχει μόνο μία είσοδο και μία έξοδο για τη διαχείριση. Έτσι, ο γενικευμένος χειριστής έχει μόνο μία είσοδο και μία έξοδο.
Είναι επίσης πολύ σημαντικό ότι αυτά τα σχέδια είναι ήδη μαθηματικά αντικείμενα (τα οποία, στο σώμα, και εξηγεί το λόγο για την επιτυχία του διαρθρωτικού προγραμματισμού). Αποδεικνύεται ότι για κάθε αδόμητο πρόγραμμα, είναι δυνατόν να κατασκευαστεί ένα λειτουργικά ισοδύναμο (δηλαδή αποφασιστική ίδια εργασία) ένα δομημένο πρόγραμμα. Για δομημένα προγράμματα, μπορείτε να αποδείξετε μαθηματικά ορισμένες ιδιότητες, το οποίο σας επιτρέπει να ανιχνεύσετε ορισμένα σφάλματα στο πρόγραμμα. Μια ξεχωριστή διάλεξη θα διατεθεί σε αυτό το ζήτημα.
Ο διαρθρωτικός προγραμματισμός ονομάζεται μερικές φορές "προγραμματισμός χωρίς να πάει στο". Ωστόσο, η υπόθεση δεν είναι εδώ ενόψει της δήλωσης, αλλά με την ατασθαλία χρήση του. Πολύ συχνά στην ενσωμάτωση του διαρθρωτικού προγραμματισμού σε ορισμένες γλώσσες προγραμματισμού (για παράδειγμα, στο Fortran), ο μεταβατικός χειριστής (μετάβαση) χρησιμοποιείται για την εφαρμογή δομικών δομών χωρίς να μειώσει τα κύρια πλεονεκτήματα του δομικού προγραμματισμού. Συνεχίστε το πρόγραμμα απλώς "μη διαρθρωτικές" δηλώσεις μετάβασης, ειδικά η μετάβαση στον χειριστή που βρίσκεται στο κείμενο της ενότητας παραπάνω (νωρίτερα) ο μεταβατικός χειριστής που εκτελείται. Ωστόσο, μια προσπάθεια να αποφευχθεί ο μεταβατικός χειριστής σε ορισμένες απλές περιπτώσεις μπορεί να οδηγήσει σε πολύ δυσκίνητα δομημένα προγράμματα, τα οποία δεν βελτιώνουν τη σαφήνεια και περιέχουν τον κίνδυνο εμφάνισης πρόσθετων σφαλμάτων στο κείμενο. Ως εκ τούτου, μπορεί να συνιστάται να αποφεύγεται η χρήση του χειριστή μετάβασης καθ 'όλη τη διάρκεια, όπου είναι δυνατόν, αλλά όχι στην τιμή της σαφήνειας του προγράμματος.
Χρήσιμες περιπτώσεις χρήσης της δήλωσης μετάβασης μπορούν να αποδοθούν από τον κύκλο ή τη διαδικασία για ειδική κατάσταση, "πρόωρα" που τερματίζουν τη λειτουργία αυτού του κύκλου ή αυτής της διαδικασίας, δηλ. Η ολοκλήρωση μιας συγκεκριμένης δομικής μονάδας (γενικευμένος φορέας) και, ως εκ τούτου, παραβιάζει μόνο τοπικά τη δομή του προγράμματος. Οι μεγάλες δυσκολίες (και επιπλοκή της δομής) προκαλούν τη δομική συνειδητοποίηση της αντίδρασης στις αναδυόμενες εξαιρετικές (συχνά λανθασμένες) καταστάσεις, δεδομένου ότι δεν λαμβάνει όχι μόνο την εκτέλεση πρόωρης εξόδου από τη δομική μονάδα, αλλά και για την παραγωγή της απαραίτητης επεξεργασίας (Εξαίρεση) αυτής της κατάστασης (για παράδειγμα, η έκδοση κατάλληλων διαγνωστικών πληροφοριών). Ο χειριστής εξαίρεσης μπορεί να βρίσκεται σε οποιοδήποτε επίπεδο της δομής του προγράμματος και η έκκληση σε αυτό μπορεί να γίνει από διαφορετικά χαμηλότερα επίπεδα. Ένα πλήρως αποδεκτό από μια τεχνολογική άποψη είναι η ακόλουθη "μη διαρθρωτική" υλοποίηση της αντίδρασης σε αποκλειστικές καταστάσεις. Οι εξαιρετικοί χειριστές τοποθετούνται στο τέλος μιας συγκεκριμένης δομικής μονάδας και κάθε τέτοιος χειριστής προγραμματίζεται με τέτοιο τρόπο ώστε μετά το τέλος της δουλειάς του, παράγει μια παραγωγή από τη δομική μονάδα στο τέλος του οποίου τοποθετείται. Η έκκληση σε τέτοιο χειριστή πραγματοποιείται από τον μεταβατικό φορέα από αυτή τη δομική μονάδα (συμπεριλαμβανομένης οποιασδήποτε δομικής μονάδας που είναι ένθετο σε αυτό).
8.3. Βήμα-βήμα λεπτομερώς και η έννοια του ψευδοκτύου.
Ο διαρθρωτικός προγραμματισμός παρέχει συστάσεις για τον τρόπο με τον οποίο πρέπει να είναι το κείμενο της ενότητας. Το ερώτημα προκύπτει πώς πρέπει να ενεργεί ο προγραμματιστής προκειμένου να οικοδομήσει ένα τέτοιο κείμενο. Μερικές φορές ο προγραμματισμός της ενότητας ξεκινά με την κατασκευή του ροής της περιγράφοντας τη λογική της λειτουργίας του γενικά. Ωστόσο, η σύγχρονη τεχνολογία προγραμματισμού δεν συνιστά αυτό. Παρόλο που οι ροές σας επιτρέπουν σαφώς τη λογική της μονάδας, όταν κωδικοποιεί τη γλώσσα προγραμματισμού, υπάρχει μια πολύ συγκεκριμένη πηγή σφάλματος: η εμφάνιση ουσιαστικά δισδιάστατων δομών, ποια είναι τα διαγράμματα ροής, το γραμμικό κείμενο που αντιπροσωπεύει την ενότητα Περιέχει τον κίνδυνο να στρεβλώνει τη λογική της μονάδας, τόσο περισσότερο, το οποίο είναι ψυχολογικά αρκετά δύσκολο να διατηρηθεί ένα υψηλό επίπεδο προσοχής όταν επανεξετάζεται. Μια εξαίρεση μπορεί να συμβαίνει όταν ένας γραφικός επεξεργαστής χρησιμοποιείται για την κατασκευή ροής και επισημοποιείται τόσο πολύ ώστε το κείμενο στη γλώσσα προγραμματισμού να δημιουργείται αυτόματα (όπως μπορεί να γίνει σε p - τεχνολογία).
Ως κύριος τρόπος κατασκευής του κειμένου της ενότητας, η σύγχρονη τεχνολογία προγραμματισμού συνιστά λεπτομέρεια βήμα προς βήμα. Η ουσία αυτής της μεθόδου είναι να χωρίσει τη διαδικασία ανάπτυξης του κειμένου της ενότητας σε διάφορα βήματα. Στο πρώτο βήμα, το συνολικό σχήμα της ενότητας περιγράφεται στην προβλεπόμενη μορφή γραμμικού κειμένου (δηλ. Χρησιμοποιώντας πολύ μεγάλες έννοιες) και η περιγραφή αυτή δεν επισημοποιείται πλήρως και επικεντρώνεται στην αντίληψή του από το πρόσωπό του. Σε κάθε επόμενο βήμα, η λεπτομέρεια μιας από τις έννοιες είναι εξευγενισμένη (θα ονομαστεί εκλεπτυσμένη), που χρησιμοποιείται (κατά κανόνα, μη τυποποιημένη) σε οποιαδήποτε περιγραφή που έχει σχεδιαστεί σε ένα από τα προηγούμενα βήματα. Ως αποτέλεσμα αυτού του βήματος, δημιουργείται μια περιγραφή μιας περιγραφής της επιλεγμένης διευκρινισμένης έννοιας ή από την άποψη της βασικής γλώσσας προγραμματισμού (δηλ., Που επιλέγεται για την παρουσίαση της μονάδας) ή με την ίδια μορφή με το πρώτο βήμα χρησιμοποιώντας νέες εξευγενισμένες έννοιες. Αυτή η διαδικασία ολοκληρώνεται όταν όλες οι διευκρινισμένες έννοιες εκφράζονται τελικά στη βασική γλώσσα προγραμματισμού. Το τελικό βήμα είναι να αποκτήσετε το κείμενο της ενότητας στη βασική γλώσσα προγραμματισμού αντικαθιστώντας όλες τις καταχωρήσεις των εκλεπτυσμένων εννοιών που δίνονται από τις περιγραφές τους και την έκφραση όλων των καταχωρήσεων δομών προγραμματισμού με τα μέσα αυτής της γλώσσας προγραμματισμού.
Η λεπτομέρεια βήμα προς βήμα σχετίζεται με τη χρήση μερικής τυποποιημένης γλώσσας ώστε να αντιπροσωπεύει τις καθορισμένες περιγραφές, οι οποίες έλαβαν το όνομα του ψευδοδεκάδρου. Αυτή η γλώσσα σας επιτρέπει να χρησιμοποιείτε όλα τα σχέδια προγραμματισμού που επισημοποιούνται, μαζί με ανεπίσημα θραύσματα στη φυσική γλώσσα για την παρουσίαση γενικευμένων φορέων και προϋποθέσεων. Ως γενικευμένοι χειριστές και συνθήκες, μπορούν να οριστούν τα αντίστοιχα θραύσματα στη βασική γλώσσα προγραμματισμού.
Η περιγραφή της κεφαλής στο ψευδοκόκτερο μπορεί να θεωρηθεί εξωτερικός σχεδιασμός της μονάδας στη βασική γλώσσα προγραμματισμού, η οποία
Η αρχή της μονάδας στη βάση της βάσης, δηλ. πρώτη πρόταση ή τίτλος (προδιαγραφή) αυτής της ενότητας.
Τμήμα (Ορισμός) Περιγραφές στη βάση βάσης και αντί για περιγραφές διαδικασιών και λειτουργιών - μόνο το εξωτερικό τους σχεδιασμό.
Άτυπη ονομασία της ακολουθίας των φορέων του σώματος της μονάδας ως γενικευμένου φορέα εκμετάλλευσης (βλέπε κατωτέρω), καθώς και μια άτυπη ονομασία της ακολουθίας των φορέων του σώματος κάθε περιγραφής της διαδικασίας ή τη λειτουργία ως γενικευμένος φορέας,
Τελευταία πρόταση (τέλος) της μονάδας στη βάση βάσης.
Ο εξωτερικός σχεδιασμός της περιγραφής της διαδικασίας ή της λειτουργίας φαίνεται ομοίως. Ωστόσο, αν ακολουθήσετε το Daekster, οι περιγραφές των περιγραφών είναι καλύτερα να παρουσιάσουν εδώ στην άτυπη ονομασία, καθιστώντας τη λεπτομέρεια με τη μορφή χωριστής περιγραφής.
Μια ανεπίσημη ονομασία του γενικευμένου φορέα εκμετάλλευσης στον ψευδοκώδικα παράγεται σε φυσική γλώσσα από μια αυθαίρετη πρόταση που αποκαλύπτει γενικά το περιεχόμενό του. Η μόνη επίσημη απαίτηση για το σχεδιασμό μιας τέτοιας ονομασίας είναι το ακόλουθο: Η πρόταση αυτή πρέπει να καταλαμβάνει μία ή περισσότερες γραφικές (τυπωμένες) χορδές και να τερματίσει το σημείο.
Για κάθε άτυπο γενικευμένο φορέα εκμετάλλευσης, θα πρέπει να δημιουργηθεί ξεχωριστή περιγραφή που εκφράζει τη λογική της λειτουργίας του (λεπτομερώς το περιεχόμενό της) χρησιμοποιώντας τη σύνθεση των κύριων δομών προγραμματισμού και άλλων γενικευμένων φορέων. Ως τίτλος μιας τέτοιας περιγραφής, πρέπει να υπάρχει άτυπη ονομασία του λεπτομερούς γενικευμένου φορέα. Οι κύριες δομές του δομικού προγραμματισμού μπορούν να παρουσιαστούν στην ακόλουθη μορφή (βλ. Σχήμα 8.2). Εδώ η κατάσταση μπορεί είτε να ρυθμιστεί σαφώς στη βασική γλώσσα προγραμματισμού ως Boolean έκφραση, είτε αντιπροσωπεύεται ανεπίσημα σε μια φυσική γλώσσα με κάποιο κομμάτι που αποκαλύπτεται γενικά η έννοια αυτής της κατάστασης. Στην τελευταία περίπτωση, θα πρέπει να δημιουργηθεί ξεχωριστή περιγραφή, λεπτομερής από την προϋπόθεση αυτή, με ένδειξη ως τίτλος της ονομασίας αυτής της κατάστασης (θραύσμα στη φυσική γλώσσα).
Σύκο. 8.2. Οι βασικές δομές του δομικού προγραμματισμού στο ψευδοκοδιό.
Σύκο. 8.3. Ιδιωτικός χειριστής μετάβασης ως γενικευμένος φορέας.
Ως γενικευμένος φορέας εκμετάλλευσης στον ψευδοκώδικό, μπορείτε να χρησιμοποιήσετε τον προαναφερθέντα μεταβατικό χειριστή (βλ. Εικ. 8.3). Η ακολουθία των χειριστών εξαίρετων (εξαιρέσεις) ορίζεται στο τέλος της μονάδας ή περιγραφή της διαδικασίας (λειτουργίες). Κάθε τέτοιος χειριστής έχει τη μορφή:
Αποκλεισμός όνομα_Choles
generalized_product
Όλη την εξαίρεση
Η διαφορά μεταξύ του χειριστή εξαίρεσης από τη διαδικασία χωρίς παραμέτρους έχει ως εξής: Μετά την εκτέλεση της διαδικασίας, ο έλεγχος επιστρέφει στον χειριστή μετά την ελκυστική σε αυτήν και μετά την εκτέλεση, ο έλεγχος επιστρέφει στον χειριστή μετά την αναφορά στη μονάδα ή τη διαδικασία ( λειτουργίες) στο τέλος των οποίων (που) τοποθετείται αυτή η εξαίρεση.
Συνιστάται να δημιουργήσετε μια επαρκώς σημαντική περιγραφή σε κάθε βήμα λεπτομέρειας, αλλά εύκολα προβλέψιμη (οπτική) έτσι ώστε να βρίσκεται σε μία σελίδα του κειμένου. Κατά κανόνα, αυτό σημαίνει ότι μια τέτοια περιγραφή πρέπει να είναι μια σύνθεση των πέντε-έξι δομικών σχεδίων προγραμματισμού. Συνιστάται επίσης να έχουν ένθετες δομές με μετατόπιση προς το δικαίωμα σε διάφορες θέσεις (βλέπε σχήμα 8.4). Ως αποτέλεσμα, μπορείτε να πάρετε μια περιγραφή της λογικής της εργασίας σχετικά με την ορατότητα αρκετά ανταγωνιστικά με το flowcharts, αλλά με ένα σημαντικό πλεονέκτημα - η γραμμικότητα της περιγραφής παραμένει.

Αφαίρεση αρχείων στο αρχείο στο πρώτο αρχείο,

Ικανοποιώντας το καθορισμένο φίλτρο:

Ορίστε την έναρξη του αρχείου.

Εάν η επόμενη εγγραφή ικανοποιεί

Φίλτρο Τ.

Διαγράψτε την επόμενη καταχώρηση από το αρχείο.

Όλα αν

ΑΝΤΙΟ

Εάν τα αρχεία δεν αφαιρεθούν

Εκτύπωση "Τα αρχεία δεν διαγράφονται".

Εκτύπωση "Remote n Records".

Όλα αν

Σύκο. 8.4. Ένα παράδειγμα ενός βήματος λεπτομέρειας στο ψευδοκόκτερο.

Η ιδέα της λεπτομέρειας βήμα προς βήμα αποδίδεται στο Daekster. Ωστόσο, η Dyacstra προσέφερε μια θεμελιωδώς διαφορετική μέθοδο κατασκευής του κειμένου της ενότητας, η οποία μας φαίνεται βαθύτερη και υποσχόμενη. Πρώτον, μαζί με τη διευκρίνιση των φορέων εκμετάλλευσης, προσέφερε σταδιακά (με βήματα) για να ελέγξει (λεπτομέρειες) και τις χρησιμοποιούμενες δομές δεδομένων. Δεύτερον, σε κάθε βήμα, προσφέρθηκε να δημιουργήσει κάποια εικονική μηχανή για λεπτομερή και με τους όρους του να κάνει τις λεπτομέρειες όλων των εκλεπτυσμένων εννοιών για τις οποίες σάς επιτρέπει να κάνετε αυτό το μηχάνημα. Έτσι, η Dyacstra προσφέρθηκε, κατ 'ουσίαν, να αναλύσει λεπτομερώς τα οριζόντια στρώματα, η οποία είναι η μεταφορά των ιδεών του σχετικά με τα στρωμένα συστήματα (βλέπε διάλεξη 6) στο επίπεδο ανάπτυξης της ενότητας. Αυτή η μέθοδος ανάπτυξης της μονάδας υποστηρίζεται επί του παρόντος από τις συσκευασίες της γλώσσας της γλώσσας και των μέσων προγραμματισμού αντικειμένων.
8.4. Μονάδα λογισμικού ελέγχου.
Χρησιμοποιούνται οι ακόλουθες μέθοδοι ελέγχου της μονάδας λογισμικού:
Έλεγχος κειμένου στατικής ενότητας;
μέσω του ίχνος.
Απόδειξη των ιδιοτήτων της μονάδας προγράμματος.
Όταν η στατική επαλήθευση του κειμένου της μονάδας, αυτό το κείμενο διαβάζεται από την αρχή μέχρι το τέλος για να βρείτε σφάλματα στην ενότητα. Συνήθως για έναν τέτοιο έλεγχο προσελκύει, εκτός από τον προγραμματιστή της ενότητας, έναν ακόμη ή και αρκετούς προγραμματιστές. Συνιστάται να διορθωθούν σφάλματα, τα οποία δεν εντοπίζονται αμέσως και μετά την ολοκλήρωση της ανάγνωσης κειμένου της μονάδας.
Μέσω της παρακολούθησης είναι ένας από τους τύπους ελέγχου δυναμικής μονάδας. Περιλαμβάνει επίσης πολλούς προγραμματιστές, οι οποίοι μετακινούνται με μη αυτόματο τρόπο την εκτέλεση της μονάδας (ο χειριστής πίσω από τον χειριστή στην ακολουθία που ακολουθεί από τη λογική της μονάδας) σε ένα συγκεκριμένο σύνολο δοκιμών.
Η ακόλουθη διάλεξη είναι αφιερωμένη σε αποδεικτικά στοιχεία των ιδιοτήτων των προγραμμάτων. Θα πρέπει να σημειωθεί μόνο ότι αυτή η μέθοδος χρησιμοποιείται ακόμη σπάνια.
Λογοτεχνία για τη διάλεξη 8.
8.2. E.Didikstra. Σημειώσεις σχετικά με τη διαρθρωτική προγραμματισμό // U. Dal, E.Dyakstra, K.Horhor. Δομικός προγραμματισμός. - M.: MIR, 1975. - Σελ. 24-97.
8.3. N.virt. Συστηματικός προγραμματισμός. - M.: MIR, 1977. - Σ. 94-164.
Διάλεξη 9. Ακίνητα απόδειξης ιδιοκτησίας
Την έννοια της τεκμηρίωσης των προγραμμάτων. Υπολογισμός των ιδιοτήτων του προγράμματος, Triafs Hoore. Κανόνες για τον καθορισμό των ιδιοτήτων του φορέα εκχώρησης, των υπό όρους και τους σύνθετους φορείς εκμετάλλευσης. Κανόνες για τον καθορισμό των ιδιοτήτων του διαχειριστή του κύκλου, της έννοιας του κύκλου αμετάβλητου. Την ολοκλήρωση της εκτέλεσης του προγράμματος.
9.1. Αιτιολόγηση των προγραμμάτων. Υπολογισμός των ιδιοτήτων του προγράμματος.
Για να βελτιώσετε την αξιοπιστία των εργαλείων λογισμικού, είναι πολύ χρήσιμο να προμηθεύεστε προγράμματα με πρόσθετες πληροφορίες, χρησιμοποιώντας τα οποία μπορείτε να αυξήσετε σημαντικά το επίπεδο ελέγχου του PS. Τέτοιες πληροφορίες μπορούν να οριστούν με τη μορφή ανεπιλημμένων ή επίσημων δηλώσεων, δεμένα με διάφορα θραύσματα προγραμμάτων. Θα καλέσουμε την έγκριση από τις τεκμηρίωση του προγράμματος. Οι ανεπιλημμένες αιτιολογήσεις των προγραμμάτων μπορούν, για παράδειγμα, να εξηγήσουν τα κίνητρα για την υιοθέτηση ορισμένων λύσεων, οι οποίες μπορούν να διευκολύνουν σημαντικά την αναζήτηση και τη διόρθωση σφαλμάτων, καθώς και τη μελέτη των προγραμμάτων όταν συνοδεύονται. Οι επίσημες δικαιολογίες μας επιτρέπουν να αποδείξουμε ορισμένες από τις ιδιότητες των προγραμμάτων τόσο με το χέρι όσο και να τα ελέγξουν αυτόματα.
Μία από τις τρέχουσες έννοιες των επίσημων τεκμηρίωσης των προγραμμάτων είναι η χρήση του λεγόμενου τριαντάφυλλου. Ας είμαστε ένας γενικευμένος χειριστής σε ένα IS, P και Q μέσο πληροφοριών - μερικά προβλέποντα (έγκριση) σε αυτό το μέσο. Στη συνέχεια, η εγγραφή (P) S (Q) και ονομάζεται Triad of the Hoor, στην οποία το predicate p ονομάζεται προϋπόθεση και ο ίδιος ο Q - η μετάθεση σε σχέση με τον φορέα εκμετάλλευσης S. Λέγεται ότι ο χειριστής (ειδικότερα, Το πρόγραμμα) S έχει ένα ακίνητο (P) S (Q) αν κάθε φορά που το Predicate P είναι αληθές πριν εκτελέσετε τον χειριστή S, μετά την εκτέλεση αυτού του χειριστή S θα είναι αληθινή πρόβατα Q.
Απλά παραδείγματα ιδιοτήτων προγραμμάτων:
(9.1) (n \u003d 0) n: \u003d n + 1 (n \u003d 1),
(9.2) (n
(9.3) (n
(9.4) (n\u003e 0) p: \u003d 1; Μ: \u003d 1;
Ενώ m / \u003d n κάνει
ΑΝΤΙΟ
Για να αποδείξετε τις ιδιότητες του προγράμματος, χρησιμοποιούνται οι ιδιότητες των απλών φορέων εκμετάλλευσης γλωσσών προγραμματισμού (περιορίζονται στον κενό χειριστή και τον χειριστή ανάθεσης) και τις ιδιότητες των δομών ελέγχου (συνθέσεις), με τη βοήθεια ενός προγράμματος από απλούς χειριστές (Περιορίζουμε σε τρεις κύριες διαρθρωτικές συνθέσεις προγραμματισμού, βλέπε διάλεξη οκτώ). Αυτές οι ιδιότητες ονομάζονται συνήθως κανόνες επαλήθευσης του προγράμματος.
9.2. Ιδιότητες απλών φορέων εκμετάλλευσης.
Για έναν κενό χειριστή είναι έγκυρο
Θεώρημα 9.1. Αφήστε το P να είναι πρόβλεψη στο περιβάλλον πληροφοριών. Στη συνέχεια, λαμβάνει χώρα το ακίνητο (p) (p).
Η απόδειξη αυτού του θεώρου είναι προφανής: ένας κενός φορέας δεν αλλάζει την κατάσταση του περιβάλλοντος πληροφόρησης (σύμφωνα με τη σημασιολογία της), επομένως η προϋπόθεση της παραμένει αλήθεια και μετά την εφαρμογή της.
Για τον φορέα εκχώρησης ισχύει
Θεώρημα 9.2. Αφήστε το μέσο πληροφόρησης να αποτελείται από τη μεταβλητή X και το υπόλοιπο περιβάλλον πληροφοριών των RIS:
Τότε το ακίνητο
(Q (f (x, ris), ris) x: \u003d f (x, ris) (q (x, ris)),
Όπου f (x, ris) είναι κάποια ξεκάθαρη λειτουργία, Q - Predicate.
Απόδειξη. Ας υποθέσουμε ότι το πρόβατο Q (X0, RIS0), RIS0) ήταν αληθές πριν από την εκτέλεση του χειριστή αντιστοίχισης, όπου (X0, RIS0) είναι μια ορισμένη αυθαίρετη κατάσταση του μέσου πληροφόρησης, τότε το πρόβατο Q (x, ris) Να είστε αληθές μετά την εκτέλεση του χειριστή ανάθεσης) πώς το x θα λάβει την τιμή F (x0, RIS0) και η κατάσταση των RIS δεν αλλάζει από αυτόν τον χειριστή ανάθεσης και, ως εκ τούτου, μετά την εκτέλεση αυτού του φορέα εκχώρησης στην περίπτωση αυτή
Q (x, ris) \u003d q (f (x0, ris0), ris0).
Λόγω της αυθαιρεσίας επιλογής της κατάστασης του περιβάλλοντος πληροφοριών, αποδεικνύεται το θεώρημα.
Ένα παράδειγμα της ιδιότητας του φορέα εκχώρησης μπορεί να είναι παράδειγμα 9.1.
9.3. Ιδιότητες βασικών σχεδίων προγραμματισμού.
Σκεφτείτε τώρα τις ιδιότητες των κύριων δομικών σχεδίων προγραμματισμού: Ακολουθώντας, διακλάδωση και επανάληψη.
Οι παρακάτω ιδιότητες εκφράζουν τα ακόλουθα
Θεώρημα 9.3. Αφήστε τα p, q και r να προβλέπονται πάνω από το μέσο πληροφόρησης και οι S1 και S2 είναι γενικευμένοι χειριστές με αντίστοιχα ιδιότητες
(P) S (Q) και (Q) S2 (R).
Στη συνέχεια, για τον σύνθετο χειριστή
S1; S2.<.blockquote>
Υπάρχει ένα ακίνητο
(P) S1; S2 (R).
Απόδειξη. Ας υποθέσουμε για μια ορισμένη κατάσταση του περιβάλλοντος πληροφοριών πριν εκτελέσετε τον φορέα εκμετάλλευσης S1, το Predicate P. στη συνέχεια, από τις ιδιότητες του χειριστή S1 μετά την εκτέλεση του, το προκαταρκτικό Q θα αποδίδεται. Δεδομένου ότι ο φορέας εκμετάλλευσης S2 θα πραγματοποιηθεί στο σημασιολογικό Μετά την εκτέλεση του χειριστή S1, τότε το Q είναι αληθές και πριν από την εκτέλεση του χειριστή S2. Κατά συνέπεια, μετά την εκτέλεση του φορέα εκμετάλλευσης S2, δυνάμει της περιουσίας του, το πρόβατο R θα είναι αληθές και δεδομένου ότι ο φορέας εκμετάλλευσης S2 ολοκληρώνει την εκτέλεση του σύνθετου φορέα Αυτός ο σύνθετος χειριστής, ο οποίος ήταν υποχρεωμένος να αποδείξει.
Για παράδειγμα, εάν οι ιδιότητες (9.2) και (9.3) έχουν (9.2) και (9.3), έχει
Τόπος και ιδιοκτησία
(Ν.
Η ιδιοκτησία υποκαταστήματος εκφράζει τα ακόλουθα
Θεώρημα 9.4. Αφήστε τα p, q και r να προβλέπονται πάνω από το μέσο πληροφόρησης και οι S1 και S2 είναι γενικευμένοι χειριστές με αντίστοιχα ιδιότητες
(P, Q) S1 (R) και (`P, Q) S2 (R).
Στη συνέχεια, για τον υπό όρους χειριστή
Αν p τότε s1 διαφορετικά s2 όλα αν
Υπάρχει ένα ακίνητο
(Q) εάν p τότε S1 διαφορετικά S2 όλα αν (R).
Απόδειξη. Αφήστε για κάποια κατάσταση του περιβάλλοντος πληροφοριών πριν από την εκτέλεση ενός προϋπάρχοντος όρους φορέα εκμετάλλευσης Q. Εάν το Preadicate P είναι επίσης αληθές, τότε η εκτέλεση του υπό όρους φορέα εκμετάλλευσης σύμφωνα με τη σημασιολογία του μειώνεται στην εκτέλεση του φορέα εκμετάλλευσης S1. Λόγω των ιδιοτήτων του φορέα εκμετάλλευσης S1 μετά την εκτέλεση του (και σε αυτή την περίπτωση, θα είναι αληθινή πρόβατα R. Εάν πριν εκτελέσετε έναν όφελος φορέα, το predicate p είναι ψευδές (και q, ακόμα αληθινό), Σύμφωνα με τη σημασιολογία της, μειώνεται στην εκτέλεση του φορέα εκμετάλλευσης S2. Λόγω των ιδιοτήτων του φορέα εκμετάλλευσης S2 μετά την εκτέλεση της (και στην περίπτωση αυτή, θα είναι αληθινή πρόβατα R. Έτσι, το θεώρημα είναι πλήρως αποδεδειγμένο.
Πριν μετακινηθείτε στην ιδιότητα σχεδιασμού επανάληψης, πρέπει να σημειωθεί χρήσιμη για περαιτέρω
Θεώρημα 9.5. Αφήστε το P, Q, P1 και το Q1 να προβλέπονται πάνω από το περιβάλλον πληροφοριών για το οποίο ισχύουν οι συνέπειες
P1 \u003d\u003e p και q \u003d\u003e Q1,
Και για τον χειριστή S, εμφανίζεται η ιδιότητα (P) S (Q). Στη συνέχεια εμφανίζεται η ιδιότητα (P1) S (Q1).
Αυτό το θεώρημα ονομάζεται εξακολουθεί να θεώρημα των αποδυναμώνων.
Απόδειξη. Ας υποθέσουμε για κάποια κατάσταση του περιβάλλοντος πληροφοριών πριν εκτελέσετε τον χειριστή S, το PRICINATE P1 είναι αληθές. Στη συνέχεια, θα είναι αληθινή και θα καταδικαστεί p (λόγω της επίδικης p1 \u003d\u003e p). Επομένως, λόγω των ιδιοτήτων του φορέα εκμετάλλευσης μετά την εκτέλεση του, το πρόβατο Q θα είναι τριπλασιασμένο και επομένως τα προετοιμασία Q1 (λόγω της επίδικης Q \u003d\u003e Q1). Έτσι, αποδεικνύεται το θεώρημα.
Η ιδιότητα επανάληψης εκφράζει τα ακόλουθα
Θεώρημα 9.6. Αφήστε i, p, q και r να προβλέπουν πάνω από το περιβάλλον πληροφοριών για το οποίο οι συνέπειες είναι έγκυρες
P \u003d\u003e i και (i, `q) \u003d\u003e r,
Και ας είναι ένας γενικευμένος χειριστής με ένα ακίνητο (i) s (i).
Στη συνέχεια, για τον χειριστή του κύκλου
Ενώ το q κάνει όλα ενώ
Υπάρχει ένα ακίνητο
(P) ενώ το q κάνει τα πάντα ενώ (r).
Το Preadicate i ονομάζεται αμετάβλητος του χειριστή του κύκλου.
Απόδειξη. Για να αποδείξει αυτό το θεώρημα, αρκεί να αποδείξει την ιδιοκτησία
(I) ενώ q κάνει τα πάντα ενώ (i, `Q)
(Σύμφωνα με το θεώρημα 9.5 με βάση τις επιπτώσεις που διατίθενται υπό τους όρους αυτού του θεώρου). Αφήστε την πρόβλεψη ότι δοκιμάθηκα πριν εκτελέσετε τον διαχειριστή του κύκλου του κύκλου. Εάν το Q predicate Q είναι ψευδές, ο χειριστής του κύκλου θα ισοδυναμεί με έναν κενό χειριστή (σύμφωνα με τη σημασιολογία του) και λόγω του θεώρημα 9.1 μετά την εκτέλεση του διαχειριστή του κύκλου (i , `Q). Εάν πριν εκτελέσετε έναν φορέα εκμετάλλευσης κύκλου, το Q preducate θα είναι αληθές, ο φορέας εκμετάλλευσης του κύκλου σύμφωνα με το σημασιολογικό της μπορεί να εκπροσωπείται ως σύνθετο χειριστή s. Ενώ το q κάνει όλα ενώ
Λόγω των ιδιοτήτων του φορέα εκτέλεσης μετά την εκτέλεση του, ο πρόβλεψη θα είμαι αληθής και η αρχική κατάσταση προκύπτει για να αποδείξει τις ιδιότητες του διαχειριστή του κύκλου: το predicate i είναι αλήθεια πριν από την εκτέλεση του φορέα εκμετάλλευσης του κύκλου, αλλά ήδη για άλλη (τροποποιημένη ) Κατάσταση του περιβάλλοντος πληροφοριών (για το οποίο το Q predicate μπορεί να είναι είτε TRUE είτε ψευδές). Εάν ολοκληρωθεί η εκτέλεση του φορέα εκτέλεσης του κύκλου, εφαρμόζοντας τη μέθοδο της μαθηματικής επαγωγής, εμείς για έναν πεπερασμένο αριθμό βημάτων, θα έρθουμε σε μια κατάσταση όπου η έγκριση (i, Q) είναι αληθινή πριν από την εκπληρωτή. Και στην περίπτωση αυτή, όπως αποδείχθηκε παραπάνω, αυτή η δήλωση θα είναι δίκαιη και μετά τη λειτουργία του διαχειριστή του κύκλου. Το θεώρημα αποδειχθεί.
Για παράδειγμα, ο χειριστής του κύκλου από το παράδειγμα (9.4) έχει ένα ακίνητο
Μ: \u003d Μ + 1; P: \u003d p * m
Όλα μέχρι τώρα (p \u003d n.!}
Αυτό προκύπτει από το θεώρημα 9.6, δεδομένου ότι το αμετάβλητο αυτού του φορέα εκμετάλλευσης κύκλου είναι pimicate p \u003d m! Και οι συνέπειες είναι έγκυρες (n\u003e 0, p \u003d 1, m \u003d 1) \u003d\u003e p \u003d m! και (p \u003d m!, m \u003d n) \u003d\u003e p \u003d n!
9.4. Την ολοκλήρωση της εκτέλεσης του προγράμματος.
Μία από τις ιδιότητες του προγράμματος που μπορεί να ενδιαφέρεται να αποφύγει πιθανά σφάλματα στο PS είναι η ολοκλήρωσή της, δηλ. Έλλειψη βρόχου σε ένα ή και άλλα δεδομένα πηγής. Στα δομημένα προγράμματα που θεωρούνται από εμάς, μόνο ο σχεδιασμός επανάληψης μπορεί να είναι η πηγή. Ως εκ τούτου, για να αποδείξει την ολοκλήρωση του προγράμματος, αρκεί να είναι σε θέση να αποδείξει την ολοκλήρωση του φορέα εκμετάλλευσης του κύκλου. Αυτό είναι χρήσιμο για αυτό.
Θεώρημα 9.7. Αφήστε το F να είναι μια ακέραια λειτουργία ανάλογα με την κατάσταση ενός περιβάλλοντος πληροφοριών και την ικανοποίηση των ακόλουθων συνθηκών:
(1) Εάν είναι αληθινός ένας πρόβατος Q για αυτή την κατάσταση του περιβάλλοντος πληροφοριών, η αξία του είναι θετική.
(2) μειώνεται όταν η κατάσταση του μέσου πληροφόρησης αλλάζει ως αποτέλεσμα της εκτέλεσης του φορέα εκμετάλλευσης S.
Στη συνέχεια, εκτέλεση του χειριστή του κύκλου
Ενώ το q κάνει τα πάντα ολοκληρώθηκαν.
Απόδειξη. Ας είναι η κατάσταση του μέσου πληροφοριών πριν εκτελέσετε τον χειριστή του κύκλου και αφήστε το f (είναι) \u003d k. Εάν το Q (είναι) είναι ψευδές, η εκτέλεση του χειριστή του κύκλου ολοκληρώνεται. Εάν το Q (είναι) είναι αληθές, τότε με την κατάσταση του θεώρημα k\u003e 0. Σε αυτή την περίπτωση, ο χειριστής S θα εκτελεστεί μία ή περισσότερες φορές. Μετά από κάθε εκτέλεση του φορέα εκμετάλλευσης κάτω από την κατάσταση του θεώρημα, η λειτουργία λειτουργίας F μειώνεται και, αφού πριν εκτελέσει το προκαταρκτικό στοιχείο του χειριστή Q θα πρέπει να είναι αληθές (με σημασιολογία του χειριστή του κύκλου), τότε η τιμή της συνάρτησης f στο εκείνη τη στιγμή πρέπει να είναι θετική (από την κατάσταση του θεώρημα). Ως εκ τούτου, λόγω της ακροσώσεως της λειτουργίας F, ο φορέας εκμετάλλευσης σε αυτόν τον κύκλο μπορεί να πραγματοποιηθεί περισσότερο από k THALS. Το θεώρημα αποδειχθεί.
Για παράδειγμα, για τον χειριστή που θεωρείται παραπάνω, οι κύκλοι θεώρημα 9.7 ικανοποιούν τη λειτουργία F (n, m) \u003d n-m. Δεδομένου ότι πριν εκτελέσετε τον χειριστή του κύκλου m \u003d 1, το σώμα αυτού του κύκλου θα πραγματοποιηθεί (n-1) φορές, δηλ. Αυτός ο χειριστής του κύκλου ολοκληρώνεται.
9.5. Ένα παράδειγμα ιδιοτήτων απόδειξης προγραμμάτων.
Με βάση τους αποδεδειγμένους κανόνες επαλήθευσης του προγράμματος, είναι δυνατόν να αποδειχθούν οι ιδιότητες των προγραμμάτων που αποτελούνται από διαχειριστές πιστώσεων και κενούς φορείς εκμετάλλευσης και χρησιμοποιώντας τρεις βασικές συνθέσεις διαρθρωτικού προγραμματισμού. Για να το κάνετε αυτό, αναλύοντας τη δομή του προγράμματος και τη χρήση των προκαθορισμένων και των ταχυδρομείων του, είναι απαραίτητο σε κάθε βήμα ανάλυσης να εφαρμόσει έναν κατάλληλο κανόνα επαλήθευσης. Στην περίπτωση της εφαρμογής της σύνθεσης επανάληψης, θα χρειαστεί να επιλέξετε έναν κατάλληλο κύκλο αμετάβλητο.
Για παράδειγμα, αποδεικνύουμε την ιδιοκτησία (9.4). Αυτή η απόδειξη θα αποτελείται από τα ακόλουθα βήματα.
(Βήμα 1). N\u003e 0 \u003d\u003e (n\u003e 0, p - οποιαδήποτε, m - οποιαδήποτε).
(Βήμα 2). Λαμβάνει χώρα
(n\u003e 0, p - οποιαδήποτε, m - οποιαδήποτε) p: \u003d 1 (n\u003e 0, p \u003d 1, m - οποιαδήποτε).
Από το θεώρημα 9.2.
(Βήμα 3). Λαμβάνει χώρα
(n\u003e 0, p \u003d 1, m - οποιαδήποτε) m: \u003d 1 (n\u003e 0, p \u003d 1, m \u003d 1).
Από το θεώρημα 9.2.
(Βήμα 4). Λαμβάνει χώρα
(n\u003e 0, p - οποιαδήποτε, m - οποιαδήποτε) p: \u003d 1; Μ: \u003d 1 (n\u003e 0, p \u003d 1, m \u003d 1).
Από το θεώρημα 9.3 δυνάμει των αποτελεσμάτων των βημάτων 2 και 3.
Αποδείξαμε ότι το predicate p \u003d m! είναι ένας κύκλος αμετάβλητος, δηλ. (P \u003d m m:=m+1; p:=p*m {p=m!}.!}
(Βήμα 5). Λαμβάνει χώρα (p \u003d m m:=m+1 {p=(m-1)!}.!}
Από το θεώρημα 9.2, αν υποβάλλετε προϋπόθεση στη φόρμα (p \u003d ((m + 1) -1).!}
(Βήμα 6). Λαμβάνει χώρα (p \u003d (m-1) p:=p*m {p=m!}.!}
Από το θεώρημα 9.2, εάν αντιπροσωπεύετε την προϋπόθεση στη φόρμα (p * m \u003d m.!}
(Βήμα 7). Υπάρχει ένας αμετάβλητος κύκλος
(P \u003d m m:=m+1; p:=p*m {p=m!}.!}
Από το θεώρημα 9.3, λόγω των αποτελεσμάτων των βημάτων 5 και 6.
(Βήμα 8). Λαμβάνει χώρα
(n\u003e 0, p \u003d 1, m \u003d 1) ενώ m / \u003d n κάνει
Μ: \u003d Μ + 1; P: \u003d p * m
Όλα μέχρι τώρα (p \u003d n.!}
Από το θεώρημα 9.6, λόγω του αποτελέσματος του βήματος 7 και έχοντας κατά νου ότι (n\u003e 0, p \u003d 1, m \u003d 1) \u003d\u003e p \u003d m !; (p \u003d m !, m \u003d n) \u003d\u003e p \u003d n!.
(Βήμα 9). Λαμβάνει χώρα
(n\u003e 0, p - οποιαδήποτε, m - οποιαδήποτε) p: \u003d 1; Μ: \u003d 1;
Ενώ m / \u003d n κάνει
Μ: \u003d Μ + 1; P: \u003d p * m
Όλα μέχρι τώρα (p \u003d n.!}
Από το θεώρημα 9.3, λόγω των αποτελεσμάτων των βημάτων 3 και 8.
(Βήμα 10). Το ακίνητο (9.4) έχει ένα ακίνητο (9.4) από το θεώρημα 9.5 δυνάμει των αποτελεσμάτων των βημάτων 1 και 9.
Λογοτεχνία για τη διάλεξη 9.
9.1. ΑΝΩΝΥΜΗ ΕΤΑΙΡΙΑ. Abramov. Στοιχεία προγραμματισμού. - M.: Science, 1982. Σ. 85-94.
9.2. Μ. Zelkovts, Α. Show, J. Gannon. Αρχές ανάπτυξης λογισμικού. - M.: MIR, 1982. Σ. 98-105.
Διάλεξη 10. Λογισμικό δοκιμής και εντοπισμού σφαλμάτων
ΒΑΣΙΚΕΣ ΕΝΝΟΙΕΣ. Στρατηγική σχεδιασμού δοκιμών. Εντολή εντοπισμού εντοπισμού. Offline Debugging και δοκιμή Μονάδα λογισμικού. Πολύπλοκο λογισμικό εντοπισμού σφαλμάτων και δοκιμών.
10.1. ΒΑΣΙΚΕΣ ΕΝΝΟΙΕΣ.
Το Debugging PS είναι μια δραστηριότητα που αποσκοπεί στην ανίχνευση και τη διόρθωση σφαλμάτων στο PS χρησιμοποιώντας τις διαδικασίες εκτέλεσης των προγραμμάτων του. Η δοκιμή PS είναι η διαδικασία εκτέλεσης των προγραμμάτων του σε ένα ορισμένο σύνολο δεδομένων για το οποίο είναι γνωστό το αποτέλεσμα της εφαρμογής ή οι κανόνες για τη συμπεριφορά αυτών των προγραμμάτων είναι γνωστές. Το συγκεκριμένο σύνολο δεδομένων ονομάζεται δοκιμή ή μόνο μια δοκιμή. Έτσι, η εντοπισμός σφαλμάτων μπορεί να εκπροσωπείται ως πολλαπλή επανάληψη τριών διαδικασιών: δοκιμές, ως αποτέλεσμα της οποίας μπορεί να δηλωθεί στο PC ERROR, αναζητώντας τον τόπο σφάλματος στα προγράμματα και την τεκμηρίωση των προγραμμάτων PS και την επεξεργασία των προγραμμάτων και της τεκμηρίωσης για την εξάλειψη των προγραμμάτων και την τεκμηρίωση το ανιχνευμένο σφάλμα. Με άλλα λόγια:
Debugging \u003d Δοκιμή + Αναζήτηση σφάλματος + Επεξεργασία.
Στην υπερπόντια λογοτεχνία, η εντοπισμός σφαλμάτων γίνεται συχνά κατανοητή μόνο ως η διαδικασία αναζήτησης και διόρθωσης σφαλμάτων (χωρίς δοκιμή), το γεγονός του οποίου ορίζεται κατά τη δοκιμή. Μερικές φορές οι δοκιμές και η εντοπισμός σφαλμάτων θεωρούν συνώνυμα. Στη χώρα μας, οι δοκιμές περιλαμβάνονται συνήθως στην έννοια της σφαλμάτωσης, οπότε θα ακολουθήσουμε την τρέχουσα παράδοση. Ωστόσο, η κοινή εξέταση σε αυτή τη διάλεξη αυτών των διαδικασιών καθιστά την καθορισμένη απόκλιση όχι τόσο σημαντική. Θα έπρεπε, ωστόσο, πρέπει να σημειωθεί ότι η δοκιμή χρησιμοποιείται και ως μέρος της διαδικασίας πιστοποίησης PS (βλέπε διάλεξη 14).
10.2. Αρχές και τύποι εντοπισμού σφαλμάτων.
Η επιτυχία της εντοπισμού σφαλμάτων είναι αρκετά προκαθορισμένες η ορθολογική οργάνωση των δοκιμών. Κατά την εντοπισμό σφαλμάτων, βρίσκονται και εξαλείφονται, κυρίως τα σφάλματα, η παρουσία της οποίας στο ΡΡ ρυθμίζεται κατά τη δοκιμή. Όπως είχε ήδη σημειωθεί, οι δοκιμές δεν μπορούν να αποδείξουν την ορθότητα του PS, στην καλύτερη περίπτωση, μπορεί να αποδείξει την παρουσία σφαλμάτων σε αυτό. Με άλλα λόγια, είναι αδύνατο να διασφαλιστεί ότι η δοκιμή PS με ένα πρακτικά εκτελεσμένο σετ δοκιμών μπορεί να ρυθμιστεί από την παρουσία κάθε διαθέσιμου σφάλματος. Επομένως, προκύπτουν δύο καθήκοντα. Πρώτον: Προετοιμάστε ένα τέτοιο σύνολο δοκιμών και εφαρμόστε το PS σε αυτό για να το ανιχνεύσετε με μεγαλύτερο αριθμό σφαλμάτων. Ωστόσο, όσο μεγαλύτερη η διαδικασία δοκιμής (και η εντοπισμός σφαλμάτων στο σύνολό του) συνεχίζεται, τόσο μεγαλύτερο είναι το κόστος του PS. Ως εκ τούτου, η δεύτερη εργασία: να καθορίσει τον χρόνο του τέλους της εντοπισμού σφαλμάτων του PS (ή του ξεχωριστού συστατικού του). Ένα σημάδι της δυνατότητας ολοκλήρωσης εντοπισμού σφαλμάτων είναι η πλήρης κάλυψη της μεταβιβάσεως μέσω δοκιμών PS (δηλαδή, των δοκιμών στις οποίες η PS) πολλών διαφορετικών καταστάσεων που προκύπτουν από την εκτέλεση προγραμμάτων PS και σχετικά σπάνια εκδήλωση σφαλμάτων στο τελευταίο τμήμα του τελευταίου τμήματος της διαδικασίας δοκιμών. Το τελευταίο καθορίζεται σύμφωνα με τον απαιτούμενο βαθμό αξιοπιστίας του PS που καθορίζεται στην προδιαγραφή της ποιότητας του.
Για να βελτιστοποιήσετε το σετ δοκιμών, δηλ. Να προετοιμάσει ένα τέτοιο σύνολο δοκιμών, το οποίο θα τους επέτρεπε όπως ορίζεται από αυτούς (ή σε ένα δεδομένο χρονικό διάστημα που κατανέμεται για δοκιμές) για την ανίχνευση μεγαλύτερου αριθμού σφαλμάτων, είναι απαραίτητο, πρώτον, να σχεδιάσει αυτό το σετ εκ των προτέρων και, δεύτερον, , να χρησιμοποιήσετε δοκιμές στρατηγικής λογικού σχεδιασμού (σχεδιασμού). Ο σχεδιασμός δοκιμής μπορεί να ξεκινήσει αμέσως μετά την ολοκλήρωση του βήματος εξωτερικής περιγραφής PS. Διαφορετικές προσεγγίσεις για την ανάπτυξη στρατηγικών σχεδιασμού δοκιμών, οι οποίες μπορούν να προγραμματιστούν γραφικά να είναι γραφικά (βλέπε εικ. 9.1) μεταξύ των ακόλουθων δύο ακραίων προσεγγίσεων. Η αριστερή ακραία προσέγγιση είναι ότι οι δοκιμές σχεδιάζονται μόνο με βάση τη μελέτη των προδιαγραφών PS (εξωτερική περιγραφή, περιγραφή της προδιαγραφής αρχιτεκτονικής και της μονάδας). Η δομή των μονάδων δεν λαμβάνεται υπόψη, δηλ. Θεωρούνται μαύρα κουτιά. Στην πραγματικότητα, αυτή η προσέγγιση απαιτεί πλήρη κατάσβεση όλων των συνόλων δεδομένων εισόδου, δεδομένου ότι όταν χρησιμοποιείτε μόνο τμήματα αυτών των συνόλων, ορισμένα από τα προγράμματα PS ενδέχεται να μην λειτουργούν σε καμία δοκιμή και σημαίνει ότι τα λάθη που περιέχονται σε αυτά δεν θα εμφανιστούν. Ωστόσο, η δοκιμή του PS με ένα πλήρες σύνολο συνόλων εισόδου είναι σχεδόν αδύνατο. Η σωστή ακραία προσέγγιση είναι ότι οι δοκιμές σχεδιάζονται με βάση τη μελέτη κειμένων κειμένου, προκειμένου να δοκιμαστούν όλες οι διαδρομές κάθε προγράμματος PS. Εάν λάβετε υπόψη τη διαθεσιμότητα των κύκλων με μεταβλητό αριθμό επαναλήψεων, οι διαφορετικοί τρόποι εκτέλεσης προγραμμάτων PS μπορεί επίσης να είναι εξαιρετικά πολύ, έτσι ώστε η δοκιμή τους να είναι επίσης πρακτικά αδύνατη.
Η βέλτιστη στρατηγική του σχεδιασμού δοκιμής βρίσκεται μέσα στο διάστημα μεταξύ αυτών των ακραίων προσεγγίσεων, αλλά πιο κοντά στην αριστερή άκρη. Περιλαμβάνει το σχεδιασμό ενός σημαντικού μέρους των δοκιμών σύμφωνα με τις προδιαγραφές, βάσει των αρχών: για κάθε λειτουργία που χρησιμοποιείται ή η ικανότητα - τουλάχιστον μία δοκιμή, για κάθε περιοχή και σε κάθε περίγραμμα αλλαγών σε οποιαδήποτε τιμή εισόδου - τουλάχιστον ένα Δοκιμή, για κάθε ειδική περίπτωση ή σε κάθε εξαιρετική κατάσταση που καθορίζεται στις προδιαγραφές είναι τουλάχιστον μία δοκιμή. Ωστόσο, απαιτεί επίσης το σχεδιασμό ορισμένων δοκιμών και στα κείμενα των προγραμμάτων, με βάση την αρχή (τουλάχιστον): Κάθε ομάδα κάθε προγράμματος PS θα πρέπει να λειτουργεί τουλάχιστον σε μια δοκιμή.
Ο βέλτιστος σχεδιασμός στρατηγικών δοκιμών μπορεί να προσδιοριστεί με βάση την αρχή της ακόλουθης αρχής: Για κάθε έγγραφο του προγράμματος (συμπεριλαμβανομένων των κειμένων των προγραμμάτων) που περιλαμβάνονται στο PS, οι δοκιμές τους πρέπει να σχεδιάζονται για να εντοπίζουν σφάλματα σε αυτήν. Εν πάση περιπτώσει, η αρχή αυτή πρέπει να τηρείται σύμφωνα με τον ορισμό του PS και το περιεχόμενο της έννοιας της τεχνολογίας προγραμματισμού ως τεχνολογία για την ανάπτυξη αξιόπιστων PS (βλέπε διάλεξη 1). Από την άποψη αυτή, οι Myers καθορίζουν ακόμη διαφορετικούς τύπους δοκιμών ανάλογα με τον τύπο του εγγράφου του προγράμματος, βάσει των οποίων κατασκευάζονται οι δοκιμές. Στη χώρα μας υπάρχουν δύο κύριοι τύποι εντοπισμού σφαλμάτων (συμπεριλαμβανομένων των δοκιμών): Αυτόνομο και περίπλοκο εντοπισμό εντοπισμού. Αυτόνομη λειτουργία εντοπισμού σφαλμάτων που ελέγχουν μόνο κάποιο μέρος του προγράμματος που περιλαμβάνεται στο PS, με αναζήτηση και διόρθωση σε αυτό που καταγράφηκε κατά τη δοκιμή σφαλμάτων. Περιλαμβάνει πραγματικά σφαλμάτωση κάθε ενότητας και εντοπισμού εντοπισμού σφαλμάτων. Ενσωματωμένα μέσα εντοπισμού σφαλμάτων που ελέγχουν το PS στο σύνολό της με την αναζήτηση και τη διόρθωση των σφαλμάτων που καταγράφονται κατά τη δοκιμή σφαλμάτων σε όλα τα έγγραφα (συμπεριλαμβανομένων των κειμένων των προγραμμάτων PS) που σχετίζονται με το PS στο σύνολό του. Αυτά τα έγγραφα περιλαμβάνουν τον ορισμό των απαιτήσεων PS, τις προδιαγραφές ποιότητας PS, τις λειτουργικές προδιαγραφές PS, περιγραφή της αρχιτεκτονικής PS και PS προγράμματα.
10.3. Εντολή εντοπισμού εντοπισμού.
Αυτή η ενότητα παρέχει γενικές συστάσεις για την οργάνωση της εντοπισμού σφαλμάτων. Ωστόσο, πρέπει να σημειωθεί ότι ένα φαινόμενο που επιβεβαιώνει τη σημασία των προειδοποιητικών σφαλμάτων στα προηγούμενα στάδια ανάπτυξης: καθώς ο αριθμός των ανιχνευμένων και σταθερών σφαλμάτων στο PS αναπτύσσει επίσης τη σχετική πιθανότητα της ύπαρξης σε αυτά των μη διαταραγμένων σφαλμάτων. Αυτό εξηγείται από το γεγονός ότι με αύξηση του αριθμού των σφαλμάτων που διαπιστώθηκαν στο PS, διευκρινίζεται επίσης από την ιδέα μας για το συνολικό αριθμό των σφαλμάτων που γίνονται δεκτά σε αυτήν, και ως εκ τούτου, σε κάποιο βαθμό, τον αριθμό των παρού εντούτοις Σφάλματα. Αυτό το φαινόμενο επιβεβαιώνει τη σημασία της έγκαιρης ανίχνευσης σφαλμάτων και την ανάγκη να ελέγχουν προσεκτικά τις αποφάσεις που έγιναν σε κάθε στάδιο της ανάπτυξης του PS.
Εντολές 1. Σκεφτείτε τη δοκιμή του βασικού καθήκοντος της ανάπτυξης PS, αναθέτουν τους ειδικευμένους και προικισμένους προγραμματιστές του. Είναι ανεπιθύμητο να δοκιμάσετε το δικό σας πρόγραμμα.
Εντολειρισμός 2. Είναι καλό ότι η δοκιμή για την οποία είναι υψηλή η ανίχνευση σφάλματος και όχι εκείνη που καταδεικνύει τη σωστή λειτουργία του προγράμματος.
Command 3. Προετοιμάστε τις δοκιμές τόσο για τα σωστά όσο και τα εσφαλμένα δεδομένα.
Εντολή 4. Αποφύγετε τις μη εκλεπτυσμένες δοκιμές, να τις εγγράφετε μέσω του υπολογιστή. Εξερευνήστε τα αποτελέσματα κάθε δοκιμής λεπτομερώς.
Εντολή 5. Συνδέστε κάθε ενότητα στο πρόγραμμα μόνο μία φορά. Ποτέ μην τροποποιήσετε το πρόγραμμα για να διευκολύνετε τη δοκιμή του.
Εντολή 6. Παραλείψτε όλες τις δοκιμές που σχετίζονται με τον έλεγχο του έργου οποιουδήποτε προγράμματος PS ή της αλληλεπίδρασής του με άλλα προγράμματα εάν έχουν γίνει αλλαγές σε αυτό (για παράδειγμα, ως αποτέλεσμα της εξάλειψης του σφάλματος).
10.4. Αυτόνομη εντοπισμός σφαλμάτων της ενότητας.
Με αυτόνομη εντοπισμό σφαλμάτων, κάθε ενότητα δοκιμάζεται στην πραγματικότητα σε ένα συγκεκριμένο περιβάλλον λογισμικού, εκτός από την περίπτωση όπου το πρόγραμμα εντοπισμού σφαλμάτων αποτελείται μόνο από μία μονάδα. Το περιβάλλον αυτό αποτελείται από άλλες ενότητες, ορισμένες από τις οποίες είναι οι ενότητες του προγράμματος που στράφηκαν, οι οποίες έχουν ήδη στροφώσει και το μέρος είναι από τις μονάδες που διαχειρίζονται σφαλμάτωση (με δώδεκα εντοπισμού σφαλμάτων, βλέπε παρακάτω). Έτσι, με αυτόνομη εντοπισμό σφαλμάτων, ένα συγκεκριμένο πρόγραμμα που κατασκευάστηκε ειδικά δοκιμάζεται πάντα για τη δοκιμή της εντοπίσσεως της μονάδας. Το πρόγραμμα αυτό συμπίπτει μόνο μερικώς με το πρόγραμμα που απορρίπτεται, εκτός εάν ο τελευταίος συντελεστής του προγράμματος απορρίπτεται. Όπως προωθείται το σφάλμα του προγράμματος, ένα αυξανόμενο μέρος της επόμενης εντυπωσιακής ενότητας θα είναι οι ήδη εντοπίσεις εντοπισμού σφαλμάτων αυτού του προγράμματος και κατά την υποχρέωση εντοπισμού σφαλμάτων της τελευταίας ενότητας αυτού του προγράμματος, το περιβάλλον της εντυπωσιακής μονάδας θα αποτελείται εξ ολοκλήρου από όλα τα άλλα (ήδη Debugged) Moduli του προγράμματος (χωρίς καμία) ενοίκηση εντοπισμού σφαλμάτων, δηλ. Στην περίπτωση αυτή, το πρόγραμμα εντοπισμού σφαλμάτων θα δοκιμαστεί. Μια τέτοια διαδικασία αύξησης του εντυπωσιακού προγράμματος εντοπίστηκαν και οι εντοπίσεις εντοπισμού σφαλμάτων και η επίστρωση των εντυπωσιακών στοιχείων ονομάζεται ενσωμάτωση του προγράμματος.
Οι ενότητες εντοπισμού σφαλμάτων που περιλαμβάνονται στο περιβάλλον της εντυπωσιακής μονάδας εξαρτάται από τη σειρά κατά την οποία οι ενότητες του παρόντος προγράμματος απορρίπτονται, στις οποίες η ενότητα απορρίπτεται και, ίσως, τι είδους δοκιμασία θα παραλειφθεί.
Κατά την αύξηση της δοκιμής (βλ. Διάλεξη 7), το περιβάλλον αυτό θα περιέχει πάντοτε μόνο μία μονάδα εντοπισμού σφαλμάτων (εκτός όταν το τελευταίο μέτρο του προγράμματος απορρίπτεται), το οποίο θα είναι το κεφάλι στο πρόγραμμα δοκιμής και το οποίο ονομάζεται Master (ή οδηγός) . Η κορυφαία μονάδα εντοπισμού εντοπισμού σφαλμάτων προετοιμάζει το μέσο πληροφορίας για τη δοκιμή της εντοπίσσεως της υπομονάδας (δηλ τα απαραίτητα μηνύματα. Κατά την εντοπισμό εντοπισμού μιας ενότητας για διαφορετικές δοκιμές, μπορούν να γίνουν διαφορετικές κορυφαίες μονάδες εντοπισμού σφαλμάτων.
Με τη δοκιμή προς τα κάτω (βλ. Διάλεξη 7) Το περιβάλλον της εντυπωσιακής μονάδας ως εντοπισμού εντοπισμού σφαλμάτων περιέχει προσομοιωτές όλων των μονάδων στις οποίες μια ενότητα εντοπισμού σφαλμάτων, καθώς και οι προσομοιωτές αυτών των ενοτήτων στα οποία οι αφοσιωμένες ενότητες του προγράμματος αποσυνδέονται (περιλαμβάνονται Σε αυτό το περιβάλλον) μπορεί να προσπελάσει, αλλά δεν είναι ακόμη σφαλμένα. Μερικοί από αυτούς τους προσομοιωτές κατά την εντοπισμό εντοπισμού μιας ενότητας μπορεί να ποικίλουν για διαφορετικές δοκιμές.
Στην πραγματικότητα, που περιβάλλεται από την εντοπισμένη ενότητα σε πολλές περιπτώσεις μπορεί να περιέχει ενότητες σφαλμάτων και των δύο τύπων επόμενων λόγων. Τόσο η ανύψωση όσο και προς τα κάτω δοκιμή έχει τα πλεονεκτήματα και τα μειονεκτήματά του.
Τα πλεονεκτήματα των ανερχόμενων δοκιμών περιλαμβάνουν
Εύκολη προετοιμασία δοκιμών και
Τη δυνατότητα πλήρους εφαρμογής του σχεδίου δοκιμής της ενότητας.
Αυτό οφείλεται στο γεγονός ότι η κατάσταση δοκιμής του μέσου πληροφοριών παρασκευάζεται αμέσως πριν παραπέμψει στη μονάδα εντοπισμού σφαλμάτων (η κορυφαία μονάδα εντοπισμού σφαλμάτων). Οι φορητοί υπολογιστές των ανερχόμενων δοκιμών είναι τα ακόλουθα χαρακτηριστικά:
Τα δεδομένα δοκιμών προετοιμάζονται, κατά κανόνα, όχι στη φόρμα, η οποία έχει σχεδιαστεί με τον χρήστη (εκτός εάν χρεώνεται η τελευταία, η επικεφαλίδα, η ενότητα των προγραμμάτων σφαλμάτων).
Ένα μεγάλο ποσό προγραμματισμού εντοπισμού σφαλμάτων (κατά την εντοπισμό εντοπισμού μιας ενότητας συχνά πρέπει να είναι πολλές κορυφαίες μονάδες εντοπισμού σφαλμάτων για διαφορετικές δοκιμές).
Η ανάγκη για δοκιμή διεπαφής ειδικής ενότητας.
Τα πλεονεκτήματα των δοκιμών προς τα κάτω περιλαμβάνουν τα ακόλουθα χαρακτηριστικά:
Οι περισσότερες δοκιμές προετοιμάζονται στη φόρμα που έχει σχεδιαστεί για τον χρήστη.
Σε πολλές περιπτώσεις, ένας σχετικά μικρός προγραμματισμός εντοπισμού σφαλμάτων (προσομοιωτές μονάδων είναι συνήθως αρκετά απλός και ο καθένας είναι κατάλληλος για μεγάλο αριθμό, συχνά - για όλους, δοκιμές).
Δεν χρειάζεται να ελέγξετε τη σύζευξη της μονάδας.
Το μειονέκτημα της δοκιμής προς τα κάτω είναι ότι η κατάσταση δοκιμής του μέσου πληροφοριών προετοιμάζει έμμεση πριν αναφερθεί στη μονάδα μίας χρήσης - είναι το αποτέλεσμα της χρήσης των ήδη στροφικών μονάδων για τη δοκιμή δεδομένων ή δεδομένων που εκδίδονται από προσομοιωτές. Αυτό, καταρχάς, καθιστά δύσκολη την προετοιμασία των δοκιμών, απαιτεί υψηλά προσόντα της δοκιμής δοκιμών και, δεύτερον, καθιστά δύσκολη ή ακόμη και αδύνατη την εφαρμογή του πλήρους σχεδίου δοκιμής για τη δρομολογήσιμη μονάδα. Αυτό το μειονέκτημα μερικές φορές αναγκάζει τους προγραμματιστές να εφαρμόζουν αύξουσα δοκιμή ακόμη και σε περίπτωση ανάπτυξης προς τα κάτω. Ωστόσο, ορισμένες τροποποιήσεις των δοκιμών προς τα κάτω χρησιμοποιούνται συχνότερα ή ορισμένοι φθίνουσες και ανάντη συνδυασμό.
Με βάση το γεγονός ότι η δοκιμή προς τα κάτω, κατ 'αρχήν, προτιμάται, θα σταματήσουμε στις δεξιώσεις που σας επιτρέπουν να ξεπεράσετε αυτές τις δυσκολίες σε κάποιο βαθμό. Πρώτα απ 'όλα, είναι απαραίτητο να οργανωθεί η αποσφάλιση του προγράμματος με τέτοιο τρόπο ώστε οι ενότητες που να ασκούν τα δεδομένα μπορούν να αποσυρθούν - τότε τα δεδομένα δοκιμής μπορούν να παρασκευαστούν στη φόρμα που έχει σχεδιαστεί για τον χρήστη, το οποίο θα απλοποιήσει σημαντικά την προετοιμασία των επόμενων δοκιμές. Όχι πάντα, αυτή η είσοδος πραγματοποιείται στη μονάδα κεφαλής, επομένως, είναι απαραίτητο να διορθωθούν οι αλυσίδες των ενοτήτων που οδηγούν σε μονάδες που θα εφαρμόζουν την καθορισμένη είσοδο (CP. Με μια μέθοδο στοχευμένη εποικοδομητική εφαρμογή σε διαλέξεις 7). Ενώ οι ενότητες που εκτελούν καταχώρηση δεδομένων δεν εντοπίζονται, τα δεδομένα δοκιμών παρέχονται από ορισμένους προσομοιωτές: είτε περιλαμβάνονται στον προσομοιωτή ως μέρος του είτε εισάγονται από αυτόν τον προσομοιωτή.
Με μια δοκιμή κατερχόμενης ζεύξης, κάποια από την κατάσταση του περιβάλλοντος πληροφοριών στο οποίο θέλετε να ελέγξετε τη δομοστοιχειωμένη μονάδα εντοπισμού ενδέχεται να μην συμβεί όταν το πρόγραμμα πληρούται από οποιαδήποτε είσοδο. Σε αυτές τις περιπτώσεις, θα ήταν δυνατό να δοκιμαστεί καθόλου η δομοστοιχειωμένη μονάδα, καθώς οι ανιχνευτές σφαλμάτων δεν θα εκδηλωθούν κατά την εκτέλεση του προγράμματος που απορρίπτονται σε οποιαδήποτε είσοδο. Ωστόσο, δεν συνιστάται να το πράξει, δεδομένου ότι κατά την αλλαγή του προγράμματος στροφώθηκε (για παράδειγμα, όταν συνοδεύεται από PS), που δεν χρησιμοποιείται για τη δοκιμή της ισορροπημένης ενότητας του περιβάλλοντος πληροφοριών μπορεί να προκύψει ήδη, η οποία απαιτεί πρόσθετες δοκιμές αυτής της ενότητας ( Και αυτό, με μια ορθολογική θέση, θα ήταν δυνατόν να γίνει εάν η ίδια η ενότητα δεν έχει αλλάξει). Για να ελέγξετε τη συσκευή που απορρίπτεται σε αυτές τις καταστάσεις, οι κατάλληλοι προσομοιωτές χρησιμοποιούν μερικές φορές για να δημιουργήσουν την επιθυμητή κατάσταση του περιβάλλοντος πληροφοριών. Πιο συχνά χρησιμοποιούν μια τροποποιημένη κατεβαίνουσα επιλογή δοκιμής, στην οποία οι εντοπισμένες μονάδες έχουν προηγουμένως δοκιμαστεί ξεχωριστά (στην περίπτωση αυτή, μια κορυφαία μονάδα εντοπισμού σφαλμάτων περιβάλλεται από μια μονάδα εντοπισμού σφαλμάτων, μαζί με τους προσομοιωτές της μονάδας στις οποίες μπορεί να εμφανιστεί μια μονάδα εντοπισμού σφαλμάτων). Ωστόσο, φαίνεται ότι μια πιο κατάλληλη άλλη τροποποίηση της δοκιμής προς τα κάτω: μετά την ολοκλήρωση της δοκιμής προς τα κάτω της λειτουργίας της εντοπίσσεως, θα πρέπει να δοκιμάζεται χωριστά για τις εφικτές δοκιμαστικών κρατών του περιβάλλοντος πληροφοριών για τα υπόλοιπα απαιτούμενα κράτη του πληροφοριακού περιβάλλοντος.
Χρησιμοποιείται επίσης ένας συνδυασμός ανύψωσης και προς τα κάτω, η οποία ονομάζεται μέθοδος σάντουιτς. Η ουσία αυτής της μεθόδου είναι η ταυτόχρονη εφαρμογή των δοκιμών αύξουσα και προς τα κάτω, μέχρι στιγμής αυτές οι δύο διαδικασίες δοκιμών θα ικανοποιηθούν από οποιαδήποτε ενότητα κάπου στη μέση της δομής του προγράμματος που καταγράφεται. Αυτή η μέθοδος επιτρέπει, με μια λογική προσέγγιση, να επωφεληθείτε από τα πλεονεκτήματα τόσο της ανόδου όσο και της προς τα κάτω δοκιμή και να εξουδετερώσουν σε μεγάλο βαθμό τα μειονεκτήματα τους. Το αποτέλεσμα αυτό είναι μια εκδήλωση μιας γενικότερης αρχής: το μεγαλύτερο τεχνολογικό αποτέλεσμα μπορεί να επιτευχθεί συνδυάζοντας μεθόδους προς τα κάτω και προς τα πάνω για την ανάπτυξη προγραμμάτων PS. Είναι για την υποστήριξη αυτής της μεθόδου ότι μια αρχιτεκτονική προσέγγιση για την ανάπτυξη προγραμμάτων (βλέπε διάλεξη 7): ένα στρώμα εξειδικευμένων και προσεκτικά δοκιμασμένων μονάδων διευκολύνει σημαντικά την εφαρμογή της οικογένειας των προγραμμάτων στο σχετικό τομέα και το επόμενο επίπεδο εκσυγχρονισμός.
Πολύ σημαντική στην αυτόνομη εντοπισμός σφαλμάτων είναι η δοκιμή συνδυασμού ενότητας. Το γεγονός είναι ότι οι προδιαγραφές κάθε μονάδας προγράμματος, εκτός από το κεφάλι, χρησιμοποιούνται σε αυτό το πρόγραμμα σε δύο καταστάσεις: πρώτα, κατά την ανάπτυξη κειμένου (μερικές φορές λένε: το σώμα) αυτής της ενότητας και, δεύτερον, όταν γράφουν μια έκκληση Αυτή η ενότητα σε άλλες μονάδες προγραμματισμού. Και σε αυτό, σε μια άλλη περίπτωση, ως αποτέλεσμα σφάλματος, η απαιτούμενη συμμόρφωση της καθορισμένης προδιαγραφής της μονάδας μπορεί να σπάσει. Τέτοια σφάλματα απαιτούνται για την ανίχνευση και την εξάλειψη. Για να το κάνετε αυτό, δοκιμάζοντας τις διεπαφές μονάδας. Με τη δοκιμή προς τα κάτω, η δοκιμή της σύζευξης διεξάγεται σε ένα πέρασμα μέσω κάθε μεταδιδόμενης δοκιμής, το οποίο θεωρείται το μεγαλύτερο πλεονέκτημα της δοκιμής προς τα κάτω. Κατά την αύξηση της δοκιμής, η πρόσβαση στην εντοπισμένη μονάδα εντοπισμού σφαλμάτων δεν γίνεται από τις ενότητες του προγράμματος που απορρίπτονται, αλλά από τη μονάδα ελέγχου Debug. Από την άποψη αυτή, υπάρχει ο κίνδυνος να προσαρμοστεί η τελευταία ενότητα σε ορισμένες "αυταπάτες" της εντοπίστηκαν δομοστοιχεία. Επομένως, η εκκίνηση (κατά τη διάρκεια της ολοκλήρωσης του προγράμματος), για να εντοπίσει εντοπισμό μιας νέας ενότητας, πρέπει να δοκιμάσετε κάθε έκκληση με την προηγουμένως στροφική μονάδα προκειμένου να ανιχνεύσετε την ασυνέπεια αυτής της θεραπείας με το σώμα της αντίστοιχης μονάδας (και είναι δυνατόν ότι η μη προσαρμοσμένη μονάδα είναι φταίξιμο. Έτσι, είναι απαραίτητο να επαναληφθούν εν μέρει στις νέες συνθήκες για τη δοκιμή της μονάδας που προβάλλεται προηγουμένως, ενώ οι ίδιες δυσκολίες προκύπτουν όπως και στις δοκιμές προς τα κάτω.
Αυτόνομη δοκιμή ενότητας συνιστάται να πραγματοποιηθεί σε τέσσερα σταθερά εκτελούμενα βήματα.
Βήμα 1. Με βάση τις προδιαγραφές του Τμήματος της Ενότητας, προετοιμάστε δοκιμή για κάθε δυνατότητα και κάθε κατάσταση, για κάθε περίγραμμα της περιοχής επιτρεπόμενων τιμών όλων των δεδομένων εισόδου, για κάθε περιοχή αλλαγής δεδομένων, Για κάθε περιοχή μη έγκυρων τιμών όλων των δεδομένων εισόδου και κάθε μη έγκυρη κατάσταση.
Βήμα 2. Ελέγξτε το κείμενο της μονάδας για να βεβαιωθείτε ότι κάθε κατεύθυνση οποιουδήποτε διακλάδωσης θα ολοκληρωθεί τουλάχιστον μία δοκιμή. Προσθέστε τις δοκιμές που λείπουν.
Βήμα 3. Βεβαιωθείτε ότι το κείμενο της μονάδας είναι ότι για κάθε κύκλο υπάρχει μια δοκιμή για την οποία το σώμα του κύκλου δεν εκτελείται, η δοκιμή για την οποία εκτελείται το σώμα του κύκλου μία φορά και η δοκιμή για την οποία το σώμα του κύκλου είναι το μέγιστο για το οποίο το σώμα του κύκλου είναι το μέγιστο τον μέγιστο αριθμό. Προσθέστε τις δοκιμές που λείπουν.
Βήμα 4. Βεβαιωθείτε ότι το κείμενο της ενότητας έχει την ευαισθησία του στις επιμέρους ειδικές τιμές εισόδου - όλες αυτές οι τιμές πρέπει να περιλαμβάνονται στις δοκιμές. Προσθέστε τις δοκιμές που λείπουν.
10.5. Περιεκτικό λογισμικό εντοπισμού σφαλμάτων.
Όπως αναφέρθηκε παραπάνω, το PS στο σύνολό του δοκιμάζεται κάτω από το περίπλοκο εντοπισμό σφαλμάτων και οι δοκιμές προετοιμάζονται για κάθε ένα από τα έγγραφα PS. Η δοκιμή αυτών των εγγράφων γίνεται συνήθως, κατά κανόνα, προκειμένου να αναπτυχθούν (η εξαίρεση δοκιμάζει μόνο την τεκμηρίωση της αίτησης, η οποία αναπτύσσεται από την εξωτερική περιγραφή παράλληλα με την ανάπτυξη κειμένων κειμένου. Αυτή η δοκιμή είναι καλύτερη να παράγει μετά την παραγωγή μετά την παραγωγή ολοκληρώνοντας τη δοκιμή της εξωτερικής περιγραφής). Ολοκληρωμένος έλεγχος εντοπισμού σφαλμάτων είναι η χρήση του PS σε συγκεκριμένα δεδομένα, η οποία μπορεί κατ 'αρχήν να συμβεί από τον χρήστη (ειδικότερα, όλες οι δοκιμές παρασκευάζονται στη φόρμα που σχεδιάστηκαν για τον χρήστη), αλλά μπορεί να είναι στο προσομοιωμένο (και όχι πραγματικό) περιβάλλον. Για παράδειγμα, ορισμένες απρόσιτες συσκευές εισόδου και εξόδου στο περίπλοκο εντοπισμό εντοπισμού μπορούν να αντικατασταθούν από τους προσομοιωτές λογισμικού τους.
Δοκιμάζοντας την αρχιτεκτονική του PS. Ο σκοπός της δοκιμής είναι η αναζήτηση ασυνεπειών μεταξύ της περιγραφής της αρχιτεκτονικής και του συνόλου των προγραμμάτων PS. Μέχρι την αρχή της δοκιμής της αρχιτεκτονικής PS, θα πρέπει να ολοκληρωθεί μια αυτόνομη εντοπισμός εντοπισμού κάθε υποσυστήματος. Τα σφάλματα της εφαρμογής της αρχιτεκτονικής μπορούν να συνδεθούν κυρίως με την αλληλεπίδραση αυτών των υποσυστημάτων, ειδικότερα, με την εφαρμογή αρχιτεκτονικών λειτουργιών (εάν υπάρχουν). Ως εκ τούτου, θα ήθελα να ελέγξω όλους τους τρόπους αλληλεπίδρασης μεταξύ υποσυστημάτων PS. Αλλά επειδή μπορεί να είναι πάρα πολύ, θα ήταν επιθυμητό να δοκιμαστεί τουλάχιστον όλες οι αλυσίδες των υποσυστημάτων χωρίς να εισέλθουν ξανά στην τελευταία. Εάν η συγκεκριμένη αρχιτεκτονική αντιπροσωπεύει το PS ως ένα μικρό σύστημα από τα ειδικά υποσυστήματα, ο αριθμός αυτών των αλυσίδων θα χαλαρώσει.
Δοκιμές εξωτερικών λειτουργιών. Ο σκοπός της δοκιμής είναι η αναζήτηση αποκλίσεων μεταξύ της λειτουργικής προδιαγραφής και του συνόλου προγραμμάτων PS. Παρά το γεγονός ότι όλα αυτά τα προγράμματα είναι αυτόνομα ήδη αποσυνδεδεμένα, αυτές οι αποκλίσεις μπορούν να είναι, για παράδειγμα, λόγω της ασυνέπειας των εσωτερικών προδιαγραφών των προγραμμάτων και των ενοτήτων τους (με βάση τις οποίες οι αυτόνομες λειτουργικές λεπτομέρειες) Το PS πραγματοποιήθηκε. Κατά κανόνα, η δοκιμή εξωτερικών λειτουργιών εκτελείται με τον ίδιο τρόπο όπως με τις μονάδες ελέγχου στο πρώτο βήμα, δηλ. Όπως ένα μαύρο κουτί.
Δοκιμή ποιότητας PS. Ο σκοπός της δοκιμής είναι η αναζήτηση παραβιάσεων των απαιτήσεων ποιότητας που διατυπώνονται σε προδιαγραφές ποιότητας PS. Αυτός είναι ο πιο δύσκολος και λιγότερο μελετημένος τύπος δοκιμών. Είναι σαφές ότι δεν μπορεί να δοκιμαστεί κάθε πρωτόγονη ποιότητα του PS με δοκιμές (στην αξιολόγηση της ποιότητας του PS, βλέπε την ακόλουθη διάλεξη). Η ολοκλήρωση του PS ελέγχεται ήδη κατά τη δοκιμή εξωτερικών λειτουργιών. Σε αυτό το στάδιο, η δοκιμή αυτού του πρωτόγονου ποιότητας μπορεί να συνεχιστεί εάν απαιτείται να λάβει τυχόν πιθανοτική αξιολόγηση του βαθμού αξιοπιστίας του PS. Ωστόσο, η μέθοδος τέτοιων δοκιμών εξακολουθεί να απαιτεί την ανάπτυξή της. Ακρίβεια, σταθερότητα, ασφάλεια, χρονική αποτελεσματικότητα, σε κάποιο βαθμό - αποδοτικότητα μνήμης, αποδοτικότητα σε συσκευές, επεκταθεσιμότητα και εν μέρει, ανεξαρτησία από συσκευές. Κάθε ένας από αυτούς τους τύπους δοκιμών έχει τις δικές της ιδιαιτερότητες και αξίζει ξεχωριστή εξέταση. Μπορούμε να περιορίζουμε μόνο στη μεταφορά τους. Η ευκολία χρήσης του PS (κριτήριο ποιότητας, ο οποίος περιλαμβάνει πολλά ποιοτικά πρωτόγονα, βλέπε διάλεξη 4) αξιολογείται κατά τη δοκιμή της τεκμηρίωσης για τη χρήση του PS.
Έλεγχος τεκμηρίωσης για τη χρήση του PS. Ο σκοπός της δοκιμής είναι να βρεθεί η ασυνέπεια της τεκμηρίωσης για την εφαρμογή και ένα σύνολο προγραμμάτων PS, καθώς και την ταλαιπωρία της χρήσης του PS. Αυτό το στάδιο προηγείται άμεσα από τη σύνδεση του χρήστη με την ολοκλήρωση της ανάπτυξης PS (δοκιμή των απαιτήσεων για την πιστοποίηση PS και PS), οπότε είναι πολύ σημαντικό οι προγραμματιστές να χρησιμοποιήσουν τα ίδιες το PS όπως θα γίνει. Όλες οι δοκιμές σε αυτό το στάδιο προετοιμάζονται αποκλειστικά με βάση μόνο την τεκμηρίωση για τη χρήση του PS. Πρώτα απ 'όλα, οι δυνατότητες του PS πρέπει να δοκιμάζονται κατά τη δοκιμή εξωτερικών λειτουργιών, αλλά μόνο με βάση την τεκμηρίωση για χρήση. Όλοι οι ασαφείς θέσεις στην τεκμηρίωση πρέπει να δοκιμάζονται, καθώς και όλα τα παραδείγματα που χρησιμοποιούνται στην τεκμηρίωση. Περαιτέρω, οι πιο δύσκολες περιπτώσεις εφαρμογής του PS δοκιμάζονται προκειμένου να ανιχνευθεί παραβίαση της σχετικότητας της ευκολίας χρήσης του PS.
Δοκιμάζοντας τον ορισμό των απαιτήσεων PS. Ο σκοπός της δοκιμής είναι ο προσδιορισμός του βαθμού στον οποίο το PS δεν αντιστοιχεί στον προσδιορισμό των απαιτήσεων για αυτό. Η ιδιαιτερότητα αυτού του είδους δοκιμής είναι ότι πραγματοποιείται από οργανισμό αγοραστή ή οργανισμό PS ως έναν από τους τρόπους για να ξεπεραστεί το εμπόδιο μεταξύ του προγραμματιστή και του χρήστη (βλ. Διάλεξη 3). Τυπικά, αυτή η δοκιμή εκτελείται χρησιμοποιώντας εργασίες ελέγχου - τυπικές εργασίες για τις οποίες είναι γνωστό το αποτέλεσμα του αποτελέσματος. Σε περιπτώσεις όπου το PS που αναπτύχθηκε θα πρέπει να έρθει να αντικαταστήσει μια άλλη παραλλαγή PS, η οποία επιλύει τουλάχιστον ένα μέρος των καθηκόντων του αναπτυγμένου PS, η δοκιμή πραγματοποιείται με την επίλυση κοινών καθηκόντων χρησιμοποιώντας τόσο τα παλιά όσο και τα νέα PS, με την επακόλουθη σύγκριση των αποτελεσμάτων λαμβάνεται. Μερικές φορές η μορφή τέτοιων δοκιμών χρησιμοποιεί την πιλοτική λειτουργία του PS - η περιορισμένη εφαρμογή του νέου PS με ανάλυση της χρήσης των αποτελεσμάτων στην πρακτική δραστηριότητα. Στην ουσία, αυτός ο τύπος δοκιμών περιγράφεται σε μεγάλο βαθμό με τη δοκιμή του PS στην πιστοποίησή του (βλέπε διάλεξη 14), αλλά εκτελείται πριν από την πιστοποίηση και μερικές φορές αντί της πιστοποίησης.
Λογοτεχνία για τη διάλεξη 10.
10.1. Myers. Αξιοπιστία λογισμικού. - m.: Mir, 1980. - Σελ. 171-262.
10.2. Δ. Van Tassel. Στυλ, ανάπτυξη, αποτελεσματικότητα, debugging και δοκιμαστικά προγράμματα. - M.: MIR, 1985. - Σελ. 179-295.
10.3. J. Hughes, J. Micht. Διαρθρωτική προσέγγιση στον προγραμματισμό. - M.: MIR, 1980. - Σ. 254-268.
10.4. J. Fox. Λογισμικό και την ανάπτυξή του. - M.: MIR, 1985. - Σ. 227-241.
10.5. Μ. Zelkovitz, Α. Show, J. Gannon. Αρχές ανάπτυξης λογισμικού. - M.: MIR, 1982. - Σ. 105-116.
10.6. Yu.m. Bezborodov. Ατομικά προγράμματα εντοπισμού σφαλμάτων. - M.: Science, 1982. - Σ. 9-79.
10.7. V.v. Lipaev. Προγράμματα δοκιμών. - Μ.: Ραδιόφωνο και επικοινωνία, 1986. - Σελ. 15-47.
10.8. Ε.Α. Zhogolev. Εισαγωγή στην τεχνολογία προγραμματισμού (ικανότητα διάλεξης). - m.: Διαλόγου-MSU, 1994.
10.9. Ε. DYACSTRA. Δομικές σημειώσεις προγραμματισμού. // y. Dal, Ε. Dyacstra, Κ. Khor. Δομικός προγραμματισμός. - m.: Mir, 1975. - Σ. 7-13.
Διάλεξη 11. Διασφάλιση της λειτουργικότητας και της αξιοπιστίας του λογισμικού
11.1. Λειτουργικότητα και αξιοπιστία ως υποχρεωτικά κριτήρια ποιότητας λογισμικού.
Στην προηγούμενη διάλεξη, εξετάσαμε όλα τα στάδια της ανάπτυξης του PS, εκτός από την πιστοποίησή του. Ταυτόχρονα, δεν αφορούσαμε τις ερωτήσεις ποιότητας ποιότητας σύμφωνα με τις προδιαγραφές της ποιότητας (βλ. Διάλεξη 4). Είναι αλήθεια, υπό την εφαρμογή της λειτουργικής προδιαγραφής του PS, συζητήσαμε έτσι τα βασικά ζητήματα της εξασφάλισης του κριτηρίου της λειτουργικότητας. Έχοντας δηλώσει την αξιοπιστία του κύριου χαρακτηριστικού PS (βλ. Διάλεξη 1), επιλέξαμε την πρόληψη σφαλμάτων ως την κύρια προσέγγιση για να εξασφαλίσουμε την αξιοπιστία του PS (βλέπε διάλεξη 3) και συζήτησε την υλοποίησή του σε διαφορετικά στάδια της ανάπτυξης PS. Έτσι, η διατριβή εκδηλώθηκε με την υποχρέωση της λειτουργικότητας και της αξιοπιστίας του PS ως κριτήρια για την ποιότητά του.
Ωστόσο, στις προδιαγραφές της ποιότητας του PS, ενδέχεται να υπάρχουν πρόσθετα χαρακτηριστικά αυτών των κριτηρίων, η παροχή της οποίας απαιτεί μια ειδική συζήτηση. Αυτές οι διαλέξεις είναι αφιερωμένες σε αυτά τα θέματα. Η εξασφάλιση άλλων κριτηρίων ποιότητας θα συζητηθεί στην επόμενη διάλεξη.
Παρακάτω συζητούνται στην παροχή πρωτοτύπων της ποιότητας PS που εκφράζει τα κριτήρια της λειτουργικότητας και της αξιοπιστίας του PS.
11.2. Εξασφαλίζοντας την πληρότητα του λογισμικού.
Η ολοκλήρωση του PS είναι μια κοινή πρωτόγονη ποιότητα του PS για την έκφραση και τη λειτουργικότητα και την αξιοπιστία του PS και για τη λειτουργικότητα είναι η μόνη πρωτόγονη (βλέπε διάλεξη 4).
Η λειτουργικότητα του PS καθορίζεται από τις λειτουργικές του προδιαγραφές. Η ολοκλήρωση του PS ως πρωτόγονος της ποιότητας του είναι ένα μέτρο για το πόσο εφαρμόζεται αυτή η προδιαγραφή σε αυτό το PS. Η εξασφάλιση αυτού του πρωτόγονα εν μέρει σημαίνει την εφαρμογή καθενός από τις λειτουργίες που ορίζονται στη λειτουργική προδιαγραφή, με όλες τις λεπτομέρειες και τις λειτουργίες που υποδεικνύονται εκεί. Όλες οι τεχνολογικές διαδικασίες που συζητήθηκαν προηγουμένως δείχνουν πώς μπορεί να γίνει.
Ωστόσο, στην προδιαγραφή ποιότητας PS, μπορούν να οριστούν διάφορα επίπεδα εφαρμογής της λειτουργικότητας PS: μπορεί να οριστεί κάποια απλοποιημένη (αρχική ή εκκίνηση) έκδοση, η οποία πρέπει επίσης να εφαρμοστεί, μπορούν επίσης να εντοπιστούν αρκετές ενδιάμεσες εκδόσεις. Στην περίπτωση αυτή, προκύπτει ένα πρόσθετο τεχνολογικό πρόβλημα: η οργάνωση της αύξησης της λειτουργικότητας του PS. Είναι σημαντικό να σημειωθεί ότι η ανάπτυξη μιας απλοποιημένης έκδοσης του PS δεν είναι η ανάπτυξη του πρωτοτύπου της. Το πρωτότυπο έχει σχεδιαστεί για να κατανοήσει καλύτερα τις προϋποθέσεις εφαρμογής του μελλοντικού PS, διευκρινίζει την εξωτερική του περιγραφή. Είναι σχεδιασμένο για επιλεγμένους χρήστες και ως εκ τούτου μπορεί να είναι πολύ διαφορετική από την απαιτούμενη PS όχι μόνο από τις λειτουργίες που εκτελούνται, αλλά και τα χαρακτηριστικά της διεπαφής χρήστη. Η απλοποιημένη έκδοση του απαιτούμενου PS πρέπει να υπολογιστεί για σχεδόν χρήσιμη χρήση από όλους τους χρήστες για τους οποίους προορίζεται. Ως εκ τούτου, η κύρια αρχή της εξασφάλισης της λειτουργικότητας ενός τέτοιου τύπου PS είναι η ανάπτυξη του PS από την αρχή, σαν να απαιτείται πλήρως το PS, μέχρι οι προγραμματιστές να ασχοληθούν με αυτά τα μέρη ή τμήματα του PS, την εφαρμογή του οποίου μπορεί να αναβληθούν σύμφωνα με τις προδιαγραφές της ποιότητας του. Έτσι, η εξωτερική περιγραφή και η περιγραφή της αρχιτεκτονικής PS πρέπει να αναπτυχθεί πλήρως. Μπορείτε να αναβάλλετε την εφαρμογή αυτών των υποσυστημάτων του προγράμματος που ορίζονται στην αρχιτεκτονική του PS που αναπτύχθηκε, η λειτουργία του οποίου δεν απαιτείται στην αρχική έκδοση αυτού του PS. Η εφαρμογή των ίδιων των υποσυστημάτων του προγράμματος γίνεται καλύτερα με τη μέθοδο της στοχοθετημένης εποικοδομητικής εφαρμογής, αφήνοντας τους κατάλληλους προσομοιωτές αυτών των μονάδων λογισμικού στην αρχική έκδοση του PS, η λειτουργία της οποίας δεν απαιτείται σε αυτή την έκδοση. Απλοποιημένη εφαρμογή ορισμένων μονάδων λογισμικού επιτρέπεται επίσης, μειώνοντας την εφαρμογή ορισμένων τμημάτων των αντίστοιχων λειτουργιών. Ωστόσο, τέτοιες ενότητες από τεχνολογική άποψη είναι καλύτερα να θεωρηθούν ως περίεργοι μιμητές (αν και πολύ προχωρημένοι).
Λόγω των σφαλμάτων στα ανεπτυγμένα PS, η ολοκλήρωση που επιτυγχάνεται κατά την παροχή της λειτουργικότητάς της (σύμφωνα με τις προδιαγραφές της ποιότητάς του) μπορεί πράγματι να μην αναμένεται. Είναι δυνατόν να πούμε μόνο ότι αυτή η ολοκλήρωση επιτυγχάνεται με κάποια πιθανότητα που καθορίζεται από τον όγκο και την ποιότητα των δοκιμών. Προκειμένου να αυξηθεί αυτή η πιθανότητα, είναι απαραίτητο να συνεχιστούν οι δοκιμές και η εντοπισμός σφαλμάτων PS. Ωστόσο, η αξιολόγηση αυτής της πιθανότητας είναι μια πολύ συγκεκριμένη εργασία (δεδομένου ότι η εκδήλωση του διαθέσιμου σφάλματος στο PS είναι η λειτουργία των δεδομένων προέλευσης), η οποία εξακολουθεί να περιμένει σχετικές θεωρητικές μελέτες.
11.3. Παρέχοντας ακρίβεια του λογισμικού.
Η διασφάλιση αυτού του πρωτόγονα συσχετίζεται με τις δράσεις στις αξίες των πραγματικών τύπων (με μεγαλύτερη ακρίβεια, με τις τιμές που υποβάλλονται σε κάποιο σφάλμα). Παρέχετε την απαιτούμενη ακρίβεια κατά τον υπολογισμό της αξίας μιας λειτουργίας ή άλλου - σημαίνει να πάρετε αυτή την τιμή με ένα σφάλμα που δεν υπερβαίνει τα καθορισμένα όρια. Οι τύποι σφάλματος, οι μέθοδοι αξιολόγησης και οι μέθοδοι επίτευξης της απαιτούμενης ακρίβειας (αποκαλούμενοι κατά προσέγγιση υπολογισμοί) ασχολούνται με τα υπολογιστικά μαθηματικά. Εδώ θα δώσουμε προσοχή μόνο σε κάποια δομή σφάλματος: το σφάλμα της υπολογιζόμενης τιμής (πλήρες σφάλμα) εξαρτάται
από το σφάλμα της χρησιμοποιούμενης μεθόδου υπολογισμού (στην οποία συμπεριλαμβάνουμε και την ανακρίβεια του χρησιμοποιούμενου μοντέλου),
από το σφάλμα της παρουσίασης των χρησιμοποιούμενων δεδομένων (από το λεγόμενο παράλογο σφάλμα),
Από το σφάλμα στρογγυλοποίησης (ανακρίβεια της εκτέλεσης των λειτουργιών που χρησιμοποιούνται στη μέθοδο).
11.4. Εξασφαλίζοντας την αυτονομία του λογισμικού.
Αυτή η πρωτόγονη ποιότητα εξασφαλίζεται στο στάδιο της προδιαγραφής ποιότητας από τη λύση λήψης αποφάσεων στο ανεπτυγμένο PS οποιουδήποτε κατάλληλου βασικού λογισμικού ή δεν χρησιμοποιεί οποιοδήποτε βασικό λογισμικό σε αυτό. Ταυτόχρονα, είναι απαραίτητο να ληφθεί υπόψη τόσο η αξιοπιστία όσο και οι πόροι που απαιτούνται για τη χρήση της. Με βελτιωμένες απαιτήσεις για την αξιοπιστία του ανεπτυγμένου PS, η αξιοπιστία του βασικού λογισμικού που είναι διαθέσιμη στους προγραμματιστές μπορεί να μην είναι ικανοποιητική, επομένως είναι απαραίτητο να αρνηθεί η χρήση της και η υλοποίηση των λειτουργιών της στον απαιτούμενο όγκο πρέπει να συμπεριλάβει στο ΥΣΤΕΡΟΓΡΑΦΟ. Παρόμοιες αποφάσεις πρέπει να λαμβάνονται με άκαμπτους περιορισμούς στους χρησιμοποιούμενους πόρους (με το κριτήριο της αποτελεσματικότητας του PS).
11.5. Παρέχοντας βιωσιμότητα λογισμικού.
Αυτή η ποιότητα πρωτόγονος εξασφαλίζεται χρησιμοποιώντας τον λεγόμενο προστατευτικό προγραμματισμό. Σε γενικές γραμμές, ο προγραμματισμός προστασίας χρησιμοποιείται για την αύξηση της αξιοπιστίας του PS κατά τον προγραμματισμό της μονάδας με ευρύτερη έννοια. Σύμφωνα με τους Myers, ο "προστατευτικός προγραμματισμός βασίζεται σε μια σημαντική προϋπόθεση: το χειρότερο πράγμα που μπορεί να κάνει η ενότητα είναι να δεχτεί εσφαλμένα δεδομένα εισόδου και στη συνέχεια να επιστρέψει το λάθος, αλλά εύλογο αποτέλεσμα". Προκειμένου να αποφευχθεί αυτό, το κείμενο της ενότητας περιλαμβάνει τον έλεγχο των δεδομένων εισόδου και εξόδου στην ορθότητα τους σύμφωνα με τις προδιαγραφές αυτής της ενότητας, ιδίως τους περιορισμούς στα δεδομένα εισόδου και εξόδου και τη σχέση μεταξύ τους, που καθορίζονται στο Πρέπει να ελεγχθεί η προδιαγραφή των μονάδων. Στην περίπτωση αρνητικού αποτελέσματος δοκιμής, είναι ενθουσιασμένη η κατάλληλη εξαίρεση. Από την άποψη αυτή, το τέλος αυτής της ενότητας περιλαμβάνει θραύσματα του δεύτερου τύπου - χειριστές κατάλληλων εξαιρετικών καταστάσεων, οι οποίες εκτός από την έκδοση των απαραίτητων διαγνωστικών πληροφοριών, μπορούν να αναλάβουν δράση ή να αποκλείσουν ένα σφάλμα στα δεδομένα (για παράδειγμα, να απαιτούν την επανένταξή τους - ή να αποδυναμώσετε την επιρροή σφάλματος (για παράδειγμα, μια μαλακή στάση των διαχειριζόμενων συσκευών PS, προκειμένου να αποφευχθεί η κατανομή τους όταν τερματίζεται έκτακτης ανάγκης του προγράμματος).
Η εφαρμογή προστατευτικού προγραμματισμού των ενοτήτων οδηγεί σε μείωση της αποτελεσματικότητας του PS τόσο στο χρόνο όσο και της μνήμης. Ως εκ τούτου, είναι λογικό να ρυθμιστεί εύλογα ο βαθμός προστασίας του προστατευτικού προγραμματισμού, ανάλογα με τις απαιτήσεις για την αξιοπιστία και την αποτελεσματικότητα του PS, που διατυπώνονται με την προδιαγραφή ποιότητας των ανεπτυγμένων PS. Η είσοδος της αναπτυγμένης μονάδας μπορεί να λειτουργήσει ως απευθείας από τον χρήστη και από άλλες μονάδες. Η πιο κοινή ευκαιρία της εφαρμογής του προστατευτικού προγραμματισμού είναι η χρήση της για την πρώτη ομάδα δεδομένων, πράγμα που σημαίνει την εφαρμογή της βιωσιμότητας του PS. Είναι πάντοτε απαραίτητο να γίνει αυτό όταν η προδιαγραφή ποιότητας PS έχει απαίτηση να εξασφαλίσει τη βιωσιμότητα του PS. Η χρήση προστατευτικού προγραμματισμού για τη δεύτερη ομάδα εισόδου σημαίνει μια προσπάθεια ανίχνευσης ενός σφάλματος σε άλλες μονάδες κατά την ανάπτυξη της ανάπτυξης της μονάδας και για την ανάπτυξη της ανάπτυξης της μονάδας - μια προσπάθεια ανίχνευσης σφάλματος σε αυτήν την ίδια τη μονάδα κατά τη διάρκεια της ίδιας την εκτέλεση του. Στην ουσία, αυτό σημαίνει μια μερική ενσάρκωση μιας αντίθετης προσέγγισης αυτο-δαπάνης για τη διασφάλιση της αξιοπιστίας του PS, η οποία συζητήθηκε σε διαλέξεις 3. Αυτή η περίπτωση προστασίας του προγραμματισμού είναι εξαιρετικά σπάνια εφαρμοζόμενη - μόνο όταν οι απαιτήσεις για την αξιοπιστία PS είναι εξαιρετικά υψηλή .
11.6. Παρέχοντας ασφάλεια λογισμικού.
Διακρίνοντας τους ακόλουθους τύπους προστασίας PS από τη στρέβλωση των πληροφοριών:
προστασία από αποτυχίες εξοπλισμού ·
Προστασία από την επίδραση του "ξένου" προγράμματος ·
Προστασία από αρνήσεις του "προγράμματος" της ",
Προστασία από λάθη χειριστή (χρήστης).
προστασία από μη εξουσιοδοτημένη πρόσβαση ·
Προστασία από την προστασία.
Η προστασία από τις αποτυχίες του εξοπλισμού δεν είναι επί του παρόντος μια πολύ τοπική εργασία (συμπεριλαμβανομένου του επιπέδου των υπολογιστών που επιτυγχάνονται). Αλλά εξακολουθεί να είναι χρήσιμο να γνωρίζουμε την απόφασή της. Αυτό εξασφαλίζεται από την οργάνωση των λεγόμενων "διπλών τριπλών λανθασμάτων". Για το λόγο αυτό, ολόκληρη η διαδικασία επεξεργασίας δεδομένων, που ορίζεται από το PS, χωρίζεται σε χρόνο σε χρονικά διαστήματα των αποκαλούμενων "σημείων αναφοράς". Το μήκος αυτού του διαστήματος δεν πρέπει να υπερβαίνει το μισό μέσο όρο της λειτουργίας χωρίς προβλήματα του υπολογιστή. Ένα αντίγραφο της κατάστασης της μεταβλητής μνήμης σε αυτή τη διαδικασία κάθε σημείου αναφοράς καταγράφεται στη δευτερεύουσα μνήμη με ένα συγκεκριμένο έλεγχο (ο αριθμός που υπολογίζεται ως κάποια λειτουργία από αυτήν την κατάσταση) στην περίπτωση που υπολογίζεται αυτή η επεξεργασία δεδομένων από την προηγούμενη αναφορά Σηματοδοτήστε αυτό (δηλαδή,. Ένας "λανθασμένος υπολογισμός") γίνεται σωστά (χωρίς αποτυχίες υπολογιστή). Προκειμένου να ανακαλυφθεί, παράγονται δύο τέτοιοι "κακομετακλασμοί". Μετά τον πρώτο "λανθασμένο", υπολογίζεται ο συγκεκριμένος έλεγχος ελέγχου και θυμάται και στη συνέχεια η κατάσταση μνήμης αποκαθίσταται για το προηγούμενο σημείο αναφοράς και το δεύτερο "λανθασμένο" γίνεται ". Μετά το δεύτερο "λανθασμένο δισκίο", υπολογίζεται ο καθορισμένος έλεγχος ελέγχου, ο οποίος στη συνέχεια συγκρίνεται με το ποσό του πρώτου "λανθασμάτων". Εάν αυτά τα δύο ποσά ελέγχου αθροίσματος είναι τα ίδια, ο δεύτερος εσφαλμένος υπολογισμός θεωρείται σωστός, διαφορετικά το άθροισμα ελέγχου του δεύτερου "λανθασμάτων" θυμάται και το τρίτο "λανθασμένο δισκίο" (με προκαταρκτική ανάκτηση της κατάστασης μνήμης για το προηγούμενο σημείο αναφοράς). Εάν το ποσό ελέγχου του τρίτου "λανθασμάτων" συμπίπτει με το άθροισμα ελέγχου ενός από τα δύο δύο "λανθασμένα υπολογισμούς", τότε ο τρίτος εσφαλμένος υπολογισμός θεωρείται σωστός, διαφορετικά απαιτείται μηχανική έλεγχος του υπολογιστή.
Η προστασία από την επίδραση του προγράμματος "Alien" ισχύει κυρίως στα λειτουργικά συστήματα ή προγράμματα που εκτελούν εν μέρει λειτουργίες. Υπάρχουν δύο ποικιλίες αυτής της προστασίας:
Προστασία από αποτυχίες
Προστασία από κακόβουλη επιρροή του "ξένου" προγράμματος.
Όταν μια λειτουργία πολλαπλών υπολογιστών εμφανίζεται στη μνήμη του, μπορεί ταυτόχρονα να βρίσκεται στο στάδιο εκτέλεσης πολλών προγραμμάτων, να λαμβάνει εναλλακτικά τη διαχείριση ως αποτέλεσμα των αναδυόμενων διακοπών (η λεγόμενη οιονεί παράλληλη εκτέλεση του προγράμματος). Ένα από αυτά τα προγράμματα (συνήθως: το λειτουργικό σύστημα) ασχολείται με διακοπή επεξεργασίας και έλεγχο πολυπρογραμματίων. Σε κάθε ένα από αυτά τα προγράμματα, μπορεί να συμβεί αρνήσεις (σφάλματα που εκδηλώνεται), η οποία μπορεί να επηρεάσει την απόδοση των λειτουργιών από άλλα προγράμματα. Ως εκ τούτου, το πρόγραμμα διαχείρισης (λειτουργικό σύστημα) πρέπει να εξασφαλίζει την προστασία του εαυτού του και άλλων προγραμμάτων από μια τέτοια επιρροή. Για να το κάνετε αυτό, ο εξοπλισμός υπολογιστών πρέπει να εφαρμόσει τα ακόλουθα χαρακτηριστικά:
προστασία μνήμης
Δύο τρόποι λειτουργίας υπολογιστών: Προνόμιο και εργασία (χρήστης),
Δύο τύποι λειτουργιών: προνομιούχοι και συνηθισμένοι,
η σωστή εφαρμογή των διακοπών και η αρχική ένταξη του υπολογιστή,
Προσωρινή διακοπή.
Η προστασία της μνήμης σημαίνει τη δυνατότητα να προσδιοριστεί για κάθε πρόγραμμα απρόσιτο για αυτό. Σε προνομιακή λειτουργία, οι λειτουργίες μπορούν να εκτελεστούν (τόσο συνηθισμένες όσο και προνομιούχοι) και στον τρόπο λειτουργίας - μόνο συνηθισμένο. Μια προσπάθεια να εκτελέσετε μια προνομιακή επιχείρηση και ανατρέξτε επίσης στην προστατευμένη μνήμη στον τρόπο λειτουργίας καλεί την αντίστοιχη διακοπή. Επιπλέον, οι προνομιακές πράξεις περιλαμβάνουν τις λειτουργίες αλλάζουν την προστασία της μνήμης και τη λειτουργία λειτουργίας, καθώς και την πρόσβαση σε ένα εξωτερικό περιβάλλον πληροφοριών. Η αρχική ενεργοποίηση του υπολογιστή και οποιαδήποτε διακοπή πρέπει να περιλαμβάνει αυτόματα την προνομιακή λειτουργία και την ακύρωση της προστασίας της μνήμης. Σε αυτή την περίπτωση, το πρόγραμμα ελέγχου (λειτουργικό σύστημα) μπορεί να προστατευθεί πλήρως από την επίδραση άλλων προγραμμάτων, εάν όλα τα σημεία ελέγχου για την αρχική ενεργοποίηση και τα διακόμισαν θα ανήκουν σε αυτό το πρόγραμμα εάν δεν έχει άλλο πρόγραμμα για να εργαστεί σε προνομιακή λειτουργία ( Κατά τη μετάδοση οποιουδήποτε άλλου ελέγχου, το πρόγραμμα θα ενεργοποιήσει μόνο τη λειτουργία εργασίας) και αν προστατεύει πλήρως τη μνήμη του (που περιέχει, ειδικότερα, όλες τις πληροφορίες ελέγχου, συμπεριλαμβανομένου του λεγόμενου φορέα διακοπής) από άλλα προγράμματα. Τότε κανείς δεν θα την εμποδίσει να εκτελέσει άλλα προγράμματα που εφαρμόζονται σε αυτό (συμπεριλαμβανομένης της πρόσβασης στο εξωτερικό περιβάλλον πληροφοριών). Για να διευκολυνθεί η λύση αυτού του στόχου, μέρος ενός τέτοιου προγράμματος τοποθετείται σε συνεχή μνήμη, δηλ. αδιαχώριστο από τον ίδιο τον υπολογιστή. Η παρουσία προσωρινής διακοπής επιτρέπει στο πρόγραμμα ελέγχου να προστατεύει από τη βρόχο σε άλλα προγράμματα (χωρίς μια τέτοια διακοπή, θα μπορούσε απλώς να χάσει την ευκαιρία να διαχειριστεί).
Η προστασία από τις αρνήσεις του "προγράμματος" του "εξασφαλίζεται από την αξιοπιστία του παρόντος προγράμματος, στην οποία επικεντρώνεται η τεχνολογία προγραμματισμού που συζητείται στην παρούσα πορεία των διαλέξεων.
Προστασία εναντίον σφαλμάτων χρήστη (εκτός από τα σφάλματα εισόδου, βλέπε τη βιωσιμότητα του PS) εξασφαλίζεται με την έκδοση προειδοποιητικών μηνυμάτων σχετικά με την προσπάθεια αλλαγής της κατάστασης του εξωτερικού περιβάλλοντος πληροφοριών με την απαίτηση επιβεβαίωσης αυτών των δράσεων, καθώς και τη δυνατότητα αποκαθιστώντας την κατάσταση των μεμονωμένων συστατικών του εξωτερικού περιβάλλοντος πληροφοριών. Το τελευταίο βασίζεται σε αλλαγές στην αρχειοθέτηση στην κατάσταση του εξωτερικού περιβάλλοντος πληροφοριών.
Η προστασία από μη εξουσιοδοτημένη πρόσβαση εξασφαλίζεται χρησιμοποιώντας μυστικές λέξεις (κωδικούς πρόσβασης). Σε αυτή την περίπτωση, κάθε χρήστης παρέχεται ορισμένες πληροφορίες και διαδικαστικούς πόρους (υπηρεσίες), για τη χρήση των οποίων το PS παρουσιάστηκε με κάποιο κωδικό πρόσβασης, που προηγουμένως καταχωρημένο στο PS του χρήστη. Με άλλα λόγια, ο χρήστης, όπως ήταν, "Κρεμάστε το κάστρο" στους πόρους που του διαθέτει, το "κλειδί" από το οποίο έχει μόνο αυτόν τον χρήστη. Ωστόσο, σε ορισμένες περιπτώσεις, σε ορισμένες περιπτώσεις, μπορούν να ληφθούν επίμονες προσπάθειες για την αντιμετώπιση αυτής της προστασίας εάν υποβάλλονται προστατευόμενες πόροι για κάποιον έκτακτη τιμή έκτακτης ανάγκης. Για μια τέτοια περίπτωση, είναι απαραίτητο να ληφθούν πρόσθετα μέτρα για την προστασία από την προστασία του σπάσιμο.
Η προστασία από την προστασία του σπάσιμο σχετίζεται με τη χρήση ειδικών τεχνικών προγραμματιστών στο PS, το οποίο καθιστά δύσκολη την αντιμετώπιση της προστασίας από μη εξουσιοδοτημένη πρόσβαση. Η χρήση των συνηθισμένων κωδικών πρόσβασης είναι ανεπαρκής όταν πρόκειται για μια εξαιρετικά επίμονη επιθυμία (για παράδειγμα, ποινικό χαρακτήρα) για την πρόσβαση σε πολύτιμες πληροφορίες. Πρώτον, επειδή οι πληροφορίες κωδικού πρόσβασης που χρησιμοποιεί το PS για την προστασία από μη εξουσιοδοτημένη πρόσβαση, το "cracker" αυτής της άμυνας μπορεί να είναι σχετικά εύκολο να πάρει εάν έχει πρόσβαση σε αυτό το PS. Δεύτερον, χρησιμοποιώντας έναν υπολογιστή, μπορείτε να ασκήσετε αρκετά μεγάλη αναζήτηση πιθανών κωδικών πρόσβασης για να βρείτε κατάλληλα για πρόσβαση στις πληροφορίες. Είναι δυνατή η προστασία από μια τέτοια hacking ως εξής. Η μυστική λέξη (κωδικός πρόσβασης) ή απλά ένα μυστικό ακέραιο x γνωρίζει μόνο τον ιδιοκτήτη των προστατευόμενων πληροφοριών και ένας άλλος αριθμός y \u003d f (x) αποθηκεύεται για να ελέγξει τα δικαιώματα πρόσβασης στον υπολογιστή, με μοναδικό υπολογισμό PS με κάθε προσπάθεια πρόσβασης σε αυτό πληροφορίες με την παρουσίαση μιας μυστικής λέξης. Σε αυτή την περίπτωση, η λειτουργία F μπορεί να είναι γνωστή σε όλους τους χρήστες PS, ωστόσο, έχει μια τέτοια ακίνητη περιουσία ότι η ανάκτηση της λέξης x μέσω y είναι σχεδόν αδύνατη: με επαρκώς μεγάλο μήκος της λέξης Χ (για παράδειγμα, αρκετές Εκατοντάδες χαρακτήρες) απαιτεί αστρονομικό χρόνο. Ένας τέτοιος αριθμός y θα ονομάζεται ηλεκτρονική υπογραφή (υπολογιστή) του ιδιοκτήτη της μυστικής λέξης Χ (και ως εκ τούτου προστατεύεται επίσης πληροφορίες).
Ένας άλλος τύπος τέτοιας προστασίας σχετίζεται με την προστασία μηνυμάτων που αποστέλλονται από δίκτυα υπολογιστών, σκόπιμη (ή κακόβουλα) στρεβλώσεις. Τέτοια μηνύματα μπορούν να παρεμποδιστούν σε σημεία δικτύου "μεταφόρτωσης" και να αντικατασταθούν από ένα άλλο μήνυμα από τον συντάκτη του παρατεταμένου μηνύματος. Μια τέτοια κατάσταση προκύπτει κυρίως στην εφαρμογή τραπεζικών εργασιών χρησιμοποιώντας ένα δίκτυο υπολογιστών. Αντικατάσταση ενός τέτοιου μηνύματος, ο οποίος αναφέρεται στον ιδιοκτήτη ενός τραπεζικού λογαριασμού σχετικά με την εφαρμογή μιας συγκεκριμένης τραπεζικής επιχείρησης, τα χρήματα από το λογαριασμό του μπορούν να μεταφερθούν στον λογαριασμό "θρυμματισμού" (ένας ιδιόμορφος τύπος ληστείας υπολογιστών της τράπεζας). Η προστασία από μια τέτοια προστασία σπασίματος μπορεί να πραγματοποιηθεί ως εξής. Μαζί με τη λειτουργία F, η οποία ορίζει την υπογραφή του υπολογιστή του μυστικού ιδιοκτήτη λέξεων, τον οποίο γνωρίζει ο προορισμός του προστατευμένου μηνύματος (αν μόνο ο ιδιοκτήτης του είναι ο πελάτης αυτού του παραλήπτη), μια άλλη λειτουργία σφραγίδας ορίζεται στο PS, σύμφωνα με Ο αποστολέας πρέπει να υπολογίσει τον αριθμό S \u003d σφραγίδα (x, r) χρησιμοποιώντας τη μυστική λέξη x και το κείμενο του μεταδιδόμενου μηνύματος R. Η λειτουργία σφραγίδας θεωρείται επίσης καλά γνωστή σε όλους τους χρήστες PS και έχει ένα τέτοιο ακίνητο το οποίο Είναι σχεδόν αδύνατο να επαναφέρετε τον αριθμό x, ούτε να επιλέξετε ένα άλλο μήνυμα R με την αντίστοιχη υπογραφή του υπολογιστή. Το ίδιο το μεταδιδόμενο μήνυμα (μαζί με την προστασία του) πρέπει να είναι:
Επιπλέον, το y (υπογραφή υπολογιστή) επιτρέπει την αντιμετώπιση της αλήθειας του πελάτη και S φαίνεται να στερεώνει το προστατευμένο μήνυμα rc υπογραφή υπολογιστή rc y. Από αυτή την άποψη, θα καλέσουμε τη σφραγίδα ηλεκτρονικού υπολογιστή (υπολογιστή). Ένα άλλο συμβολαιογράφο ορίζεται στο PS, στο οποίο ο παραλήπτης του προστατευμένου μηνύματος ελέγχει την αλήθεια του μεταδιδόμενου μηνύματος:
Αυτό σας επιτρέπει να αποδεικνύετε σαφώς ότι το μήνυμα R ανήκει στον ιδιοκτήτη της μυστικής λέξης X.
Η προστασία από την προστασία είναι απαραίτητη στην περίπτωση που ο χρήστης έχει ξεχάσει (ή χάθηκε) τον κωδικό πρόσβασής του. Για μια τέτοια περίπτωση, θα πρέπει να παρέχεται για έναν ειδικό χρήστη (διαχειριστής PS) που είναι υπεύθυνος για τη λειτουργία του συστήματος προστασίας, να διεξάγει προσωρινή απομάκρυνση προστασίας από μη εξουσιοδοτημένη πρόσβαση για τον ιδιοκτήτη του ξεχασμένου κωδικού πρόσβασης για να του δώσει το ευκαιρία να διορθώσετε έναν νέο κωδικό πρόσβασης.
Λογοτεχνία για τη διάλεξη 11.
11.1. ΕΙΝΑΙ. Berezin, Ν.Ρ. Υγρό. Μέθοδοι υπολογισμού κλπ. 1 και 2. - Μ.: Fizmatgiz, 1959.
11.2. Ν. Κύπελλα, n.p. Υγρό, Γ.Μ. Kobelkov. Αριθμητικές μεθόδους. - M.: Science, 1987.
11.3. Myers. Αξιοπιστία λογισμικού. - M.: MIR, 1980. Σ. 127-154.
11.4. ΕΝΑ. Lebedev. Προστασία των τραπεζικών πληροφοριών και της σύγχρονης κρυπτογραφίας // Θέματα προστασίας πληροφοριών, 2 (29), 1995.
Διάλεξη 12. Παροχή ποιότητας λογισμικού
12.1. Τα συνολικά χαρακτηριστικά της διαδικασίας διασφάλισης της ποιότητας λογισμικού.
Όπως έχει ήδη σημειωθεί σε διαλέξεις 4, η προδιαγραφή ποιότητας καθορίζει τις κύριες κατευθυντήριες γραμμές (στόχοι), οι οποίοι σε όλα τα στάδια της ανάπτυξης του PS, ούτως ή άλλως επηρεάζουν την υιοθέτηση διαφόρων λύσεων για να επιλέξουν από την κατάλληλη επιλογή. Ωστόσο, κάθε πρωτόγονος ποιότητας έχει τα δικά της χαρακτηριστικά μιας τέτοιας επιρροής, εξασφαλίζοντας έτσι την παρουσία της στο PS μπορεί να απαιτήσει τις προσεγγίσεις και τις μεθόδους της για την ανάπτυξη PS ή μεμονωμένων εξαρτημάτων. Επιπλέον, η ασυνέπεια των κριτηρίων ποιότητας των PS και η έκφραση των πρωτίστων ποιότητας ήταν επίσης: η καλή παροχή μιας ενιαίας ποιότητας πρωτόγονο PS θα μπορούσε να καταστήσει σημαντικά δύσκολη ή να καταστήσει αδύνατη την παροχή ορισμένων από αυτά από αυτά τα πρωτογενή. Ως εκ τούτου, ένα σημαντικό μέρος της διαδικασίας διασφάλισης της ποιότητας PS συνίσταται στην εξεύρεση αποδεκτών συμβιβασμών. Αυτοί οι συμβιβασμοί μερικώς προσδιορίζονται ήδη ορίζονται ήδη στην προδιαγραφή ποιότητας PS: Το μοντέλο ποιότητας PS πρέπει να καθορίζει τον απαιτούμενο βαθμό παρουσίας στο PS του καθενός από την ποιότητα της ποιότητας και να καθορίσει τις προτεραιότητες για την επίτευξη αυτών των πτυχίων.
Η διασφάλιση της ποιότητας διεξάγεται σε κάθε τεχνολογική διαδικασία: οι αποφάσεις που λαμβάνονται σε αυτό σε διαφορετικούς βαθμούς επηρεάζουν την ποιότητα του PS στο σύνολό του. Συγκεκριμένα, επειδή ένα σημαντικό μέρος των πρωτίστων ποιότητας συνδέεται όχι τόσο με τις ιδιότητες των προγραμμάτων που περιλαμβάνονται στο PS, όπως συμβαίνει με τις ιδιότητες της τεκμηρίωσης. Λόγω της σημειωμένης σύγκρουσης των πρωτίστων ποιότητας, είναι πολύ σημαντικό να τηρούμε τις επιλεγμένες προτεραιότητες στην παροχή τους. Αλλά σε κάθε περίπτωση, είναι χρήσιμο να τηρήσουμε δύο γενικές αρχές:
Πρώτον, είναι απαραίτητο να εξασφαλιστεί η απαιτούμενη λειτουργικότητα και η αξιοπιστία του PS και στη συνέχεια να φέρει τα υπόλοιπα κριτήρια ποιότητας σε ένα αποδεκτό επίπεδο παρουσίας τους στο PS.
Δεν υπάρχει ανάγκη και μπορεί ακόμη και να είναι επιβλαβής για την επίτευξη υψηλότερου επιπέδου παρουσίας στο PS οποιουδήποτε ποιοτικού προϊόντος από εκείνο που ορίζεται στην προδιαγραφή ποιότητας PS.
Η εξασφάλιση της λειτουργικότητας και της αξιοπιστίας του PP εξετάστηκε στην προηγούμενη διάλεξη. Παρακάτω συζητείται με την παροχή άλλων κριτηρίων ποιότητας PS.
12.2 .. εξασφαλίζοντας την ευκολία εφαρμογής του λογισμικού
Το PP Documenutment καθορίζει τη σύνθεση της τεκμηρίωσης χρήστη
Στην προηγούμενη διάλεξη, η παροχή δύο από τα πέντε πρωτόκολλα ποιότητας (αειφορία και ασφάλεια) εξετάστηκε ήδη, η οποία καθορίζει την ευκολία χρήσης του PS.
Η τεκμηρίωση και η πληροφορικότητα καθορίζουν τη σύνθεση και την ποιότητα των εγγράφων χρήστη (δείτε την ακόλουθη διάλεξη).
Η επικοινωνία εξασφαλίζεται ότι δημιουργώντας μια κατάλληλη διεπαφή χρήστη και την αντίστοιχη εφαρμογή εξαιρετικών καταστάσεων. Ποιο είναι το πρόβλημα εδώ;
12.3. Εξασφάλιση της αποτελεσματικότητας του λογισμικού.
Η αποτελεσματικότητα του PS εξασφαλίζεται από την υιοθέτηση κατάλληλων λύσεων σε διαφορετικά στάδια της ανάπτυξής της, ξεκινώντας από την ανάπτυξη της αρχιτεκτονικής της. Ειδικά έντονα στην αποτελεσματικότητα του PS (ειδικά από τη μνήμη) επηρεάζει την επιλογή της δομής και της παρουσίασης των δεδομένων. Αλλά η επιλογή των αλγορίθμων που χρησιμοποιούνται σε ορισμένες μονάδες λογισμικού, καθώς και τα χαρακτηριστικά της εφαρμογής τους (συμπεριλαμβανομένης της επιλογής της γλώσσας προγραμματισμού), μπορούν να επηρεάσουν σημαντικά την αποτελεσματικότητα του PS. Ταυτόχρονα, πρέπει συνεχώς να επιλύσει την αντίφαση μεταξύ της προσωρινής απόδοσης και της αποδοτικότητας της μνήμης. Ως εκ τούτου, είναι πολύ σημαντικό η προδιαγραφή ποιότητας να υποδεικνύει σαφώς τον ποσοτικό λόγο μεταξύ των δεικτών αυτών των πρωτίστων ποιότητας ή τουλάχιστον τα ποσοτικά όρια δίδονται για έναν από αυτούς τους δείκτες. Παρ 'όλα αυτά, διαφορετικές μονάδες λογισμικού επηρεάζουν την αποτελεσματικότητα του PS στο σύνολό τους με διαφορετικούς τρόπους: και κατά την κατάθεση στο συνολικό κόστος του PS στο χρόνο και τη μνήμη και στην επίδραση σε διαφορετικά πρωτίστια ποιότητας (ορισμένες μονάδες μπορούν να επηρεάσουν έντονα την επίτευξη της επίτευξης Προσωρινή απόδοση και πρακτικά δεν επηρεάζουν την απόδοση της μνήμης, ενώ άλλοι μπορούν να επηρεάσουν σημαντικά τη συνολική κατανάλωση μνήμης, χωρίς να παρέχουν αξιοσημείωτη επίδραση κατά τη λειτουργία του PS). Επιπλέον, πρόκειται για αντίκτυπο (πρώτα απ 'όλα όσον αφορά την προσωρινή απόδοση) εκ των προτέρων (μέχρι το τέλος της εφαρμογής του PS) δεν είναι πάντοτε δυνατό να εκτιμηθεί.
Πρώτα πρέπει να αναπτύξετε ένα αξιόπιστο PS, και μόνο τότε να επιτύχετε την απαιτούμενη αποτελεσματικότητα σύμφωνα με την προδιαγραφή ποιότητας αυτού του PS.
Για να βελτιωθεί η αποτελεσματικότητα του PS, χρησιμοποιήστε κυρίως τον συνδετήρα βελτιστοποίησης - αυτό μπορεί να παράσχει την απαιτούμενη απόδοση.
Εάν η αποτελεσματικότητα του PS δεν ικανοποιεί τις προδιαγραφές της ποιότητάς του, στη συνέχεια, βρείτε τις πιο κρίσιμες μονάδες από την άποψη της απαιτούμενης αποτελεσματικότητας PS (σε περίπτωση χρόνου απόδοσης, θα χρειαστεί να αποκτήσετε διανομή χρόνου λειτουργίας PS ενότητες με κατάλληλες μετρήσεις κατά τη διάρκεια της εκτέλεσης PS) · Αυτές οι ενότητες και προσπαθήστε να βελτιστοποιήσετε πρώτα από τις χειροκίνητες αλλαγές τους.
Μην βελτιστοποιείτε τη μονάδα εάν αυτό δεν απαιτείται για την επίτευξη της απαιτούμενης απόδοσης του PS.
12.4. Εξασφαλίζοντας συνοδευόμενη.
Η C-Documence, ενημερωτική και κατανοητή καθορίζει τη σύνθεση και την ποιότητα της τεκμηρίωσης συνοδείας (δείτε την ακόλουθη διάλεξη). Επιπλέον, μπορούν να σχεδιαστούν οι ακόλουθες συστάσεις σε σχέση με τα κείμενα των προγραμμάτων (ενότητες).
Χρήση στα σχόλια της ενότητας κειμένου που διευκρινίζει και εξηγεί τα χαρακτηριστικά των αποφάσεων που έγιναν. Εάν είναι δυνατόν, ενεργοποιήστε τα σχόλια (τουλάχιστον σε σύντομη μορφή) το νωρίτερο στάδιο του κειμένου της ενότητας.
Χρησιμοποιήστε νόημα (Mnemonic) και σταθερά διακριτά ονόματα (βέλτιστο μήκος ονόματος - 4-12 λίτρων, αριθμοί - στο τέλος), μην χρησιμοποιείτε παρόμοια ονόματα και λέξεις-κλειδιά.
Παρατηρήστε προσοχή στη χρήση των σταθερών (η μοναδική σταθερά πρέπει να έχει μία μόνο είσοδο στο κείμενο της μονάδας: όταν δηλώνεται ή, στην ακραία περίπτωση, όταν η μεταβλητή αρχικοποιείται ως σταθερά).
Μην φοβάστε να χρησιμοποιήσετε μη δεσμευτικούς αγκύλες (οι παρενθέσεις είναι φθηνότερες από τα σφάλματα.
Τοποθετήστε όχι περισσότερο από έναν χειριστή στη συμβολοσειρά. Για να αποσαφηνίσετε τη δομή της ενότητας, χρησιμοποιήστε επιπλέον κενά (περιπτώσεις) στην αρχή κάθε σειράς.
Αποφύγετε τα κόλπα, δηλ. Τέτοιες τεχνικές προγραμματισμού όταν δημιουργούνται θραύσματα της μονάδας, το κύριο αποτέλεσμα του οποίου δεν είναι προφανές ή κρυφό (αποκαλυπτόμενο), για παράδειγμα, παρενέργειες λειτουργιών.
Η εκτατότητα εξασφαλίζεται δημιουργώντας έναν κατάλληλο εγκαταστάτη.
Η διάρθρωση και η διαμόρφωση απλοποιούν τόσο την κατανόηση των κειμένων κειμένου όσο και την τροποποίησή τους.
12.5. Κινητικότητα.
Λογοτεχνία για τη διάλεξη 12.
12.1. Ian sommerville. Μηχανική λογισμικού. - Addison-Wesley Publishing Company, 1992. Π.
12.3. D.Va Tasel. Στυλ, ανάπτυξη, αποτελεσματικότητα, debugging και δοκιμαστικά προγράμματα. - M.: MIR, 1985. Σ. 8-44, 117-178.
12.4. Τεκμηρίωση χρήστη λογισμικού / ANSI / IEEE 1063-1987 πρότυπο.
Διάλεξη 13. Τεκμηρίωση του λογισμικού
13.1. Τεκμηρίωση που δημιουργήθηκε στη διαδικασία ανάπτυξης λογισμικού.
Κατά την ανάπτυξη του PS, δημιουργείται μια μεγάλη ποσότητα διαφορετικής τεκμηρίωσης. Είναι απαραίτητο ένα μέσο διαβίβασης πληροφοριών μεταξύ των προγραμματιστών PS ως μέσου διαχείρισης της ανάπτυξης του PS και ως μέσου μεταφοράς στους χρήστες των πληροφοριών που είναι απαραίτητες για τη χρήση και την υποστήριξη του PS. Η δημιουργία αυτής της τεκμηρίωσης αντιπροσωπεύει ένα μεγάλο μέρος του κόστους του PS.
Αυτή η τεκμηρίωση μπορεί να χωριστεί σε δύο ομάδες:
Διαχείριση εγγράφων του PS.
Έγγραφα που περιλαμβάνονται στο PS.
Τα έγγραφα ανάπτυξης PS (τεκμηρίωση διαδικασίας), καταγράφουν τις διαδικασίες ανάπτυξης και συντήρησης PS, παρέχοντας επικοινωνία εντός της ομάδας προγραμματιστών και μεταξύ των διευθυντών ανάπτυξης των προγραμματιστών (διαχειριστές) - διαχειριστές ανάπτυξης. Αυτά τα έγγραφα μπορεί να είναι οι ακόλουθοι τύποι:
Σχέδια, αξιολογήσεις, χρονοδιαγράμματα. Αυτά τα έγγραφα δημιουργούνται από τους διαχειριστές για την πρόβλεψη και τη διαχείριση των διαδικασιών ανάπτυξης και συντήρησης.
Αναφορές σχετικά με τη χρήση των πόρων στη διαδικασία ανάπτυξης. Δημιουργήθηκε από τους διαχειριστές.
Πρότυπα. Αυτά τα έγγραφα συνταγογραφούνται στους προγραμματιστές, ποιες αρχές, κανόνες, συμφωνίες, πρέπει να ακολουθήσουν στη διαδικασία ανάπτυξης PS. Αυτά τα πρότυπα μπορούν να είναι τόσο διεθνή είτε εθνικά και ειδικά δημιουργημένα για την οργάνωση, η οποία περιέχει την ανάπτυξη αυτού του PS.
Έγγραφα εργασίας. Αυτά είναι τα κύρια τεχνικά έγγραφα που εξασφαλίζουν τη σχέση μεταξύ των προγραμματιστών. Περιέχουν στερέωση ιδεών και προβλημάτων που προκύπτουν από τη διαδικασία ανάπτυξης, περιγραφή των στρατηγικών και προσεγγίσεων που χρησιμοποιούνται, καθώς και εργάζονται (προσωρινές) εκδόσεις εγγράφων που πρέπει να συνδεθούν.
Σημειώσεις και αλληλογραφία. Αυτά τα έγγραφα καταγράφουν διάφορες λεπτομέρειες της αλληλεπίδρασης μεταξύ διαχειριστών και προγραμματιστών.
Τα έγγραφα που περιλαμβάνονται στο PS (τεκμηρίωση του προϊόντος) περιγράφουν τα προγράμματα PS τόσο από την άποψη της χρήσης τους από τους χρήστες όσο και από την άποψη των προγραμματιστών και των υποστηρίξεών τους (σύμφωνα με το σκοπό του PS). Πρέπει να σημειωθεί εδώ ότι αυτά τα έγγραφα θα χρησιμοποιηθούν όχι μόνο στο στάδιο λειτουργίας PS (στις φάσεις εφαρμογής και συντήρησης), αλλά και στο στάδιο ανάπτυξης για τον έλεγχο της διαδικασίας ανάπτυξης (μαζί με έγγραφα εργασίας) - σε κάθε περίπτωση, Πρέπει να ελέγχονται (δοκιμασμένοι) για συμμόρφωση με τα προγράμματα PS. Αυτά τα έγγραφα αποτελούν δύο σύνολα με διαφορετικούς σκοπούς:
Προσαρμοσμένη τεκμηρίωση PS (P-τεκμηρίωση).
Τεκμηρίωση συνοδείας PS (τεκμηρίωση C).
13.2. Προσαρμοσμένη τεκμηρίωση λογισμικού.
Η προσαρμοσμένη τεκμηρίωση PS (Τεκμηρίωση χρηστών) εξηγεί στους χρήστες, καθώς πρέπει να ενεργήσουν για να εφαρμόσουν αυτό το PS. Είναι απαραίτητο εάν το PS συνεπάγεται οποιαδήποτε αλληλεπίδραση με τους χρήστες. Μια τέτοια τεκμηρίωση περιλαμβάνει έγγραφα που οι οδηγοί χρήστη κατά την εγκατάσταση του PS (κατά την εγκατάσταση του PS με την κατάλληλη ρύθμιση στο περιβάλλον εφαρμογής PS), κατά την εφαρμογή του PS για την επίλυση των εργασιών του και κατά τον έλεγχο του PS (για παράδειγμα, όταν αυτό το PS αλληλεπιδρά με άλλα συστήματα). Αυτά τα έγγραφα επηρεάζουν εν μέρει τις συνοδές PS, αλλά δεν αφορούν ζητήματα που σχετίζονται με τις τροποποιήσεις του προγράμματος.
Από την άποψη αυτή, θα πρέπει να υπάρχουν δύο κατηγορίες χρηστών PS: συνηθισμένοι χρήστες διαχειριστών PS και PS. Ο συνηθισμένος χρήστης PS (τελικός χρήστης) χρησιμοποιεί το PS για την επίλυση των καθηκόντων της (στην περιοχή του). Μπορεί να είναι ένας μηχανικός που σχεδιάζει μια τεχνική συσκευή ή ένα ταμείο που πωλεί σιδηροδρομικά εισιτήρια χρησιμοποιώντας PS. Μπορεί να μην γνωρίζει πολλές λεπτομέρειες των αρχών του υπολογιστή ή του προγραμματισμού. Ο διαχειριστής PS (διαχειριστής συστήματος) διαχειρίζεται τη χρήση PS από τους απλούς χρήστες και διατηρεί PS, που δεν σχετίζεται με τις τροποποιήσεις του προγράμματος. Για παράδειγμα, μπορεί να ρυθμίσει τα δικαιώματα πρόσβασης στο PS μεταξύ των συνηθισμένων χρηστών, να διατηρήσει την επικοινωνία με τους παροχείς PS ή να εκτελέσει ορισμένες ενέργειες για την υποστήριξη PS στην κατάσταση λειτουργίας, εάν είναι ενεργοποιημένη ως μέρος σε άλλο σύστημα.
Η σύνθεση της τεκμηρίωσης χρήστη εξαρτάται από το κοινό των χρηστών στις οποίες επικεντρώνεται αυτό το PS και στη χρήση εγγράφων. Κάτω από το κοινό, το ενδεχόμενο των χρηστών PS είναι κατανοητό εδώ, το οποίο έχει ανάγκη για μια συγκεκριμένη τεκμηρίωση χρήστη του PS. Ένα επιτυχημένο έγγραφο χρήστη εξαρτάται από τον ακριβή ορισμό του κοινού για το οποίο προορίζεται. Η προσαρμοσμένη τεκμηρίωση θα πρέπει να περιέχει τις απαραίτητες πληροφορίες για κάθε κοινό. Σύμφωνα με τη λειτουργία χρήσης εγγράφων εννοείται μια μέθοδος που ορίζει τον τρόπο χρήσης αυτού του εγγράφου. Συνήθως, ο χρήστης είναι συνήθως απαραίτητος για να χρειαστεί ή έγγραφα για τη μελέτη του PS (χρήση με τη μορφή οδηγιών) ή για να αποσαφηνίσει ορισμένες πληροφορίες (χρήση ως αναφορά).
Σύμφωνα με τα έργα, μπορείτε να εξετάσετε τυπικά την ακόλουθη σύνθεση τεκμηρίωσης χρήστη για επαρκώς μεγάλα PS:
Γενική λειτουργική περιγραφή PS. Δίνει μια σύντομη περιγραφή της λειτουργικότητας του PS. Σχεδιασμένο για χρήστες που πρέπει να αποφασίσουν πόσο είναι απαραίτητο για αυτό το PS.
Οδηγός εγκατάστασης PS. Σχεδιασμένο για διαχειριστές συστημάτων. Πρέπει να συνταγογραφήσει λεπτομερώς τον τρόπο εγκατάστασης συστημάτων σε ένα συγκεκριμένο περιβάλλον. Πρέπει να περιέχει μια περιγραφή των μηχάνημα-αναγνώσιμα μέσα ενημέρωσης στα οποία τα PS, τα αρχεία που αντιπροσωπεύουν το PS και τις απαιτήσεις για την ελάχιστη διαμόρφωση του εξοπλισμού.
Οδηγίες χρήσης PS. Σχεδιασμένο για τους απλούς χρήστες. Περιέχει τις απαραίτητες πληροφορίες σχετικά με τη χρήση του PS, οργανωμένη με τη μορφή που είναι βολικό για να το μελετήσει.
Κατάλογος για τη χρήση του PS. Σχεδιασμένο για τους απλούς χρήστες. Περιέχει τις απαραίτητες πληροφορίες σχετικά με τη χρήση του PS, που οργανώθηκε με τη φόρμα που είναι βολική για την επιλεκτική αναζήτηση ατομικών λεπτομερειών.
Οδηγός διαχείρισης PS. Σχεδιασμένο για διαχειριστές συστημάτων. Θα πρέπει να περιγράψει τα μηνύματα που δημιουργούνται όταν το PS αλληλεπιδρά με άλλα συστήματα και πώς να απαντήσετε σε αυτά τα μηνύματα. Επιπλέον, εάν το PS χρησιμοποιεί εξοπλισμό συστήματος, το έγγραφο αυτό μπορεί να εξηγήσει πώς να συνοδεύσει αυτόν τον εξοπλισμό.
Όπως αναφέρθηκε προηγουμένως (βλ. Διάλεξη 4), η ανάπτυξη τεκμηρίωσης χρήστη ξεκινά αμέσως μετά τη δημιουργία εξωτερικής περιγραφής. Η ποιότητα αυτής της τεκμηρίωσης μπορεί να καθορίσει σημαντικά την επιτυχία του PS. Θα πρέπει να είναι αρκετά απλό και βολικό για τον χρήστη (διαφορετικά είναι PS, γενικά, δεν πρέπει να δημιουργεί). Επομένως, παρόλο που τα σχέδια παραλλαγών (σκίτσα) των προσαρμοσμένων εγγράφων δημιουργούνται από τους κύριους προγραμματιστές των PS, οι επαγγελματίες τεχνικοί συγγραφείς συχνά προσελκύονται στη δημιουργία των τελικών τους εκδόσεων. Επιπλέον, αναπτύχθηκαν ορισμένα πρότυπα για να εξασφαλιστεί η ποιότητα των εγγράφων χρήστη (βλ. Για παράδειγμα), στην οποία προβλέπεται η διαδικασία ανάπτυξης αυτής της τεκμηρίωσης, διατυπώνονται οι απαιτήσεις για κάθε τύπο εγγράφων χρηστών και η δομή και η περιεκτικότητά τους είναι προσδιορίζεται.
13.3. Το λογισμικό συνοδεύει την τεκμηρίωση.
Τεκμηρίωση υποστήριξης PS (τεκμηρίωση συστήματος) περιγράφει το PS από την άποψη της ανάπτυξής της. Αυτή η τεκμηρίωση είναι απαραίτητη εάν το PS περιλαμβάνει τη μάθηση του τρόπου με τον οποίο είναι ρυθμισμένο (σχεδιασμένο) και ο εκσυγχρονισμός των προγραμμάτων της. Όπως ήδη σημειώθηκε, η συνοδεία συνεχίζεται η ανάπτυξη. Επομένως, εάν είναι απαραίτητο, ο εκσυγχρονισμός του PS σε αυτό το έργο προσελκύεται από μια ειδική ομάδα προγραμματιστών. Αυτή η ομάδα θα πρέπει να ασχοληθεί με την ίδια τεκμηρίωση που καθόρισε τις δραστηριότητες της ομάδας των αρχικών (βασικών) προγραμματιστών PS, - με τη διαφορά ότι αυτή η τεκμηρίωση για την ομάδα προγραμματιστών προγραμματιστών θα είναι, κατά κανόνα, κάποιος άλλος (ήταν δημιουργήθηκε από άλλη εντολή). Η ομάδα του Scheduler θα πρέπει να μελετήσει αυτή την τεκμηρίωση για να κατανοήσει τη δομή και τη διαδικασία ανάπτυξης αναβαθμισμένου PS και να καταστήσει τις απαραίτητες αλλαγές σε αυτή την τεκμηρίωση, επαναλαμβάνοντας μια μεγάλη έκταση τεχνολογικές διεργασίες με τη βοήθεια της οποίας δημιουργήθηκε το αρχικό PS.
Η τεκμηρίωση υποστήριξης PS μπορεί να χωριστεί σε δύο ομάδες:
(1) τεκμηρίωση που καθορίζει τη δομή των προγραμμάτων και των δομών δεδομένων του PS και της τεχνολογίας της ανάπτυξής τους ·
(2) Τεκμηρίωση που συμβάλλει στην πραγματοποίηση αλλαγών στο PS.
Η τεκμηρίωση της πρώτης ομάδας περιέχει τα τελικά έγγραφα κάθε τεχνολογικού σταδίου της ανάπτυξης του PS. Περιλαμβάνει τα ακόλουθα έγγραφα:
Εξωτερική περιγραφή PS (Απαιτήσεις Έγγραφο).
Περιγραφή της αρχιτεκτονικής PS (περιγραφή της αρχιτεκτονικής του συστήματος), συμπεριλαμβανομένης της εξωτερικής προδιαγραφής καθενός από τα προγράμματά του.
Για κάθε πρόγραμμα PS, μια περιγραφή της αρθρωτής δομής της, συμπεριλαμβανομένης της εξωτερικής προδιαγραφής κάθε ενότητας που περιλαμβάνεται σε αυτό.
Για κάθε ενότητα - τις προδιαγραφές και την περιγραφή της δομής του (περιγραφή σχεδιασμού).
Κείμενα των ενοτήτων στην επιλεγμένη γλώσσα προγραμματισμού (καταχωρήσεις πηγαίου κωδικού προγράμματος).
PS Λογιστικά έγγραφα (έγγραφα επικύρωσης) που περιγράφουν τον τρόπο με τον οποίο δημιουργήθηκε η ακρίβεια κάθε προγράμματος PS και πώς συνδέθηκε η πληροφορία σχετικά με την ακρίβεια ρύθμισης με τις απαιτήσεις για το PS.
PS Τα έγκυρα έγγραφα περιλαμβάνουν κυρίως την τεκμηρίωση (Σχήμα δοκιμής και περιγραφή των δοκιμών), αλλά μπορεί επίσης να περιλαμβάνει τα αποτελέσματα άλλων τύπων επαλήθευσης PS, για παράδειγμα, απόδειξη ιδιοτήτων προγραμμάτων.
Η τεκμηρίωση της δεύτερης ομάδας περιέχει
Ο οδηγός υποστήριξης PS (Οδηγός συντήρησης συστήματος), η οποία περιγράφει γνωστά προβλήματα με το PS, περιγράφει ποια μέρη του συστήματος εξαρτώνται από το υλικό και το λογισμικό εξαρτώμενο και πώς η ανάπτυξη του PS λαμβάνεται υπόψη στη δομή του (σχεδιασμός).
Το συνολικό πρόβλημα της διατήρησης του PS είναι να διασφαλιστεί ότι όλες οι αναπαραστάσεις του θα πάνε στο πόδι (παρέμειναν συμφωνημένες) όταν το PS ποικίλλει. Για να βοηθήσετε, η επικοινωνία και τις εξαρτήσεις μεταξύ εγγράφων και των εξαρτημάτων τους θα πρέπει να καταγράφονται στη βάση δεδομένων διαχείρισης διαμόρφωσης.
Λογοτεχνία για τη διάλεξη 13.
13.1. Ian sommerville. Μηχανική λογισμικού. - Addison-Wesley Publishing Company, 1992. Π.
13.2. ANSI / IEEE STD 1063-1988, IEEE πρότυπο για την τεκμηρίωση χρήστη λογισμικού.
13.3. ANSI / IEEE STD 830-1984, Οδηγός IEEE για τις προδιαγραφές απαιτήσεων λογισμικού.
13.4. ANSI / IEEE STD 1016-1987, IEEE συνέστησε πρακτική για την περιγραφή του σχεδιασμού λογισμικού.
13.5. ANSI / IEEE STD 1008-1987, IEEE πρότυπο για τη δοκιμή μονάδας λογισμικού.
13.6. ANSI / IEEE STD 1012-1986, IEEE πρότυπο για προγράμματα επαλήθευσης λογισμικού και επικύρωσης.
13.7. ANSI / IEEE STD 983-1986, Οδηγός IEEE για σχεδιασμό διασφάλισης ποιότητας λογισμικού.
13.8. ANSI / IEEE STD 829-1983, IEEE πρότυπο για τεκμηρίωση δοκιμής λογισμικού.
Διάλεξη 14. Πιστοποίηση λογισμικού
Διορισμός πιστοποίησης λογισμικού. Δοκιμές και αξιολόγηση της ποιότητας του λογισμικού. Τύποι δοκιμών και μέθοδοι για την αξιολόγηση της ποιότητας του λογισμικού.
14.1. Διορισμός πιστοποίησης λογισμικού.
Η πιστοποίηση PS αποτελεί έγκυρη επιβεβαίωση της ποιότητας του PS. Συνήθως, μια προμήθεια εκπροσώπησης (πιστοποίησης) από εμπειρογνώμονες, εκπρόσωποι του πελάτη και εκπροσώπους του προγραμματιστή δημιουργείται για την πιστοποίηση PS. Αυτή η Επιτροπή διεξάγει δοκιμές PS προκειμένου να λάβουν τις απαραίτητες πληροφορίες για να αξιολογήσει την ποιότητά του. Σύμφωνα με τη δοκιμασία του PS, θα κατανοήσουμε τη διαδικασία διεξαγωγής ενός συνόλου μέτρων που διερευνά την καταλληλότητα του PS για επιτυχή λειτουργία (εφαρμογή και συντήρηση) σύμφωνα με τις απαιτήσεις του πελάτη. Αυτό το συγκρότημα περιλαμβάνει τον έλεγχο της πληρότητας και της ακρίβειας της τεκμηρίωσης του προγράμματος, τη μελέτη και τη συζήτηση των άλλων ακινήτων της, καθώς και τις απαραίτητες δοκιμές των προγραμμάτων που περιλαμβάνονται στο PS και, ειδικότερα, τη συμμόρφωση αυτών των προγραμμάτων τεκμηρίωσης.
Με βάση τις πληροφορίες που αποκτήθηκαν κατά τη διάρκεια των δοκιμών του PS, καταρχάς, θα πρέπει να αποδειχθεί ότι το PS εκτελεί δηλωθείσες λειτουργίες και πρέπει επίσης να καθοριστεί στα οποία το PS μειώθηκε αρχικά και κριτήρια ποιότητας. Έτσι, η αξιολόγηση της ποιότητας του PS είναι το κύριο περιεχόμενο της διαδικασίας πιστοποίησης. Η αξιολόγηση της ποιότητας PS καταγράφεται στην κατάλληλη απόφαση της Επιτροπής βεβαίωσης.
14.2. Τύποι λογισμικού δοκιμών.
Οι ακόλουθοι τύποι δοκιμών του PS είναι γνωστές για το σκοπό της πιστοποίησης του PS:
Δοκιμαστικά εξαρτήματα του PS.
δοκιμές συστήματος ·
Δοκιμές αποδοχής.
δοκιμές πεδίου.
Βιομηχανικές δοκιμές.
Τα συστατικά δοκιμής του PS είναι μια δοκιμή (δοκιμή) της απόδοσης μεμονωμένων υποσυστημάτων PS. Πραγματοποιήθηκε μόνο σε εξαιρετικές περιπτώσεις σε ειδική απόφαση της Επιτροπής βεβαίωσης.
Οι δοκιμές συστήματος PS είναι μια δοκιμή (δοκιμή) της λειτουργίας του PS στο σύνολό του. Μπορεί να περιλαμβάνει τους ίδιους τύπους δοκιμών όπως στο περίπλοκο εντοπισμό σφαλμάτων του PS (βλέπε διάλεξη 10). Εκτελείται με την απόφαση της Επιτροπής βεβαίωσης, εάν προκύψουν αμφιβολίες ως σφαλμάτωση των προγραμματιστών PS.
Οι δοκιμές αποδοχής είναι ο κύριος τύπος δοκιμών κατά τη διάρκεια της πιστοποίησης PS. Από αυτούς τους εξετάσεις αρχίζει η Επιτροπή βεβαίωσης. Αυτές οι δοκιμές αρχίζουν με τη μελέτη της παρουσιαζόμενης τεκμηρίωσης, συμπεριλαμβανομένης της τεκμηρίωσης για τη δοκιμή και την εντοπισμό σφαλμάτων PS. Εάν η τεκμηρίωση δεν έχει αρκετά πλήρη αποτελέσματα δοκιμών του PS, η Επιτροπή βεβαίωσης μπορεί να αποφασίσει να διεξάγει δοκιμές συστήματος του PS ή τον τερματισμό της διαδικασίας πιστοποίησης με τη σύσταση του προγραμματιστή να πραγματοποιήσει πρόσθετες (πληρέστερες) δοκιμές PS. Επιπλέον, κατά τη διάρκεια αυτών των δοκιμών, οι δοκιμές προγραμματιστών μπορούν να παραλειφθούν επιλεκτικά, καθώς και τις εργασίες ελέγχου των χρηστών (βλέπε διάλεξη 10) και πρόσθετες δοκιμές που εκπονήθηκαν από την Επιτροπή για την αξιολόγηση της ποιότητας των πιστοποιημένων PS.
Οι δοκιμές πεδίου PS είναι μια επίδειξη του PS μαζί με το τεχνικό σύστημα που διαχειρίζεται αυτό το PS, πραγματοποιείται ένας στενός κύκλος πελατών σε πραγματικές συνθήκες και μια λεπτομερής παρακολούθηση της συμπεριφοράς PS. Οι πελάτες πρέπει να έχουν τη δυνατότητα να καθορίζουν τα δικά τους παραδείγματα ελέγχου, ιδίως, από τις εξόδους σε κρίσιμους τρόπους λειτουργίας του τεχνικού συστήματος, καθώς και με την πρόκληση των καταστάσεων έκτακτης ανάγκης. Πρόκειται για πρόσθετες δοκιμές που διενεργούνται με την απόφαση της Επιτροπής βεβαίωσης μόνο για ορισμένους PS κατά τη διαχείριση ορισμένων τεχνικών συστημάτων.
Οι βιομηχανικές δοκιμές του PS είναι η διαδικασία μετάδοσης του PS σε συνεχή λειτουργία στους χρήστες. Πρόκειται για μια περίοδο πιλότης λειτουργίας του PS (βλέπε διάλεξη 10) χρηστών με τη συλλογή πληροφοριών σχετικά με τις ιδιαιτερότητες της συμπεριφοράς PS και τα λειτουργικά της χαρακτηριστικά. Αυτές είναι οι τελικές δοκιμές του PS, οι οποίες πραγματοποιούνται με την απόφαση της Επιτροπής βεβαίωσης, εάν δεν υπάρχουν αρκετές πλήρεις ή αξιόπιστες πληροφορίες σχετικά με τις προηγούμενες δοκιμές για την αξιολόγηση της ποιότητας των πιστοποιημένων PS.
14.3. Μέθοδοι αξιολόγησης της ποιότητας του λογισμικού.
Η αξιολόγηση της ποιότητας του PS για κάθε ένα από τα κριτήρια μειώνεται στην εκτίμηση καθενός από τα πρωτίστια που σχετίζονται με το κριτήριο ποιότητας PS, σύμφωνα με την υλοποίησή τους που παράγεται στην προδιαγραφή ποιότητας αυτού του PS. Μέθοδοι για την εκτίμηση των πρωτοτύπων του PS μπορούν να χωριστούν σε τέσσερις ομάδες:
Άμεση μέτρηση των πρωτόγονων δεικτών ποιότητας ·
Προγράμματα επεξεργασίας και τεκμηρίωση PS με ειδικά εργαλεία λογισμικού (επεξεργαστές).
Δοκιμές προγραμμάτων PS.
Αξιολόγηση εμπειρογνωμόνων με βάση τη μελέτη των προγραμμάτων και την τεκμηρίωση του PS.
Η άμεση μέτρηση των πρωτόγονων δεικτών ποιότητας γίνεται με την καταμέτρηση του αριθμού των περιστατικών σε ένα ή ένα άλλο έγγραφο λογισμικού των χαρακτηριστικών μονάδων, αντικειμένων, δομών κ.λπ., καθώς και με τη μέτρηση του χρόνου λειτουργίας διαφόρων συσκευών και τον όγκο του κατεχόμενου υπολογιστή Μνήμη κατά την εκτέλεση παραδείγματα ελέγχου. Για παράδειγμα, ένας ορισμένος δείκτης απόδοσης μνήμης μπορεί να είναι ο αριθμός των γραμμών προγραμματισμού στη γλώσσα προγραμματισμού και ένα ορισμένο ποσοστό χρόνου αποτελεσματικότητας μπορεί να είναι χρόνος απόκρισης σε ένα αίτημα. Η χρήση οποιωνδήποτε δεικτών για ποιοτικά πρωτόκολλα μπορεί να προσδιοριστεί σε προδιαγραφές ποιότητας PS. Η μέθοδος άμεσης μέτρησης των πρωτόγονων δεικτών ποιότητας μπορεί να συνδυαστεί με τη χρήση προγραμμάτων δοκιμών.
Για να διαπιστωθεί η παρουσία ορισμένων πρωτίστων ποιότητας, μπορούν να χρησιμοποιηθούν ορισμένα εργαλεία λογισμικού. Αυτά τα εργαλεία λογισμικού χειρίζονται τα κείμενα προγραμμάτων ή τεκμηρίωσης λογισμικού, προκειμένου να ελέγχουν τυχόν ποιοτικά πρωτόγονα ή να λάβουν ορισμένους δείκτες αυτών των πρωτίστων ποιότητας. Για να αξιολογηθεί η δομή των προγραμμάτων PS, εάν προγραμματιστούν σε μια κατάλληλη δομική διάλεκτο της γλώσσας προγραμματισμού, θα ήταν αρκετό να τους παραλείψετε μέσω του μετατροπέα δομημένων προγραμμάτων που εκτελούν τον συντακτικό και κάποιο σημασιολογικό έλεγχο αυτής της διάλειμμα και τη μετάφραση Κείμενα αυτών των προγραμμάτων στη γλώσσα εισόδου του μεταφραστή βάσης. Ωστόσο, με αυτόν τον τρόπο, μόνο ένας μικρός αριθμός πρωτοτύπων ποιότητας μπορεί να ελεγχθεί και ακόμη και στη συνέχεια σε σπάνιες περιπτώσεις. Σε ορισμένες περιπτώσεις, αντί για εργαλεία λογισμικού που ελέγχουν την ποιότητα του PS είναι πιο χρήσιμες για την εφαρμογή εργαλείων που μετατρέπουν την παρουσίαση προγράμματος ή την τεκμηρίωση λογισμικού. Τέτοια, για παράδειγμα, είναι ο τύπος του προγράμματος, οδηγώντας τα κείμενα των προγραμμάτων σε μια αναγνώσιμη μορφή, - η επεξεργασία των κειμένων των προγραμμάτων PS, ένα τέτοιο εργαλείο μπορεί να εξασφαλίσει αυτόματα την παρουσία κατάλληλης ποιότητας ποιότητας για το PS.
Η δοκιμή χρησιμοποιείται για την αξιολόγηση ορισμένων πρωτόγονων ποιότητας PS. Αυτά τα πρωτόγονα ισχύουν κατά κύριο λόγο την ολοκλήρωση του PS, καθώς και την ακρίβεια, τη σταθερότητα, την ασφάλεια και άλλα πρωτίστια ποιότητας. Σε ορισμένες περιπτώσεις, η δοκιμή χρησιμοποιείται σε συνδυασμό με άλλες μεθόδους για την αξιολόγηση των επιμέρους πρωτίστων της ποιότητας του PS. Έτσι, για να εκτιμηθεί η ποιότητα των τεκμηρίωσης για τη χρήση του PS (Documenation), η δοκιμή χρησιμοποιείται σε συνδυασμό με μια αξιολόγηση εμπειρογνωμόνων αυτής της τεκμηρίωσης. Εάν, με μια ολοκληρωμένη εντοπισμό σφαλμάτων PS, πραγματοποιήθηκε αρκετά πλήρης δοκιμή, τότε οι ίδιες δοκιμές μπορούν επίσης να χρησιμοποιηθούν στην πιστοποίηση PS. Στην περίπτωση αυτή, η επιτροπή βεβαίωσης μπορεί να χρησιμοποιήσει πρωτόκολλα δοκιμών που διεξάγονται κατά τη διάρκεια πολύπλοκου εντοπισμού σφαλμάτων. Ωστόσο, στην περίπτωση αυτή, πρέπει να εκπληρώσετε τυχόν νέες δοκιμές ή τουλάχιστον να επανέλθω. Εάν η δοκιμή κατά τη διάρκεια πολύπλοκου εντοπισμού σφαλμάτων θα απολεσθεί αρκετά, είναι απαραίτητο να πραγματοποιηθούν πιο πλήρεις δοκιμές. Σε αυτή την περίπτωση, μπορεί να αποφασιστεί η διεξαγωγή των συστατικών δοκιμών ή των δοκιμών συστημάτων του PS, καθώς και η επιστροφή του PS στην ανάπτυξη της βελτίωσης. Είναι πολύ σημαντικό να εκτιμάται το PS με το κριτήριο της ευκολίας χρήσης (κατά τη διάρκεια της εντοπισμού σφαλμάτων και την πιστοποίηση του PS), πλήρη δοκιμή των δοκιμών που προετοιμάζονται βάσει τεκμηρίωσης για την εφαρμογή και σύμφωνα με το κριτήριο των συνοδείων - σχετικά με τις δοκιμές που προετοιμάζονται Για κάθε ένα από τα έγγραφα που προσφέρονται για συντήρηση PS.
Για να αξιολογηθεί τα περισσότερα από τα πρωτίστια της ποιότητας του PS, είναι σήμερα δυνατόν να χρησιμοποιηθεί μόνο η μέθοδος των αξιολογήσεων εμπειρογνωμόνων. Η μέθοδος αυτή έχει ως εξής: ανατεθεί μια ομάδα εμπειρογνωμόνων, καθένας από αυτούς τους εμπειρογνώμονες ως αποτέλεσμα της μελέτης της υποβαλλόμενης τεκμηρίωσης αποτελεί τη γνώμη της σχετικά με την κατοχή του PS που απαιτείται από την πρωτόγονη ποιότητα και στη συνέχεια την ψηφοφορία των μελών του Αυτή η ομάδα θεσπίζει την αξιολόγηση της απαιτούμενης πρωτόγονης ποιότητας του PS. Αυτή η αξιολόγηση μπορεί να διεξαχθεί ως ένα δίδυμο σύστημα ("κατέχει" - "δεν έχει") και εξετάζει το βαθμό κατοχής του PS αυτής της πρωτόγονης ποιότητας (για παράδειγμα, να γίνει σε ένα σύστημα πέντε σημείων ). Ταυτόχρονα, η ομάδα εμπειρογνωμόνων θα πρέπει να καθοδηγείται από την υλοποίηση αυτού του πρωταρχικού και ένδειξη της μεθόδου αξιολόγησης που διατυπώνεται στην προδιαγραφή ποιότητας των πιστοποιημένων PS.
Λογοτεχνία για τη διάλεξη 14.
14.2. V.v.lipaev. Προγράμματα δοκιμών. - Μ.: Ραδιόφωνο και επικοινωνία, 1986. - Σ. 231-245.
14.3. D.Va Tasel. Στυλ, ανάπτυξη, αποτελεσματικότητα, debugging και δοκιμαστικά προγράμματα. - M.: Mir, 1985. - Σ. 281-283.
14.4. Β. Shneiderman. Προγραμματισμός Ψυχολογία. - Μ.: Ραδιόφωνο και επικοινωνία, 1984. - Σ. 99-127.
Διάλεξη 15. Προσέγγιση της ανάπτυξης λογισμικού
15.1. Αντικείμενα και σχέσεις στον προγραμματισμό. Την ουσία της προσέγγισης αντικειμένου στην ανάπτυξη λογισμικού.
Ο κόσμος γύρω μας αποτελείται από αντικείμενα και σχέσεις μεταξύ τους. Το αντικείμενο ενσωματώνει κάποια ουσία και έχει κάποια κατάσταση που μπορεί να αλλάξει με την πάροδο του χρόνου ως αποτέλεσμα της επίδρασης άλλων αντικειμένων που είναι με δεδομένα σε οποιοδήποτε σεβασμό. Μπορεί να έχει μια εσωτερική δομή: αποτελείται από άλλα αντικείμενα, επίσης μεταξύ τους σε ορισμένες απόψεις. Με βάση αυτό, μπορείτε να δημιουργήσετε μια ιεραρχική δομή του κόσμου από αντικείμενα. Ωστόσο, με κάθε συγκεκριμένη εξέταση του κόσμου μας γύρω μας, ορισμένα αντικείμενα θεωρούνται αδιαίρετα ("σημείο") και, ανάλογα με τους στόχους της εξέτασης από τέτοιου είδους (αδιαίρετες), μπορούν να ληφθούν αντικείμενα διαφορετικών επιπέδων της ιεραρχίας. Η στάση συνδέει ορισμένα αντικείμενα: μπορούμε να υποθέσουμε ότι ο συνδυασμός αυτών των αντικειμένων έχει κάποια ιδιοκτησία. Εάν ο λόγος δεσμεύσει τα αντικείμενα N, τότε μια τέτοια στάση ονομάζεται Ν-τοπική (n-arny). Σε κάθε τόπο συνδυασμού αντικειμένων που μπορεί να σχετίζονται με οποιαδήποτε συγκεκριμένη στάση, ενδέχεται να υπάρχουν διαφορετικά αντικείμενα, αλλά αρκετά καθορισμένα (στην περίπτωση αυτή λένε: αντικείμενα μιας συγκεκριμένης τάξης). Η ενιαία αναλογία ονομάζεται ιδιοκτησία ενός αντικειμένου (αντίστοιχη τάξη). Η κατάσταση του αντικειμένου μπορεί να μελετηθεί με την αξία των ιδιοτήτων αυτού του αντικειμένου ή σιωπηρά την αξία των ιδιοτήτων των ιδιοτήτων των αντικειμένων που σχετίζονται με αυτές τις μία ή άλλη στάση.
Στη διαδικασία γνώσης ή αλλαγής του κόσμου γύρω μας, λαμβάνουμε πάντα υπόψη αυτό ή αυτό το απλοποιημένο μοντέλο του κόσμου (μοντέλο κόσμο), το οποίο περιλαμβάνει μερικά από τα αντικείμενα και μερικές από τις σχέσεις γύρω μας και, κατά κανόνα, ένα επίπεδο της ιεραρχίας. Κάθε αντικείμενο που έχει μια εσωτερική δομή μπορεί να αντιπροσωπεύει τον μοντέλο του κόσμου που περιλαμβάνει αντικείμενα αυτής της δομής και τη σχέση που τους συσχετίζουν. Έτσι, ο κόσμος γύρω μας μπορεί να θεωρηθεί (σε κάποια προσέγγιση) ως ιεραρχική δομή των μοντέλων κόσμων.
Επί του παρόντος, ένας εξοπλισμός υπολογιστών για την επεξεργασία διαφόρων ειδών πληροφοριών χρησιμοποιείται ευρέως στη διαδικασία της γνώσης ή της αλλαγής γύρω μας. Από την άποψη αυτή, εφαρμόζεται ένας υπολογιστής (ενημερωτικός) εκπροσώπηση αντικειμένων και σχέσεων. Κάθε πληροφορία αντικειμένου μπορεί να αντιπροσωπεύεται από κάποια δομή δεδομένων που εμφανίζει την κατάστασή του. Οι ιδιότητες αυτού του αντικειμένου μπορούν να ρυθμιστούν άμεσα ως μεμονωμένα συστατικά αυτής της δομής ή ειδικά χαρακτηριστικά μέσω αυτής της δομής δεδομένων. Οι n-τοπικές σχέσεις για το Ν\u003e 1 μπορούν να εκπροσωπούνται είτε σε ενεργό μορφή είτε σε παθητική μορφή. Σε ενεργό μορφή, η n-τοπική σχέση φαίνεται να είναι κάποιο θραύσμα λογισμικού που εφαρμόζει είτε N-τοπική λειτουργία (ορίζοντας την τιμή της ιδιότητας των αντίστοιχων αντικειμένων συνδυασμού) ή η διαδικασία που εκτελεί ως τις παρουσιάσεις αντικειμένων που σχετίζονται με την αντιπροσωπευτική σχέση, την αλλαγή των κρατών ορισμένων από αυτά. Στην παθητική μορφή, μια τέτοια στάση μπορεί να εκπροσωπείται από μια συγκεκριμένη δομή δεδομένων (η οποία μπορεί να περιλαμβάνει και να αντιπροσωπεύει αντικείμενα που συνδέονται με αυτόν τον λόγο), που ερμηνεύονται με βάση τις εγκριθείσες συμφωνίες σχετικά με τις γενικές διαδικασίες, ανεξάρτητα από τις συγκεκριμένες σχέσεις (για παράδειγμα, μια σχεσιακή βάση δεδομένων ). Σε κάθε περίπτωση, η άποψη της σχέσης καθορίζει ορισμένες ενέργειες επεξεργασίας δεδομένων.
Όταν μελετάτε τον κόσμο του μοντέλου, ο χρήστης μπορεί να λάβει διαφορετικά (ή θέλετε να λάβει) πληροφορίες από τον υπολογιστή. Με μια προσέγγιση, μπορεί να ενδιαφέρεται να λάβει πληροφορίες σχετικά με τις μεμονωμένες ιδιότητες των αντικειμένων του ενδιαφέροντος ή τα αποτελέσματα οποιασδήποτε αλληλεπίδρασης μεταξύ ορισμένων αντικειμένων. Για να γίνει αυτό, διατάζει την ανάπτυξη ενός συγκεκριμένου PS που εκτελεί τις λειτουργίες του που συμφέρον, ή κάποιο σύστημα πληροφοριών, ικανές να εκδίδουν πληροφορίες σχετικά με τις σχέσεις του, χρησιμοποιώντας την αντίστοιχη βάση δεδομένων. Κατά την αρχική περίοδο της ανάπτυξης του εξοπλισμού ηλεκτρονικών υπολογιστών (χωρίς αρκετή υψηλή ισχύς υπολογιστών), αυτή η προσέγγιση στη χρήση υπολογιστών ήταν αρκετά φυσική. Ήταν αυτός που προκάλεσε μια λειτουργική (σχεσιακή) προσέγγιση στην ανάπτυξη του PS, η οποία εξετάστηκε λεπτομερώς στις προηγούμενες διαλέξεις. Η ουσία αυτής της προσέγγισης συνίσταται στη συστηματική χρήση της αποσύνθεσης των λειτουργιών (σχέσεις) για την κατασκευή της δομής των PS και των κειμένων των προγραμμάτων που περιλαμβάνονται σε αυτό. Ταυτόχρονα, τα αντικείμενα που χρησιμοποιούνται για να παραγγείλουν και να εφαρμόζονται λειτουργίες είναι αποσπασματικές (στην ένταση ήχου που είναι απαραίτητες για την εκτέλεση αυτών των λειτουργιών) και στη φόρμα, βολικό να εφαρμόζεται αυτές τις λειτουργίες. Έτσι, δεν δόθηκε με μια σταθερή και επαρκή αναπαράσταση υπολογιστών του μοντέλου κόσμου, του χρήστη που ενδιαφέρεται: η εμφάνιση του στο PS που χρησιμοποιείται θα μπορούσε να είναι για τον χρήστη ένα μάλλον επίπονο καθήκον, προσπαθεί να μικρή επέκταση και τη φύση των πληροφοριών σχετικά με τον μοντέλο κόσμο ενδιαφέροντος. που λαμβάνεται από τέτοια PS, θα μπορούσε να οδηγήσει σε σοβαρό εκσυγχρονισμό. Μια τέτοια προσέγγιση στην ανάπτυξη του PS υποστηρίζεται από την πλειοψηφία των γλωσσών προγραμματισμού, που κυμαίνεται από τις γλώσσες του συναρμολογητή και των διαδικαστικών γλωσσών (Fortran, Pascal) σε λειτουργικές γλώσσες (Lisp) και λογικές γλώσσες προγραμματισμού (Prolog).
Σε μια άλλη προσέγγιση της μελέτης του παγκόσμιου μοντέλου, η χρήση ενός υπολογιστή υπολογιστή μπορεί να ενδιαφέρεται να παρακολουθεί την αλλαγή των κρατικών καταστάσεων ως αποτέλεσμα των αλληλεπιδράσεών τους. Αυτό απαιτεί μια επαρκώς σταθερή παρουσίαση στον υπολογιστή του αντικειμένου του αντικειμένου ενδιαφέροντος και τα συστατικά λογισμικού που εφαρμόζουν τις σχέσεις στις οποίες συνδέεται ρητά αυτό το αντικείμενο. Για την εφαρμογή αυτής της προσέγγισης, έπρεπε να χτίσσω εργαλεία λογισμικού που προσομοιώνουν τις διαδικασίες αλληλεπίδρασης αντικειμένων (μοντέλο κόσμο). Με τη βοήθεια παραδοσιακών εργαλείων ανάπτυξης, αποδείχθηκε ότι ήταν ένα μάλλον επίπονο έργο. Αληθινές, οι γλώσσες προγραμματισμού εμφανίστηκαν ειδικά προσανατολισμένες σε μια τέτοια μοντελοποίηση, αλλά απλοποίησε μόνο εν μέρει το έργο της ανάπτυξης του απαιτούμενου PS. Η αντικειμενική προσέγγιση στην ανάπτυξη του PS είναι πιο πλήρως υπεύθυνη για την επίλυση αυτού του έργου. Η ουσία της συνίσταται στη συστηματική χρήση της αποσύνθεσης αντικειμένων κατά την οικοδόμηση της δομής των PS και των κειμένων των προγραμμάτων που περιλαμβάνονται σε αυτό. Στην περίπτωση αυτή, οι λειτουργίες (αναλογίες) που εκτελούνται από ένα τέτοιο PS εκφράστηκαν μέσω της σχέσης αντικειμένων διαφορετικών επιπέδων, δηλ., Η αποσύνθεση τους εξαρτιόταν σημαντικά από την αποσύνθεση αντικειμένων.
Η ομιλία σχετικά με την προσέγγιση αντικειμένων θα πρέπει επίσης να κατανοεί σαφώς τι είδους αντικείμενα μιλάμε για: Αντικείμενα του μοντέλου κόσμου του χρήστη, σχετικά με την ενημερωτική παρουσίασή τους, σχετικά με τα αντικείμενα του προγράμματος, με τη βοήθεια που χτίστηκε το PS. Επιπλέον, πρέπει να διακριθούν αντικείμενα (αντικείμενα "παθητικά") και τα άτομα ("ενεργά" αντικείμενα).
15.2. Αντικείμενα και θέματα στον προγραμματισμό.
15.3. Αντικείμενο και υποκείμενη προσεγγίσεις στην ανάπτυξη λογισμικού.
Ο Descartes σημείωσε ότι οι άνθρωποι συνήθως έχουν μια αντικειμενική προσανατολισμένη άποψη του κόσμου (Β).
Πιστεύεται ότι ο σχεδιασμός αντικειμενοστρεφής ο σχεδιασμός βασίζεται στις αρχές:
Κατανομή αφαίρεσης
Περιορισμός πρόσβασης,
modularity,
ιεραρχία,
Χαρακτηρισμός
παραλληλισμός,
Σταθερότητα.
Αλλά όλα αυτά μπορούν να εφαρμοστούν με μια λειτουργική προσέγγιση.
Θα πρέπει να διακρίνεται από τα πλεονεκτήματα και τα μειονεκτήματα της γενικής προσέγγισης αντικειμένου και της συγκεκριμένης υπόθεσης - μια προσέγγιση προσανατολισμένη σε αντικείμενο.
Τα πλεονεκτήματα μιας γενικής αντικειμενικής προσέγγισης:
Η φυσική χαρτογράφηση του πραγματικού κόσμου στη δομή του PS (η φυσική αντίληψη των δυνατοτήτων του ατόμου του PS δεν χρειάζεται να "εφεύρει" τη δομή του PS και να χρησιμοποιήσει φυσικές αναλογίες).
Η χρήση επαρκώς σημαντικών δομικών μονάδων του PS (αντικειμένου ως ακεραιότητα των μη κενών ενώσεων, των γευστικών και ανθεκτικών μονάδων).
Μείωση της πολυπλοκότητας της ανάπτυξης του PS μέσω της χρήσης ενός νέου επιπέδου αφαίρεσης (χρησιμοποιώντας την "μη εκτυπώσιμη" ιεραρχία των αφαίρεσης στην ανάπτυξη PS: Ταξινόμηση των αντικειμένων του πραγματικού κόσμου, η μέθοδος αναλογίας στη φύση) όπως ένα νέο επίπεδο κληρονομιάς.
15.4. Προσέγγιση αντικειμένων στην ανάπτυξη μιας εξωτερικής περιγραφής και αρχιτεκτονικής λογισμικού.
Σχεδιασμός αντικειμένων - μια μέθοδος που χρησιμοποιεί αποσύνθεση αντικειμένων. Η αντικειμενική προσανατολισμένη προσέγγιση έχει το δικό της σύστημα υπό όρους ονομασίες και προσφέρει ένα πλούσιο σύνολο λογικών και φυσικών μοντέλων για το σχεδιασμό συστημάτων εξαιρετικά πολυπλοκότητας. .
Προσέγγιση αντικειμένων παρέχεται από αντικειμενοστρεφόμενη ανάλυση (OOA). Το OOA απευθύνεται στη δημιουργία μοντέλων πλησιέστερα στην πραγματικότητα χρησιμοποιώντας μια αντικειμενοστρεφόμενη προσέγγιση. Αυτή η μεθοδολογία στην οποία οι απαιτήσεις σχηματίζονται με βάση τις έννοιες των τάξεων και των αντικειμένων που αποτελούν ένα λεξικό του θέματος. .
Χαρακτηριστικά του αντικειμενικού προγραμματισμού.
Αντικείμενα, τάξεις, συμπεριφορά αντικειμένων, ιδιότητες, συμβάντα.
Λογοτεχνία για τη διάλεξη 15.
15.1. Κ. Futi, Ν. Suzuki. Γλώσσες προγραμματισμού και σχάρα Sciti. - M.: MIR, 1988. Σ. 85-98.
15.2. Ian sommerville. Μηχανική λογισμικού. - Addison-Wesley Publishing Company, 1992. P.? -?
15.3. Θάμνος. Σχεδίαση αντικειμένων με παραδείγματα εφαρμογής: ανά. από τα Αγγλικά - M.: Concord, 1992.
15.4. V.sh.kufman. Γλώσσες προγραμματισμού. Έννοιες και αρχές. M.: Ραδιόφωνο και επικοινωνία, 1993.

Εισαγωγή

1 Ανάπτυξη του αλγορίθμου του έργου και την εφαρμογή των μέσων αυτοματοποιημένου σχεδιασμού

1.1 Ανάλυση της εργασίας

1.2 Επιλογή μεθόδων και ανάπτυξη βασικών λύσεων Αλγορίθμοι

2 Ανάπτυξη του κώδικα λογισμικού που βασίζεται στην τελική προδιαγραφή στο επίπεδο της μονάδας

3. Χρησιμοποιώντας εργαλεία οργάνων στο στάδιο της εντοπισμού σφαλμάτων της μονάδας λογισμικού

4 Διεξάγετε μια ενότητα λογισμικού για ένα συγκεκριμένο σενάριο

5 Εγγραφή τεκμηρίωσης λογισμικού

Συμπεράσματα

Κατάλογος συνδέσμων

Παράρτημα Α.

Διάλεξη 8. Ανάπτυξη μίας μονάδας λογισμικού

8.1. Τη διαδικασία ανάπτυξης μιας μονάδας λογισμικού.

8.2. Δομικός προγραμματισμός.

8.3. Βήμα-βήμα λεπτομερώς και η έννοια του ψευδοκτύου.

8.4. Μονάδα λογισμικού ελέγχου.

Λογοτεχνία για τη διάλεξη 8.

Διάλεξη 9. Ακίνητα απόδειξης ιδιοκτησίας

9.1. Αιτιολόγηση των προγραμμάτων. Υπολογισμός των ιδιοτήτων του προγράμματος.

9.2. Ιδιότητες απλών φορέων εκμετάλλευσης.

9.3. Ιδιότητες βασικών σχεδίων προγραμματισμού.

9.4. Την ολοκλήρωση της εκτέλεσης του προγράμματος.

9.5. Ένα παράδειγμα ιδιοτήτων απόδειξης προγραμμάτων.

Λογοτεχνία για τη διάλεξη 9.

Διάλεξη 10. Λογισμικό δοκιμής και εντοπισμού σφαλμάτων

10.1. ΒΑΣΙΚΕΣ ΕΝΝΟΙΕΣ.

10.2. Αρχές και τύποι εντοπισμού σφαλμάτων.

10.3. Εντολή εντοπισμού εντοπισμού.

10.4. Αυτόνομη εντοπισμός σφαλμάτων της ενότητας.

10.5. Περιεκτικό λογισμικό εντοπισμού σφαλμάτων.

Λογοτεχνία για τη διάλεξη 10.

Διάλεξη 11. Διασφάλιση της λειτουργικότητας και της αξιοπιστίας του λογισμικού

11.1. Λειτουργικότητα και αξιοπιστία ως υποχρεωτικά κριτήρια ποιότητας λογισμικού.

11.2. Εξασφαλίζοντας την πληρότητα του λογισμικού.

11.3. Παρέχοντας ακρίβεια του λογισμικού.

11.4. Εξασφαλίζοντας την αυτονομία του λογισμικού.

11.5. Παρέχοντας βιωσιμότητα λογισμικού.

11.6. Παρέχοντας ασφάλεια λογισμικού.

Λογοτεχνία για τη διάλεξη 11.

Διάλεξη 12. Παροχή ποιότητας λογισμικού

12.1. Τα συνολικά χαρακτηριστικά της διαδικασίας διασφάλισης της ποιότητας λογισμικού.

12.3. Εξασφάλιση της αποτελεσματικότητας του λογισμικού.

Λογοτεχνία για τη διάλεξη 12.

Διάλεξη 13. Τεκμηρίωση του λογισμικού

13.1. Τεκμηρίωση που δημιουργήθηκε στη διαδικασία ανάπτυξης λογισμικού.

13.2. Προσαρμοσμένη τεκμηρίωση λογισμικού.

Λογοτεχνία για τη διάλεξη 13.

Διάλεξη 14. Πιστοποίηση λογισμικού

14.1. Διορισμός πιστοποίησης λογισμικού.

14.2. Τύποι λογισμικού δοκιμών.

14.3. Μέθοδοι αξιολόγησης της ποιότητας του λογισμικού.

Διάλεξη 15. Προσέγγιση της ανάπτυξης λογισμικού

15.1. Αντικείμενα και σχέσεις στον προγραμματισμό. Την ουσία της προσέγγισης αντικειμένου στην ανάπτυξη λογισμικού.

15.2. Αντικείμενα και θέματα στον προγραμματισμό.

15.3. Αντικείμενο και υποκείμενη προσεγγίσεις στην ανάπτυξη λογισμικού.

15.4. Προσέγγιση αντικειμένων στην ανάπτυξη μιας εξωτερικής περιγραφής και αρχιτεκτονικής λογισμικού.

Λογοτεχνία για τη διάλεξη 15.