N.V. Komleva, A.A. Smirnov manual de informatică și programare. Programare ≠ informatică

  • Programare
    • Traducere

    Dezvoltarea software ca și cum ar fi în partea cea mai rea diferă de alte discipline informatice.

    Acum câțiva ani studiam algoritmii și complexitatea. Un domeniu încântător de curat, în care fiecare concept este clar definit, fiecare rezultat se bazează pe dovezile anterioare. Când cunoști un fapt în acest domeniu, te poți baza pe el, deoarece matematica însăși l-a dedus. Chiar și rezultatele imperfecte, cum ar fi algoritmii de aproximare și probabilistici, au o analiză riguroasă a imperfecțiunilor lor. Alte discipline de informatică, cum ar fi topologia rețelelor și criptografia, au un statut la fel de satisfăcător.

    Și acum lucrez în dezvoltarea de software, iar acesta este un subiect incredibil de alunecos. Niciun concept nu este definit cu precizie. Rezultatele sunt evaluate ca „de obicei” sau „în general”. Cercetarea de astăzi poate informa sau nu munca de mâine. Noile abordări răstoarnă adesea metodele anterioare, ard puternic pentru o perioadă scurtă de timp și apoi se demodează atunci când apar limitările lor. Am crezut în programarea structurată. Apoi au început să creadă în limbaje de generația a patra, apoi în metode orientate pe obiecte, apoi în programare extremă, și acum, poate, în sursă deschisă.

    Dar programarea este exact acolo unde anvelopa intră în contact cu asfaltul. Puțină lume îi pasă dacă este într-adevăr egal, doar de dragul frumuseții întrebării. Zona calculatoare se ocupa de calculatoare. Aceasta este scrierea de programe pentru a rezolva probleme umane reale și rularea acestor programe mașini adevărate. Conform tezei Church-Turing, totul echipamente informaticeîn esență echivalent. Deci deocamdată arhitectura calculatorului cool, adevărata limitare în informatică rămâne problema creării de software. Ne dorim programe care să poată fi puse împreună într-un timp rezonabil și la un cost rezonabil, care să funcționeze aproximativ așa cum au intenționat designerii și care rulează fără erori.

    Având în vedere acest scop, am fost întotdeauna îngrijorat de o întrebare (ca mulți alți cercetători): de ce nu pot programatorii să obțină rezultate mai riguroase ca în alte domenii ale informaticii? Cu alte cuvinte, „Cât de mult din arhitectura și designul software pot fi făcute formale și dovedibile?” Răspunsul la această întrebare este în Figura 1.


    Figura 1: Linie strălucitoare în informatică

    Subiectele de deasupra acestei linii aparțin dezvoltării software. Domeniile de studiu de sub această linie sunt subiectele de bază ale informaticii. Acestea din urmă au rezultate clare, formale. Pentru probleme deschiseîn acest domeniu ne aşteptăm să obţinem rezultate noi care vor fi formulate formal. Aceste subiecte se bazează unul pe celălalt: criptografia pe complexitate și compilatorii pe algoritmi, de exemplu. Mai mult, credem că rezultatele dovedite în aceste domenii vor rămâne așa în 100 de ani.

    Deci, ce este această linie strălucitoare și de ce nu există subiecte de programare sub ea? Linia este o calitate numită „implicare umană directă”. Dezvoltarea software are această calitate, dar informatica tradițională nu. Rezultatele de la disciplinele de sub linie pot fi folosite de oameni, dar aceste rezultate nu sunt direct afectate influență al oamenilor.

    Dezvoltarea software are o componentă umană inerentă. De exemplu, fiabilitatea operațională a software-ului este capacitatea oamenilor de a înțelege, găsi și corecta defecte. sistem software. Fiabilitatea operațională poate fi influențată de unele concepte formale de informatică - poate complexitatea ciclomatică a graficului de control al software-ului. Dar fiabilitatea operațională depinde în mod critic de oameni și de capacitatea lor de a înțelege semnificația și intenția codului sursă. Întrebarea dacă un anumit sistem software are o fiabilitate operațională ridicată nu poate fi răspunsă doar prin studierea mecanică a software-ului.

    La fel este și cu securitatea. Cercetătorii au folosit câteva metode formale pentru a afla impactul unui sistem software asupra sănătății și proprietății oamenilor. Dar nicio discuție despre securitatea software-ului nu poate fi considerată completă fără a aborda componenta umană a sistemului studiat. La fel și pentru dezvoltarea cerințelor. Putem dezvolta orice tehnici de sondaj pentru a obține cerințe precise de la părțile interesate și putem crea diverse sisteme pentru a le înregistra. Dar nici o cantitate de cercetare în acest domeniu nu va schimba faptul că colectarea cerințelor implică adesea vorbirea sau observarea oamenilor. Uneori, acești oameni ne spun informatii corecte, și uneori nu. Uneori oamenii mint, poate din motive întemeiate. Uneori, oamenii încearcă sincer să transmită informațiile corecte, dar nu reușesc să o facă.

    Această observație duce la teza lui Connell:

    Dezvoltarea software nu va fi niciodată o disciplină riguroasă cu rezultate dovedite, deoarece implică activitate umană.


    Aceasta este o afirmație extra-matematică despre limitele sistemelor formale. Nu am dovezi pro sau contra. Dar adevărul este că problemele umane rămân probleme centrale în dezvoltarea de software:
    • Ce ar trebui să facă acest program? (cerințe, utilizare, securitate)
    • Cum ar trebui să arate programul în interior, astfel încât să poată fi reparat și modificat cu ușurință? (arhitectură, design, scalabilitate, portabilitate, extensibilitate)
    • Cât timp va dura să-l scrii? (clasa)
    • Cum ar trebui să o dezvoltăm? (codificare, testare, măsurare, configurare)
    • Cum ar trebui să lucreze eficient o echipă? (management, proces, documentare)
    Toate aceste probleme gravitează în jurul oamenilor.

    Teza mea explică de ce dezvoltarea de software este atât de dificilă și atât de alunecoasă. Metodele dovedite ale unei echipe de programatori nu funcționează pentru alte echipe. O analiză exhaustivă a proiectelor trecute poate să nu fie utilă pentru o bună evaluare a următorului. Fiecare dintre instrumentele revoluționare de dezvoltare ajută puțin și apoi nu își îndeplinește marile promisiuni. Motivul este că oamenii sunt prea moale, dezamăgitori și imprevizibili.

    Înainte de a trece la implicațiile afirmației mele, să luăm în considerare trei obiecții plauzibile:

    Teza se realizează de la sine. Dacă o anumită zonă a dezvoltării software-ului are dintr-o dată o definiție strictă, atunci puteți schimba pur și simplu definiția dezvoltare de software pentru a elimina această problemă din ea.


    În anumite privințe, această obiecție este corectă, dar nu în toate. Susțin că setul de discipline denumit în mod obișnuit inginerie software va continua să provoace în mod inerent soluția riguroasă. Aspectele restrânse ale unor probleme se pot preta unei abordări formale, dar succesul lor va fi doar la periferia problemelor de dezvoltare de bază.

    Rezultatele statistice în programare infirmă deja această teză.


    Aceste metode abordează în general problema de estimare și includ Function Point Counting, COCOMO II, PROBE și altele. În ciuda aspectului lor matematic, aceste metode nu sunt dovezi sau rezultate formale. Astfel de statistici sunt pur și simplu o încercare de a cuantifica experiența umană subiectivă a proiectelor software trecute și de a o extrapola la proiectele viitoare. Uneori funcționează. Dar formulele aparent stricte din aceste scheme sunt un porc cu ruj, ca să folosim o expresie modernă. De exemplu, una dintre formulele din COCOMO II arată astfel: , unde , a este un set de cinci factori de scalare, cum ar fi „flexibilitatea dezvoltării” și „coeziunea echipei”. Formula în sine pare strictă, dar este dominată de un indicator format din factori umani.

    Procesele formale de dezvoltare, cum ar fi metoda camerei curate, găsesc treptat metode riguroase, demonstrabile. Ele ridică o linie strălucitoare pentru a aduce teme anterior neclare dedesubt.


    Într-adevăr, cercetătorii proceselor formale demonstrează progrese în rezolvare probleme diferite. Dar ei pot fi prinși încălcând prima obiecție de pe această listă: definesc dezvoltarea de software prea îngust pentru ca aceasta să se preteze la o soluție riguroasă. Metodele formale oferă pur și simplu o interpretare convenabilă a oricărei probleme care se bazează pe participarea și interpretarea umană. De exemplu, un element cheie al metodelor formale de dezvoltare este crearea de specificații stricte, fără ambiguitate. Aceste specificații sunt apoi folosite pentru a ghida (și dovedi) etapele de dezvoltare ulterioare. Desigur, o metodă formală poate conține o schemă de notație semantică neambiguă. Dar nicio metodă formală nu conține o rețetă exactă despre cum să traducă în gândurile vagi ale oamenilor fără ambiguitate despre ceea ce ar trebui să facă un program.

    Împotriva acestor obiecții, susțin că ingineria software este fundamental diferită de informatica tradițională, formală. Prima depinde de oameni, dar a doua nu. Acest lucru ne duce la concluzia lui Connell:

    Ar trebui să încetăm să încercăm să dovedim rezultate fundamentale în dezvoltarea de software și să recunoaștem că progresele semnificative în acest domeniu vor fi doar recomandări generale.


    De exemplu, David Parnas în 1972 a scris un articol științific minunat „Despre criteriile pentru descompunerea unui sistem în module”. Descrie un experiment simplu pe care Parnas l-a efectuat cu strategii alternative de proiectare a software-ului, una cu ascunderea informațiilor și alta cu vizibilitate globală a datelor. Apoi, pe baza acestui mic experiment, a tras mai multe concluzii și a făcut recomandări. Nimic din articol nu a fost dovedit, iar Parnas nu garantează că urmând recomandările toată lumea va obține același rezultat. Dar articolul contine sfat înțeleptși a influențat foarte mult popularitatea limbajelor de programare orientate pe obiecte.

    Un alt exemplu este buna treaba institut Inginerie software la Universitatea Carnegie Mellon, cunoscută sub numele de CMMI. CMMI a început ca un model de proces de dezvoltare software și acum a crescut pentru a include și alte tipuri de proiecte. CMMI are aproximativ 1.000 de pagini – fără exemple, interpretări și materiale de instruire – și reprezintă peste 1.000 de ani-persoană de muncă. Multe organizații mari l-au folosit și au făcut progrese semnificative în procesele și produsele lor de dezvoltare software. Dar nu există un singur rezultat ferm dovedit în CMMI. Este pur și simplu un set de sugestii (bine cercetate) despre cum să organizați un proiect software bazat pe metode care au funcționat pentru alte organizații în trecut. De fapt, Institutul de Inginerie Software afirmă că CMMI nu este nici măcar un proces, ci mai degrabă un meta-proces, ale cărui detalii sunt completate de fiecare organizație.

    Alte domenii de cercetare în același sens sunt modelele de design, stilurile arhitecturale, refactorizarea îndoielnică, dezvoltarea agilă și vizualizarea datelor. Aceste discipline pot conține rezultate parțial dovedite, dar în general sunt destinate sistemelor care conțin în mod inerent participarea umană. A fi clar: subiecte cheie Informatica (sub linia strălucitoare) sunt instrumente vitale pentru orice dezvoltator. Cunoașterea algoritmilor este importantă atunci când se proiectează aplicații de înaltă performanță. Teorie la coadă ajută la proiectarea nucleului sistem de operare. Metodologia camerei curate este, de asemenea, utilă în unele situații. Analiza statisticilor poate fi utilă atunci când planificați proiecte similare cu un grup similar de participanți. Dar formalismul este pur și simplu necesar, nu condiție suficientă pentru o bună dezvoltare. Să luăm ca exemplu construcția și arhitectura (adică case și clădiri).

    Imaginați-vă un inginer civil strălucit, cel mai bun expert din lume în materiale de construcție, relații stres-deformare, distribuție a sarcinii, protecție împotriva forfecării vântului și cutremurelor etc. Acest tip este listat în caiete arhitecți din toate țările să-l cheme pentru consultații cu privire la fiecare proiect de construcție. Va fi acest mitic inginer civil la fel de bun la proiectarea clădirilor pe care le analizează? Deloc. Se poate pierde în conversațiile cu clienții, este incapabil să proiecteze locuri plăcute pentru a trăi, îi lipsește imaginația pentru a găsi soluții la probleme noi și este plictisitor ca naiba. Tehnicile de construcție sunt utile pentru arhitecții adevărați, dar nu sunt suficiente pentru un design bun. Arhitectura de succes necesită creativitate, concept, gândire interdisciplinară și umanism.

    În același mod, informatica clasică este utilă în dezvoltarea de software, dar nu va fi niciodată suficientă. Proiectarea unui software bun necesită, de asemenea, creativitate, concept, gândire interdisciplinară și umanism. Această observație îi eliberează pe cercetătorii de procese software. Ei pot petrece timp învățând tehnici de succes - construind un corp de cunoștințe colective pentru viitorii practicieni. Nu ar trebui să stoarcem dezvoltarea de software în extinderea informaticii la baza matematica. Acest lucru nu va funcționa și ne poate distrage atenția de la descoperirile utile care încă așteaptă să fie descoperite.

    Mulțumiri
    Mulțumesc lui Steve Homer pentru discuția care mi-a stârnit interesul pentru această problemă.

    Manualul conține o prezentare a conceptelor de bază din domeniul informaticii și a bazelor programării, precum și exemple practice.
    Manualul este destinat studenților de la următoarele specialități: - „Management”, „Managementul organizațiilor”, „Managementul resurselor umane”, „Comerț”, „Marketing”, „Economie mondială”, „Managementul crizelor”, „Contabilitate, Analiză și Audit”, „Finanțe și credit”, „Lingvistică”, „Impozite și fiscalitate”, „Psihologie”.

    Sub informatică în sens larg este înțeles ca un ansamblu de diferite ramuri ale științei, tehnologiei și producției legate de prelucrarea informațiilor. ÎN în sens restrâns Informatica poate fi reprezentata ca un set de urmatoarele parti interconectate:
    1) mijloace tehnice (hardware);
    2) software;
    3) instrumente algoritmice (brainware).
    Este caracteristic faptul că informatica, atât în ​​sens larg, cât și în sens restrâns, poate fi privită din diferite poziții:
    - ca ramură a economiei naţionale;
    - ca știință fundamentală;
    - ca disciplină aplicată.
    Termenul „informație” provine de la cuvânt latin„Informatio”, care înseamnă clarificare, conștientizare, prezentare. Informatica considera informatia ca informatie interconectata conceptual, date, concepte care ne schimba ideile despre un fenomen sau obiect din lumea inconjuratoare. Alături de informație, conceptul de date este adesea folosit în informatică. Datele pot fi considerate semne sau observații înregistrate care acest moment nu este folosit, dar depozitat. Când datele sunt utilizate, acestea se transformă în informații.

    Cuprins
    Informații despre autori 5
    1. Informatica 7
    1.1. Informarea și informatizarea societății 8
    1.2. Măsurarea și prezentarea informațiilor 9
    1.3. Mijloace tehnice implementare procesele informaţionale 10
    1.4. Instrumente software pentru implementarea proceselor informaționale 14
    1.5. Tehnologii de programare 15
    2. Algoritmizarea proceselor de prelucrare a datelor 21
    2.1. Concepte de bază și definiții 22
    2.2. Instrumente pentru reprezentarea algoritmilor 23
    2.3. Caracteristicile și clasificarea datelor 24
    3. Structuri de bază ale limbajului Programare Pascal 29
    3.1. Elementele principale ale programului pe limbajul Pascal 30
    3.2. Operatori lingvistici 32
    3.3. Operator condiționatși utilizarea sa pentru organizarea ramificării 34
    3.4. Gestionarea filialelor folosind declarația Case 35
    3.5. Organizarea proceselor ciclice 37
    3.6. Prelucrarea informațiilor simbolice 41
    3.7. Organizarea executiei programului in Mediul DELPHI 43
    4. Prelucrare software tipuri structurale 49
    4.1. Organizarea informațiilor sub formă de matrice 50
    4.2. Organizarea informațiilor sub formă de înregistrări 52
    4.3. Organizarea informațiilor ca un set 55
    4.4. Caracteristici de procesare informatii economice, organizat ca o serie de înregistrări 58
    5. Programare modulară 65
    5.1 Organizarea structurii modulare a programului 66
    5.2. Utilizarea procedurilor 68
    5.3. Utilizarea funcțiilor 72
    5.4. Proceduri și funcții fără parametri 77
    5.5. Organizare module externe 80
    Teme munca de laborator 89
    Glosar 90
    Lista literaturii recomandate 94

    Descărcare gratuită e-carte V format convenabil, urmăriți și citiți:
    Descarcă cartea Informatică și programare, Komleva N.V., Smirnov A.A., Khripkov D.V., 2008 - fileskachat.com, descărcare rapidă și gratuită.

    Descărcați pdf
    Puteți cumpăra această carte mai jos cel mai bun preț la reducere cu livrare în toată Rusia.

    Manualul dezvăluie conținutul metodelor de procesare a informațiilor bazate pe tehnologia informatică, ceea ce vă permite să vă faceți o idee despre componentele tehnologice și software ale informaticii. Cartea include sarcini practiceși exerciții de control, a căror finalizare vă va permite să vă familiarizați cu elementele de bază ale MS DOS și să obțineți abilități în utilizarea programului shell Comandantul Norton, precum și metode de lucru în grafic medii de operare Familia Windows, stăpânește tehnicile de programare și trece la autoinstruire programe. Pentru a face acest lucru, manualul studiază texte specifice ale structurilor programului și oferă sarcini pentru munca independentă.
    Pentru studenții universitari și de facultate care studiază în domeniul tehnologiilor informaționale de management, precum și pentru toți cei care doresc să stăpânească în mod independent elementele de bază ale programării.

    Informatica este un domeniu de cunostinte stiintifice si practice care iti permite sa gestionezi diverse obiecteși sisteme bazate pe prelucrarea informațiilor. În acest sens, îmbogățește cercetarea științifică și activitățile practice în diverse domeniile subiectului, începând de la gestionarea echipelor mici, extinzând totul forme cunoscute activitatea umană, având un impact semnificativ asupra implementării cu succes a proiectelor spațiale.
    Unul dintre domeniile importante ale informaticii este utilizarea noilor metode de prelucrare a informației și a tehnologiilor informatice în managementul sistemelor organizaționale și economice.
    Pregătirea specialiştilor pentru a gestiona structurile organizatorice presupune nu doar instruire utilizare activă tehnologia Informatiei(IT), dar și studiul metodelor și metodelor de aplicare a acestora pentru optimizarea și dezvoltarea sistemului de management al organizației.

    Cuprins
    Introducere
    Prefaţă
    Capitolul 1. Componentele de bază ale tehnologiei informatice
    1.1. Tehnologii computerizateȘi spațiu informațional 17
    1.2. Calculator: structură și parametri 18
    1.2.1. Schema structurala computer 19
    1.2.2. Dispozitive suplimentare informații de intrare/ieșire 22
    1.2.3. Clasificarea calculatoarelor 24
    1.2.4. Rețele de date 26
    1.3. Software de calculator 27
    1.3.1. Clasificarea software-ului 27
    1.3.2. Sistemul de fișiere stocarea informațiilor 29
    1 4 Sistem de operare disc MS DOS .31
    1.4.1. Compoziția și scopul MS DOS .31
    1.4.2. Alocarea memoriei în MS DOS 32
    1 4.3. Structura fișierului discul 33
    1.4.4. Utilitare MS DOS 34
    1.4.5. Drivere de dispozitiv în MS DOS 39
    1.5. Executarea comenzilor MS DOS.40
    1.6. Programul shell Norton Commander, Workshop; lucrează în mediul MS DOS. 50
    Capitolul 2. Sistem grafic de operare sistem WINDOWS XP 51
    2.1 Desktop al sistemului de operare
    2.1.1. Elementele de bază ale desktopului 55
    2.1.2. Decorarea biroului 66
    2.1 3. Gestionarea obiectelor de pe desktop 70
    2.2. Panou de control 71
    2.3. Formatarea unui disc 76
    2.4. Personalizarea barei de activități 76
    2.5. Personalizarea meniului butonului Start 77
    2.6. Aplicația Explorer 80
    2.7. Coș de aplicații 84
    2.8. Portofoliul de aplicații 85
    2.9. Aplicația Notepad 87
    2.10. Aplicații Sarcini programate și data și ora 87
    2.11. Aplicarea vopselei 89
    2.11.1. Elemente esentiale editor grafic Vopsea 90
    2.11.2. meniul de sistem grafic Editor de vopsea 91
    2.11.3. Instrumentele editorului grafic Paint 95
    2 11.4. Inserarea elementelor grafice 99
    Workshop: lucru într-un sistem de operare grafic al familiei Windows 100
    Capitolul 3. Bazele programării în Turbo Pascal 7.0
    3.1. Procesul de programare 115
    3.2. Trusa de instrumente Turbo Pascal 118 integrată
    3.2.1. Opțiuni din meniul principal 118
    3.2.2. Scop tastele funcționale 125
    3.2.3. Editor de text 127
    3.2.4. Operațiuni 127
    3.3. Limbajul de programare Turbo Pascal 7.0 128
    3.3.1. Vocabularul limbii 128
    3.3.2. Gramatica limbajului 132
    3 4. Operatori 133
    3.4.1. Instrucțiuni de intrare și ieșire a datelor 134
    3.4.2. Simplu Treci la 136
    3.4.3. Declarații structurate 137
    3.5. Tipuri de date 145
    3.5.1 Tipuri simple datele 145
    3 5.2. Tipuri de date structurate 148
    3.6. Proceduri și funcții - 166
    3.7. Modul în Turbo Pascal 173
    3.7.1. Modul standard de bibliotecă SP 176
    3.7.2. Modul standard al bibliotecii Graph 184
    3.7.3. Sistemul de module standard de bibliotecă 211
    3.8. Dezvoltare sisteme de informare pentru practica de afaceri 215
    Workshop: programare în Turbo Pascal 226
    Capitolul 4. Misiuni pentru muncă independentă
    4.1. Lucrul cu Norton Commander 318
    4 2 Lucrul în mediul grafic Paint 320
    4.3. Comenzi de bază mediu integrat Turbo Pascal 320
    4.4. Interfața fereastră în programele utilizator 324
    4.5. Programe de structură liniară 324
    4.6. Programe cu structură ramificată 325
    4.7. Organizarea ciclurilor 326
    4.8. Tratament tablouri multidimensionale datele 326
    4.9. Procesarea datelor de caractere 327
    4.10. Procesarea șirului de date 327
    4.11. Prelucrarea datelor de tip Înregistrare” 328
    4.12. Dactilografiat și fișiere text 328
    4.13. Proceduri și funcții 329
    4.14. Prelucrarea seturilor de date 329
    4.15. Rânduri și înregistrări 330
    Capitolul 5. Serviciul de informare Internet 331
    5.1. Structura retea globala 331
    5.1.1. Servicii de informare rețele 331
    5.1.2 Protocoale de rețea 333
    5.2. Vizualizatori de documente retele de informatii 335
    5.2.1. Interfața ferestrei browser Netscape Communicator 336
    5.2.2. Interfața ferestrei MS Browser Internet Explorer 341
    5.3. E-mail 346
    5.3.1. Instalare cutie poștală 346
    5.3.2. Editarea unui fișier de setări 350
    5.3.3. Structura e-mail 350
    5.3.4. Tratament mesaje e-mail 356
    5 3.5. Lucreaza cu carte de adrese 359
    Atelier: tehnologie de aplicare E-mail 361
    5.4. Lucrul cu documente web 364
    5.4.1. Metode de accesare a documentelor web 364
    5.4.2. Configurarea unei pagini de căutare 372
    5 4 3. Copierea paginilor web 372
    5.b. Participarea la teleconferințe 374
    5.5.1. Structura serviciului 374
    5.5.2. Citirea știrilor 375
    5 5.3. Citirea articolelor grupurilor de știri 377
    5 5.4. Vizualizarea documentelor de teleconferință 379
    5 5.5. Trimiterea documentelor la o teleconferință 380
    5.6. Motoare de căutareși directoare de resurse 381
    5 6 1. Pagini galbene ale segmentului rusesc al internetului 382
    5 6.2. Știință și tehnologie 384
    5 6 3. Educație 385
    5 6.4. Magazin online 389
    5.6.5. Biblioteci virtuale 390
    5.7. Asociația de internet a rețelelor de informații din Rusia 392
    5.7.1. Furnizorii naționali de internet 393
    5.7.2. Resurse informaționale Internet 395
    Atelier: căutarea și prelucrarea informațiilor pe Internet 395
    Capitolul 6. HTML - Limbajul de marcare hipertext
    6.1. Structura limbajului HTML 401
    6.1.1. Notarea documentului HTML 403
    6.1.2. Titlul documentului 403
    6.1.3. Corpul documentului 404
    6.2. Scrierea textului documentului web 404
    6.2.1. Începutul paragrafului și sfârșitul rândului 405
    6.2.2. 405 Stiluri de titlu
    6 2.3. Stiluri fizice 406
    6.2.4. Stiluri booleene 407
    6.2.5. Text preformatat 407
    6.2.6. Listele 408
    6.2.7. Simboluri speciale 409
    6.3. Organizarea legăturilor hipertext 410
    6.3 1. generare de pointeri 411
    6 3 2. Crearea unui cuprins folosind nume de index 411
    6.3 3. Utilizarea hyperlinkurilor pentru a forma un cuprins al documentului web curent 412
    Workshop - formarea textului unui document web 412
    6.4. Culoarea textului și imagini de fundal 416
    6 5. Instalarea elementelor de masă 418
    6.5.1 Etichetele de bază ale tabelului 418
    6.5.2. Cazare tabele complexe 421
    6.5.3. Combinarea textului și a tabelului pe marginea documentului 423
    Workshop: liste și tabele pe domeniul paginilor web 425
    6.6. Amplasarea elementelor grafice 429
    6 6.1 Linii orizontale 429
    6 6.2. Imagini grafice 430
    6 6.3. Link pointers 433
    6 6.4. Elemente graficeîn marginile tabelelor 433
    6 7 Hărți imagine pe câmpul documentului web 436
    6.8 Organizarea paginilor web folosind cadre 439
    Atelier: folosirea graficelor și a cadrelor pentru organizarea documentelor web
    Glosar de termeni 445
    Literatura 458

    1. Algoritmul și proprietățile acestuia. Mijloace vizuale ale algoritmilor: verbal, formulă-verbal, diagramă bloc. Ajutoare vizuale ale algoritmilor: diagrame de structură, pseudocod, limbaje de programare 3

    2. Programare structurată. Principii de bază ale metodologiei structurale. Design de sus în jos și aplicarea acestuia. Programare modulară. Codificare structurală. Structuri canonice de bază utilizate în proiectarea algoritmilor pentru procese de calcul liniare, ramificate și ciclice 4

    3. Clasificarea limbajelor de programare. Caracteristicile generale ale limbajului Pascal. Structura unui program Pascal. Comentați scopul secțiunilor. Formatul și regulile de executare a operatorului de atribuire. Conceptul și aplicarea unui operator compus. 6

    4. Conceptul de procedură și funcție în Pascal. Scopul lor, aplicarea, opțiunile de plasare în program 9

    5. Reguli pentru construirea unei proceduri, plasarea ei într-un program, accesarea ei din programul apelant. Schimbul de informații între procedură și program de apelare: conceptul de parametru formal și real. Tehnologii de transmitere a parametrilor – prin referință și după valoare. Aplicarea acestor tehnologii 10

    6. Reguli pentru construirea unei funcții în Pascal, plasarea ei în program, accesarea ei din programul apelant. Schimbul de informații între o funcție și programul apelant: conceptul de parametri formali, descrierea acestora, caracteristici ale tehnologiei de returnare a unui rezultat. 12

    7. Analiza comparativa capabilități de procedură și funcție. Posibilitatea de a converti o procedură într-o funcție și invers. 13

    8. Conceptul de recursivitate. Proceduri recursiveși funcții, aplicarea acestora, avantaje și dezavantaje 13

    9. Sfera (vizibilitatea) numelor. Variabile globale și locale. Avantajele și dezavantajele utilizării variabilelor și parametrilor globali la schimbul de informații între programe. Recomandări de utilizare 14

    10. Înregistrați ca tip de date. Lucrul cu înregistrările: descrierea înregistrării, operatorul de anexare, înregistrarea cu variante. Utilizarea înregistrărilor. 15

    11. Fișiere în Pascal. Conceptul de fișier fizic și logic, relația dintre ele. Tipuri de fișiere și descrierile acestora, proceduri standardși funcții pentru lucrul cu fișiere. Caracteristici generale 16 metode de acces la fișiere

    12. Memoria statica si dinamica. Informații generale despre management memorie dinamică folosind proceduri și funcții standard (GetMem, FreeMem; New, Dispose). 19

    13. Structuri dinamice date. Matrice dinamice(unidimensionale și bidimensionale), lucrul cu ele 22

    14. Structuri dinamice de date. Liste. Principalele tipuri de liste. Acțiuni cu liste 24

    15. Liste unidirecționale (liniare). Descrierea, crearea, vizualizarea listelor, adăugarea și ștergerea elementelor 28



    16. Liste bidirecționale, simetrice. Descrierea, crearea, vizualizarea listelor, adăugarea și ștergerea elementelor 31

    17. Ring, liste ciclice. Descrierea, crearea, vizualizarea listelor, adăugarea și ștergerea elementelor 34

    18. Arbore binar. Definiții și concepte de bază. Căutare în arbore binar. Formarea unui arbore binar folosind această metodă 36

    19. Arbore binar. Operații de bază cu arbori binari. Metode de parcurgere a unui arbore binar. Opțiuni de căutare în arbore binar. 38

    20. Recursiune atunci când lucrați cu liste și arbori. Coadă, stivă, pachet ca forme de lucru cu o listă, acțiuni asupra lor 40

    21. Testare. Conceptul și scopul testării. Definirea corectă și incorectă a testării. Definiții de bază. Testarea cutiei negre. Testarea folosind " cutie alba» 42

    22. Depanare. Principii generale,metode de depanare. Relația dintre procesele de testare și depanare, utilizare mijloace automate depanare 44

    23. Principii de bază ale programării orientate pe obiecte: încapsulare, moștenire, polimorfism. Diferența dintre o abordare orientată pe obiect și o abordare modulară la dezvoltarea programelor 46

    24. Clase și obiecte: definiția lor, relația dintre ele. Rolul componentelor clasei - câmpuri, proprietăți, metode. Specificatoare de acces publicate, publice, private, protejate. Constructorii și distrugătorii, rolul lor. Evenimente și utilizarea lor în managementul programelor. 48

    25. Principalele diferențe dintre limbajul Object Pascal (Delphi) și Turbo Pascal. Matrice dinamice în Delphi: descriere, caracteristici, aplicație. 50

    26. Structura modulelor în Delphi. Interfață, piese executabile, piese de inițiere și finisare. Proceduri și funcții: caracteristici în Delphi 51

    27. Lucrul cu fișiere și foldere în Delphi: proceduri și funcții standard, caracteristici suplimentareÎn comparație cu Pascal, ferestre de dialog pentru lucrul cu fișiere. 53

    28. Definiția termenului „certificare”, tipuri de certificare. Sistemul de certificare organizațională 56

    29. Principalele funcții ale organismului de certificare. 57

    30. Temeiul legal pentru certificarea în Federația Rusă. Cerințe pentru laboratoarele de testare 58

    31. Înțelesul metrologiei software pentru a-și îmbunătăți calitatea și competitivitatea 60

    32. Calitatea software-ului și evaluarea acestuia. Indicatori de calitate a software-ului 61

    33. Fiabilitatea software-ului și evaluarea acestuia. Modele de fiabilitate. 63

    34. Probleme, scopuri și obiective de analiză tehnică și economică a dezvoltării software. Indicatori de analiză tehnică și economică. 65

    35. Evaluare eficiență economică instrumente software. 67

    36. Certificare, metrologie și progres științific și tehnologic. 68


    1. Algoritmul și proprietățile acestuia. Mijloace vizuale ale algoritmilor: verbal, formulă-verbal, diagramă bloc. Ajutoare vizuale ale algoritmilor: diagrame structurale, pseudocod, limbaje de programare

    Algoritmizare este procesul de construire a unui algoritm pentru rezolvarea unei probleme, al cărui rezultat este identificarea etapelor procesului de prelucrare a datelor, înregistrarea formală a conținutului acestor etape și determinarea ordinii de execuție a acestora.

    Algoritm- aceasta este o prescripție exactă care definește procesul de calcul care duce de la variația datelor inițiale la rezultatul dorit.

    Proprietățile algoritmului:

    1) determinism – acuratețea instrucțiunilor, excluzând interpretarea lor arbitrară;

    2) discretitate - posibilitatea de a împărți procesul de calcul în operații elementare separate, a căror posibilitate este fără îndoială;

    3) eficacitate - terminarea procesului după un anumit număr de pași cu ieșirea rezultatelor dorite sau mesaje despre imposibilitatea continuării procesului de calcul;

    4) caracter de masă - adecvarea algoritmului pentru rezolvarea tuturor problemelor unei clase date.

    Limbajul algoritmic– un set de simboluri și reguli pentru formarea și interpretarea structurilor din aceste simboluri pentru scrierea algoritmilor.

    Principalele mijloace vizuale ale algoritmilor sunt următoarele metode intrările lor:

    Verbal;

    Formula-verbal;

    Diagramă bloc;

    Pseudo cod;

    Diagrame de structură;

    Limbaje de programare.

    Verbal– conținutul etapelor de calcul este specificat în limbaj natural în liber de la cu detaliul cerut.

    Formula-verbal– instrucțiuni de setare folosind simboluri matematiceși expresii combinate cu explicații verbale.

    Diagramă bloc- Acest imagine grafică structura logica algoritm în care fiecare etapă a procesului de prelucrare a datelor este reprezentată sub formă forme geometrice(blocuri) având o anumită configurație în funcție de natura operațiunilor efectuate.

    Pseudo cod- vă permite să descrieți în mod oficial logica programului fără a vă face griji cu privire la caracteristicile sintactice limbaj specific programare. De obicei, un amestec de limbaj de programare și declarații în limbaj natural. Este un mijloc de reprezentare a logicii programului care poate fi folosit în locul unei diagrame bloc.

    Diagrame de structură- poate fi folosit ca diagrame bloc structurale, pentru a afișa conexiuni intermodulare, pentru a afișa structuri de date, programe și sisteme de prelucrare a datelor. Există diverse diagrame structurale: diagrame Nussi-Shneiderman, diagrame Warnier, diagrame Jackson, diagrame MESID etc.

    Limbaje de programare- mijloace vizuale pentru implementarea directă a programului pe calculator. Un program este un algoritm scris într-o formă care poate fi înțeleasă de un computer.

    • Traducere

    Dezvoltarea software pare să difere în mai rău de alte discipline informatice.

    Acum câțiva ani studiam algoritmii și complexitatea. Un domeniu încântător de curat, în care fiecare concept este clar definit, fiecare rezultat se bazează pe dovezile anterioare. Când cunoști un fapt în acest domeniu, te poți baza pe el, deoarece matematica însăși l-a dedus. Chiar și rezultatele imperfecte, cum ar fi algoritmii de aproximare și probabilistici, au o analiză riguroasă a imperfecțiunilor lor. Alte discipline de informatică, cum ar fi topologia rețelelor și criptografia, au un statut la fel de satisfăcător.

    Și acum lucrez în dezvoltarea de software, iar acesta este un subiect incredibil de alunecos. Niciun concept nu este definit cu precizie. Rezultatele sunt evaluate ca „de obicei” sau „în general”. Cercetarea de astăzi poate informa sau nu munca de mâine. Noile abordări răstoarnă adesea metodele anterioare, ard puternic pentru o perioadă scurtă de timp și apoi se demodează atunci când apar limitările lor. Am crezut în programarea structurată. Apoi au început să creadă în limbaje de generația a patra, apoi în metode orientate pe obiecte, apoi în programare extremă, iar acum, poate, în sursă deschisă.

    Dar programarea este exact acolo unde anvelopa intră în contact cu asfaltul. Puțină lume îi pasă dacă este într-adevăr egal, doar de dragul frumuseții întrebării. Domeniul computerelor se ocupă de calculatoare. Scrie programe pentru a rezolva probleme umane reale și rulează acele programe pe mașini reale. Conform tezei Church-Turing, tot hardware-ul computerului este în esență echivalent. Deci, în timp ce arhitectura computerelor este cool, adevărata limitare în informatică rămâne problema creării de software. Ne dorim programe care să poată fi puse împreună într-un timp rezonabil și la un cost rezonabil, care să funcționeze aproximativ așa cum au intenționat designerii și care rulează fără erori.

    Având în vedere acest scop, am fost întotdeauna îngrijorat de o întrebare (ca mulți alți cercetători): de ce nu pot programatorii să obțină rezultate mai riguroase ca în alte domenii ale informaticii? Cu alte cuvinte, „Cât de mult din arhitectura și designul software pot fi făcute formale și dovedibile?” Răspunsul la această întrebare este în Figura 1.


    Figura 1: Linie strălucitoare în informatică

    Subiectele de deasupra acestei linii aparțin dezvoltării software. Domeniile de studiu de sub această linie sunt subiectele de bază ale informaticii. Acestea din urmă au rezultate clare, formale. Pentru problemele deschise din acest domeniu, ne așteptăm ca noi rezultate să fie declarate oficial. Aceste subiecte se bazează unul pe celălalt: criptografia pe complexitate și compilatorii pe algoritmi, de exemplu. Mai mult, credem că rezultatele dovedite în aceste domenii vor rămâne așa în 100 de ani.

    Deci, ce este această linie strălucitoare și de ce nu există subiecte de programare sub ea? Linia este o calitate numită „implicare umană directă”. Dezvoltarea software are această calitate, dar informatica tradițională nu. Rezultatele de la disciplinele de sub linie pot fi folosite de oameni, dar aceste rezultate nu sunt direct afectate influență al oamenilor.

    Dezvoltarea software are o componentă umană inerentă. De exemplu, fiabilitatea operațională a software-ului este capacitatea unei persoane de a înțelege, găsi și corecta defectele unui sistem software. Fiabilitatea operațională poate fi influențată de unele concepte formale de informatică - poate complexitatea ciclomatică a graficului de control al software-ului. Dar fiabilitatea operațională depinde în mod critic de oameni și de capacitatea lor de a înțelege semnificația și intenția codului sursă. Întrebarea dacă un anumit sistem software are o fiabilitate operațională ridicată nu poate fi răspunsă doar prin studierea mecanică a software-ului.

    La fel este și cu securitatea. Cercetătorii au folosit câteva metode formale pentru a afla impactul unui sistem software asupra sănătății și proprietății oamenilor. Dar nicio discuție despre securitatea software-ului nu poate fi considerată completă fără a aborda componenta umană a sistemului studiat. La fel și pentru dezvoltarea cerințelor. Putem dezvolta orice tehnici de sondaj pentru a obține cerințe precise de la părțile interesate și putem crea diverse sisteme pentru a le înregistra. Dar nici o cantitate de cercetare în acest domeniu nu va schimba faptul că colectarea cerințelor implică adesea vorbirea sau observarea oamenilor. Uneori, acești oameni ne oferă informațiile corecte, iar uneori nu. Uneori oamenii mint, poate din motive întemeiate. Uneori, oamenii încearcă sincer să transmită informațiile corecte, dar nu reușesc să o facă.

    Această observație duce la teza lui Connell:

    Dezvoltarea software nu va fi niciodată o disciplină riguroasă cu rezultate dovedite, deoarece implică activitate umană.


    Aceasta este o afirmație extra-matematică despre limitele sistemelor formale. Nu am dovezi pro sau contra. Dar adevărul este că problemele umane rămân probleme centrale în dezvoltarea de software:
    • Ce ar trebui să facă acest program? (cerințe, utilizare, securitate)
    • Cum ar trebui să arate programul în interior, astfel încât să poată fi reparat și modificat cu ușurință? (arhitectură, design, scalabilitate, portabilitate, extensibilitate)
    • Cât timp va dura să-l scrii? (clasa)
    • Cum ar trebui să o dezvoltăm? (codificare, testare, măsurare, configurare)
    • Cum ar trebui să lucreze eficient o echipă? (management, proces, documentare)
    Toate aceste probleme gravitează în jurul oamenilor.

    Teza mea explică de ce dezvoltarea de software este atât de dificilă și atât de alunecoasă. Metodele dovedite ale unei echipe de programatori nu funcționează pentru alte echipe. O analiză exhaustivă a proiectelor trecute poate să nu fie utilă pentru o bună evaluare a următorului. Fiecare dintre instrumentele revoluționare de dezvoltare ajută puțin și apoi nu își îndeplinește marile promisiuni. Motivul este că oamenii sunt prea moale, dezamăgitori și imprevizibili.

    Înainte de a trece la implicațiile afirmației mele, să luăm în considerare trei obiecții plauzibile:

    Teza se realizează de la sine. Dacă o anumită zonă a dezvoltării software-ului are dintr-o dată o definiție strictă, atunci puteți schimba pur și simplu definiția dezvoltare de software pentru a elimina această problemă din ea.


    În anumite privințe, această obiecție este corectă, dar nu în toate. Susțin că setul de discipline denumit în mod obișnuit inginerie software va continua să provoace în mod inerent soluția riguroasă. Aspectele restrânse ale unor probleme se pot preta unei abordări formale, dar succesul lor va fi doar la periferia problemelor de dezvoltare de bază.

    Rezultatele statistice în programare infirmă deja această teză.


    Aceste metode abordează în general problema de estimare și includ Function Point Counting, COCOMO II, PROBE și altele. În ciuda aspectului lor matematic, aceste metode nu sunt dovezi sau rezultate formale. Astfel de statistici sunt pur și simplu o încercare de a cuantifica experiența umană subiectivă a proiectelor software trecute și de a o extrapola la proiectele viitoare. Uneori funcționează. Dar formulele aparent stricte din aceste scheme sunt un porc cu ruj, ca să folosim o expresie modernă. De exemplu, una dintre formulele din COCOMO II arată astfel: , unde , a este un set de cinci factori de scalare, cum ar fi „flexibilitatea dezvoltării” și „coeziunea echipei”. Formula în sine pare strictă, dar este dominată de un indicator format din factori umani.

    Procesele formale de dezvoltare, cum ar fi metoda camerei curate, găsesc treptat metode riguroase, demonstrabile. Ele ridică o linie strălucitoare pentru a aduce teme anterior neclare dedesubt.


    Într-adevăr, cercetătorii proceselor formale demonstrează progrese în rezolvarea diferitelor probleme. Dar ei pot fi prinși încălcând prima obiecție de pe această listă: definesc dezvoltarea de software prea îngust pentru ca aceasta să se preteze la o soluție riguroasă. Metodele formale oferă pur și simplu o interpretare convenabilă a oricărei probleme care se bazează pe participarea și interpretarea umană. De exemplu, un element cheie al metodelor formale de dezvoltare este crearea de specificații stricte, fără ambiguitate. Aceste specificații sunt apoi folosite pentru a ghida (și dovedi) etapele de dezvoltare ulterioare. Desigur, o metodă formală poate conține o schemă de notație semantică neambiguă. Dar nicio metodă formală nu conține o rețetă exactă despre cum să traducă în gândurile vagi ale oamenilor fără ambiguitate despre ceea ce ar trebui să facă un program.

    Împotriva acestor obiecții, susțin că ingineria software este fundamental diferită de informatica tradițională, formală. Prima depinde de oameni, dar a doua nu. Acest lucru ne duce la concluzia lui Connell:

    Ar trebui să încetăm să încercăm să dovedim rezultate fundamentale în dezvoltarea de software și să recunoaștem că progresele semnificative în acest domeniu vor fi doar recomandări generale.


    De exemplu, David Parnas în 1972 a scris un articol științific minunat „Despre criteriile pentru descompunerea unui sistem în module”. Descrie un experiment simplu pe care Parnas l-a efectuat cu strategii alternative de proiectare a software-ului, una cu ascunderea informațiilor și alta cu vizibilitate globală a datelor. Apoi, pe baza acestui mic experiment, a tras mai multe concluzii și a făcut recomandări. Nimic din articol nu a fost dovedit, iar Parnas nu garantează că urmând recomandările toată lumea va obține același rezultat. Dar articolul conține sfaturi înțelepte și a influențat foarte mult popularitatea limbajelor de programare orientate pe obiecte.

    Un alt exemplu este un efort uriaș al Institutului de Inginerie Software de la Universitatea Carnegie Mellon, cunoscut sub numele de CMMI. CMMI a început ca un model de proces de dezvoltare software și acum a crescut pentru a include și alte tipuri de proiecte. CMMI are aproximativ 1.000 de pagini – fără exemple, interpretări și materiale de instruire – și reprezintă peste 1.000 de ani-persoană de muncă. Multe organizații mari l-au folosit și au făcut progrese semnificative în procesele și produsele lor de dezvoltare software. Dar nu există un singur rezultat ferm dovedit în CMMI. Este pur și simplu un set de sugestii (bine cercetate) despre cum să organizați un proiect software bazat pe metode care au funcționat pentru alte organizații în trecut. De fapt, Institutul de Inginerie Software afirmă că CMMI nu este nici măcar un proces, ci mai degrabă un meta-proces, ale cărui detalii sunt completate de fiecare organizație.

    Alte domenii de cercetare în același sens sunt modelele de design, stilurile arhitecturale, refactorizarea îndoielnică, dezvoltarea agilă și vizualizarea datelor. Aceste discipline pot conține rezultate parțial dovedite, dar în general sunt destinate sistemelor care conțin în mod inerent participarea umană. Pentru a fi clar: subiectele de bază ale informaticii (sub linia strălucitoare) sunt instrumente vitale pentru orice dezvoltator. Cunoașterea algoritmilor este importantă atunci când se proiectează aplicații de înaltă performanță. Teoria punerii la coadă ajută la proiectarea nucleului sistemului de operare. Metodologia camerei curate este, de asemenea, utilă în unele situații. Analiza statisticilor poate fi utilă atunci când planificați proiecte similare cu un grup similar de participanți. Dar formalismul este pur și simplu o condiție necesară, nu suficientă pentru o bună dezvoltare. Să luăm ca exemplu construcția și arhitectura (adică case și clădiri).

    Imaginați-vă un inginer civil genial, cel mai bun expert din lume în materiale de construcție, relații stres-deformare, distribuție a sarcinii, protecție împotriva forfecării vântului și cutremurelor etc. Tipul ăsta este pe caietele arhitecților de pretutindeni pentru a-l suna pentru consultații pentru fiecare proiect de construcție. Va fi acest mitic inginer civil la fel de bun la proiectarea clădirilor pe care le analizează? Deloc. Se poate pierde în conversațiile cu clienții, este incapabil să proiecteze locuri plăcute pentru a trăi, îi lipsește imaginația pentru a găsi soluții la probleme noi și este plictisitor ca naiba. Tehnicile de construcție sunt utile pentru arhitecții adevărați, dar nu sunt suficiente pentru un design bun. Arhitectura de succes necesită creativitate, concept, gândire interdisciplinară și umanism.

    În același mod, informatica clasică este utilă în dezvoltarea de software, dar nu va fi niciodată suficientă. Proiectarea unui software bun necesită, de asemenea, creativitate, concept, gândire interdisciplinară și umanism. Această observație îi eliberează pe cercetătorii de procese software. Ei pot petrece timp învățând tehnici de succes - construind un corp de cunoștințe colective pentru viitorii practicieni. Nu ar trebui să stoarcem dezvoltarea de software în extensia matematică a informaticii. Acest lucru nu va funcționa și ne poate distrage atenția de la descoperirile utile care încă așteaptă să fie descoperite.

    Mulțumiri
    Mulțumesc lui Steve Homer pentru discuția care mi-a stârnit interesul pentru această problemă.