Dezvoltarea unui modul software. Programare structurală. PM.01. Dezvoltarea modulelor software pentru sisteme informatice Modul Software Program Dezvoltarea modulelor software software
Adnotarea programului de lucru al modulului profesional
numele modulului profesional
1. Domeniul de aplicare al programului
Programul de lucru al modulului profesional face parte din programul de specialitate la nivel mediu în conformitate cu GEF Spo 09.02.07 sisteme informatice și programare incluse în grupul integrat de specialități 09.00.00 Informatică și computere
și competențele profesionale relevante (PC):
Programul de lucru al modulului profesional poate fi utilizat în pregătirea specialiștilor în cursul "Dezvoltarea modulelor software ale software-ului pentru sistemele informatice" pe baza educației generale de bază. Experiența de lucru nu este necesară.
Programul de lucru este compilat pentru corespondență cu normă întreagă, corespondența cu elemente ale tehnologiilor educaționale la distanță pentru formularele de formare.
2. Obiectivele și obiectivele modulului - Cerințe pentru rezultatele modulului
Ca urmare a dezvoltării părții obligatorii a modulului, elevul trebuie să aibă experiență practică:
Dezvoltarea unui algoritm pentru sarcina și implementările prin mijloacele sale de design automatizat;
Dezvoltarea codului software pe baza specificației finalizate la nivelul modulului;
Utilizarea instrumentelor la etapa de depanare a programului;
Testarea unui modul software pentru un anumit scenariu.
Ca urmare a dezvoltării părții obligatorii a modulului, elevul trebuie să poată:
Pentru a dezvolta un cod de modul software în limbile moderne de programare;
Creați un program pe un algoritm dezvoltat ca un modul separat;
Executați depanarea și testarea programului la nivelul modulului;
Elaborarea documentației pentru software;
Utilizați instrumentele de instrumente pentru automatizarea documentației.
Ca urmare a dezvoltării părții obligatorii a modulului, elevul trebuie să știe:
Principalele etape ale dezvoltării software-ului;
Principiile de bază ale tehnologiei de programare structurale și orientate pe obiecte;
Principiile de bază ale produselor software de depanare și testare;
Metode și mijloace de dezvoltare a documentației tehnice.
6. Dezvoltarea codului software folosind programarea structurală
7. Dezvoltarea unui cod de program utilizând detaliile pas cu pas
8. Dezvoltarea codului software utilizând programarea modulară
9. Inițializarea armelor
10. Implementarea structurilor dinamice cu matrice
11. Dezvoltarea codului software folosind structuri
12. Dezvoltarea codului software folosind funcții
13. Dezvoltarea codului software utilizând semnalizarea
14. Implementarea I / O
15. fluxurile de fișiere
16. Datele de șir.
17. Dezvoltarea clasei statice
18. Dezvoltarea claselor dinamice
19. Dezvoltarea claselor abstracte
20. Dezvoltarea șabloanelor de clase
21. Efectuarea depanării codului de program
22. Efectuarea de sortare prin bule
23. Efectuarea de sortare prin introducerea prin metodă
24. Efectuarea unei sortare de către HOARE
25. Efectuați testarea codului programului prin principiul "casetei albe"
26. Realizarea unui cod de program de testare cu un principiu "cutie gri"
27. Efectuarea unei teste de cod de program prin principiul "casetei negre"
28. Implementarea optimizării codului programului
29. Implementarea optimizării motorului de căutare a codului programului
30. Elaborarea documentației tehnice
31. Elaborarea algoritmilor pentru muncă cu grafică
32. Inițializarea sistemului grafic
33. Lucrați cu ferestre și coordonate
34. Lucrați cu primitive grafice
35. Crearea unei imagini de animație
36. Elaborarea documentației utilizatorului
Ministerul Educației și Științei
Republica Populară Donetsk
Profesionist de stat
INSTITUȚIE EDUCAȚIONALĂ
"Colegiul Industrial și Economic" Donetsk "
Program de lucru
Practica educațională UE.01.
modul profesional PM.01 Dezvoltarea modulelor software pentru sisteme informatice
specialitatea 09.02.03 "Programare în sisteme informatice"
Compilatoare:
Volkov Vladimir Alexandrovich, profesor de discipline de calculator din categoria de calificare "Specialist al categoriei superioare", GPO "Donetsk Industrial și Economic College"
Programul este convenit asupra: Pavel Andreevich VKV, director "Smart It Service"
| 1. Pașaportul practicilor practice | |
| 2. Practicați rezultatele | |
| 3. Structura și conținutul practicii | |
| 4. Condiții de organizare și desfășurare a practicii | |
| 5. Controlul și evaluarea rezultatelor practicii |
1 pașaport al programului de practică de formare UE. 01.
1.1 Locul practicilor educaționale UE.01
Programul de practică de instruire a modulului profesional UD.01 PM.01 "Dezvoltarea modulelor software de software pentru sistemele informatice" Specialitatea 09.02.03 "Programare în sisteme informatice » grupul extins 09.00.00 "Tehnică informatică și computing", în ceea ce privește mastering tipul principal de activitate profesională (VDD):
Dezvoltarea modulelor software pentru sisteme informatice și competențe profesionale relevante (PC):
| Efectuați dezvoltarea specificațiilor componentelor individuale. |
|
| Implementați dezvoltarea unui cod de produs software bazat pe specificațiile pregătite la nivelul modulului. |
|
| Module de program de mașină utilizând software specializat. |
|
| Testarea modulelor software. |
|
| Optimizați codul software al modulului. |
|
| Dezvoltați componentele proiectului și documentației tehnice utilizând specificațiile limbajului grafic. |
Programul de practică educațională a Modulului PM.01 profesional PM.01 "Dezvoltarea modulelor software de software pentru sistemele informatice" poate fi utilizată în educație profesională suplimentară și formare profesională a lucrătorilor pentru specialități 09.02.03 Programarea în sistemele informatice în prezența a educație generală medie (completă). Experiența de lucru nu este necesară.
1.2 Obiective și sarcinipractica educațională UE.01.
Pentru a stăpâni tipul specificat de activitate profesională și competențele profesionale relevante, studentul în timpul practicii de formare a UD.01 ar trebui:
au o experiență practică:
dezvoltarea unui algoritm pentru sarcina și implementarea acestuia prin design automatizat;
dezvoltarea codului software pe baza specificației finalizate la nivelul modulului;
utilizarea instrumentelor la etapa de depanare a programului;
testarea modulului de program pe un anumit scenariu;
a fi capabil să:
pentru a dezvolta un cod de modul software în limbile moderne de programare;
creați un program pe un algoritm dezvoltat ca un modul separat;
executați depanarea și testarea programului la nivelul modulului;
elaborarea documentației pentru software;
utilizați instrumente instrumentale pentru automatizarea documentației;
știți:
principalele etape ale dezvoltării software-ului;
principiile de bază ale tehnologiei de programare structurale și orientate pe obiecte;
principiile de bază ale produselor software de depanare și testare;
metode și mijloace de dezvoltare a documentației tehnice.
1.3 Numărul de săptămâni(ceas) pentru dezvoltarea programuluipractica educațională UE.01.
Doar 1,5 săptămâni, 54 de ore.
2 rezultate practice
Rezultatul practicii de instruire a modulului profesional UD.01 PM.01 "Dezvoltarea modulelor software de software pentru sistemele informatice" este dezvoltarea competențelor generale (OK):
| Numele rezultatului practicii |
|
| - |
|
| OK 2. Organizați-vă propria activitate, alegeți metode și metode tipice pentru îndeplinirea sarcinilor profesionale, evaluați eficacitatea și calitatea acestora. | |
| OK 3. Să ia decizii în situații standard și non-standard și să fie responsabil pentru acestea. | |
| OK 4. Pentru a căuta și a utiliza informațiile necesare pentru a îndeplini efectiv sarcinile profesionale, dezvoltarea profesională și personală. | |
| OK 5. Utilizați tehnologiile informației și comunicațiilor în activitățile profesionale. | |
| OK 6. Lucrați în echipă și lucrul în echipă, comunicați eficient cu colegii, managementul, consumatorii. | |
| OK 7. Să-și asume responsabilitatea pentru activitatea membrilor echipei (subordonați), pentru rezultatul sarcinilor. | - |
| calificări |
|
| OK 9. Concentrați-vă în condiții de schimbare frecventă a tehnologiei în activitățile profesionale. |
competențe profesionale (PC):
| Tipul activității profesionale | Numele rezultatelor practicilor |
|
| Mastering tipul principal de activitate profesională | utilizarea resurselor rețelelor de calculatoare locale și globale; gestionarea fișierelor de date pe dispozitive de stocare locale, detașabile, precum și pe discurile rețelei de calculatoare locale și pe Internet; imprimare, replicare și copiere documente pe imprimantă și alte echipamente de birou. controlul curent sub forma unui raport pentru fiecare lucrare practică. modul de calificare de examen. |
|
| adevăr și precizie de lucru în aplicații: editori textuale și grafice, baze de date, editor de prezentare; căutarea rapidă a informațiilor în conținutul bazelor de date. |
||
| setări de e-mail de precizie și de alfabetizare, Server și Software client: viteza de căutare a informațiilor utilizând tehnologii și servicii de internet; precizia și alfabetizarea introducerii și transmiterii informațiilor utilizând tehnologii și servicii de internet. |
||
| alfabetizarea utilizării metodelor și a mijloacelor de protejare a informațiilor de la accesul neautorizat; corectitudinea și acuratețea backup-ului și recuperarea datelor; |
||
| altecare și precizie de lucru cu sisteme de fișiere, diverse formate de fișiere, programe de gestionare a fișierelor; |
||
| menținerea documentației de raportare și tehnică. |
3 Structura și conținutul programuluiPractica educațională UE.01.
3.1 Planul tematic
| Codurile au format competențe | Numele modulului profesional | Volumul de timp, a fost mutat la practică (în săptămâni, ceas) | Date de transport |
| PC 1.1 - PC 1.6 | PM.01 "Dezvoltarea modulelor software pentru sisteme informatice" | 1,5 săptămâni, 54 de ore |
3.2 Practica de conținut
| Activități | Tipuri de locuri de muncă | Numele disciplinelor educaționale, cursuri interdisciplinare care indică, furnizarea de performanță | Numărul de ore (săptămâni) |
|
| "Mastering tipul principal de activitate profesională » | Subiect 1. Introducere Sarcini de rezolvare a algoritmilor. Structura unui algoritm liniar. Structura algoritmului ciclic. Algoritmul de subrutină (funcții). | Cunoașterea pentru elementele de bază ale creării obiectelor speciale | ||
| Subiect2 . Miercuri Skratch (Scratch). | Cunoștințele privind elementele de bază ale procesului de automatizare a procesului sunt formate din cunoștințe privind elementele de bază ale efectelor de animație asupra obiectelor; Folosind hyperlink-uri și butoane; Stabilirea demonstrației; Prezentări stocate în diferite formate. | MDC.01.01 "Programare sistem" | ||
| Subiect 3 . Crearea unui program de instruire (lecție de la subiect). | Cunoașterea bazelor de analiză a cunoștințelor utilizând funcțiile procesorului | MDK.01.02 "Programarea aplicațiilor" | ||
| Subiect 4. Dezvoltarea unui program de jocuri. | Cunoașterea elementelor de bază Calculează caracteristicile finale sunt formate. | MDC.01.01 "Programare sistem" | ||
| Subiect 5. Limba de programare grafic Labview. | Cunoașterea bazată pe elementele de bază ale testului procesorului. | MDK.01.02 "Programarea aplicațiilor" | ||
| Subiect 6. Crearea unei aplicații utilizând LabVIEW. | Cunoașterea cunoștințelor despre elementele de bază ale dialogului utilizator cu sistemul | MDK.01.02 "Programarea aplicațiilor" | ||
| Subiect 7 Utilizarea multiplă a fragmentului programului. | Cunoașterea operatorilor și a funcțiilor sistemului sunt formate. | MDK.01.02 "Programarea aplicațiilor" | ||
| Subiect 8 Workshop pe LabView. Protecția muncii atunci când lucrați cu un computer la locul de muncă al utilizatorului. | Se formează cunoașterea calculelor funcțiilor elementare. Cunoașterea cunoașterii muncii. | MDK.01.02 "Programare aplicație". OP.18 "Protecția muncii" | ||
| Subiect 9 Concluzii. Elaborarea unui raport privind practica. | Abilitatea de a analiza tehnologiile informatice formate, soluțiile de sarcini formate. | MDC.01.01 "Programare sistem" MDK.01.02 "Programarea aplicațiilor" MDK.04.01 "Software de birou" |
4 Termeni de organizare și comportament
Practica de învățare UE. 01.
4.1 Cerințe pentru documentație, necesare pentru practică:
Programul de lucru al practicii educaționale UE.01 Modul profesional PM.01. "Dezvoltarea modulelor software pentru sistemele informatice" face parte din programul de formare specialist la nivel mediu de către instituția de învățământ profesional de stat "Colegiul Industrial și Economic" Donetsk ", în conformitate cu standardul educațional de stat al învățământului secundar profesional în specialitatea 09.02.03" Programarea în sisteme informatice ", pe baza curriculumului din specialitate, Programul de lucru pe discipline MDC.01.01" Programarea sistemului ", MDK01.02" Programare aplicată ", recomandări metodologice pentru sprijinul educațional și metodic al practicii studenților, dezvoltând programe educaționale de învățământul profesional secundar.
4.2 Cerințe pentru practica educațională:
lista sarcinilor aprobate pe tipuri de muncă, orientări pentru studenți pentru a îndeplini lucrările, recomandări pentru implementarea rapoartelor de raportare.
4.3 Cerințe materiale:
organizarea practicii industriale necesită disponibilitatea cabinetelor și laboratorului.
Cabinet și locuri de muncă:
scaune în numărul de studenți (tabel, calculator, scaun);
locul de muncă al profesorului (tabel, calculator, scaun);
cabinet pentru stocarea beneficiilor educaționale și vizuale și a mass-media;
sarcini pentru o abordare individuală în învățare, organizarea de muncă independentă și exerciții, student pe un computer;
referință și literatură metodică;
un set de programe de sistem, aplicate și de instruire pentru PC-uri pe suporturi optice și electronice;
jurnalul de Briefing Muncii;
un set de ajutoare educaționale și vizuale.
Instrumente tehnice de învățare:
pC-uri de instruire;
set de echipamente interactive (proiector, ecran, coloane);
mijloace de stingere a incendiilor (stingător de incendiu).
consiliul de audit;
computer personal cu software licențiat;
imprimanta laser;
Echipamente ale cabinetului și locurilor de lucru Instrumente de dezvoltare: Calculatoare personale (monitor, bloc de sistem, tastatură, mouse), un set de documentație educațională și metodologică, software în conformitate cu conținutul disciplinei (coajă limbilor de programare).
Toate computerele din clasă sunt combinate în rețeaua locală, au acces la stocarea în rețea a informațiilor și au acces la Internet.
Echipamente de comunicare:
adaptoare de rețea;
cabluri de rețea;
echipament wireless WiFi.
Componente de montare, echipamente de instalare.
4.4 Lista publicațiilor de formare, Resurse Internet., literatură suplimentară
Principalele surse:
Olifer V.G. Sisteme de operare de rețea: tutorial pentru universități / V.G. Voli, N.A. Volifer. - A doua ed. - St. Petersburg: Peter, 2009, 2008. - 668 p.:
E. Tannbaum. OS. Dezvoltare și implementare. Sankt Petersburg: Peter, 2006. - 568 p.
Pupkov K.A. Dezvoltarea sistemului de operare Unix / K.A. Pupkov, A.S. CHERIKOV, N.M. YAKUSHEV. - Moscova: radio și comunicare, 1994. - 112 p.
L. Beck Introducere în programarea sistemului - M: Mir, 1988.
Grekul V.I., Denischenko G.N., Korovkina N.L. Proiectarea sistemelor informatice / Moscova: Binom, 2008. - 304 p.
Lipaev, V.V. Inginerie software. Fundații metodologice [Text]: Studii. / V. V. LIPAEV; Stat Universitatea - Școala de Economie Superioară. - M.: THEIS, 2006. - 608 p.
Lavryshcheva E. M., Petrukhin V. A. Metode și mijloace de software de inginerie. - Tutorial
Ian Sommerville. Software-ul de inginerie, ediția a 6-a.: Per. din engleza -M. : Editura "Williams", 2002.-624 p.
Excel 2010: Programare profesională pe VBA: per. din engleza - M.: LLC "I.D. Williams, 2012. - 944 p. : Il. - Paral. Tit. Engleză
Fowler M. Refactoring: Îmbunătățirea unui cod existent. Pen. De la engleza-spb: simbol-plus, 2003.-432 s.
Surse suplimentare:
Volkov V.A. Instrucțiuni metodice pentru implementarea lucrărilor practice privind disciplina "Programarea sistemului", Donetsk: Donpek, 2015.
Volkov V.A. Instrucțiuni metodice pentru implementarea proiectului cursului, Donetsk: Donpek, 2015.
Internetul- resurse:
Programarea sistemului [Resurse electronice] / Mod de acces: http://www.umk3.utmn.ru.
Resurse de software și Internet: http://www.intuit.ru
Literatură privind disciplina - http://www.internet-tehnologys.ru/books/
Materialul electronic "Introducere în ingineria software" - http://www.intuit.ru/studies/profesional_skill_improvements/1419/info
Tehnica electronică "Tehnologie de programare" -Http: //bourabai.kz/alg/pro.htm
4.5 Cerințe pentru directorii manuali din instituția și organizarea educațională
Cerințe pentru directorii manuali de la instituția de învățământ:
inginerie și compoziție pedagogică: specialiști certificați - profesori de cursuri interdisciplinare și discipline profesionale generale. Experiența în organizațiile din sfera profesională relevantă este obligatorie.
Master of Production Formare: Prezența de 5-6 descărcare de gestiune cu stagiu obligatoriu în organizațiile specializate de cel puțin o dată în 3 ani. Experiența în organizațiile din sfera profesională relevantă este obligatorie.
5 Controlul și evaluarea rezultatelor
Practica de învățare UE. 01.
Forma de raportare privind practica educațională UE.01 este un raport de practică, decorat în conformitate cu cerințele recomandărilor metodologice.
| Rezultate (Competențe profesionale dezvoltate) | Principalii factori pregătirea rezultatelor | Forme și metode control |
| PC 1.1. Efectuați dezvoltarea de specificații ale componentelor individuale | Dezvoltarea unui algoritm pentru sarcina și implementarea mijloacelor sale de design automatizat | Observarea experților și evaluarea activităților studenților în procesul de stăpânire a programului educațional în clase practice, atunci când efectuează lucrări privind practica educațională și industrială. |
| PC 1.2. Implementați dezvoltarea unui cod de produs software bazat pe specificațiile pregătite la nivelul modulului. | Cunoașteți principiile de bază ale tehnologiei de programare structurale și orientate pe obiecte. Implementați codul modulului software în limbile moderne de programare. |
|
| PC 1.3. Pentru a depana module de program utilizând software specializat | Faceți o depanare și testare a programului la nivelul modulului. |
|
| PC 1.4. Testarea modulelor software. | Creați un program în funcție de algoritmul dezvoltat ca un modul separat. |
|
| PC 1.5. Optimizați codul programului al modulului | Dezvoltarea codului software bazat pe specificația finalizată la nivelul modulului. |
|
| PC 1.6. Dezvoltați componentele proiectului și documentației tehnice utilizând specificațiile limbajului grafic | Cunoașteți metodele și mijloacele de dezvoltare a documentației tehnice. Înregistrați documentația pentru software. Utilizați instrumentele de instrumente pentru automatizarea documentației. |
Formele și metodele de monitorizare și evaluare a rezultatelor învățării ar trebui să vă permită să verificați nu numai formarea competențelor profesionale, ci și dezvoltarea competențelor generale și asigurarea competențelor acestora.
| Rezultate (Competențe generale de stăpânire) | Principalii indicatori ai evaluării rezultatului | Forme și metode de control și evaluare |
| OK 1. Înțelegeți esența și importanța socială a profesiei viitoare, pentru a arăta un interes durabil. | Manifestarea interesului constant în profesia viitoare; - valabilitatea utilizării competențelor profesionale dezvoltate; | Observarea și evaluarea experților în clasele practice în desfășurarea lucrărilor privind practica industrială; |
| OK 2. Organizați-vă propriile activități, identificați metodele și metodele de efectuare a sarcinilor profesionale, pentru a evalua eficiența și calitatea acestora. | Justificare a scopului scopului, alegerii și aplicării metodelor și metodelor de soluționare a sarcinilor profesionale; Efectuarea de auto-analiză și corectarea rezultatelor propriilor lucrări | Evaluarea în clasele practice la desfășurarea muncii; Observarea în timpul practicii; Auto-analiză |
| OK 3. Rezolvați problemele, evaluați riscurile și luați decizii în situații non-standard. | Eficacitatea procesului de luare a deciziilor de sarcini profesionale standard și non-standard pentru o anumită perioadă de timp; Performanța planului de optimizare a calității muncii efectuate | Interpretarea rezultatelor observării activității studiului în procesul de îndeplinire a sarcinilor |
| OK 4. Pentru a căuta, analiza și evalua informațiile necesare stabilirii și soluționării sarcinilor profesionale, a dezvoltării profesionale și personale. | Selectarea și analiza informațiilor necesare pentru o performanță clară și rapidă a sarcinilor profesionale, a dezvoltării profesionale și personale | Evaluarea experților în cursul muncii; Auto-control în cursul formulării și rezolvarea problemelor |
| OK 5. Folosiți tehnologii de informare și comunicare pentru a îmbunătăți activitățile profesionale. | abilitatea de a utiliza tehnologii de informare și comunicare pentru a rezolva sarcini profesionale | evaluarea sarcinilor |
| Ok 6. Lucrați în echipă și în echipă, asigurați-vă coeziunea, comunicați eficient cu colegii, gestionarea, consumatorii. | Abilitatea de a interacționa cu un grup, profesori, atelier de formare de producție | |
| Ok 7. Stabiliți obiective, motivați activitățile subordonatelor, organizați și controlați munca lor cu adoptarea responsabilității pentru rezultatul sarcinilor. | - efectuarea de auto-analiză și corectarea rezultatelor propriilor lor lucrări și activitatea echipei | Observarea cursului de lucru în grup în procesul de practică industrială |
| OK 8. Identificați în mod independent sarcinile dezvoltării profesionale și personale, de a se angaja în auto-educație, intenționează conștient să planifice formarea avansată. | Organizarea de lucrări independente privind formarea imaginii creative și profesionale; Organizarea de lucru privind auto-educația și creșterea calificări | Observarea și evaluarea în procesul de practică industrială; Analiza reflexivă (algoritmul acțiunilor de învățare); Practicați jurnalul; Analiza portofoliului de studenți |
| OK 9. Fiind pregătit pentru schimbarea tehnologiei în activități profesionale. | Analiza inovării în domeniul proceselor tehnologice de dezvoltare și fabricare a produselor de cusut | Evaluarea soluțiilor de luare a deciziilor; Jocuri de afaceri și organizaționale și educaționale; Observarea și evaluarea în clasele practice, în procesul de practică industrială |
ESEU
Controlul lucrării proiectului PM.01 "Dezvoltarea modulelor software pentru sistemele informatice". Bugetul de stat instituția de învățământ profesională a Republicii Crimeea "Academia Tehnică Politehnică Feodosia". 2015 -20 s. Ilustrații 7, apendicele 1, sursele bibliografice 3.
Instrumentul software proiectat și implementat "Acțiuni pe matrice", a dezvoltat o interfață grafică în mediuMicrosoft Visual Studio Ultimate 2013 C # Produsul software vă permite să studiați structura și sintaxa noilor limbi de programare.
Software, sarcină tehnică, testarea funcțională, testarea estimată, testarea structurală, dezvoltarea, depbugarea, algoritmul, interfața
|
Introducere 1 Dezvoltarea algoritmului sarcinii și implementarea mijloacelor sale de design automatizat 1.1 Analiza sarcinii 1.2 Selectarea metodelor și dezvoltarea algoritmilor de soluții de bază 2 Dezvoltarea codului software bazat pe specificația finalizată la nivelul modulului 3. Utilizarea instrumentelor instrumentale în stadiul depanării modulului software 4 Realizarea unui modul software pentru un anumit scenariu 5 Înregistrarea documentației software Lista de link-uri Anexa A. |
Introducere
Fiecare produs software constă din module. Modulul poate fi dezvoltat separat și, astfel, pentru a îmbunătăți software-ul, îmbunătățind funcționalitatea acestuia.
Scopul lucrării este:
- Fixarea cunoștințelor teoretice rezultate asupra disciplinelor. Programarea aplicațiilor, programarea sistemului, teoria algoritmilor, elementele de bază ale programării și limbile algoritmice ";
- Colectarea, analiza și generalizarea materialelor pentru pregătirea raportului de practică.
Sarcinile muncii se datorează sarcinii individuale:
- analiza sarcinii;
- alegerea metodelor și dezvoltarea algoritmilor de soluții de bază;
- selectarea tehnologiei și a mediului de programare;
- construirea unui cadru de aplicație și un design de interfață utilizator;
- dezvoltarea unui cod de produs software bazat pe specificațiile finalizate;
- selectarea strategiilor de testare și testare;
- utilizarea instrumentelor de depanare transmise de interfața cu utilizatorul;
- efectuarea testelor modulului software pe un anumit scenariu;
- Înregistrarea documentației software.
Lucrarea este formată din cinci secțiuni.
Prima secțiune descrie dezvoltarea unui algoritm pentru sarcina și implementarea mijloacelor sale de design automatizat.
În cea de-a doua secțiune, selectarea mediului de programare este descrisă de interfața de utilizator proiectată, iar codul produsului software a fost dezvoltat.
În cea de-a treia secțiune, este descrisă utilizarea instrumentelor la modulul de fixare.
În cea de-a patra secțiune, testarea modulului de testare este descrisă, caracterizată de testare funcțională, structurală, estimată.
Cea de-a cincea secțiune este dedicată proiectării documentației pentru software.
1 Dezvoltarea algoritmului sarcinii și implementarea mijloacelor sale de design automatizat
1.1 Analiza sarcinii
Este necesar să scrieți un program care să efectueze acțiuni pe matrice: multiplicare, adăugare, scădere, transpuneri. Programul trebuie să rezolve matricea introdusă manual în formă. Pentru confortul utilizatorului, programul trebuie să aibă o interfață intuitivă.
1.2 Selectarea metodelor și dezvoltarea algoritmilor de soluții de bază
Programul utilizează următorul algoritm de lucru: în program există forme în care sunt introduse elementele matricelor, elementele sunt traduse dinString tip în număr întreg . Apoi, trebuie să apăsați butonul de acțiune corespunzător. Algoritmul de soluții matrice sunt efectuate și rezultatul este afișat în element.Datagridview.
Pentru a construi cursuri de flux, a fost utilizat un programMicrosoft Office Visio. 2013. Cu ajutorul său, puteți constitui diferite diagrame și scheme, inclusiv diagrame bloc.
Figura 1.1 - Diagrama blocului de citire și scriere a datelor dintr-o înregistrare de matrice
Figura 1.2 - Verificați accesibilitatea pentru intrare
Figura 1.3 - Diagrama de intrare blocată încasetă de text. și comparații cu o matrice existentă
Figura 1.4 - Apelul metodeiVizov cu parametri
2 Dezvoltarea codului software bazat pe specificația finalizată la nivelul modulului
Calculatorul de matrice este implementat în limba de programare C # în mediul de programare Microsoft Visual Studio Ultimate 2013. Selecția C # se datorează faptului că este un limbaj de programare modern și popular al obiectului, iar Microsoft Visual Studio Ultimate 2013 Mediul este un instrument puternic care vă permite să creați rapid un program cu un instrument puternic. Interfață de fereastră grafică.
Aspectul ferestrei este prezentat în Figura 2.1
Figura 2.1 - Interfață fereastră viitoare
3 elemente sunt situate pe formularDatagridview. Matricele vor fi plasate în ele. De asemenea, 4.Buton. Pentru a efectua acțiuni pe matrice.
3. Utilizarea instrumentelor instrumentale în stadiul depanării modulului software
La depanarea unui produs software, trebuie să utilizați comanda Meniu Debug (figura 3.1). Meniul de depanare există o serie de comenzi, al cărui scop este prezentat mai jos.
Figura 3.1 - Depanarea ferestrei de meniu
Fereastra deschide punctul de oprire în mediul integrat, care oferă acces la toate punctele de oprire a acestei soluții. Afișează o fereastră de ieșire într-un mediu integrat.
Fereastra de ieșire este jurnalul de funcționare al unui set de mesaje emise de mediul integrat, compilatorul și debuggerul. Prin urmare, aceste informații se referă nu numai la depanarea sesiunii și, de asemenea, deschide o fereastră de interpretare într-un mediu integrat care permite comenzilor:
- Începeți Debugging - Începe aplicația în modul Debug;
- alăturați-vă procesului - vă permite să atașați debuggerul procesului executabil (fișier executabil). De exemplu, dacă aplicația este lansată fără depanare, atunci puteți apoi să vă atașați la acest proces executabil și să începeți depanarea;
- excepții, deschide o casetă de dialog Excepție care vă permite să selectați o metodă de oprire a debuggerului pentru fiecare stare excepțională;
- un pas cu o ocupare rulează aplicația în modul Debug. Pentru majoritatea proiectelor, selectarea pasului de comandă cu o ocazie înseamnă a apela debuggerul pe prima linie executabilă a cererii. Astfel, puteți introduce aplicația de la prima linie;
- pas cu bypassing - atunci când nu te afli în sesiunea de depanare, atunci echipa de comuniune lansează doar aplicația la fel ca butonul de alergare;
- punctul oprește - include sau dezactivează punctul de oprire de pe șirul curent al codului editorului de text. Această opțiune este inactivă dacă nu există fereastră de cod activ în mediul integrat;
- creați un punct STOPS - Activează caseta de dialog Creare dialog care vă permite să specificați numele funcției pentru care doriți să creați un punct de oprire;
- Ștergeți toate punctele rămâne - elimină toate punctele de oprire din soluția curentă;
- Ștergeți toate solicitările conform datelor - dezactivează (fără ștergere) toate punctele de oprire a soluției curente;
- parametrii și setările - Execuția de întrerupere Când excepțiile traversează frontiera domeniului aplicației sau granița dintre codul controlat și cel al mașinii.
4 Realizarea unui modul software pentru un anumit scenariu
Testarea estimată, care se numește și "Testarea sistemului ca întreg"a cărei scop este de a testa programul pentru respectarea cerințelor de bază. Această etapă de testare este deosebit de importantă pentru produsele software.Include următoarele tipuri:
- utilizabilitatea de testare - o verificare consecventă pentru conformitatea produsului software și documentația cu privire la acestea principalele dispoziții ale sarcinii tehnice;
- testarea pe margini - verificarea performanței programului pe cantitatea maximă de date, de exemplu, texte, tabele, un număr mare de fișiere etc.;
- testarea sarcinilor limită - verificarea executării programului pentru a gestiona o cantitate mare de date primite pentru o perioadă scurtă de timp;
- testarea înființării - Analiza factorilor psihologici care apar la lucrul cu software-ul; Această testare vă permite să determinați dacă interfața este convenabilă, dacă suportul de culoare sau sunet este iritat, etc.;
- testarea protecției - verificarea protecției, de exemplu, de la accesul neautorizat la informații;
- testarea performanței - definiția lățimii de bandă pentru o anumită configurație și sarcină;
- testarea cerințelor de memorie - definirea nevoilor reale în memoria operațională și externă;
- configurarea echipamentului de testare - Testarea performanței software pe diferite echipamente;
- testarea compatibilității - Verificarea continuității versiunilor: În cazul în care următoarea versiune a sistemului modifică formatele de date, ar trebui să includă convectoare speciale, oferind capacitatea de a lucra cu fișierele create de versiunea versiunii anterioare;
- instalarea instalațiilor de testare - verificarea confortului de instalare;
- testarea fiabilității - verificarea fiabilității utilizând modele matematice;
- testarea recuperării - verificarea recuperării software-ului, cum ar fi sistemele care includ o bază de date, după eșecurile și programul echipamentului;
- serviciul de testare a confortului - verificarea instalațiilor de întreținere incluse în software;
- testarea documentației este o verificare aprofundată a documentației, de exemplu, dacă documentația conține exemple, atunci toți trebuie să încerce;
- proceduri de testare - Verificarea proceselor manuale asumate în sistem.
Firește, scopul tuturor acestor verificări este de a găsi inconsecvențe în ceea ce privește atribuirea tehnică. Se crede că numai după efectuarea tuturor tipurilor de testare, produsul software poate fi trimis utilizatorului sau pentru a implementa. Cu toate acestea, în practică, nu toate tipurile de testare de evaluare sunt de obicei efectuate, deoarece este foarte scump și laborios. De regulă, pentru fiecare tip de software, se efectuează acele tipuri de testare care sunt cele mai importante pentru aceasta. Deci, bazele de date sunt testate în mod necesar pe volumele maxime, iar sistemele în timp real sunt pe sarcini maxime.
5 Înregistrarea documentației software
Produsul software creat este conceput pentru a efectua acțiuni aritmetice asupra matricelor.
Pentru a porni programul trebuie să porniți aplicația.
Pentru a crea matrice, trebuie să introduceți dimensiunea matricei și să apăsați butoanele "Build". Apoi introduceți datele din matrice și selectați acțiunea dorită.
Figura 5.1 - Cerere de lucru
Programul are o interfață convenabilă și oferă o oportunitate de a rezolva cu ușurință matricele de dimensiuni arbitrare.
Concluzii
În cursul lucrării, a fost finalizată o sarcină individuală:
- a fost efectuată o analiză a zonei subiectului;
- soluțiile selectate și dezvoltate dezvoltate și dezvoltate de algoritm;
- tehnologia definită și mediul de programare sunt selectate;
- cadrul de aplicații este construit și interfața cu utilizatorul este proiectată;
- a fost dezvoltat un cod de modul software;
- sunt descrise instrumentele de depanare utilizate în timpul testării;
- modulul software este testat pe un scenariu specific;
- element de meniu adăugat cu o scurtă descriere a lucrărilor cu programul.
Obiectivele realizate.
Lista de link-uri
1 Forum Cyber \u200b\u200b[Resurse electronice]:http: // cyberforum. RU.
2 Dezvoltator Microsoft. [Documentația oficială MicrosoftC #] TTPS: // msdn. Microsoft. Com.
3 http://programming-edu.ru/ Blog Aid pentru începători cu #
Anexa A.
Codul programului.
MyMatrix. CS.
folosind sistemul;
folosind sistemul.Linq;
utilizând System.Text;
utilizând System.Windows.Forms;
matricea spațiului de nume.
MyMatrix de clasă.
Int [,] a \u003d nou int;
// Transferul valorilor
Public VOID SET (INT I, INT J, INT ZNNACH)
A \u003d znach;
// plus.
Public Static MyMatrix Operator + (MyMatrix Matrix1, MyMatrix Matrix2)
Pentru (int i \u003d 0; i< 3; i++)
Pentru (int j \u003d 0; j< 3; j++)
Newmatrix.a \u003d matrix1.a + matrix2.a;
Return NewMatrix;
// Concluzie a matricei
String public vizual (int i, int j)
Întoarcere a.tostring ();
// Concluzie pentru întreaga și imediat. Hd.
Public Datagridview Fullvisual (DatagridView DT)
Pentru (int i \u003d 0; i< 3; i++)
Pentru (int j \u003d 0; j< 3; j++)
Dt.rotă [j] .valls [i] .val \u003d a;
Retur dt;
// subdundul
Operatorul static al MyMatrix static - (MyMatrix Matrix1, MyMatrix Matrix2)
MyMatrix NewMatrix \u003d New MyMatrix ();
Pentru (int i \u003d 0; i< 3; i++)
Pentru (int j \u003d 0; j< 3; j++)
NewMatrix.A \u003d Matrix1.a - Matrix2.a;
Return NewMatrix;
// transpunerea
Mymatrix Trans ()
MyMatrix NewMatrix \u003d New MyMatrix ();
Pentru (int i \u003d 0; i< 3; i++)
Pentru (int j \u003d 0; j< 3; j++)
Newmatrix.a \u003d a;
Return NewMatrix;
// multiplicare
Public Static MyMatrix Operator * (MyMatrix Matrix1, MyMatrix Matrix2)
MyMatrix NewMatrix \u003d New MyMatrix ();
Pentru (int i \u003d 0; i< 3; i++)
Pentru (int k \u003d 0; k< 3; k++)
// int a \u003d 0;
Pentru (int j \u003d 0; j< 3; j++)
// a + \u003d matrix1.a * matrix2.a;
NewMatrix.A + \u003d Matrix1.a * Matrix2.a;
//Newmatrix.a \u003d a;
Return NewMatrix;
// umplere
Public Vid Zapoln (Grid Datagridview)
Pentru (int i \u003d 0; i< 3; i++)
Pentru (int j \u003d 0; j< 3; j++)
A \u003d convert.toint32 (grilă.rows [j] .valls [i].
FORM1.CS.
folosind sistemul;
folosind sistemul.collections.Genic;
utilizarea sistemului.componentmodel;
folosind sistemul.Data;
utilizând sistemul.drawing;
folosind sistemul.Linq;
utilizând System.Text;
utilizând System.Windows.Forms;
matricea spațiului de nume.
Formularul de clasă parțială publică1: formă
Formularul public1 ()
InițializareComponenta ();
Private Voil Form1_load (expeditor obiect, Evenimente E)
Pentru (int i \u003d 0; i< 3; i++)
DatagridView.rows.add ();
DatagridView2rows.add ();
DatagridView.rows.add ();
//datagridview1rows[ii.cells.value \u003d i.tostring ();
Private VOID Button1_Click (Expeditor Object, Evenimente E)
Matricea mymatrix3;
Matrix3 \u003d (Matrix1 + Matrix2);
Private VOID Button2_Click (expeditor obiect, Evenimente E)
MyMatrix Matrix1 \u003d New MyMatrix ();
MyMatrix Matrix2 \u003d New MyMatrix ();
Matricea mymatrix3;
Matrix1.zapoln (Datagridview1);
Matrix2.zapoln (DataagridView2);
Matrix3 \u003d (Matrix1 - Matrix2);
Matrix3.fulglvisual (datagridview3);
Private VOID Button3_Click (Expeditor Object, Evenimente E)
MyMatrix Matrix1 \u003d New MyMatrix ();
Matricea mymatrix3;
Matrix1.zapoln (Datagridview1);
Matrix3 \u003d matrix1.trans ();
Matrix3.fulglvisual (datagridview3);
Private VOID Button4_Click (expeditor obiect, Evenimente E)
MyMatrix Matrix1 \u003d New MyMatrix ();
MyMatrix Matrix2 \u003d New MyMatrix ();
Matricea mymatrix3;
Matrix1.zapoln (Datagridview1);
Matrix2.zapoln (DataagridView2);
Matrix3 \u003d (Matrix1 * Matrix2);
Matrix3.fulglvisual (datagridview3);
Page \\ * MergeFormat 3
Curs 8. Dezvoltarea unui modul software
Procedura de dezvoltare a unui modul software. Programarea structurală și detaliile pas cu pas. Conceptul de pseudocod. Controlați modulul software.
8.1. Procedura de dezvoltare a unui modul software.
La dezvoltarea unui modul software, este recomandabil să urmați următoarea ordine:
specificația modulului de învățare și verificare, selecția limbii
programare;
selectați algoritmul și structura de date;
modul de programare;
măcinarea textului modulului;
verificarea modulului;
compilarea modulului.
Primul pas al dezvoltării unui modul software este în mare parte controlul adiacent al structurii programului de mai jos: Studierea specificației modulului, dezvoltatorul trebuie să se asigure că este clar și suficient pentru a dezvolta acest modul. La sfârșitul acestei etape, este selectată limba de programare: deși limba de programare poate fi deja predeterminată pentru toate PS, dar în unele cazuri (dacă sistemul de programare permite) poate fi selectată o altă limbă, mai potrivită pentru implementarea acestui modul (de exemplu, limba de asamblare).
În a doua etapă a dezvoltării unui modul software, este necesar să se afle dacă s-au cunoscut orice algoritmi care rezolvă și sau aproape de sarcina IT. Și dacă există un algoritm adecvat, este recomandabil să îl utilizați. Alegerea structurilor de date adecvate care vor fi utilizate la efectuarea modulului funcțiilor lor, predeterminează în mare măsură indicatorii logici și calitativi ai modulului, astfel încât acesta ar trebui considerat o decizie foarte responsabilă.
Al treilea pas este de a construi textul modulului în limba de programare selectată. Abundența tuturor tipurilor de părți care urmează să fie luate în considerare la punerea în aplicare a funcțiilor specificate în specificația modulului poate duce cu ușurință la crearea unui text foarte confuz care conține o mulțime de erori și inexactități. Căutarea erorilor într-un astfel de modul și pentru a face schimbările necesare pot fi o sarcină foarte consumatoare de timp. Prin urmare, este foarte important să se construiască textul modulului pentru a utiliza disciplina de programare rezonabilă din punct de vedere tehnologic și practic dovedită. Pentru prima dată, Dakstra a plătit acest lucru, formulând și justifică principiile de bază ale programării structurale. Aceste principii se bazează pe multe discipline de programare, utilizate pe scară largă în practică. Cea mai comună este o disciplină a detaliilor pas cu pas, care este discutată în detaliu în secțiunile 8.2 și 8.3.
Următoarea etapă de dezvoltare a modulelor este asociată cu aducerea textului modulului la vizualizarea completă în conformitate cu specificațiile calității PS. La programarea modulului, dezvoltatorul se concentrează asupra corectitudinii punerii în aplicare a funcțiilor modulului, lăsând comentariile defecte și permițând unor încălcări ale cerințelor stilului de program. La șlefuirea textului modulului, acesta trebuie să editeze comentariile disponibile în text și pot include comentarii suplimentare în acesta pentru a furniza primitivele de calitate necesare. În același scop, se efectuează editarea textului programului de a efectua cerințe stilistice.
Etapa de verificare a modulului este o verificare manuală a logicii interne a modulului înainte de începerea depanării sale (folosind execuția sa pe computer), implementează principiul general formulat pentru tehnologia de programare în discuție, despre necesitatea de a controla deciziile realizate în fiecare etapă a fazei de dezvoltare PS (a se vedea prelegerea 3). Metodele de verificare a modulelor sunt discutate secțiunea 8.4.
În final, ultima etapă a dezvoltării modulului înseamnă completarea verificării modulului (utilizând compilatorul) și trecerea la procesul de depanare a modulului.
8.2. Programare structurală.
La programarea modulului ar trebui să se țină cont de faptul că programul trebuie să fie ușor de înțeles nu numai de computer, ci și o persoană: și dezvoltatorul modulului și persoanele care verifică modulul și textele care pregătesc teste pentru depanarea modulului, Iar PS însoțește efectuarea modificărilor modulelor necesare vor fi forțate să dezasambleze mai mult logica modulului. În limbile moderne de programare, suficiente fonduri sunt suficiente pentru a confunda această logică Cât de puternică este puternică, făcând astfel modulul este greu de înțeles pentru o persoană și, ca urmare, face să fie nesigure sau dificil de însoțit. Prin urmare, este necesar să se ia măsuri pentru a selecta instrumente lingvistice adecvate și pentru a urma o anumită disciplină de programare. Pentru prima dată, Dakstra a acordat atenție acestui lucru și a sugerat să construiască un program ca o compoziție a mai multor tipuri de structuri de control (structuri) care vă permit să creșteți foarte mult înțelegerea logicii de lucru a programului. Programare folosind doar astfel de structuri numite structurale.
Principalele structuri de programare structurale sunt: \u200b\u200burmând, ramificare și repetare (a se vedea figura 8.1). Componentele acestor modele sunt operatori generalizați (noduri de procesare) s, S1, S2 și condiție (predicat) P. ca operator generalizat, fie un simplu operator al limbajului de programare utilizat (operatori de atribuire, intrare, ieșire, apeluri de procedură), fie Un fragment de program care este o compoziție a principalilor manageri de programare structurală. Este esențial ca fiecare dintre aceste structuri să aibă o singură intrare și o ieșire pentru a gestiona. Astfel, operatorul generalizat are doar o intrare și o ieșire.
De asemenea, este foarte important ca aceste modele să fie deja obiecte matematice (care, în organism și explică motivul succesului programării structurale). Se dovedește că pentru fiecare program nestructurat, este posibil să se construiască un echivalent funcțional (adică decisiv aceeași sarcină) un program structurat. Pentru programele structurate, puteți dovedi matematic unele proprietăți, ceea ce vă permite să detectați unele erori în program. O prelegere separată va fi dedicată acestei probleme.
Programarea structurală este uneori numită "programare fără a merge la". Cu toate acestea, cazul nu este aici în deplasare, ci în utilizarea dezordonată. Foarte adesea în realizarea programării structurale în unele limbi de programare (de exemplu, în FORTRAN), operatorul de tranziție (Go to) este utilizat pentru a implementa structuri structurale fără a reduce principalele avantaje ale programării structurale. Invidează programul doar declarații de tranziție "nestructurală", în special tranziția către operatorul situată în textul modulului de mai sus (mai devreme) operatorul de tranziție efectuat. Cu toate acestea, o încercare de a evita operatorul de tranziție în unele cazuri simple poate duce la programe structurate prea greoaie, care nu își îmbunătățesc claritatea și nu conține pericolul apariției unor erori suplimentare în text. Prin urmare, se recomandă evitarea utilizării operatorului de tranziție pe tot parcursul, dacă este posibil, dar nu și la prețul clarității programului.
Cazurile utile de utilizare a instrucțiunii de tranziție pot fi atribuite din ciclul sau procedura pentru o condiție specială, "precoce" terminând funcționarea acestui ciclu sau această procedură, adică Finalizarea unei anumite unități structurale (operator generalizat) și, prin urmare, violând la nivel local structura programului. Marele dificultăți (și complicații ale structurii) determină realizarea structurală a reacției la situațiile excepționale excepționale (adesea eronate), deoarece nu este doar pentru a efectua o ieșire timpurie de la unitatea structurală, ci și pentru a produce prelucrarea necesară (Excepție) din această situație (de exemplu, emiterea unei informații adecvate de diagnosticare). Manipulatorul de excepție poate fi la orice nivel al structurii programului, iar apelul la acesta poate fi făcut din diferite niveluri mai scăzute. Un punct de vedere complet acceptabil din punct de vedere tehnologic este următoarea realizare "non-structurală" a reacției la situații exclusive. Stivuitorii excepționali sunt plasați la sfârșitul unei unități structurale particulare și fiecare astfel de manipulare este programat în așa fel încât, după sfârșitul lucrării, produce o ieșire de la unitatea structurală la sfârșitul căreia este plasată. Apelul la un astfel de manipulare este realizat de operatorul de tranziție de la această unitate structurală (inclusiv orice unitate structurală imbricată în acesta).
8.3. Detalii pas cu pas și conceptul de pseudocod.
Programarea structurală oferă recomandări pentru modul în care ar trebui să fie textul modulului. Întrebarea apare cum ar trebui să acționeze programatorul pentru a construi un astfel de text. Uneori, programarea modulului începe cu construcția fluxului său care descrie logica funcționării sale în general. Cu toate acestea, tehnologia de programare modernă nu recomandă acest lucru. Deși schemele de debit vă permit să prezentați foarte clar logica modulului, la codificarea în limba de programare, există o sursă de eroare foarte specifică: afișarea unor structuri substanțial bidimensionale, care sunt diagramele de flux, textul liniar reprezentând modulul Conține riscul de a distorsiona logica modulului, cu atât mai mult, care este destul de dificil să se mențină un nivel ridicat de atenție atunci când este reexaminată. O excepție poate fi cazul în care un editor grafic este utilizat pentru a construi cursuri de debit și este formalizat atât de mult încât textul din limba de programare este generat automat (cum se poate face în tehnologia P).
Deoarece metoda principală de construire a textului modulului, tehnologia de programare modernă recomandă detalii pas cu pas. Esența acestei metode este de a împărți procesul de dezvoltare a textului modulului la un număr de pași. În prima etapă, schema globală a modulului este descrisă în forma de text liniară previzibilă (adică, folosind concepte foarte mari), iar această descriere nu este pe deplin formalizată și concentrată pe percepția sa de către persoana sa. La fiecare pas următor, detaliile unuia dintre concepte este rafinată (va fi numită-o rafinată), utilizată (de regulă, nu formalizată) în orice descriere proiectată pe una din etapele anterioare. Ca rezultat al acestei etape, o descriere este creată o descriere a conceptului clarificat selectat sau din punct de vedere al limbajului de programare de bază (adică selectat pentru prezentarea modulului) sau în aceeași formă ca și primul pas folosind noi concepte rafinate. Acest proces este finalizat când toate conceptele clarificate sunt în cele din urmă exprimate în limba de bază de programare. Pasul final este obținerea textului modulului la limbajul de programare de bază prin înlocuirea tuturor intrărilor conceptelor rafinate date de descrierile lor și expresia tuturor intrărilor structurilor de programare structurale cu mijloacele acestui limbaj de programare.
Detaliile pas cu pas este legată de utilizarea limbajului parțial formalizat pentru a reprezenta descrierile specificate, care au primit numele pseudocodului. Această limbă vă permite să utilizați toate modelele de programare structurale care sunt formalizate, împreună cu fragmente informale în limba naturală pentru prezentarea operatorilor și condițiilor generalizate. În calitate de operatori și condiții generalizate, pot fi setate fragmente corespunzătoare pe limbajul de programare de bază.
Descrierea capului de pe pseudocode poate fi considerată un design extern al modulului la limba de programare de bază, care
Începutul modulului la limbajul de bază, adică prima teză sau titlu (specificație) a acestui modul;
secțiunea (set) descrieri la limbajul de bază și în loc de descrieri ale procedurilor și funcțiilor - numai designul lor extern;
desemnarea informală a secvenței operatorilor de corp a modulului ca operator generalizat (a se vedea mai jos), precum și o desemnare informală a secvenței operatorilor de organism a fiecărei descrieri a procedurii sau funcției ca operator generalizat;
ultima propunere (sfârșitul) modulului la limbă de bază.
Designul extern al descrierii procedurii sau funcției pare similar. Cu toate acestea, dacă urmați DAEKSTER, descrierile descrierilor sunt mai bune pentru a prezenta aici în desemnarea informală, făcându-l detaliat sub forma unei descrieri separate.
O denumire informală a operatorului generalizat pe pseudocod este produsă într-o limbă naturală printr-o propunere arbitrară care dezvăluie conținutul său în general. Singura cerință formală pentru proiectarea unei astfel de desemnări este următoarea: Această propunere trebuie să ocupe una sau mai multe și mai multe șiruri de caractere grafice și să încheie punctul.
Pentru fiecare operator generalizat informal, ar trebui creată o descriere separată care exprimă logica funcționării sale (detaliind conținutul său) utilizând compoziția principalelor structuri de programare structurale și alți operatori generalizați. Ca titlu de o astfel de descriere, trebuie să existe o desemnare informală a operatorului generalizat detaliat. Principalele structuri de programare structurală pot fi prezentate în formularul de mai jos (a se vedea figura 8.2). Aici starea poate fi fie stabilită în mod clar pe limba de programare de bază ca o expresie booleană, fie este reprezentată informal într-o limbă naturală printr-un anumit fragment care dezvăluie în termeni generali sensul acestei afecțiuni. În ultimul caz, ar trebui creată o descriere separată, detaliată de această condiție, cu o indicație ca titlu de desemnare a acestei afecțiuni (fragment în limba naturală).
Smochin. 8.2. Structurile de bază ale programării structurale pe pseudocod.
Smochin. 8.3. Operatorul de tranziție privat ca operator generalizat.
În calitate de operator generalizat pe Pseudocode, puteți utiliza operatorul de tranziție menționat mai sus (vezi figura 8.3). Secvența de stivuitoare de excepție (excepții) este setată la sfârșitul modulului sau descrierea procedurii (funcții). Fiecare astfel de manipulare are forma:
Excludere name_choles.
generalized_Product.
Toate excepțiile
Diferența dintre manipulatorul de excepție din procedură fără parametri este după cum urmează: După ce procedura este executată, controlul revine la operator după apel la acesta și după executare, controlul revine la operator după referință la modul sau procedura ( Funcții) La sfârșitul cărora (care) este plasată această excepție.
Se recomandă crearea unei descrieri suficient de semnificativ la fiecare etapă de detaliu, dar cu ușurință previzibilă (vizuală), astfel încât să fie localizată pe o singură pagină a textului. De regulă, aceasta înseamnă că o astfel de descriere ar trebui să fie o compoziție a celor cinci șase modele de programare structurale. De asemenea, se recomandă ca structurile imbricate cu o deplasare la dreapta la mai multe poziții (vezi figura 8.4). Ca rezultat, puteți obține o descriere a logicii lucrărilor la vizibilitate destul de competitivă cu deficiențele, dar cu un avantaj semnificativ - liniaritatea descrierii rămâne.
Eliminarea înregistrărilor în fișier la început,
Satisfacerea filtrului specificat:
Setați începutul fișierului.
Dacă următorul record satisface
Filtru T.
Ștergeți următoarea intrare din fișier.
Toate dacă
PA
Dacă înregistrările nu sunt eliminate
Print "Înregistrările nu sunt șterse."
Imprimați "Remote N înregistrări".
Toate dacă
Ideea detaliilor pas cu pas este atribuită lui Daekster. Cu toate acestea, Dyacstra a oferit o metodă fundamentală diferită de a construi textul modulului, care ne pare mai profund și promițător. În primul rând, împreună cu clarificarea operatorilor, el a oferit treptat (prin pași) să verifice (detalii) și structurile de date utilizate. În al doilea rând, la fiecare pas, el sa oferit să creeze o mașină virtuală pentru detalii și în termeni pentru a face detaliile tuturor conceptelor rafinate pentru care această mașină vă permite să faceți. Astfel, Dyacstra a oferit, în esență, să detalieze straturile orizontale, care este transferul ideilor sale despre sistemele stratificate (a se vedea prelegerea 6) la nivelul de dezvoltare al modulului. Această metodă de dezvoltare a modulului este în prezent susținută de pachetele de limbă a limbii și mijloacele de programare orientată pe obiecte.
8.4. Controlați modulul software.
Următoarele metode de controlare a modulului software sunt utilizate:
verificarea textului modulului static;
prin urmărire;
dovada proprietăților modulului programului.
Când verificarea statică a textului modulului, acest text este citit de la început până la capăt pentru a găsi erori în modul. De obicei, pentru un astfel de cec atrage, cu excepția dezvoltatorului modulului, încă unul sau mai mulți programatori. Se recomandă corectarea erorilor, care nu sunt detectate imediat și la finalizarea citirii textului modulului.
Prin urmărire este unul dintre tipurile de control al modulului dinamic. De asemenea, implică mai mulți programatori, care defilor manual prin execuția modulului (operatorul din spatele operatorului în secvența care rezultă din logica modulului) pe un anumit set de teste.
Următoarea prelegere este dedicată dovezilor proprietăților programelor. Ar trebui să se observe doar că această metodă este utilizată încă foarte rar.
Literatură pentru curs 8.
8.2. E.dikstra. Note privind programarea structurală // U. Dal, E.Dyakstra, K.horhor. Programare structurală. - M.: MIR, 1975. - P. 24-97.
8.3. N.virt. Programare sistematică. - M.: MIR, 1977. - P. 94-164.
Curs 9. Proprietăți imobiliare
Conceptul de fundamentare a programelor. Formalizarea proprietăților programului, Triade Hoore. Reguli pentru stabilirea proprietăților operatorului de cesiune, operatorii condiționați și compuși. Reguli pentru stabilirea proprietăților operatorului ciclului, conceptul de invariant al ciclului. Finalizarea executării programului.
9.1. Justificarea programelor. Formalizarea proprietăților programului.
Pentru a îmbunătăți fiabilitatea instrumentelor software, este foarte util să furnizați programe cu informații suplimentare, folosind care puteți crește semnificativ nivelul de control al PS. Aceste informații pot fi stabilite sub formă de declarații informalizate sau formalizate, legate de diverse fragmente de programe. Vom numi o astfel de aprobare prin fundamentarea programului. Justificările informale ale programelor pot explica, de exemplu, motivele pentru adoptarea anumitor soluții, care pot facilita în mod semnificativ căutarea și corectarea erorilor, precum și studiul programelor atunci când sunt însoțite. Justificările formalizate ne permit să dovedim unele dintre proprietățile programelor atât manual, cât și să le controlez automat.
Unul dintre conceptele utilizate în prezent de fundamentare formală de programe este utilizarea așa-numitului hater triad. Fie ca un operator generalizat pe un mediu de informare PS, P și Q - unele predicate (aprobare) pe acest mediu. Apoi înregistrarea (p) (q) și se numește triada hoorului, în care predicatul P se numește precondiție și predicat Q - postpoziția față de operator S. Se spune că operatorul (în special, Programul) S are o proprietate (q) dacă de fiecare dată predicatul P este adevărat înainte de a executa operatorul, după executarea acestui operator, va fi adevărat predicat Q.
Exemple simple de proprietăți ale programului:
(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; M: \u003d 1;
În timp ce m / \u003d n do
PA
Pentru a dovedi proprietățile programului s, sunt utilizate proprietățile operatorilor de limbi simpli de programare (suntem limitați la operatorul gol și operatorul de atribuire) și proprietățile structurilor de control (compoziții), cu ajutorul unui program de la operatori simpli (Suntem limitați la trei compoziții principale de programare structurală, a se vedea conferința opt). Aceste proprietăți se numesc de obicei reguli de verificare a programelor.
9.2. Proprietățile operatorilor simpli.
Pentru un operator gol este valabil
Teorema 9.1. Fie P să fie predicat asupra mediului de informare. Apoi are loc proprietatea (p) (p).
Dovada acestei teoreme este evidentă: un operator gol nu schimbă starea mediului de informare (în conformitate cu semantica sa), prin urmare, precondiția sa rămâne adevărul și după punerea sa în aplicare.
Pentru operatorul de atribuire este valabil
Teorema 9.2. Permiteți Mediumul de informații este format din variabila X și restul mediului de informare al RIS:
Apoi proprietatea
(Q (x, RIS), RIS)) x: \u003d F (x, RIS) (Q (x, RIS)),
unde F (x, Ris) este o funcție neechivocă, Q - predicat.
Dovezi. Să presupunem că predicatul Q (F (X0, RIS0), RIS0) a fost adevărat înainte de a efectua operatorul de atribuire, unde (X0, RIS0) este o anumită stare arbitrară a mediului informativ este, apoi predicatul Q (x, RIS) va să fie adevărat după executarea operatorului de cesiune) Cum va primi valoarea F (x0, RIS0), iar starea RIS nu se schimbă de acest operator de atribuire și, prin urmare, după executarea acestui operator de atribuire în acest caz
Q (x, RIS) \u003d Q (F (x0, RIS0), RIS0).
În virtutea arbitrarului selectării stării mediului de informare, teorema este dovedită.
Un exemplu de proprietate al operatorului de cesiune poate fi exemplul 9.1.
9.3. Proprietățile modelelor de programare structurale de bază.
Luați în considerare acum proprietățile principalelor modele de programare structurală: urmând, ramificare și repetare.
Următoarele proprietăți exprimă următoarele
Teorema 9.3. Fie P, Q și R predicate deasupra mediului de informare, iar S1 și S2 sunt operatori generalizați cu proprietăți respectiv
(P) S (Q) și (Q) S2 (R).
Apoi pentru operatorul compozit
S1; S2.<.blockquote>
există o proprietate
(P) S1; S2 (R).
Dovezi. Să presupunem că pentru o anumită stare a mediului de informare înainte de a efectua operatorul S1, predicatul P. Apoi, prin proprietățile operatorului S1 după executarea acestuia, predicatul q va fi atribuit. Deoarece operatorul S2 va fi efectuat pe semantica După executarea operatorului S1, execuția operatorului S2. În consecință, după executarea operatorului S2, în virtutea proprietății sale, predicatul r va fi adevărat, iar de când operatorul S2 completează execuția operatorului compozit (în funcție de semantica sa), atunci predicatul r va fi adevărat și după efectuarea Acest operator compozit, care trebuia să dovedească.
De exemplu, dacă proprietățile (9.2) și (9.3) au (9.2) și (9.3), acesta are
loc și proprietate
(N.
Proprietatea ramurii exprimă următoarele
Teorema 9.4. Fie P, Q și R predicate deasupra mediului de informare, iar S1 și S2 sunt operatori generalizați cu proprietăți respectiv
(P, Q) S1 (R) și (`P, Q) S2 (R).
Apoi pentru operatorul condițional
Dacă P atunci S1 altfel S2 toate dacă
există o proprietate
(Q) dacă P atunci S1 altfel S2 toate dacă (R).
Dovezi. Să permită o anumită stare a mediului de informare înainte de a efectua un predicat de operator condiționat Q. Dacă predicatul P este, de asemenea, adevărat, atunci executarea operatorului condițional în conformitate cu semantica sa este redusă la execuția operatorului S1. În virtutea proprietăților operatorului S1 după executarea sa (și în acest caz, va fi adevărat predicat R. Dacă înainte de a efectua un operator condiționat, predicatul P este fals (și Q, tot adevărat), apoi condiționarea operatorului În conformitate cu semantica sa se reduce la execuția operatorului S2. În virtutea proprietăților operatorului S2 după executarea sa (și în acest caz, va fi adevărat predicat R. Astfel, teorema este complet dovedită.
Înainte de a trece la proprietatea de design repetare, trebuie remarcat util pentru mai multe
Teorema 9.5. Fie P, Q, P1 și Q1 predicate deasupra mediului de informare pentru care implicațiile sunt valabile
P1 \u003d\u003e P și Q \u003d\u003e Q1,
Și pentru operatorul, are loc proprietatea (p) (q). Apoi apare proprietatea (P1) S (Q1).
Această teoremă se numește încă teorema proprietăților de slăbire.
Dovezi. Să presupunem că pentru o anumită stare a mediului de informare înainte de a efectua operatorul, predicatul P1 este adevărat. Apoi va fi adevărat și predicat P (datorită implicării P1 \u003d\u003e P). Prin urmare, în virtutea proprietăților operatorului după executarea acestuia, predicatul q va fi trifumat și, prin urmare, predicat Q1 (datorită implicării Q \u003d\u003e Q1). Astfel, teorema este dovedită.
Proprietatea repetiției exprimă următoarele
Teorema 9.6. Fie ca I, Q și R să fie predicate deasupra mediului de informare pentru care implicațiile sunt valabile
P \u003d\u003e i și (i, `q) \u003d\u003e r,
Și să fie un operator generalizat cu o proprietate (i) s (i).
Apoi pentru operatorul ciclului
În timp ce Q face totul în timp ce
există o proprietate
(P) în timp ce Q face tot ce este în timp ce (r).
Predicat I Se numește invariant al operatorului ciclului.
Dovezi. Pentru a dovedi această teoremă, este suficient să dovediți proprietatea
(I) în timp ce Q face totul în timp ce (i, `q)
(Potrivit teoremei 9.5 pe baza implicațiilor disponibile în condițiile acestei teoreme). Lăsați predicatorul să fiu încercat înainte de a efectua operatorul de ciclu al ciclului. Dacă predicatul Q este fals, operatorul ciclului va fi echivalent cu un operator gol (în funcție de semantica sa) și în virtutea teoremei 9.1 după executarea operatorului ciclului (I , `Q). Dacă, înainte de a efectua un operator de ciclism, predicatul Q va fi adevărat, operatorul ciclului în conformitate cu semantica sa poate fi reprezentat ca operator compozit; În timp ce Q face totul în timp ce
Datorită proprietăților operatorului, după executarea sa, predicat voi fi adevărat, iar situația inițială apare pentru a dovedi proprietățile operatorului ciclului: predicat I este adevărat înainte de a efectua operatorul ciclului, dar deja pentru altul (modificat ) Starea mediului de informare (pentru care predicatul Q poate fi fie adevărat fie fals). Dacă execuția operatorului ciclului este finalizată, aplicarea metodei de inducție matematică, noi pentru un număr finit de pași, vom ajunge la o situație în care aprobarea (I, `` Q) este adevărată înainte de a fi îndeplinită. Și în acest caz, așa cum sa dovedit mai sus, această afirmație va fi corectă și după funcționarea operatorului ciclului. Teorema este dovedită.
De exemplu, operatorul ciclului din Exemplu (9.4) are o proprietate
m: \u003d M + 1; P: \u003d P * m
Toate până acum (p \u003d n.!}
Acest lucru rezultă din teorema 9.6, deoarece invariantul acestui operator de ciclu este predicat p \u003d m! Și implicațiile sunt valide (n\u003e 0, p \u003d 1, m \u003d 1) \u003d\u003e p \u003d m! și (p \u003d m!, m \u003d n) \u003d\u003e p \u003d n!
9.4. Finalizarea executării programului.
Una dintre proprietățile programului care poate fi interesată pentru a evita posibilele erori în PS este finalizarea acesteia, adică. Lipsa de buclă în una sau alte date sursă. În programele structurate considerate de noi, numai designul de repetare poate fi sursa. Prin urmare, pentru a dovedi finalizarea programului, este suficient să se poată dovedi finalizarea operatorului ciclului. Acest lucru este util pentru acest lucru.
Teorema 9.7. Fie f o funcție întregă în funcție de starea unui mediu de informare și satisfacerea următoarelor condiții:
(1) Dacă un predicat Q este adevărat pentru această stare a mediului de informare, valoarea sa este pozitivă;
(2) scade atunci când starea de mediu a mediului este modificată ca urmare a executării operatorului S.
Apoi executarea operatorului ciclului
În timp ce q face s, totul este finalizat.
Dovezi. Să fie starea de stat a mediului de informare înainte de a efectua operatorul ciclului și Let F (este) \u003d k. Dacă predicatul Q (este) este fals, execuția operatorului ciclului este finalizată. Dacă Q (este) este adevărat, atunci cu starea teoremei k\u003e 0. În acest caz, operatorul va fi executat de una sau mai multe ori. După fiecare execuție a operatorului S sub starea teoremei, funcția Funcția F este scăzută și, înainte de a executa predicatul operatorului Q ar trebui să fie adevărat (prin semantica operatorului ciclului), apoi valoarea funcției F la Acest moment ar trebui să fie pozitiv (cu starea teoremei). Prin urmare, în virtutea integrității funcției F, operatorul în acest ciclu poate fi efectuat mai mult de k ori. Teorema este dovedită.
De exemplu, pentru operatorul considerat mai sus, ciclurile teoremei 9.7 satisface funcția F (N, M) \u003d n-m. Deoarece înainte de a efectua operatorul ciclului m \u003d 1, corpul acestui ciclu va fi efectuat (n-1) ori, adică. Acest operator de ciclu este finalizat.
9.5. Un exemplu de proprietăți ale programului de probă.
Pe baza regulilor de verificare a programelor dovedite, este posibil să se demonstreze proprietățile programelor care constau din operatori de credit și operatori goliți și să utilizeze trei compoziții de bază ale programării structurale. Pentru a face acest lucru, analizând structura programului și utilizând posturile sale predefinite și postale, este necesar la fiecare etapă de analiză pentru a aplica o regulă de verificare adecvată. În cazul aplicării compoziției repetate, va trebui să alegeți un invariat al ciclului adecvat.
De exemplu, demonstrăm proprietatea (9.4). Această dovadă va consta din următorii pași.
(Pasul 1). N\u003e 0 \u003d\u003e (n\u003e 0, p - orice, m - orice).
(Pasul 2). Apare
(n\u003e 0, p - orice, m - oricare) p: \u003d 1 (n\u003e 0, p \u003d 1, m - orice).
Prin Teorema 9.2.
(Pasul 3). Apare
(N\u003e 0, p \u003d 1, m - oricare) M: \u003d 1 (n\u003e 0, p \u003d 1, m \u003d 1).
Prin Teorema 9.2.
(Pasul 4). Apare
(n\u003e 0, p - orice, m - oricare) p: \u003d 1; M: \u003d 1 (n\u003e 0, p \u003d 1, m \u003d 1).
Prin teorema 9.3 în virtutea rezultatelor pașilor 2 și 3.
Doveim că predicat p \u003d m! este un invariantă a ciclului, adică (P \u003d m m:=m+1; p:=p*m {p=m!}.!}
(Pasul 5). Are loc (p \u003d m m:=m+1 {p=(m-1)!}.!}
Prin Teorema 9.2, dacă trimiteți o condiție prealabilă în formular (P \u003d ((M + 1) -1).!}
(Pasul 6). Are loc (P \u003d (M-1) p:=p*m {p=m!}.!}
Prin Teorema 9.2, dacă reprezentați precondiția în formă (p * m \u003d m.!}
(Pasul 7). Există un ciclu invariantor
(P \u003d m m:=m+1; p:=p*m {p=m!}.!}
Prin teorema 9.3, datorită rezultatelor pașilor 5 și 6.
(Pasul 8). Apare
(N\u003e 0, p \u003d 1, m \u003d 1) în timp ce m / \u003d n do
m: \u003d M + 1; P: \u003d P * m
Toate până acum (p \u003d n.!}
Prin teorema 9.6, datorită rezultatului pasului 7 și ținând cont de faptul că (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!.
(Pasul 9). Apare
(n\u003e 0, p - orice, m - oricare) p: \u003d 1; M: \u003d 1;
În timp ce m / \u003d n do
m: \u003d M + 1; P: \u003d P * m
Toate până acum (p \u003d n.!}
Prin teorema 9.3, datorită rezultatelor pașilor 3 și 8.
(Pasul 10). Proprietatea (9.4) are o proprietate (9.4) prin teorema 9.5 în virtutea rezultatelor pașilor 1 și 9.
Literatură pentru prelegerea 9.
9.1. S.A. Abramov. Elemente de programare. - M.: ȘTIINȚĂ, 1982. P. 85-94.
9.2. M. Zelkovts, A. Show, J. Gannon. Principii de dezvoltare software. - M.: MIR, 1982. P. 98-105.
Curs 10. Testarea și depanarea software-ului
Noțiuni de bază. Strategia de proiectare a testului. Comanda depanare. Modulul software de depanare și testare offline. Software complex de depanare și testare.
10.1. Noțiuni de bază.
Debugging PS este o activitate care vizează detectarea și corectarea erorilor în PS folosind procesele de executare a programelor sale. Testarea PS este procesul de realizare a programelor sale pe un anumit set de date pentru care rezultatul cererii este preconceput sau regulile pentru comportamentul acestor programe sunt cunoscute. Setul de date specificat se numește test sau doar un test. Astfel, depanarea poate fi reprezentată ca o repetare multiplă a trei procese: testarea, ca rezultat care poate fi menționat în PC-ul de eroare, căutând locul de eroare în programele și documentarea programelor și a programelor de editare și a documentației pentru a elimina eroarea detectată. Cu alte cuvinte:
Debugging \u003d Testarea + Căutare de eroare + Editare.
În literatura de peste mări, depanarea este adesea înțeleasă doar ca proces de căutare și corectare a erorilor (fără testare), a cărui lucru este setat la testarea. Uneori testarea și depanarea consideră sinonimele. În țara noastră, testarea este de obicei inclusă în conceptul de depanare, așa că vom urma tradiția actuală. Cu toate acestea, considerația comună în această prelegere a acestor procese face ca discrepanța specificată să nu fie atât de importantă. Cu toate acestea, trebuie remarcat faptul că se utilizează testarea și ca parte a procesului de certificare PS (a se vedea prelegerea 14).
10.2. Principii și tipuri de depanare.
Succesul depanării destul de mult predeterminează organizarea rațională a testelor. La depanarea, acestea sunt găsite și eliminate, în principal acele erori, prezența cărora în PP este setată la testarea. Așa cum sa observat deja, testarea nu poate dovedi corectitudinea PS, în cel mai bun caz, poate demonstra prezența erorilor în ea. Cu alte cuvinte, este imposibil să se asigure că testarea PS cu un set de testare executați practic poate fi stabilită de prezența fiecărei erori disponibile. Prin urmare, apar două sarcini. În primul rând: pregătiți un astfel de set de teste și aplicați PS pentru a le detecta cu un număr mai mare de erori. Cu toate acestea, cu cât procesul de testare (și depanarea în ansamblu) continuă, cu atât este mai mare costul PS. Prin urmare, a doua sarcină: pentru a determina timpul sfârșitului depanării PS (sau componenta sa separată). Un semn al posibilității de a finaliza depanarea este o acoperire completă a testului PS (adică testele la care PS) din multe situații diferite care decurg din execuția programelor PS și manifestarea relativ rară a erorilor în ultimul segment a procesului de testare. Acesta din urmă este determinat în conformitate cu gradul necesar de fiabilitate a PS specificat în specificarea calității sale.
Pentru a optimiza setul de testare, adică Pentru a pregăti un astfel de set de teste, care le-ar permite acestora, după cum se specifică (sau la un anumit interval de timp alocat pentru testare) pentru a detecta un număr mai mare de erori, este necesar, în primul rând, să planificați acest lucru în avans și, în al doilea rând , să utilizeze o strategie de planificare rațională (design). Designul de testare poate fi pornit imediat după finalizarea pasului de descriere externă PS. Diferite abordări ale dezvoltării strategiilor de proiectare a testului, care pot fi programate grafic să fie cazate grafic (vezi figura 9.1) între următoarele două abordări extreme. Abordarea extremă stângă este că testele sunt proiectate doar pe baza studiului specificațiilor PS (descrierea externă, descrierea arhitecturii și specificațiile modulului). Structura modulelor nu este luată în considerare, adică Ele sunt considerate cutii negre. De fapt, această abordare necesită o stingere completă a tuturor seturilor de date de intrare, deoarece utilizând numai părți ale acestor seturi, unele dintre programele PS nu pot funcționa pe nici un test și înseamnă că erorile conținute în ele nu vor apărea. Cu toate acestea, testarea PS cu un set complet de seturi de intrare este aproape imposibilă. Abordarea extremă corectă este că testele sunt proiectate pe baza studiului textelor text pentru a testa toate căile fiecărui program PS. Dacă luați în considerare disponibilitatea ciclurilor cu un număr variabil de repetiții, diferitele modalități de execuție a programelor PS pot fi, de asemenea, extrem de mult, astfel încât testarea lor să fie, de asemenea, practic imposibilă.
Strategia optimă a designului de testare este situată în interiorul intervalului dintre aceste abordări extreme, dar mai aproape de marginea din stânga. Acesta include proiectarea unei părți semnificative a testelor conform specificațiilor, pe baza principiilor: pentru fiecare funcție utilizată sau a capacității - cel puțin un test, pentru fiecare regiune și la fiecare margine a modificărilor la orice valoare de intrare - cel puțin una Testul, pentru fiecare caz special sau pentru fiecare situație excepțională specificată în specificații este cel puțin un test. Dar, de asemenea, necesită proiectarea unor teste și în textele programelor, pe baza principiului (cel puțin): Fiecare echipă a fiecărui program PS ar trebui să funcționeze cel puțin la un test.
Proiectarea optimă a testelor poate fi specificată pe baza următorului principiu: pentru fiecare document de program (inclusiv textele programelor) incluse în PS, testele lor ar trebui concepute pentru a identifica erorile din acesta. În orice caz, acest principiu trebuie respectat în conformitate cu definiția PS și conținutul conceptului de tehnologie de programare ca o tehnologie de dezvoltare a PS fiabil (a se vedea conferința 1). În acest sens, Myers chiar definește diferite tipuri de teste în funcție de tipul de document de program, pe baza căruia sunt construite testele. În țara noastră există două tipuri principale de depanare (inclusiv testarea): depanarea autonomă și complexă. Depanarea autonomă înseamnă testarea doar o parte din programul inclus în PS, cu o căutare și o corecție în acesta înregistrată la erorile de testare. De fapt, include depanarea fiecărui module și module de depanare. Depanarea integrată înseamnă testarea PS în ansamblu, cu căutarea și corectarea erorilor înregistrate la testarea erorilor în toate documentele (inclusiv textele programelor PS) referitoare la PS ca întreg. Aceste documente includ definiția cerințelor PS, specificația calității PS, specificația funcțională PS, descrierea arhitecturii PS și programele PS.
10.3. Comanda depanare.
Această secțiune oferă recomandări generale privind organizarea depanării. Dar, la început, trebuie remarcat un anumit fenomen care confirmă importanța erorilor de avertizare în etapele anterioare de dezvoltare: deoarece numărul de erori detectate și fixe în PS cresc, de asemenea, probabilitatea relativă a existenței în ea a erorilor neperturbate. Acest lucru se explică prin faptul că, cu o creștere a numărului de erori găsite în PS, este de asemenea clarificată de ideea noastră despre numărul total de erori admise la aceasta și, prin urmare, într-o oarecare măsură, numărul totuși erori. Acest fenomen confirmă importanța detectării precoce a erorilor și necesitatea de a controla cu atenție deciziile luate în fiecare etapă a dezvoltării PS.
Porunci 1. Luați în considerare testarea sarcinii-cheie de dezvoltare PS, încredințați programatorii calificați și talentați; Este nedorit să vă testați propriul program.
Comunment 2. Este bine că testul pentru care este ridicat să detectați o eroare și nu cea care demonstrează funcționarea corectă a programului.
Comandă 3. Pregătiți teste atât pentru datele corecte și incorecte.
Commandare 4. Evitați testele nerespectate, documentați-le prin computer; Explorați în detaliu rezultatele fiecărui test.
Comanda 5. Conectați fiecare modul la program numai o singură dată; Nu modificați niciodată programul pentru a facilita testarea acestuia.
Comandamentul 6. Treceți la toate testele asociate cu verificarea lucrării oricărui program PS sau interacțiunea acestuia cu alte programe dacă au fost efectuate modificări (de exemplu, ca urmare a eliminării erorii).
10.4. Depanarea autonomă a modulului.
Cu depanare autonomă, fiecare modul este testat efectiv într-un anumit mediu software, cu excepția cazului în care programul de depanare constă doar dintr-un modul. Acest mediu constă în alte module, dintre care unele sunt modulele programului de depanare, care sunt deja depuse și, parte, sunt prin module care gestionează depanarea (prin modulele de depanare, a se vedea mai jos). Astfel, cu un depanare autonomă, un anumit program construit în mod specific este întotdeauna testat pentru testarea modulului de depanare. Acest program coincide doar parțial cu programul depanat, cu excepția cazului în care ultimul modul al programului este depanat. Întrucât depanarea programului este promovată, o parte din ce în ce mai mare a modulului de depanare va fi modulele deja depuse ale acestui program, iar la depanarea ultimului modul al acestui program, mediul modulului de depanare va fi în întregime constând în întregime din toate celelalte (deja Depanged) modul de program (fără orice) module de depanare, adică. În acest caz, programul de depanare va fi testat. Un astfel de proces de creștere a programului de depanare a programului depanat și depanat se numește integrarea programului.
Modulele de depanare incluse în mediul din modulul de depanare depind de ordinea în care sunt debugate modulele acestui program, pe care modulul depanează și, probabil, ce fel de testare va fi omisă.
Atunci când testarea în creștere (a se vedea prelegerea 7), acest mediu va conține întotdeauna un singur modul de depanare (cu excepția cazului în care ultimul modul de depanare a programului este depanat), care va fi capul în programul de testare și care se numește Master (sau șofer) . Modulul de depanare principal pregătește mediul de informare pentru testarea modulului de depanare (adică, acesta generează starea sa necesară pentru a testa acest modul, în special pentru a introduce unele date de testare), se referă la modulul de depanare și după încheierea funcționării acesteia mesajele necesare. La depanarea unui modul pentru diferite teste, pot fi făcute diferite module de depanare de conducere.
Cu testarea descendentă (a se vedea prelegerea 7) mediul modulului de depanare ca module de depanare conține simulatoare ale tuturor modulelor la care un modul de depanare, precum și simulatoarele acelor module la care sunt depuse modulele dedicate ale programului (incluse În acest mediu) pot fi accesate, dar care nu sunt încă înfășurate. Unele dintre aceste simulatoare la depanarea unui modul pot varia pentru diferite teste.
De fapt, înconjurat de modulul de depanare în multe cazuri pot conține module de depanare a ambelor tipuri de următoarele motive. Ambele teste ascendente și descendente au avantajele și dezavantajele sale.
Avantajele testelor ascendente includ
ușor de pregătit teste și
posibilitatea implementării complete a planului de testare a modulului.
Acest lucru se datorează faptului că starea de testare a mediului de informare este pregătită imediat înainte de a se referi la modulul de depanare (modulul de depanare principal). Laptopurile de testare ascendentă sunt următoarele caracteristici:
datele de testare sunt pregătite, de regulă, nu în formă, care este proiectată pentru utilizator (cu excepția cazului în care ultimul, cap, modul de programe de depanare este debitat);
o cantitate mare de programare de depanare (la depanarea unui modul trebuie adesea să fie o mulțime de module de depanare de conducere pentru diferite teste);
nevoia de testare a interfeței speciale a modulului.
Avantajele testelor descendente includ următoarele caracteristici:
cele mai multe teste se pregătesc în formularul destinat utilizatorului;
În multe cazuri, o programare relativ mică de depanare (simulatoarele modulelor sunt, de obicei, destul de simple și fiecare este potrivită pentru un număr mare, de multe ori - pentru toate, teste);
nu este nevoie să se testeze conjugația modulului.
Dezavantajul testelor descendente este acela că starea de testare a mediului informativ pregătește indirect înainte de a se referi la modulul de unică folosință - este rezultatul utilizării deja a modulelor de depanare pentru a testa datele sau datele emise de simulatoare. Acest lucru, în primul rând, face dificilă pregătirea testelor, necesită calificări ridicate ale testului de testare și, în al doilea rând, face dificilă sau chiar imposibilă implementarea planului complet de testare pentru modulul de depanare. Acest dezavantaj uneori forțează dezvoltatorii să aplice testarea ascendentă chiar și în caz de dezvoltare descendentă. Cu toate acestea, unele modificări ale testelor descendente sunt utilizate mai des sau o combinație descendentă și în amonte.
Pe baza faptului că testarea descendentă, în principiu, este preferabilă, ne vom opri la recepțiile care vă permit să depășiți aceste dificultăți într-o oarecare măsură. În primul rând, este necesar să se organizeze depanarea programului astfel încât modulele care exercită datele pot fi depuse - atunci datele de testare pot fi preparate în formularul destinat utilizatorului, ceea ce va simplifica în mod semnificativ prepararea ulterioară teste. Nu întotdeauna, această intrare este realizată în modulul cap, prin urmare, este necesar să depanați lanțurile de module care să conducă la module care implementează intrarea specificată (CP, cu o metodă de implementare constructivă orientată în prelegeri 7). În timp ce modulele care efectuează introducerea datelor nu sunt debugate, datele de testare sunt furnizate de unele simulatoare: sunt fie incluse în simulator ca parte a acestuia, fie introduse de acest simulator.
Cu un test downlink, este posibil ca statutul mediului de informare în care doriți să testați modulul de depanare să nu se producă atunci când programul este îndeplinit de orice intrare. În aceste cazuri, ar fi posibil să se testeze deloc modulul de depanare, deoarece detectorii de erori nu se vor manifesta atunci când se execută programul fiind depanat la orice intrare. Cu toate acestea, nu se recomandă acest lucru, deoarece atunci când schimbarea programului depanat (de exemplu, atunci când este însoțit de PS), nu este utilizat pentru testarea modulului echilibrat al mediului de informare poate apărea deja, ceea ce necesită testarea suplimentară a acestui modul ( Și aceasta, cu o punere în funcțiune rațională, ar fi posibil să se facă dacă acest modul în sine nu sa schimbat). Pentru a testa dispozitivul depanat în aceste situații, simulatoarele adecvate uneori utilizează pentru a crea starea dorită a mediului de informare. Mai des, utilizați o opțiune de încercare descendentă modificată, în care modulele de depanare sunt testate anterior separat (în acest caz, un modul de depanare de frunte este înconjurat de un modul de depanare, împreună cu simulatoarele modulelor la care poate apărea un modul de depanare). Cu toate acestea, se pare că o altă modificare a testării descendente: După finalizarea testării descendente a modulului de depanare, acesta trebuie testat separat pentru stările de testare realizabile ale mediului de informare pentru restul statelor necesare ale mediului de informare.
Se utilizează, de asemenea, o combinație de teste ascendente și descendente, care se numește metoda sandwich. Esența acestei metode este de a implementa simultan atât testarea ascendentă, cât și scăzută, până în prezent aceste două procese de testare vor fi îndeplinite de orice modul undeva în mijlocul structurii programului de depanare. Această metodă permite, cu o abordare rezonabilă, să profite de meritele de testare ascendentă și descendentă și neutralizează în mare măsură dezavantajele acestora. Acest efect este o manifestare a unui principiu mai general: cel mai mare efect tehnologic poate fi realizat prin combinarea metodelor descendente și ascendente pentru dezvoltarea programelor PS. Este de sprijinul acestei metode că o abordare arhitecturală a dezvoltării programelor (a se vedea prelegerea 7): un strat de module calificate dezvoltate și testate cu atenție facilitează în mod semnificativ familia de programe din zona relevantă și ulterioare modernizare.
Foarte important în depanarea autonomă este testarea împerecherii modulului. Faptul este că specificația fiecărui modul de program, cu excepția capului, este utilizată în acest program în două situații: în primul rând, atunci când se dezvoltă text (uneori spun: corpul) acestui modul și, în al doilea rând, atunci când scrieți un apel la Acest modul în alte module de program. Și în acest caz, ca urmare a unei erori, conformitatea necesară a specificației modulului specificate poate fi întreruptă. Astfel de erori sunt necesare pentru a detecta și elimina. Pentru a face acest lucru, testarea interfețelor modulului. Cu testarea descendentă, testatul conjugării este realizat într-o trecere prin fiecare test transmis, care este considerat cel mai mare avantaj al testelor descendente. Atunci când creșterea testelor, accesul la modulul de depanare nu este fabricat din modulele de depanare a programului, dar de la modulul Master Debug. În acest sens, există un pericol ca ultimul modul să se adapteze la unele "iluzii" ale modulului de depanare. Prin urmare, începând (în timpul integrării programului), pentru a depana un mod nou, trebuie să testați fiecare apel la modulul de depanare anterior pentru a detecta inconsecvența acestui tratament cu corpul modulului corespunzător (și este posibil că modulul ajustat anterior este de vină. Astfel, este necesar să se repete parțial în noile condiții pentru a testa modulul de depanare anterior, în timp ce aceleași dificultăți apar ca în încercarea descendentă.
Testarea modulelor autonome este recomandabilă să se efectueze în patru pași efectuați în mod consecvent.
Pasul 1. Pe baza specificației Departamentului Modulului, pregătiți un test pentru fiecare posibilitate și fiecare situație, pentru fiecare graniță a zonei de valori admise ale tuturor datelor de intrare, pentru fiecare zonă de schimbare a datelor, Pentru fiecare zonă de valori nevalide ale tuturor datelor de intrare și fiecare condiție nevalidă.
Pasul 2. Verificați textul modulului pentru a vă asigura că fiecare direcție a oricărei ramificații va fi finalizată cel puțin un test. Adăugați teste lipsă.
Pasul 3. Asigurați-vă că textul modulului este acela că pentru fiecare ciclu există un test pentru care nu este efectuat corpul ciclului, testul pentru care corpul ciclului este efectuat o singură dată și testul pentru care corpul ciclului este maxim numărul maxim. Adăugați teste lipsă.
Pasul 4. Verificați dacă textul modulului are sensibilitatea la valorile individuale de intrare specifice - toate aceste valori trebuie incluse în teste. Adăugați teste lipsă.
10.5. Software cuprinzător de depanare.
După cum sa menționat mai sus, PS-ul în ansamblu este testat sub depanarea complexă, iar testele sunt pregătite pentru fiecare dintre documentele PS. Testarea acestor documente este de obicei făcută, de regulă, pentru a le dezvolta (excepția este doar testarea documentației de aplicare, care este dezvoltată de descrierea externă în paralel cu dezvoltarea textelor text; acest test este mai bine să se producă după Finalizarea testelor descrierii externe). Testarea integrată de depanare este utilizarea de date specifice, care, în principiu, pot apărea de către utilizator (în special, toate testele sunt pregătite în forma concepută pentru utilizator), dar pot fi în mediul simulat (și nu real). De exemplu, unele dispozitive inaccesibile de intrare și ieșire din depanarea complexă pot fi înlocuite de simulatoarele lor de software.
Testarea arhitecturii PS. Scopul testelor este de a căuta inconsecvențe între descrierea arhitecturii și setul de programe PS. Până la începutul încercării arhitecturii PS, ar trebui deja finalizată o depanare autonomă a fiecărui subsistem. Erori de implementare a arhitecturii pot fi asociate în primul rând cu interacțiunea acestor subsisteme, în special cu implementarea funcțiilor arhitecturale (dacă există). Prin urmare, aș dori să verific toate căile de interacțiune dintre subsistemele PS. Dar, deoarece acestea pot fi prea mult, ar fi de dorit să se testeze cel puțin toate lanțurile subsistemelor, fără a reveni la acesta din urmă. Dacă arhitectura specificată reprezintă PS ca un sistem mic din subsistemele dedicate, numărul acestor lanțuri va fi destul de slăbit.
Testarea funcțiilor externe. Scopul testelor este de a căuta discrepanțe între specificațiile funcționale și setul de programe PS. În ciuda faptului că toate aceste programe sunt deja debugate în mod autonom, aceste discrepanțe pot fi, de exemplu, datorită inconsecvenței specificațiilor interne ale programelor și a modulelor lor (pe baza cărora testarea autonomă) a specificației funcționale externe a PS a fost realizat. De regulă, testarea funcțiilor externe se efectuează în același mod ca și modulele de testare în primul pas, adică. ca o cutie neagră.
Testarea calității PS. Scopul testelor este de a căuta încălcări ale cerințelor de calitate formulate în specificația calității PS. Acesta este cel mai dificil și cel mai puțin studiat tip de testare. Este clar numai că nu orice calitate primitivă a PS poate fi testată prin testarea (evaluarea calității PS-ului, a se vedea următoarea prelegere). Finalizarea PS este verificată deja la testarea funcțiilor externe. În acest stadiu, testarea acestui primitiv de calitate poate fi continuată dacă este necesară obținerea unei evaluări probabiliste a gradului de fiabilitate a PS. Cu toate acestea, metoda acestor teste necesită în continuare dezvoltarea acesteia. Precizie, stabilitate, securitate, eficacitate temporală, într-o oarecare măsură - eficiența memoriei, eficiența dispozitivelor, extinderea și, parțial, independența de dispozitive pot fi testate. Fiecare dintre aceste tipuri de testare are propriile sale specifice și merită o examinare separată. Putem fi limitați numai la transferul lor. Ușurința de utilizare a PS (criteriul de calitate, care include mai multe primitive de calitate, a se vedea Cursul 4) este evaluată la testarea documentației pentru utilizarea PS.
Documentația de testare pentru utilizarea PS. Scopul testelor este de a găsi inconsecvența documentației pentru aplicație și un set de programe PS, precum și inconvenientele utilizării PS. Această etapă este direct precedată de conexiunea utilizatorului la finalizarea dezvoltării PS (testarea cerințelor pentru certificarea PS și PS), deci este foarte important pentru dezvoltatorii să folosească PS-ul înșiși așa cum se va face. Toate testele din acest stadiu sunt pregătite exclusiv pe baza documentației numai pentru utilizarea PS. În primul rând, posibilitățile PS ar trebui să fie testate la testarea funcțiilor externe, dar numai pe baza documentației de utilizare. Toate locurile neclare din documentație trebuie testate, precum și toate exemplele utilizate în documentație. În plus, cele mai dificile cazuri de aplicare a PS sunt testate pentru a detecta încălcarea relativității ușurinței de utilizare a PS.
Testarea definiției cerințelor PS. Scopul testelor este de a determina măsura în care PS nu corespunde determinării cerințelor pentru aceasta. Particularitatea acestui tip de teste este că este efectuată de o organizație cumpărătorului sau o organizație PS ca una dintre modalitățile de depășire a barierului dintre dezvoltator și utilizator (a se vedea conferința 3). În mod obișnuit, această testare se efectuează utilizând sarcini de control - sarcini tipice pentru care rezultatul rezultat este cunoscut. În cazurile în care PS dezvoltat ar trebui să vină să înlocuiască o altă variantă PS, care rezolvă cel puțin o parte din sarcinile PS dezvoltate, testarea se efectuează prin rezolvarea sarcinilor comune folosind atât PS-ul vechi, cât și noul PS, cu compararea ulterioară a rezultatelor obținut. Uneori forma unor astfel de teste utilizează operațiunea pilot a PS - aplicarea limitată a noului PS cu o analiză a utilizării rezultatelor în activități practice. În esență, acest tip de testare este în mare parte elicat cu testul PS în certificarea sa (a se vedea prelegerea 14), dar se efectuează înainte de certificare și, uneori, în loc de certificare.
Literatură pentru prelegerea 10.
10.1. Myers. Fiabilitate software. - M.: MIR, 1980. - P. 171-262.
10.2. D. Van Tassel. Stil, dezvoltare, eficiență, depanare și testare. - M.: MIR, 1985. - P. 179-295.
10.3. J. Hughes, J. Micht. Abordarea structurală a programului. - M.: MIR, 1980. - P. 254-268.
10.4. J. Fox. Software și dezvoltarea acesteia. - M.: MIR, 1985. - P. 227-241.
10.5. M. Zelkovitz, A. Show, J. Gannon. Principii de dezvoltare software. - M.: MIR, 1982. - P. 105-116.
10.6. Yu.m. Bezborodov. Programe individuale de depanare. - M.: ȘTIINȚĂ, 1982. - P. 9-79.
10.7. V.V. Lipaev. Programe de testare. - M.: Radio și comunicare, 1986. - P. 15-47.
10.8. E.a. Zhogolev. Introducere în tehnologia de programare (capacitatea de lectură). - M.: Dialog-MSU, 1994.
10.9. E. Dyacstra. Note de programare structurală. // y. Dal, E. Dyacstra, K. Khor. Programare structurală. - M.: MIR, 1975. - P. 7-13.
Curs 11. Asigurarea funcționalității și fiabilității software-ului
11.1. Funcționalitate și fiabilitate ca criterii de calitate a software-ului obligatoriu.
În prelegerea anterioară, am analizat toate etapele dezvoltării PS, pe lângă certificarea sa. În același timp, nu ne-am referit la întrebările privind calitatea calității, în conformitate cu specificațiile sale de calitate (a se vedea cursurile 4). Adevărat, sub implementarea specificației funcționale a PS, am discutat astfel principalele probleme de asigurare a criteriului funcționalității. După ce am declarat fiabilitatea atributului PS (a se vedea prelegerea 1), am ales prevenirea erorilor ca abordare principală pentru a asigura fiabilitatea PS (a se vedea prelegerea 3) și a discutat realizarea acestuia în diferite etape ale dezvoltării PS. Astfel, teza sa manifestat cu privire la obligația funcționalității și fiabilității PS ca criterii pentru calitatea sa.
Cu toate acestea, în specificațiile calității PS, pot exista caracteristici suplimentare ale acestor criterii, a cărei dispoziție necesită o discuție specială. Aceste prelegeri sunt dedicate acestor probleme. Asigurarea altor criterii de calitate vor fi discutate în următoarea conferință.
Mai jos sunt discutate furnizarea de primitivi ai calității PS care exprimă criteriile pentru funcționalitatea și fiabilitatea PS.
11.2. Asigurarea completitudinii software-ului.
Finalizarea PS este o calitate obișnuită comună a PS pentru expresia și funcționalitatea și fiabilitatea PS, iar pentru funcționalitate este singurul primitiv (vezi conferința 4).
Funcționalitatea PS este determinată de specificațiile sale funcționale. Finalizarea PS ca primitivă a calității sale este o măsură a cât de mult este implementată această specificație în acest PS. Asigurarea completă a acestui primitiv înseamnă implementarea fiecăreia dintre funcțiile definite în specificația funcțională, cu toate detaliile și caracteristicile indicate acolo. Toate procesele tehnologice discutate anterior arată cum se poate face.
Cu toate acestea, în specificația Calității PS, pot fi definite mai multe niveluri de implementare a funcționalității PS: pot fi definite o versiune simplificată (inițial sau de pornire), care trebuie, de asemenea, implementate, pot fi identificate și mai multe versiuni intermediare. În acest caz, apare o problemă tehnologică suplimentară: organizarea de creștere a funcționalității PS. Este important de menționat că dezvoltarea unei versiuni simplificate a PS nu este dezvoltarea prototipului său. Prototipul este conceput pentru a înțelege mai bine condițiile pentru aplicarea viitorului PS, clarificând descrierea sa externă. Acesta este conceput pentru utilizatorii selectați și, prin urmare, poate fi foarte diferit de PS-ul necesar nu numai de funcțiile efectuate, ci și de caracteristicile interfeței cu utilizatorul. Versiunea simplificată a PS-ului necesar trebuie calculată pentru utilizarea aproape utilă de către oricare dintre utilizatori pentru care este destinat. Prin urmare, principiul principal al asigurării funcționalității unui astfel de PS este de a dezvolta PS încă de la început, ca și cum PS este obligat în întregime, până când dezvoltatorii se confruntă cu acele părți sau părți ale PS, a cărui implementare poate să fie amânată în conformitate cu specificațiile calității sale. Astfel, descrierea și descrierea externă a arhitecturii PS ar trebui să fie pe deplin dezvoltate. Puteți să amânați numai punerea în aplicare a acestor subsisteme ale programului definite în arhitectura dezvoltată a PS, a căror funcționare nu este necesară în versiunea inițială a acestui PS. Punerea în aplicare a subsistemelor programului în sine se face cel mai bine prin metoda de implementare constructivă orientată, lăsând simulatoarele corespunzătoare ale acestor module software în versiunea inițială a PS, a căror operație nu este necesară în această versiune. Este permisă, de asemenea, o implementare simplificată a unor module software, scăzând implementarea anumitor părți ale funcțiilor respective. Cu toate acestea, astfel de module din punct de vedere tehnologic sunt mai bine să se ia în considerare ca imitatori ciudați (deși sunt mult avansați).
În virtutea erorilor din PS dezvoltate, completarea realizată atunci când oferă funcționalitatea acestuia (în conformitate cu specificarea calității acestuia) poate fi de fapt așa cum era de așteptat. Este posibilă numai că această finalizare este realizată cu o anumită probabilitate determinată de volumul și calitatea testelor. Pentru a crește această probabilitate, este necesar să continuăm să continuați să testați și depanarea PS. Cu toate acestea, evaluarea acestei probabilități este o sarcină foarte specifică (având în vedere faptul că manifestarea erorii disponibile în PS este funcția datelor sursă), care încă mai așteaptă studii teoretice relevante.
11.3. Furnizarea de precizie a software-ului.
Asigurarea acestui primitiv este asociată cu acțiuni asupra valorilor tipurilor reale (mai precis, cu valorile transmise unei erori). Furnizați acuratețea necesară atunci când se calculează valoarea unei funcții sau alta - înseamnă a obține această valoare cu o eroare care nu depășește limitele specificate. Tipurile de eroare, metodele lor de evaluare și metodele de realizare a acurateței necesare (așa-numitele calcule aproximative) sunt angajate în matematică computațională. Aici vom acorda doar atenție unei anumite structuri de eroare: depinde de eroarea valorii calculate (eroare completă)
din cauza metodei de calcul utilizate (în care includem și inexactitatea modelului utilizat),
de la eroarea prezentării datelor utilizate (de la așa-numita eroare nerezonabilă),
de la eroarea de rotunjire (inexactitate a executării operațiunilor utilizate în metodă).
11.4. Asigurarea autonomiei software-ului.
Acest primitiv de calitate este asigurat în stadiul specificației de calitate prin soluția de luare a deciziilor în PS dezvoltat a oricărui software de bază adecvat sau nu utilizează niciun software de bază în el. În același timp, este necesar să se ia în considerare atât fiabilitatea, cât și resursele necesare pentru utilizarea acestuia. Cu cerințe sporite pentru fiabilitatea PS dezvoltat, fiabilitatea software-ului de bază la dispoziția dezvoltatorilor poate fi nesatisfăcătoare, deci este necesar să se refuze de la utilizarea acestuia, iar realizarea funcțiilor sale în volumul necesar trebuie să includă în PS. Deciziile similare trebuie luate cu restricții rigide asupra resurselor utilizate (prin criteriul eficacității PS).
11.5. Furnizarea de sustenabilitate software.
Acest primitiv de calitate este asigurat utilizând așa-numitul programare de protecție. În general, programarea protectoare este utilizată pentru a crește fiabilitatea PS la programarea modulului într-un sens mai larg. Potrivit Myers, "Programarea protectoare se bazează pe o premisă importantă: cel mai rău lucru pe care modulul îl poate face este să accepte date de intrare incorecte și apoi să returneze rezultatul greșit, dar plauzibil". Pentru a evita acest lucru, textul modulului include verificarea datelor sale de intrare și ieșire la corectitudinea lor în conformitate cu specificația acestui modul, în special, restricțiile privind datele de intrare și ieșire și relația dintre acestea, specificate în Specificația modulului trebuie verificată. În cazul unui rezultat negativ al testului, este excitată o excepție adecvată. În acest sens, sfârșitul acestui modul include fragmente ale celui de-al doilea calator de situații excepționale, care, pe lângă emiterea informațiilor de diagnosticare necesare, pot lua măsuri sau pentru a exclude o eroare în date (de exemplu, pentru a solicita acest lucru -Input) sau să slăbiți influența erorii (de exemplu, o oprire moale a dispozitivelor PS gestionate pentru a evita defalcarea lor atunci când o reziliere de urgență a programului).
Aplicarea programării de protecție a modulelor duce la o scădere a eficacității PS atât în \u200b\u200btimp, cât și în memorie. Prin urmare, este rezonabil să reglementeze în mod rezonabil gradul de protecție a programării protectoare, în funcție de cerințele privind fiabilitatea și eficacitatea PS, formulată în specificația calității PS dezvoltat. Intrarea modulului dezvoltat poate acționa direct de la utilizator și de la alte module. Cea mai obișnuită ocazie a aplicării programării de protecție este utilizarea acesteia pentru primul grup de date, ceea ce înseamnă punerea în aplicare a durabilității PS. Este întotdeauna necesar să se facă acest lucru atunci când specificația calității PS are o cerință de asigurare a sustenabilității PS. Utilizarea programării protectoare pentru cel de-al doilea grup de intrare înseamnă o încercare de a detecta o eroare în alte module în timpul executării modulului care se dezvoltă și pentru ieșirea modulului dezvoltat - o încercare de a detecta o eroare în acest modul în timpul acestui modul în timpul executarea ei. În esență, acest lucru înseamnă o realizare parțială a unei abordări de auto-cheltuială erruri pentru a asigura fiabilitatea PS, care a fost discutată în prelegeri 3. Acest caz de protejare a programului este extrem de rar aplicat - numai atunci când cerințele pentru fiabilitatea PS sunt extrem de ridicate .
11.6. Furnizarea de securitate software.
Distinge următoarele tipuri de protecție PS de la denaturarea informațiilor:
protecția împotriva eșecurilor echipamentelor;
protecția împotriva influenței programului "străin";
protecția împotriva refuzurilor programului "său";
protecția împotriva erorilor operatorului (utilizator);
protecția împotriva accesului neautorizat;
protecția împotriva protecției.
Protecția împotriva eșecurilor echipamentului nu este în prezent o sarcină foarte actuală (inclusiv nivelul de calculatoare obținute). Dar este încă util să-i cunoaștem decizia. Acest lucru este asigurat de organizarea așa-numitelor "greșeli duble triple". Pentru aceasta, întregul proces de prelucrare a datelor, definit de PS, este împărțit în timp pe intervalele așa-numitelor "puncte de referință". Durata acestui interval nu trebuie să depășească jumătate din timpul de mijloc al funcționării fără probleme a computerului. O copie a stării variabilei de memorie în acest proces al fiecărui punct de referință este înregistrată în memoria secundară, cu un anumit control (numărul calculat ca o anumită funcție din această stare) în cazul în care se calculează că prelucrarea datelor din referința anterioară indică acest lucru (adică o "greșeală") este făcută corect (fără eșecuri de calculator). Pentru a afla, se produc două astfel de "greșeli". După prima "calculare greșită", suma de control specificată este calculată și este memorată și apoi starea memoriei este restabilită pentru punctul de referință anterior și cea de-a doua "calculare greșită" se face. După cea de-a doua "calculare greșită", se calculează controlul specificat, care este apoi comparat cu cantitatea de control a primei "greșeli". Dacă aceste două sume de control sunt aceleași, a doua greșeală este considerată corectă, altfel suma de verificare a celei de-a doua "greșeli" este, de asemenea, amintită și a produs a treia "greșeală" (cu recuperarea preliminară a stării de memorie pentru punctul de referință anterior). În cazul în care suma de control a celei de-a treia "greșeli" coincide cu controlul uneia dintre primele două "greșeli", atunci cea de-a treia greșeală este considerată corectă, în caz contrar este necesară testarea ingineriei calculatorului.
Protecția împotriva influenței programului "Alien" se aplică în principal sistemelor de operare sau programelor care efectuează funcții parțial. Există două soiuri de protecție:
protecția împotriva eșecurilor
protecția împotriva influenței rău intenționate a programului "străin".
Atunci când în memoria sa un mod de computer multiprogrammatic, acesta poate fi simultan în etapa de execuție a mai multor programe, care primește alternativ managementul ca urmare a întreruperii emergente (așa-numita execuție a programului cvasi-paralel). Unul dintre aceste programe (de obicei: sistemul de operare) este angajat în procesarea întreruperilor și a modului de control multiprogram. În fiecare dintre aceste programe, pot apărea refuzuri (erori se manifestă), ceea ce poate afecta performanța funcțiilor prin alte programe. Prin urmare, programul de management (sistemul de operare) trebuie să asigure protecția în sine și a altor programe de la o astfel de influență. Pentru a face acest lucru, echipamentul informatic trebuie să implementeze următoarele caracteristici:
protecția memoriei
două moduri de funcționare a computerului: privilegiat și de lucru (utilizator),
două tipuri de operațiuni: privilegiate și obișnuite,
implementarea corectă a întreruperilor și includerea inițială a computerului,
Întreruperea temporară.
Protecția memoriei înseamnă capacitatea de a specifica pentru fiecare program inaccesibil pentru aceasta. În modul privilegiat, pot fi efectuate orice operațiune (atât obișnuită, cât și privilegiată) și în modul de funcționare - numai obișnuită. O încercare de a efectua o operație privilegiată și, de asemenea, să se refere la memoria protejată în modul de funcționare apelând întreruperea corespunzătoare. În plus, operațiunile privilegiate includ operațiunile Schimbați protecția memoriei și modul de funcționare, precum și accesul la un mediu de informare extern. Activarea inițială a computerului și orice întrerupere trebuie să includă automat modul privilegiat și anularea protecției memoriei. În acest caz, programul de control (sistemul de operare) se poate proteja pe deplin de influența altor programe, dacă toate punctele de control pentru pornirea inițială și întreruperile vor aparține acestui program dacă nu face alt program de lucru într-un mod privilegiat ( Când transmiteți orice alt control, programul va porni numai modul de lucru) și dacă protejează complet memoria (care conține, în special, toate informațiile de control, inclusiv așa-numitul vector de întrerupere) din alte programe. Apoi, nimeni nu o va împiedica să efectueze alte programe implementate în acesta (inclusiv accesul la mediul de informare externă). Pentru a facilita soluția acestei sarcini, o parte a unui astfel de program este plasată în memorie constantă, adică. inseparabil de pe computerul în sine. Prezența întreruperii temporare permite programului de control pentru a proteja împotriva înclinării în alte programe (fără o astfel de întrerupere, ar putea pierde pur și simplu ocazia de a gestiona).
Protecția împotriva refuzurilor programului "ITS" este asigurată de fiabilitatea acestui program, la care toate tehnologiile de programare discutate în cursul actual al prelegerilor este axată.
Protecția împotriva erorilor de utilizatori (în plus față de erorile de intrare, a se vedea durabilitatea PS) este asigurată prin emiterea de mesaje de avertizare despre încercarea de a schimba starea mediului de informare externă cu cerința de confirmare a acestor acțiuni, precum și posibilitatea de a Restaurarea stării componentelor individuale ale mediului extern de informații. Acesta din urmă se bazează pe schimbările de arhivare în starea mediului de informare externă.
Protecția împotriva accesului neautorizat este asigurată prin utilizarea cuvintelor secrete (parole). În acest caz, fiecare utilizator este prevăzut cu anumite informații și resurse procedurale (servicii), pentru utilizarea PS-ului a fost prezentată cu o parolă, înregistrată anterior în PS din acest utilizator. Cu alte cuvinte, utilizatorul, așa cum a fost, "atârnă castelul" la resursele alocate lui, "cheia" din care are doar acest utilizator. Cu toate acestea, în unele cazuri, pot fi luate încercări persistente pentru a hack o astfel de protecție dacă resursele protejate sunt transmise pentru o valoare de urgență pentru o valoare de urgență. Pentru un astfel de caz, este necesar să se ia măsuri suplimentare pentru a proteja împotriva protecției ruperii.
Protecția împotriva protecției de rupere este legată de utilizarea tehnicilor speciale de programator în PS, ceea ce face dificilă depășirea protecției împotriva accesului neautorizat. Utilizarea parolelor obișnuite este insuficientă atunci când vine vorba de o dorință extrem de persistentă (de exemplu, o natură penală) pentru a obține acces la informații valoroase. În primul rând, deoarece parola informează că PS utilizează pentru a proteja împotriva accesului neautorizat, "cracker" al acestei apărare poate fi relativ ușor de a obține dacă are acces la acest PS în sine. În al doilea rând, folosind un computer, puteți exercita o căutare destul de mare pentru posibilele parole pentru a găsi accesul la informații. Este posibil să se protejeze împotriva unui astfel de hacking după cum urmează. Cuvântul secret (parola) sau pur și simplu un integer secret X știe numai proprietarul informațiilor protejate, iar un alt număr Y \u003d F (x) este stocat pentru a verifica drepturile de acces în computer, calculate în mod unic, cu fiecare încercare de a accesa acest lucru informații la prezentarea unui cuvânt secret. În acest caz, funcția F poate fi bine cunoscută tuturor utilizatorilor PS, are o astfel de proprietate că recuperarea cuvântului X prin Y este aproape imposibilă: cu o lungime suficient de mare a cuvântului X (de exemplu, mai multe sute de caractere) necesită timp astronomic. Un astfel de număr Y va fi numit o semnătură electronică (computer) a proprietarului cuvântului secret X (și, prin urmare, sunt, de asemenea, informații protejate).
Un alt tip de astfel de protecție este asociat cu protecția mesajelor trimise prin rețele de calculatoare, denaturări intenționate (sau rău intenționate). Astfel de mesaje pot fi interceptate pe punctele de rețea de calculatoare "Transhipment" și înlocuite cu un alt mesaj de la autorul mesajului interceptat. O astfel de situație apare în primul rând în implementarea operațiunilor bancare utilizând o rețea de calculatoare. Prin înlocuirea unui astfel de mesaj, care se referă la proprietarul unui cont bancar cu privire la punerea în aplicare a unei anumite operațiuni bancare, banii din contul său pot fi transferați în contul "Burglăgerii" (un tip specific de jaf de calculator al băncii). Protecția împotriva unei astfel de protecții de rupere poate fi efectuată după cum urmează. Împreună cu funcția F, care definește semnarea computerului proprietarului cuvântului secret, care cunoaște destinația mesajului protejat (dacă numai proprietarul său este clientul acestui destinatar), o altă funcție de timbru este definită în PS, conform căreia Expeditorul trebuie să calculeze numărul S \u003d ștampila (x, r) utilizând cuvântul secret X și textul mesajului transmis R. Funcția de timbru este, de asemenea, considerată a fi bine cunoscută tuturor utilizatorilor PS și are o astfel de proprietate care de către S Este aproape imposibil să restaurați numărul x, nici să alegeți un alt mesaj R cu semnătura computerizată corespunzătoare. Mesajul transmis în sine (împreună cu protecția acestuia) ar trebui să fie:
mai mult decât atât, Y (Semnătura Computerului) permite adresarea de a stabili adevărul clientului și S pare să fixeze mesajul protejat RC Computer Signature Y. În această privință, vom numi sigiliul electronic de numere S. O altă caracteristică notarială este definită în PS, la care destinatarul mesajului protejat verifică adevărul mesajului transmis:
Acest lucru vă permite să stabiliți fără echivoc că mesajul R aparține proprietarului cuvântului secret X.
Protecția împotriva protecției este necesară în cazul în care utilizatorul a uitat (sau a pierdut) parola. Pentru un astfel de caz, ar trebui să fie furnizat unui utilizator special (administrator PS) responsabil pentru funcționarea sistemului de protecție, să efectueze o eliminare temporară a protecției împotriva accesului neautorizat pentru proprietarul parolei uitate pentru a le da posibilitatea de a repara o nouă parolă.
Literatură pentru prelegere 11.
11.1. ESTE. BEREZIN, N.P. Lichid. Metode de calcul etc. 1 și 2. - M.: Fizmatgiz, 1959.
11.2. N.S. Bowls, N.P. Lichid, G.M. Kobelkov. Metode numerice. - M.: ȘTIINȚĂ, 1987.
11.3. Myers. Fiabilitate software. - M.: MIR, 1980. P. 127-154.
11.4. UN. Lebedev. Protecția informațiilor bancare și a criptografiei moderne // Întrebările de protecție a informațiilor, 2 (29), 1995.
Curs 12. Furnizarea de calitate software
12.1. Caracteristicile generale ale procesului de asigurare a calității software-ului.
După cum sa menționat deja în prelegeri 4, specificația calității determină principalele orientări (obiective), care, în toate etapele dezvoltării PS, oricum influențează adoptarea diferitelor soluții pentru a alege din opțiunea corespunzătoare. Cu toate acestea, fiecare primitiv de calitate are propriile caracteristici ale unei astfel de influențe, asigurându-se astfel prezența în PS poate necesita abordările și metodele sale de dezvoltare a părților PS sau individuale. În plus, inconsecvența criteriilor de calitate a PS și exprimându-și primitivele de calitate a fost, de asemenea: o bună asigurare a unei singure PS primitive PS ar putea face în mod semnificativ dificil sau de a face imposibilă oferirea unor dintre acestea de la aceste primitive. Prin urmare, o parte substanțială a procesului de asigurare a calității PS constă în găsirea de compromisuri acceptabile. Aceste compromisuri sunt parțial determinate deja definite în specificația calității PS: modelul de calitate PS trebuie să precizeze gradul necesar de prezență în PS din fiecare dintre cele primitive de calitate și să determine prioritățile pentru realizarea acestor grade.
Asigurarea calității se desfășoară în fiecare proces tehnologic: deciziile luate în grade diferite afectează calitatea PS ca un întreg. În special, deoarece o parte semnificativă a primitivelor de calitate nu este asociată cu proprietățile programelor incluse în PS, ca și în cazul proprietăților documentației. În virtutea conflictului constatat de primitive de calitate, este foarte important să respectăm prioritățile selectate în furnizarea lor. Dar, în orice caz, este util să adere la două principii generale:
În primul rând, este necesar să se asigure funcționalitatea și fiabilitatea necesară a PS-ului și apoi să aducă criteriile de calitate rămase la un nivel acceptabil de prezență în PS;
nu este nevoie și poate fi chiar dăunătoare pentru a obține un nivel mai ridicat de prezență în PS de orice primitiv de calitate decât cel definit în specificația Calității PS.
Asigurarea funcționalității și fiabilității PP au fost luate în considerare în prelegerea anterioară. Mai jos este discutat de furnizarea altor criterii de calitate PS.
12.2 .. Asigurarea ușurinței de aplicare a software-ului
PP Documenumment determină compoziția documentației utilizatorului
În prelegerea anterioară, a fost deja luată în considerare furnizarea a două dintre cele cinci primitive de calitate (durabilitate și securitate), care determină ușurința utilizării PS.
Documentația și informativitatea determină compoziția și calitatea documentației utilizatorului (consultați următoarea prelegere).
Comunicarea este asigurată prin crearea unei interfețe de utilizator adecvate și implementarea corespunzătoare a situațiilor excepționale. Care este problema aici?
12.3. Asigurarea eficienței software-ului.
Eficacitatea PS este asigurată prin adoptarea de soluții adecvate în diferite etape ale dezvoltării sale, începând cu dezvoltarea arhitecturii sale. În special, pe eficacitatea PS (în special prin memorie) afectează alegerea structurii și prezentării datelor. Dar alegerea algoritmilor utilizați în anumite module software, precum și caracteristicile implementării acestora (inclusiv alegerea limbajului de programare) pot afecta în mod semnificativ eficacitatea PS. În același timp, trebuie să rezolve în mod constant contradicția dintre eficiența temporară și eficiența memoriei. Prin urmare, este foarte important ca specificația calității să indice în mod clar raportul cantitativ între indicatorii acestor primitivi de calitate sau cel puțin limitele cantitative sunt date pentru unul dintre acești indicatori. Cu toate acestea, diferite module software afectează eficacitatea PS în ansamblu în moduri diferite: și la depozit în costurile totale ale PS în timp și memorie și pe efectul asupra diferitelor primitive de calitate (unele module pot afecta puternic realizarea Eficiența temporară și practic nu afectează eficiența memoriei, în timp ce altele pot afecta în mod semnificativ consumul total de memorie, fără a oferi o influență vizibilă în timpul funcționării PS). În plus, acesta este un impact (în primul rând în raport cu eficiența temporară) în prealabil (până la sfârșitul implementării PS) nu este întotdeauna posibil să se aprecieze.
mai întâi trebuie să dezvolți un PS fiabil și numai atunci pentru a-și atinge eficiența necesară în conformitate cu specificația de calitate a acestui PS;
pentru a îmbunătăți eficiența PS, utilizați în primul rând compilatorul de optimizare - acest lucru poate oferi eficiența necesară;
dacă eficacitatea PS nu îndeplinește specificațiile calității sale, găsiți cele mai critice module din punctul de vedere al eficienței PS necesare (în cazul eficienței timpului, va fi necesar să se obțină o distribuție a timpului de operare PS module prin măsurători adecvate în timpul executării PS); aceste module și încearcă să optimizeze în primul rând de modificările lor manuale;
nu optimizați modulul dacă acest lucru nu este necesar pentru a atinge eficiența necesară a PS.
12.4. Asigurarea însoțită.
C-Documente, Informativitate și înțelegere determină compoziția și calitatea documentației de acompaniament (a se vedea următoarea prelegere). În plus, pot fi trase următoarele recomandări în raport cu textele programelor (module).
utilizarea în modulul de text Comentarii clarificând și explicând caracteristicile deciziilor luate; Dacă este posibil, porniți comentariile (cel puțin pe scurt) în cea mai veche etapă a textului modulului;
utilizați nume semnificative (mnemonice) și distins (lungime de nume optim - 4-12 litri, numere - la sfârșit), nu utilizați nume similare și cuvinte cheie;
observați prudență în utilizarea constantelor (constanta unică trebuie să aibă o singură intrare în textul modulului: când este declarat sau, în cazul extrem, atunci când variabila este inițializată ca o constantă);
nu vă fie frică să nu utilizați paranteze de legare (parantezele sunt mai ieftine decât erorile;
nu mai mult decât un operator în șir; Pentru a clarifica structura modulului, utilizați spații suplimentare (liniuțe) la începutul fiecărui rând;
evitați trucurile, adică Astfel de tehnici de programare Când se creează fragmente ale modulului, efectul principal al căruia nu este evident sau ascuns (învelit), de exemplu, efectele secundare ale funcțiilor.
Extinderea este asigurată prin crearea unui instalator adecvat.
Structurarea și modularitatea simplifică atât înțelegerea textelor text, cât și a modificării acestora.
12.5. Mobilitate.
Literatură pentru prelegere 12.
12.1. Ian Sommerville. Inginerie software. - Addison-Wesley Publishing Company, 1992. P.
12.3. D.Va Tasel. Stil, dezvoltare, eficiență, depanare și testare. - M.: MIR, 1985. P. 8-44, 117-178.
12.4. Documentația utilizatorului de software / standard ANSI / IEEE 1063-1987.
Curs 13. Documentarea software-ului
13.1. Documentația creată în procesul de dezvoltare software.
La dezvoltarea PS, se creează o cantitate mare de documentație diversă. Este necesar ca un mijloc de transmitere a informațiilor între dezvoltatorii PS ca mijloc de gestionare a dezvoltării PS și ca mijloc de transferare către utilizatorii informațiilor necesare pentru utilizarea și susținerea PS. Crearea acestei documentații reprezintă o mare parte din costul PS.
Această documentație poate fi împărțită în două grupe:
Managementul documentelor PS.
Documentele incluse în PS.
Documentele de dezvoltare PS (documentație de proces), înregistrează procesele de dezvoltare și întreținere PS, oferind comunicarea în cadrul echipei de dezvoltatori și între echipa dezvoltatorului și managerii (managerii) - managerii de dezvoltare. Aceste documente pot fi următoarele tipuri:
Planuri, evaluări, programe. Aceste documente sunt create de manageri pentru a prezice și a gestiona procesele de dezvoltare și întreținere.
Rapoarte privind utilizarea resurselor în procesul de dezvoltare. Create de manageri.
Standarde. Aceste documente sunt prescrise dezvoltatorilor, ce principii, reguli, acorduri, trebuie să urmeze în procesul de dezvoltare PS. Aceste standarde pot fi atât internaționale, cât și naționale și special create pentru organizație, care conține dezvoltarea acestui PS.
Documente de lucru. Acestea sunt principalele documente tehnice care asigură relația dintre dezvoltatori. Acestea conțin fixarea ideilor și a problemelor care apar în procesul de dezvoltare, o descriere a strategiilor și abordărilor utilizate, precum și versiunile de lucru (temporare) ale documentelor care trebuie înregistrate.
Note și corespondență. Aceste documente înregistrează diverse detalii despre interacțiunea dintre manageri și dezvoltatori.
Documentele incluse în PS (documentația produsului) descriu programele PS atât din punct de vedere al utilizării lor de către utilizatori, cât și din punct de vedere al dezvoltatorilor și suporturilor (în conformitate cu scopul PS). Trebuie remarcat faptul că aceste documente vor fi utilizate nu numai la etapa de operare PS (în etapele sale de aplicare și întreținere), ci și în etapa de dezvoltare pentru a controla procesul de dezvoltare (împreună cu documentele de lucru) - în orice caz, Acestea trebuie verificate (testate) pentru respectarea programelor PS. Aceste documente formează două seturi cu scopuri diferite:
Documentație personalizată PS (Documentație P).
PS Documentația de acompaniament (C-Documentație).
13.2. Documentație personalizată de software.
Documentație personalizată PS (documentația utilizatorului) explică utilizatorilor, deoarece acestea trebuie să acționeze pentru a aplica acest PS. Este necesar ca PS implică orice interacțiune cu utilizatorii. O astfel de documentație include documente pe care accesul la instalarea PS (atunci când instalați PS cu setarea corespunzătoare din mediul de aplicare PS), atunci când aplicați PS-ul pentru a-și rezolva sarcinile și la controlul PS (de exemplu, când acest PS interacționează alte sisteme). Aceste documente afectează parțial acompaniamentul PS, dar nu se referă la aspecte legate de modificările programului.
În acest sens, ar trebui să existe două categorii de utilizatori PS: utilizatorii obișnuiți ai administratorilor PS și PS. Utilizatorul obișnuit PS (utilizatorul final) utilizează PS pentru a-și rezolva sarcinile (în zona sa). Poate fi un inginer care proiectează un dispozitiv tehnic sau un casier care vinde bilete feroviare folosind PS. Este posibil să nu știe multe detalii despre computerul sau principiile de programare. Administratorul PS (administrator de sistem) gestionează utilizarea PS de către utilizatorii obișnuiți și menține PS, nu este legată de modificările programului. De exemplu, poate ajusta drepturile de acces la PS între utilizatorii obișnuiți, să mențină comunicarea cu furnizorii de PS sau să efectueze anumite acțiuni pentru a sprijini PS în stare de lucru, dacă este activă ca parte a unui alt sistem.
Componența documentației utilizatorului depinde de publicul utilizatorilor la care acest PS este focalizat și pe utilizarea documentelor. Sub publicul, contingentul utilizatorilor PS este înțeles aici, care are nevoie de o anumită documentație de utilizator a PS. Un document de utilizator de succes depinde de definiția exactă a publicului pentru care este destinată. Documentația personalizată trebuie să conțină informațiile necesare pentru fiecare audiență. Sub modul de utilizare a documentelor se înțelege o metodă care definește modul în care acest document este utilizat. În mod obișnuit, utilizatorul este de obicei necesar pentru a fi necesar sau documente pentru studierea PS (utilizarea sub formă de instrucțiuni) sau pentru a clarifica unele informații (utilizarea ca referință).
În conformitate cu lucrările, puteți lua în considerare tipic următoarei compoziții de documentație de utilizator pentru PS suficient de mare:
General Descriere funcțională PS. Oferă o scurtă descriere a funcționalității PS. Proiectat pentru utilizatorii care au nevoie să decidă cât de mult este necesar pentru acest PS.
PS Ghid de instalare. Proiectat pentru administratorii de sistem. Trebuie să prescrie în detaliu modul de instalare a sistemelor într-un mediu specific. Trebuie să conțină o descriere a suporturilor care pot fi citite de mașini pe care PS, fișiere reprezentând PS-ul și cerințele pentru configurația minimă a echipamentului.
Instrucțiuni de utilizare a PS. Concepute pentru utilizatorii obișnuiți. Conține informațiile necesare privind utilizarea PS, organizată în formularul convenabil pentru ao studia.
Director pentru utilizarea PS. Concepute pentru utilizatorii obișnuiți. Conține informațiile necesare privind utilizarea PS, organizată în formularul convenabil la căutarea selectivă a detaliilor individuale.
Ghidul de gestionare a PS. Proiectat pentru administratorii de sistem. Ar trebui să descrie mesajele generate atunci când PS interacționează cu alte sisteme și cum să răspundă la aceste mesaje. În plus, în cazul în care PS utilizează echipamentul de sistem, acest document poate explica modul de însoțire a acestui echipament.
Așa cum am menționat mai devreme (a se vedea cursurile 4), dezvoltarea documentației utilizatorului începe imediat după crearea unei descrieri externe. Calitatea acestei documentații poate determina în mod semnificativ succesul PS. Ar trebui să fie destul de simplu și convenabil pentru utilizator (altfel este PS, în general, nu ar trebui să creeze). Prin urmare, deși proiectele de variante (schițele) documentelor personalizate sunt create de principalii dezvoltatori ai PS, scriitorii tehnici profesioniști sunt adesea atrași de crearea versiunilor finale. În plus, au fost elaborate o serie de standarde pentru a asigura calitatea documentației utilizatorului (vezi de exemplu), în care este prevăzută procedura de elaborare a acestei documentații, sunt formulate cerințele pentru fiecare tip de documente de utilizator și structura și conținutul acestora sunt determinat.
13.3. Software-ul însoțește documentația.
Documentația de suport PS (documentația sistemului) descrie PS din punctul de vedere al dezvoltării sale. Această documentație este necesară dacă PS implică învățarea modului în care este aranjată (proiectată) și modernizarea programelor sale. După cum sa observat deja, acompaniamentul continuă să se dezvolte. Prin urmare, dacă este necesar, modernizarea PS la această lucrare este atrasă de o echipă specială de dezvoltatori. Această echipă va trebui să se ocupe de aceeași documentație care a determinat activitățile echipei dezvoltatorilor inițiali (de bază) PS, - cu diferența că această documentație pentru echipa dezvoltatorului de programare va fi, de regulă, altcineva (a fost create de o altă comandă). Echipa de planificator va trebui să studieze această documentație pentru a înțelege structura și procesul de dezvoltare a unui PS modernizat și pentru a face modificările necesare în această documentație, repetând o mare măsură procese tehnologice cu ajutorul cărora a fost creat PS inițial.
Documentația de asistență PS poate fi împărțită în două grupe:
(1) documentația care determină structura programelor și a structurilor de date ale PS și tehnologia dezvoltării acestora;
(2) Documentația care ajută la modificarea PS.
Documentația primului grup conține documentele finale ale fiecărei etape tehnologice a dezvoltării PS. Acesta include următoarele documente:
Descriere externă PS (documentul cerințelor).
Descrierea arhitecturii PS (descrierea arhitecturii sistemului), inclusiv specificația externă a fiecărui program.
Pentru fiecare program PS, o descriere a structurii sale modulare, inclusiv specificația externă a fiecărui modul inclus în el.
Pentru fiecare modul - specificația și descrierea structurii sale (descrierea designului).
Texte de module în limba de programare selectată (listă de coduri sursă de program).
PS Documente contabile (documente de validare) care descriu modul în care a fost stabilită acuratețea fiecărui program PS și modul în care informațiile despre stabilirea preciziei au fost asociate cu cerințele pentru PS.
Documentele valide PS includ în principal documentația de testare (schema de testare și descrierea testelor), dar pot include, de asemenea, rezultatele altor tipuri de verificări PS, de exemplu, dovezi ale proprietăților programului.
Documentația celui de-al doilea grup conține
Ghid de susținere a PS (Ghid de întreținere a sistemului), care descrie problemele cunoscute cu PS, descrie ce părți ale sistemului sunt hardware și dependente de software și modul în care dezvoltarea PS este luată în considerare în structura sa (design).
Problema generală de menținere a PS este de a se asigura că toate reprezentările sale merg la picior (rămase convenite) când PS variază. Pentru a ajuta, comunicarea și dependențele dintre documente și părțile acestora ar trebui înregistrate în baza de date de gestionare a configurației.
Literatura pentru prelegerea 13.
13.1. Ian Sommerville. Inginerie software. - Addison-Wesley Publishing Company, 1992. P.
13.2. ANSI / IEEE STD 1063-1988, Standard IEEE pentru documentația utilizatorului de software.
13.3. ANSI / IEEE STD 830-1984, Ghidul IEEE pentru specificațiile cerințelor software.
13.4. ANSI / IEEE STD 1016-1987, IEEE Practica recomandată pentru descrierea designului software.
13.5. ANSI / IEEE STD 1008-1987, standardul IEEE pentru testarea unității software.
13.6. ANSI / IEEE STD 1012-1986, standardul IEEE pentru planurile de verificare și validare a software-ului.
13.7. ANSI / IEEE STD 983-1986, Ghidul IEEE pentru planificarea asigurării calității software-ului.
13,8. ANSI / IEEE STD 829-1983, Standard IEEE pentru documentația de testare a software-ului.
Curs 14. Certificarea software-ului
Numirea certificării software-ului. Teste și evaluarea calității software-ului. Tipuri de testare și metode de evaluare a calității software-ului.
14.1. Numirea certificării software-ului.
Certificarea PS este o confirmare autoritară a calității PS. De obicei, o comisie reprezentativă (certificare) de la experți, reprezentanți ai clientului și reprezentanți ai dezvoltatorului este creată pentru certificarea PS. Această comisie desfășoară teste PS pentru a obține informațiile necesare pentru a-și evalua calitatea. Sub testul PS, vom înțelege procesul de realizare a unui set de măsuri care explorează adecvarea PS pentru o funcționare reușită (aplicare și întreținere) în conformitate cu cerințele clientului. Acest complex include verificarea completitudinii și exactității documentației programului, a studiului și a discuției despre celelalte proprietăți, precum și a testării necesare a programelor incluse în PS și, în special, conformitatea acestor programe de documentare.
Pe baza informațiilor obținute în timpul încercărilor PS, în primul rând, trebuie stabilit că PS îndeplinește funcții declarate și trebuie, de asemenea, stabilite la care PS a declarat primitive și criterii de calitate. Astfel, evaluarea calității PS este conținutul principal al procesului de certificare. Evaluarea calității PS efectuată este înregistrată în decizia corespunzătoare a Comisiei de atestare.
14.2. Tipuri de software de testare.
Următoarele tipuri de teste ale PS sunt cunoscute în scopul certificării PS:
componentele de testare ale PS;
teste de sistem;
teste de acceptare;
teste de teren;
teste industriale.
Componentele de testare ale PS este un test (testarea) de performanță a subsistemelor individuale PS. Efectuate numai în cazuri excepționale la o decizie specială a Comisiei de atestare.
Testele de sistem PS este un test (testarea) funcționării PS ca întreg. Acesta poate include aceleași tipuri de testare ca în depanarea complexă a PS (a se vedea conferința 10). Acesta este realizat prin decizia Comisiei de atestare, dacă există îndoieli ca pe depanarea dezvoltatorilor PS.
Testele de acceptare sunt principalul tip de teste în timpul certificării PS. Din aceste teste începe Comisia de atestare. Aceste teste încep cu studiul documentației prezentate, inclusiv documentația de testare și depanare PS. În cazul în care documentația nu are suficiente rezultate complete ale testului PS, Comisia de atestare poate decide să efectueze teste de sistem ale PS sau la încetarea procesului de certificare cu recomandarea dezvoltatorului de a efectua testarea suplimentară (mai completă) PS. În plus, în timpul acestor teste, testele dezvoltatorilor pot fi omiteți selectiv, precum și sarcini de control al utilizatorilor (a se vedea prelegerea 10) și teste suplimentare pregătite de Comisie pentru a evalua calitatea PS certificată.
Testele de câmp PS este o demonstrație a PS împreună cu sistemul tehnic că acest PS este gestionat, un cerc îngust de clienți în condiții reale și se efectuează o monitorizare aprofundată a comportamentului PS. Clienții trebuie să aibă posibilitatea de a-și stabili propriile exemple de control, în special din ieșiri în moduri critice de funcționare a sistemului tehnic, precum și cu provocarea situațiilor de urgență. Acestea sunt teste suplimentare efectuate prin decizia Comisiei de atestare numai pentru unele PS care gestionează anumite sisteme tehnice.
Testele industriale ale PS este procesul de transmitere a PS în funcționare continuă către utilizatori. Este o perioadă de funcționare pilot a utilizatorilor PS (a se vedea 10) cu colectarea de informații privind particularitățile comportamentului PS și caracteristicile sale operaționale. Acestea sunt testele finale ale PS, care se desfășoară prin decizia Comisiei de atestare, în cazul în care nu există suficiente informații complete sau fiabile cu privire la testele precedente pentru a evalua calitatea PS certificată.
14.3. Metode de evaluare a calității software-ului.
Evaluarea calității PS pentru fiecare dintre criterii este redusă la estimarea fiecăruia dintre primitivii asociate criteriului de calitate PS, în conformitate cu concretizarea produsă în specificația de calitate a acestui PS. Metodele de estimare a primitivilor din PS pot fi împărțite în patru grupe:
măsurarea directă a indicatorilor primitivi de calitate;
programe de procesare și documentare PS cu instrumente software speciale (procesoare);
testarea programelor PS;
evaluarea experților pe baza studiului programelor și documentației PS.
Măsurarea directă a indicatorilor primitivi de calitate este realizată prin numărarea numărului de apariții într-unul sau alt document software al unităților caracteristice, obiecte, structuri etc., precum și prin măsurarea timpului de funcționare a diferitelor dispozitive și volumul calculatorului ocupat memorie atunci când efectuați exemple de control. De exemplu, un anumit indicator al eficienței memoriei poate fi numărul de rânduri de programare în limba de programare și o anumită rată de eficiență a timpului poate fi un timp de răspuns la o cerere. Utilizarea oricăror indicatori pentru primitivii de calitate poate fi determinată în specificația Calității PS. Metoda de măsurare directă a indicatorilor primitivi de calitate poate fi combinată cu utilizarea programelor de testare.
Pentru a stabili prezența unor primitive de calitate, pot fi utilizate anumite instrumente software. Astfel de instrumente software gestionează textele programelor sau documentației software pentru a controla orice primitive de calitate sau pentru a obține unii indicatori ai acestor primitive de calitate. Pentru a evalua structura programelor PS, dacă sunt programate într-un dialect structural adecvat al limbajului de programare, ar fi suficient să le treceți prin convertizorul programelor structurate care efectuează controlul sintactic și un semantic al acestui dialectul și traducerea Textele acestor programe pe limba de intrare a traducătorului de bază. Cu toate acestea, în acest fel, doar un număr mic de primitive de calitate pot fi controlate și chiar apoi în cazuri rare. În unele cazuri, în loc de instrumente software care controlează calitatea PS-ului sunt mai utile pentru a aplica instrumente care transformă prezentarea programului sau documentația software. Astfel, de exemplu, este formatorul de program, conducând textele programelor la o formă citită, - procesarea textelor programelor PS, un astfel de instrument poate asigura în mod automat prezența unui primitiv de calitate adecvat pentru PS.
Testarea este utilizată pentru a evalua o calitate primitivă PS. Astfel de primitive se aplică în primul rând finalizarea PS, precum și acuratețea, stabilitatea, securitatea și alte primitive de calitate. În unele cazuri, testarea este utilizată în combinație cu alte metode pentru evaluarea primitivilor individuali ai calității PS. Deci, pentru a evalua calitatea documentației pentru utilizarea PS (U-Documenare), testarea este utilizată în combinație cu o evaluare a experților din această documentație. Dacă, cu o depanare cuprinzătoare a PS, a fost efectuată o testare destul de completă, atunci aceleași teste pot fi utilizate și în certificarea PS. În acest caz, Comisia de atestare poate utiliza protocoale de testare efectuate în timpul depunerii complexe. Cu toate acestea, în acest caz, trebuie să îndepliniți teste noi sau cel puțin re-unii vechi. Dacă testarea în timpul depunerii complexe vor fi defonate suficient, este necesar să se efectueze o testare mai completă. În acest caz, se poate decide să se efectueze componentele testului sau testele de sistem ale PS, precum și revenirea PS la dezvoltarea rafinării. Este foarte important ca pentru estimarea PS prin criteriul ușurinței de utilizare (în timpul depunerii și certificării PS), testarea completă a testelor întocmite pe baza documentației pentru aplicație și în conformitate cu criteriul de însoțire - pe teste pregătite Pentru fiecare dintre documentele oferite pentru întreținere PS.
Pentru a evalua majoritatea primitivi ai calității PS, este posibil în prezent să se utilizeze numai metoda evaluărilor experților. Această metodă este următoarea: Un grup de experți este desemnat, fiecare dintre acești experți ca rezultat al studiului documentației prezentate își face avizul cu privire la posesia PS cerută de calitatea primitivă și apoi votul membrilor din Acest grup stabilește evaluarea calității primitive necesare a PS. Această evaluare poate fi efectuată ca un sistem bullic ("posedă" - "nu posedă") \u200b\u200bși să ia în considerare gradul de posesie a PS-ului acestei calități primitive (de exemplu, să se facă pe un sistem de cinci puncte ). În același timp, grupul de experți ar trebui să fie ghidat de concretizarea acestui primitiv și de o indicație a metodei evaluării sale formulate în specificația calității PS certificată.
Literatură pentru prelegere 14.
14.2. V.V.LIPAEV. Programe de testare. - M.: Radio și comunicare, 1986. - P. 231-245.
14.3. D.Va Tasel. Stil, dezvoltare, eficiență, depanare și testare. - M.: MIR, 1985. - P. 281-283.
14.4. B. Shneiderman. Psihologie de programare. - M.: Radio și comunicare, 1984. - P. 99-127.
LECRE 15. Abordarea de atitudine a dezvoltării software
15.1. Obiecte și relații în programare. Esența abordării obiectului de dezvoltare software.
Lumea din jurul nostru constă în obiecte și relații între ele. Obiectul întruchipează o anumită esență și are o anumită condiție care se poate schimba în timp ca urmare a influenței altor obiecte care sunt cu date în orice respect. Poate avea o structură internă: constau din alte obiecte, de asemenea, între ele în anumite privințe. Pe baza acestui fapt, puteți construi o structură ierarhică a lumii din obiecte. Cu toate acestea, cu fiecare considerație specifică a lumii noastre din jurul nostru, unele obiecte sunt considerate indivizibile ("la fața locului") și, în funcție de obiectivele luării în considerare prin aceasta (indivizibil), pot fi luate obiecte de diferite niveluri ale ierarhiei. Atitudinea leagă unele obiecte: putem presupune că combinația acestor obiecte are o anumită proprietate. Dacă raportul leagă obiectele N, atunci o astfel de atitudine se numește N-local (n-arny). La fiecare loc de combinare a obiectelor care pot fi asociate cu orice atitudine specifică, pot exista obiecte diferite, dar destul de definite (în acest caz spun: obiecte ale unei anumite clase). Raportul unic se numește proprietatea unui obiect (clasa corespunzătoare). Starea obiectului poate fi studiată de valoarea proprietăților acestui obiect sau implicit valoarea proprietăților asociațiilor obiectelor asociate cu aceste sau alte atitudini.
În procesul de cunoaștere sau de schimbare a lumii în jurul nostru, întotdeauna luăm în considerare acest lucru sau de acel model simplificat al lumii (Model World), care include unele dintre obiectele și unele dintre relațiile din jurul nostru și, de regulă, un nivel al ierarhiei. Fiecare obiect având o structură internă poate reprezenta lumea sa, care include obiecte ale acestei structuri și relația pe care le asociază. Astfel, lumea din jurul nostru poate fi luată în considerare (într-o anumită aproximare) ca structură ierarhică a lumilor modelului.
În prezent, un echipament de calculator pentru procesarea diferitelor tipuri de informații este utilizat pe scară largă în procesul de cunoaștere sau schimbare în jurul nostru. În acest sens, se aplică o reprezentare a obiectelor și a relațiilor informatice (informaționale). Fiecare informații despre obiect pot fi reprezentate de unele structuri de date care prezintă starea acestuia. Proprietățile acestui obiect pot fi stabilite direct ca componente individuale ale acestei structuri sau caracteristici speciale asupra acestei structuri de date. Relațiile N-Locale pentru N\u003e 1 pot fi reprezentate fie în formă activă, fie în formă pasivă. În formă activă, relația N-Local pare a fi un fragment de software care implementează fie funcția N-local (definind valoarea proprietății obiectelor combinate corespunzătoare), fie procedura care se desfășoară ca prezentări ale obiectelor asociate reprezentanței Relația, schimbarea în stările unora dintre ele. În formă pasivă, o astfel de atitudine poate fi reprezentată de o anumită structură de date (care poate include și reprezentând obiectele asociate cu acest raport), interpretat pe baza acordurilor adoptate privind procedurile generale, independent de relații specifice (de exemplu, o bază de date relațională ). În orice caz, vizualizarea relației determină unele acțiuni de procesare a datelor.
Când studiați lumea modelului, utilizatorul poate primi în mod diferit (sau doriți să primiți) informații de pe computer. Cu o singură abordare, poate fi interesată să obțină informații despre proprietățile individuale ale obiectelor sale de interes sau despre rezultatele oricărei interacțiuni între unele obiecte. Pentru a face acest lucru, el ordonă dezvoltarea unui PS particular care îndeplinește funcțiile sale de interese sau un anumit sistem de informare, capabil să emită informații despre relațiile sale, utilizând baza de date corespunzătoare. În perioada inițială a dezvoltării echipamentelor informatice (cu o putere suficientă de computere), această abordare a utilizării computerelor a fost destul de naturală. A fost cel care a provocat o abordare funcțională (relațională) a dezvoltării PS, care a fost considerată în detaliu în prelegerile precedente. Esența acestei abordări constă în utilizarea sistematică a descompunerii funcțiilor (relațiilor) pentru a construi structura PS și a textelor programelor incluse în acesta. În același timp, obiectele care sunt utilizate pentru a fi comandate și funcții implementate sunt fragmentare (în volumul necesar pentru efectuarea acestor funcții) și în formă, convenabil pentru implementarea acestor funcții. Astfel, nu a fost prevăzut cu o reprezentare solidă și adecvată a computerului lumii modelului, a utilizatorului care este interesat de: afișarea acestuia pe PS utilizat ar putea fi pentru utilizator o sarcină destul de laborioasă, încercări de extindere minoră și natura a informațiilor despre modelul lumii de interes. Obținut de la astfel de PS, ar putea duce la o modernizare gravă. O astfel de abordare a dezvoltării PS este susținută de majoritatea limbilor de programare, variind de la limbile de asamblare și limbi procedurale (Fortran, Pascal) în limbile funcționale (LISP) și limbile de programare logică (Prolog).
Într-o altă abordare a studiului lumii modelului, utilizarea unui computer computer poate fi interesată de monitorizarea schimbărilor în statele de stat ca urmare a interacțiunilor lor. Acest lucru necesită o prezentare suficient de solidă în calculatorul obiectului de interes și componentele software care implementează relațiile în care acest obiect este asociat în mod explicit cu acesta. Pentru a implementa această abordare, a trebuit să construiesc instrumente software care simulează procesele de interacțiune a obiectelor (lumea modelului). Cu ajutorul instrumentelor tradiționale de dezvoltare, sa dovedit a fi o sarcină destul de laborioasă. Adevărat, limbile de programare au apărut special orientate către o astfel de modelare, dar doar a simplificat parțial sarcina de a dezvolta PS-ul necesar. Abordarea obiectivă a dezvoltării PS este cea mai responsabilă pentru rezolvarea acestei sarcini. Esența sa constă în utilizarea sistematică a descompunerii obiectelor la construirea structurii PS și a textelor programelor incluse în acesta. În acest caz, funcțiile (rapoartele) efectuate de un astfel de PS au fost exprimate prin relația de obiecte de diferite nivele, adică, descompunerea lor semnificativ de descompunerea obiectelor.
Vorbind despre abordarea obiectului ar trebui, de asemenea, să înțeleagă în mod clar ce fel de obiecte vorbim: obiecte ale lumii modelului utilizatorului, despre prezentarea lor informațională, despre obiectele programului, cu ajutorul căruia se construiește PS. În plus, ar trebui să se distingă obiectele (obiecte "pasive") și subiecți (obiecte "active").
15.2. Obiecte și subiecți în programare.
15.3. Obiectul și abordările supuse dezvoltării software-ului.
Descartes a remarcat că oamenii au de obicei o viziune orientată pe obiecte asupra lumii (b).
Se crede că designul orientat pe obiecte se bazează pe principiile:
alocarea abstracțiilor
limitarea accesului,
modularitate,
ierarhie,
tipizare
paralelism,
stabilitate.
Dar toate acestea pot fi aplicate cu o abordare funcțională.
Ar trebui să se distingă prin avantajele și dezavantajele abordării obiectului general și a cazului său special - o abordare orientată spre subiect.
Avantajele unei abordări generale obiective:
Maparea naturală a lumii reale asupra structurii PS (percepția naturală a capacităților PS a PS nu are nevoie să "inventeze" structura PS-ului și să folosească analogii naturale).
Utilizarea unităților structurale suficient de substanțiale ale PS (obiect ca integritate a asociațiilor non-goale, module infationale și durabile).
Reducerea complexității dezvoltării PS prin utilizarea unui nou nivel de abstracții (utilizând ierarhia "non-tipăribilă" a abstracțiilor în dezvoltarea PS: clasificarea obiectelor din lumea reală, metoda de analogie în natură) ca un nou nivel de moștenire.
15.4. Abordarea obiectului pentru dezvoltarea unei descrieri externe și a arhitecturii de software.
Design orientat pe obiecte - o metodă care utilizează descompunerea obiectului; Abordarea orientată pe obiect are propriul sistem de denumiri condiționate și oferă un set bogat de modele logice și fizice pentru proiectarea sistemelor de înaltă complexitate. .
Abordarea obiectului a fost asigurată de analiza orientată pe obiecte (OOA). OOA vizează crearea de modele cele mai apropiate de realitate folosind o abordare orientată pe obiect; Această metodologie în care sunt formate cerințe pe baza conceptelor de clase și obiecte care constituie un dicționar al domeniului subiectului. .
Caracteristici ale programului orientat pe obiecte.
Obiecte, clase, comportament obiect, proprietăți, evenimente.
Literatură pentru prelegere 15.
15.1. K. Fudi, N. Suzuki. Limbi de programare și schema Sciti. - M.: MIR, 1988. P. 85-98.
15.2. Ian Sommerville. Inginerie software. - Compania de publicitate Addison-Wesley, 1992. P.? -?
15.3. Tufiș. Design orientat pe obiecte cu exemple de aplicare: per. din engleza - M.: Concord, 1992.
15.4. V.SH.KUFMAN. Limbaje de programare. Concepte și principii. M.: Radio și comunicare, 1993.
J. Hughes, J. Micht. Abordarea structurală a programului. - M.: MIR, 1980. - S. 29-71.
V. Tursky. Metodologie de programare. - M.: MIR, 1981. - P.90-164.
E.a. Zhogolev. Baze tehnologice de programare modulară // programare, 1980, # 2. - P.44-49.
R.c.holt. Structura programelor informatice: un sondaj // Procedura de IEEE, 1975, 63 (6). - p. 879-893.
G.maers. Fiabilitate software. - M.: MIR, 1980. - S. 92-113.
I. PIEL. Ada este limba sistemelor încorporate. M.: Finanțe și statistici, 1984. - Cu. 67-75.
M. Zelkovts, A. Show, J. Gannon. Principii de dezvoltare software. - M.: MIR, 1982, P. 65-71.
A.L. Fuksman. Aspecte tehnologice ale creării sistemelor software. M.: Statistici, 1979. - Cu. 79-94.
Smochin. 8.4. Un exemplu de un pas de detaliu pe pseudocod.