PROFESSIONELL MODUL
"Utveckling av mjukvara
mjukvarumoduler
programvara för dator
system"

MDK

Systemprogrammering
Applikationsprogrammering

Mål och mål för modulen

känna till:
huvudstadier av mjukvaruutveckling
säkerhet;
grundläggande principer för konstruktionsteknik
och objektorienterad
programmering;
grundläggande principer för felsökning och testning
mjukvaruprodukter;
metoder och medel för att utveckla tekniska
dokumentation.

Mål och mål för modulen

kunna:
utveckla mjukvarukod
moduler i moderna programmeringsspråk;
skapa ett program enligt den utvecklade algoritmen
som en separat modul;
felsöka och testa programmet
modulnivå;
förbereda mjukvarudokumentation
anläggningar;
använda verktyg för
automatisering av pappersarbete;

Mål och mål för modulen

har praktisk erfarenhet:
utveckling av en algoritm för uppgiften och
genomförande med hjälp av medel
automatiserad design;
utveckling av programvarukod
utifrån den färdiga specifikationen på nivån
modul;
användning av verktyg på
felsökningsstadiet för mjukvaruprodukten;
mjukvarutestning
modul enligt ett specifikt scenario;

Professionella kompetenser

PC 1.1. Genomför utveckling av specifikationer för individ
komponent.
PC 1.2. Genomför utveckling av programvarukod
utifrån färdiga specifikationer på modulnivå.
PC 1.3. Utför felsökning av programmoduler med
med hjälp av specialiserad programvara.
PC 1.4. Utför testning av mjukvarumoduler.
PC 1.5. För att optimera modulens programkod.
PC 1.6. Utveckla design och tekniska komponenter
dokumentation med grafiska språk
specifikationer.

Tvärvetenskapliga kopplingar

Informatik och IKT;
Informationsteknologi;
Arkitektur datorsystem;
Grunderna i programmering;
OS.

Studiestadier

Auditiva lektioner
Praktiska lektioner
Självständigt arbete
kursprojekt
Pedagogisk praktik
Praktik
Kvalificerande prov (försvar
portfölj)

Applikationsprogrammering

Avsnitt 1. Grundläggande principer för applikationsutveckling

Ämne 1.1. Grundläggande koncept
applikationsprogrammering

Frågor

Klassificering programvara
Programvarans livscykel
Programutvecklingsstadier
Programdokumentation

Vad är programmering?

Programmering – i vid bemärkelse
representerar alla tekniska
operationer som krävs för att skapa
program, inklusive kravanalys och
alla stadier av utveckling och implementering. I
snäv mening är kodning och
programtestning inom
något specifikt projekt.

Vad är mjukvara?

Programvara (mjukvara) (mjukvara)
- allmän term för
"immateriell" (i motsats till fysisk)
komponenter i ett datorsystem.
I de flesta fall hänvisar det till
program körs
datorsystem till
betona deras skillnad från hårdvara
medel för samma system.

Vilka klasser av programvara
Du vet?

system: operativsystem; förare
anordningar; olika verktyg;
för utvecklare: programmeringsmiljöer;
översättare och tolkar; CASE-verktyg;
programbibliotek;
för slutanvändare: text
processorer; kalkylblad; grafisk
redaktörer; lösare av matematiska problem;
utbildnings- och kontrollsystem;
datorspel; applikationsprogram.

Vad är en tillämpad
program?

applikationsprogram (applikation
program) - vilket program som helst,
att bidra till uppgiften,
tilldelas datorn inom detta
organisation och ger ett direkt bidrag till
genomförandet av denna uppgift.

Vad kan kallas ett mjukvarusystem?

Mjukvarusystemet representerar
är en uppsättning lösningar till uppsättningen
annorlunda men släkt
uppgifter (OS, DBMS).
Mer högspecialiserad
program kallas inte system
(textredigerare, kompilator, etc.)

Programvarans livscykel (programvarans livscykel) hela existensperioden
mjukvarusystem,
med början från utvecklingen av initialen
konceptet med detta system och avsluta det
åldrande

PROGRAMVARANS LIVSCYKEL

STEDER FÖR ATT SKAPA PROGRAM

Systemanalys.
En analys av kraven för
mjukvarusystem baserat på
primärstudie av alla informationsflöden
under traditionellt arbete och utförs
i följande ordning:
a) förtydligande av typerna och ordningen för allt arbete;
b) definition av mål som bör vara
uppnås genom det utvecklade programmet;
c) identifiering av analoger som säkerställer uppnåendet
liknande mål, deras fördelar och nackdelar.

STEDER FÖR ATT SKAPA PROGRAM

Extern specifikation
Består av att definiera externa specifikationer, d.v.s.
beskrivningar av in- och utdatainformation,
former för deras presentation och sätt att behandla information.
Implementerat i följande ordning:
a) fastställa en uppgift för utvecklingen av ett nytt program;
b) bedömning av de uppnådda målen för de utvecklade
mjukvaruprodukt.
Vidare kan steg 1-2 upprepas vid behov tills
uppnå ett tillfredsställande utseende av programmet
system med en beskrivning av de funktioner det utför och några
klarhet i genomförandet av dess funktion.

STEDER FÖR ATT SKAPA PROGRAM

Programdesign
En uppsättning arbeten utförs för att bilda en beskrivning av programmet.
De initiala uppgifterna för denna fas är de angivna kraven
i specifikationen som utvecklades i föregående steg. accepterad
beslut om hur kraven ska uppfyllas
specifikationer. Denna fas av programutveckling är uppdelad i två steg:
a) arkitektonisk utformning. Det är en utveckling
programbeskrivningar i allmän syn. Denna beskrivning innehåller
information om möjliga alternativ för strukturell konstruktion
mjukvaruprodukt (antingen i form av flera program eller i form av
flera delar av ett program), samt om huvuddelen
algoritmer och datastrukturer. Resultaten av detta arbete är
den slutliga versionen av mjukvarusystemarkitekturen,
krav på strukturen hos enskilda programvarukomponenter och
organisation av filer för utbyte av data mellan program;
b) fungerande design. I detta skede, den arkitektoniska beskrivningen
programmet är detaljerat till en nivå som gör
möjligt arbete med dess implementering (kodning och montering). För
Detta görs genom att sammanställa och kontrollera specifikationerna för modulerna,
sammanställa beskrivningar av modulernas logik, sammanställa finalen
genomförandeplan för programmet.

STEDER FÖR ATT SKAPA PROGRAM

Kodning och testning
Implementerat för enskilda moduler och
samling av färdiga moduler upp till
ta emot det färdiga programmet.
Omfattande testning
Utveckling av operativa
dokumentation
Acceptans och andra typer
tester

STEDER FÖR ATT SKAPA PROGRAM

Programkorrigering
Baserat på resultat
tidigare tester.
Leverans till kund
Slutleverans pågår
mjukvaruprodukt till kunden.
Replikering

STEDER FÖR ATT SKAPA PROGRAM

Programstöd
Inkluderar alla tekniska operationer som krävs
att använda detta program i arbetet
läge. Programmet håller på att modifieras
göra korrigeringar i arbetsdokumentationen,
programförbättring osv.
På grund av den breda skalan av sådana
driftstödet är iterativt
process som det är önskvärt att genomföra
lika mycket efter som innan mjukvarusläpp
produkter för allmänt bruk.

Frågor

1. Grundläggande begrepp för programmering.
Programvaruklasser.
2. Programvarans livscykel
säkerställa
3. Stadier för att skapa program

PROGRAMDOKUMENTATION

Varje designstadium
kulminerar i utformningen
relevanta dokument, alltså
ett viktigt designelement
mjukvaruapplikationer är
utarbetande av mjukvarudokumentation.

PROGRAMDOKUMENTATION

Programspecifikation (program
specifikation) - en exakt beskrivning av det
resultat som ska uppnås
använder programmet. Denna beskrivning
måste ange exakt vad
göra ett program utan att ange hur det är
borde göra det.

PROGRAMDOKUMENTATION

För program som avslutar sitt arbete med något resultat, vanligtvis sammanställda
I/O-specifikationer som beskriver
önskad mappning av ingångsuppsättningen
kvantiteter till en uppsättning utgående kvantiteter.
För cykliska program (där nr
ange slutpunkten), utveckla
specifikationer där fokus ligger
fokuserar på individuella funktioner,
genomförs av programmet under cyklisk
operationer.

PROGRAMDOKUMENTATION

Den primära specifikationen beskriver:
objekt som är involverade i uppgiften (vad programmet gör
och vad gör personen som arbetar med detta program);
processer och aktiviteter (projektprocedurer och aktiviteter
människa, algoritmer för att lösa problem i en maskin,
ordning av informationsbehandling, storleken på operativa
minne som krävs för att programmet ska fungera);
in- och utdata samt deras organisation
(till exempel ett dialogskript med skärmformulär,
organisation av filer som anger längden på postfält och
maximal mängd information i filer);
instruktioner för hur du använder det framtida programmet.

PROGRAMDOKUMENTATION

Skilj mellan extern programvara
dokumentation som överensstämmer med
kund och mellanliggande
intern projektdokumentation.
När du kompilerar ett program
dokumentation utvecklas först
externa specifikationer och sedan -
inre.

PROGRAMDOKUMENTATION

Externa specifikationer inkluderar
in- och utdataspecifikationer
data, deras organisation, reaktioner på
undantag, definition,
vad gör en person (med vilka algoritmer
det fungerar och var det får information ifrån), och
den maskinen.

PROGRAMDOKUMENTATION

Interna specifikationer inkluderar
beskrivning av interna programdata
(variabler, särskilt strukturerade) och
beskrivningar av algoritmerna för hela programmet och dess
delar.
Interna specifikationer ges i enhet
med en beskrivning av mjukvaruarkitekturen
komplex och inre struktur
bygga separat programvara
komponent.

Läxa

Gör en lista över typer av dokument för
säkerställa mjukvarans livscykel.

inkluderingsprincipen, som föreskriver det
krav på tillkomst, drift och utveckling
Programvara bestäms från sidan av mer komplexa,
systemet som inkluderar det;
principen om systemisk enhet, som är
att i alla skeden av skapande, drift och
mjukvaruutveckling, kommer dess integritet att säkerställas
kopplingar mellan delsystem och
funktion av kontrolldelsystemet;
utvecklingsprincip, som tillhandahåller programvara
möjlighet att expandera och förbättra
komponenter och kopplingar mellan dem;

SYSTEMVÄNDA PRINCIPER FÖR ATT SKAPA PROGRAM

principen om komplexitet
är att programvaran ger
anslutning av informationsbehandling
enskilda element och för hela volymen
uppgifter i allmänhet i alla stadier av behandlingen;
principen om informationsenhet, det vill säga
i alla delsystem, stödmedel och
programvarukomponenter använder vanliga
termer, symboler, konventioner och
presentationsmetoder;

SYSTEMVÄNDA PRINCIPER FÖR ATT SKAPA PROGRAM

Principen för kompatibilitet är det
språk, symboler, koder och mjukvaruverktyg
bestämmelse avtalad, tillhandahålla
allas gemensamma funktion
delsystem och hålla en öppen struktur
system som helhet;
principen om invarians definierar
invarians av mjukvaruundersystem och komponenter
informationen som behandlas, det vill säga de är universella eller typiska.

Programmeringsteknik är
beprövade strategier för att skapa
program som presenteras i form av metoder
med informationsmedel, beskrivningar
designprocedurer och designoperationer.
Det finns en strukturell teknik
programmering, teknik
designa program med rationell
datastruktur, objektorienterad programmeringsteknik,
visuell programmeringsteknik.

TEKNOLOGIER OCH PROGRAMMERINGSPARADIGM

Programmeringsparadigm (begrepp,
trossystem) är olika
metoder för att skriva program.
Det finns fyra huvudparadigm
som beskriver det mesta av dagens
programmeringsmetoder: imperativ,
applikativ, regelbaserad
och objektorienterad.

TEKNOLOGIER OCH PROGRAMMERINGSPARADIGM

imperativt paradigm
Denna modell följer av funktionerna i hårdvaran
en vanlig dator som kör instruktioner
(kommandon) sekventiellt.
Den huvudsakliga typen av abstraktion som används i detta
paradigm, är algoritmer. Baserat på det utvecklat
många operatörsinriktade språk
programmering.
Ett program på ett sådant språk består av sekvensen
operatörer, vars utförande medför
ändra värdet i en eller flera minnesceller. I
I allmänhet är syntaxen för ett sådant språk:
Operator_1:
Operator_2:
...

TEKNOLOGIER OCH PROGRAMMERINGSPARADIGM

Applikativt paradigm
Detta paradigm bygger på övervägandet
funktionen som programmet utför.
Frågan är: vilken funktion behövs
gäller maskinens initiala tillstånd (av
att välja en initial uppsättning variabler och
kombinera dem på ett visst sätt).
få önskat resultat?
Språk som betonar denna syn på
beräkningar kallas applikativa, eller
funktionell. Syntaxen för ett språk som
regeln ser ut så här:
Funktion_n (... funktion_2 (funktion_1 (data))...)

TEKNOLOGIER OCH PROGRAMMERINGSPARADIGM

Regelbaserat paradigm
Språk baserade på denna paradigmkontroll
förekomsten av det nödvändiga tillåtande villkoret, och i fallet med dess
detektioner utför lämplig åtgärd.
Att köra ett program på ett liknande språk är som
genomförande av ett program skrivet på ett imperativt språk.
Uttalandet utförs dock inte i den ordning de är
som de definieras i programmet. Ordning för avrättning
definiera tillåtande villkor. Syntaxen för sådana språk
som följer:
tillåtande villkor_1 -> åtgärd_1 tillåtande
condition_2 -> action__2
tillåter condition_n -> action _n
Ibland skrivs regler som "om handling
tillåtande villkor" när åtgärden ska utföras
skrivet till vänster.

TEKNOLOGIER OCH PROGRAMMERINGSPARADIGM

Objektorienterat paradigm
Denna modell bygger komplexa dataobjekt.
För operationer på dem, vissa
begränsad uppsättning metoder. Skapad
objekt kan ärva egenskaper av enklare
föremål.
På grund av denna förmåga har objektorienterade program en hög
programmens effektivitet
skriven på imperativa språk. Möjlighet
utveckling av olika klasser som använder
begränsad uppsättning dataobjekt,
ger flexibilitet och tillförlitlighet, vilket
kännetecknande för ett applicerande språk.

Broadcast (sammanställning)
Det är en metod för att översätta program skrivna i
språk på hög nivå, till motsvarande
maskinspråksprogram som används
dator.
Efter det byggde tolken in
mikroprocessorhårdvara,
utför direkt den översatta till
maskinkodsprogram. Fördelen med detta
metod - mycket snabb programexekvering
efter att översättningsprocessen har slutförts.

SÄNDNING OCH TOLKNING AV PROGRAM

En översättare är en språkprocessor som
accepterar program på någon källa
språk som input och som output
producerar motsvarande i sin funktionalitet
program, men redan på ett annat, sk
objektspråk (som också kan vara
godtycklig nivå).
En assembler är en översättare vars källa
språket är en symbolisk representation
maskinkod (assembler) och objektspråk
är ett slags maskinspråk
vilken riktig dator som helst.

SÄNDNING OCH TOLKNING AV PROGRAM

En kompilator är en översättare för vilken källan
är ett högnivåspråk och dess objektspråk
nära maskinspråket för en riktig dator. Detta
antingen assemblerspråk eller någon variant
maskinspråk.
Länkaren (länkaren) är en översättare,
vars källspråk består av program i
maskinspråk i flyttbar form och tabeller
data som anger vid vilka punkter
flyttbar kod måste ändras,
att bli körbar. Objektspråket består av
redo att utföra maskininstruktioner. uppgift
linker är att skapa en enda körbar fil
program som använder överenskommet
adresser enligt tabellen.

SÄNDNING OCH TOLKNING AV PROGRAM

Förprocessorn (makroprocessorn) är
översättare vars källspråk
är en utökad form av
språk på hög nivå (som Java eller
C++), och objektspråket - standarden
version av detta språk. objektprogram,
skapad av förprocessorn, redo för
översättning och utförande av det vanliga
processorer av den ursprungliga standarden
språk

SÄNDNING OCH TOLKNING AV PROGRAM

Tolkning (mjukvarusimulering)
Detta är metoden när du använder programmet
(tolk) avrättad på
hårdvara dator, skapad
maskinspråk virtuell dator
hög nivå. Tolken avkodar och
exekverar varje sats i programmet
språk på hög nivå i respektive
sekvenser och producera utdata
resulterande data definierade av detta
program.

SÄNDNING OCH TOLKNING AV PROGRAM

Blandade implementeringssystem
Först översätts programmet från originalet
formar till en form som är mer bekväm att utföra.
Detta görs vanligtvis genom att skapa flera
oberoende delar av programmet, kallad
moduler.
Under lastningsfasen kombineras dessa oberoende delar
med en uppsättning runtime-program,
implementera mjukvaru-simulerad
(tolkade) operationer. Det leder till
skapa en körbar form av ett program, uttalanden
som avkodas och exekveras med hjälp av deras
tolkning.

MILJÖER OCH IMPLEMENTERINGAR AV PROGRAMMERINGSSPRÅK

Programmeringsmiljön är en uppsättning
verktyg som används i utvecklingen
programvara.
Denna uppsättning består vanligtvis av en fil
system, textredigerare, editor
länkar och kompilator. Dessutom har han
kan omfatta ett stort antal
instrumentala komplex med
enhetligt användargränssnitt

Träning

Lista och beskriv de olika
programmeringsmiljöer.

Proceduren för att utveckla en mjukvarumodul.

• 1. studie och verifiering av modulspecifikationen, val av programmeringsspråk; (det vill säga utvecklaren, som studerar specifikationen, tar reda på om det är tydligt för honom eller inte, om det beskriver modulen tillräckligt; sedan väljer han det programmeringsspråk som modulen ska skrivas på, även om programmeringsspråket kan vara samma för hela PS)
• 2. val av algoritm och datastruktur (här visar det sig om några algoritmer är kända för att lösa problemet och i så fall använda det)
• 3. modulprogrammering (skriva programkod)
• 4. polera texten i modulen (redigera befintliga kommentarer, lägga till ytterligare kommentarer för att säkerställa önskad kvalitet)
• 5. kontrollera modulen (modulens logik kontrolleras, dess arbete är felsökt)

Följande metoder för programmodulstyrning tillämpas:

• - statisk kontroll av modultexten (texten läses från början till slut för att hitta fel i modulen. Vanligtvis är, förutom modulutvecklaren, en eller till och med flera programmerare inblandade för en sådan kontroll. Det rekommenderas att fel som upptäcks under en sådan kontroll korrigeras inte omedelbart, utan efter att modultexten är klar)
• - Spårning från ände till ände (manuell rullning av exekveringen av modulen (operatör för operatör i den sekvens som följer av modulens logik) på en viss uppsättning tester)
• 6. sammanställning av modulen.

Strukturell programmering.

Den mest populära programmeringstekniken idag är strukturerad top-down programmering.

Strukturell programmering är processen att bryta ner en algoritm steg för steg i mindre och mindre delar för att erhålla element för vilka specifika recept lätt kan skrivas ut.

Två principer för strukturerad programmering:

• 1. Sekventiella detaljer "från topp till botten"
• 2. begränsad basuppsättning av strukturer för att konstruera algoritmer av någon grad av komplexitet

Strukturerade programmeringskrav:

• 1. Programmet bör utformas i små steg, så den komplexa uppgiften är uppdelad i ganska enkla, lättuppfattade delar.
• 2. Programlogik bör baseras på ett minsta antal tillräckligt grundläggande kontrollstrukturer (linjära, förgrenade och cykliska strukturer)

De viktigaste egenskaperna och fördelarna med strukturerad programmering:

• 1. Minska programmens komplexitet
• 2. Möjligheten att visa att programmen är korrekta i olika skeden av att lösa problemet
• 3. synlighet av program
• 4. enkel modifiering (ändring) av program.

Moderna programmeringsverktyg ska ge maximalt skydd mot möjliga utvecklarfel.

Här kan vi dra en analogi med utvecklingen av metoder för att köra fordon. Till en början säkrades säkerheten genom utvecklingen av trafikregler. Sedan fanns ett system med vägmarkeringar och reglering av korsningar. Och slutligen började trafikplatser byggas, som i princip förhindrar korsningen av trafikflöden för bilar och fotgängare. Men de medel som används bör bestämmas av typen av problemet som löses: för en landsväg är det tillräckligt att följa en enkel regel - "titta under dina fötter och runt."

Grundidén med strukturerad programmering: programmet bör vara en uppsättning block, kombinerade i en hierarkisk trädstruktur, som var och en har en ingång och en utgång.

Alla program kan byggas med endast tre grundläggande typer av block:

• 1. funktionsblock - en separat linjär operator eller deras sekvens;
• 2:a grenblocket - If
• 3. generaliserad loop - konstruktion av typen While

Det är väsentligt att var och en av dessa strukturer endast har en ingång och en utgång när det gäller kontroll. Den generaliserade operatorn har alltså bara en ingång och en utgång.

Strukturerad programmering kallas ibland för "programmering utan GO TO". Men poängen här är inte GO TO-satsen, utan dess urskillningslösa användning. Mycket ofta, när man implementerar strukturerad programmering i vissa programmeringsspråk, används övergångsoperatorn (GO TO) för att implementera strukturella konstruktioner utan att minska de viktigaste fördelarna med strukturerad programmering. Det är de "icke-strukturella" jump-satserna som förvirrar programmet, speciellt hoppet till en sats som finns i modultexten ovan (tidigare) den hoppsats som körs. Försöket att undvika jump-satsen i vissa enkla fall kan dock leda till strukturerade program som är för krångliga, vilket inte förbättrar deras tydlighet och innehåller risken för ytterligare fel i modulens text. Därför kan det rekommenderas att undvika att använda jump-satsen när det är möjligt, men inte på bekostnad av programmets tydlighet.

Användbara fall av användning av övergångsoperatören inkluderar att lämna en loop eller procedur på ett speciellt villkor som "tidigt" avslutar arbetet med denna loop eller denna procedur, d.v.s. avsluta arbetet för någon strukturell enhet (generaliserad operatör) och därigenom endast lokalt bryter mot struktureringen av programmet. Stora svårigheter (och komplikationer av strukturen) orsakas av den strukturella implementeringen av svaret på exceptionella (ofta felaktiga) situationer, eftersom detta inte bara kräver ett tidigt utträde från den strukturella enheten, utan också den nödvändiga bearbetningen av denna situation (till exempel , utfärdande av lämplig diagnostisk information). Undantagshanteraren kan placeras på vilken nivå som helst i programstrukturen och den kan nås från olika lägre nivåer. Helt acceptabelt ur teknisk synvinkel är följande "icke-strukturella" implementering av reaktionen på exceptionella situationer. Undantagshanterare placeras i slutet av en eller annan strukturell enhet, och varje sådan hanterare är programmerad på ett sådant sätt att den, efter att ha avslutat sitt arbete, lämnar den strukturella enhet i vars ände den är placerad. En sådan hanterare anropas av hoppoperatorn från den givna strukturella enheten (inklusive alla kapslade strukturella enheter).

Generellt sett är det viktigaste i strukturerad programmering den kompetenta sammanställningen av programmets korrekta logiska schema, vars implementering med språkmedel är en sekundär fråga.

J. Hughes, J. Michtom. Strukturellt förhållningssätt till programmering. - M.: Mir, 1980. - sid. 29-71.

V. Tursky. Programmeringsmetodik. - M.: Mir, 1981. - s. 90-164.

E.A. Zhogolev. Teknologiska grunder för modulär programmering // Programmering, 1980, nr 2. - s.44-49.

R.C. Holt. Structure of the Computer Programs: A Survey // Proceedings of the IEEE, 1975, 63(6). - sid. 879-893.

G. Myers. Programvarans tillförlitlighet. - M.: Mir, 1980. - sid. 92-113.

I. Pyle. ADA är ett inbyggt systemspråk. M.: Finans och statistik, 1984. - sid. 67-75.

M. Zelkovets, A. Shaw, J. Gannon. Principer för mjukvaruutveckling. - M.: Mir, 1982, sid. 65-71.

A.L. Fuksman. Tekniska aspekter av att skapa mjukvarusystem. M.: Statistik, 1979. - sid. 79-94.

2. Föreläsning 8. Utveckling av en mjukvarumodul

3. Proceduren för att utveckla en mjukvarumodul. Strukturell programmering och steg-för-steg detaljering. Begreppet pseudokod. Programvarumodulkontroll.

5. 8.1. Proceduren för att utveckla en mjukvarumodul.

6. När du utvecklar en mjukvarumodul är det tillrådligt att följa följande ordning:

   studie och verifiering av modulspecifikationen, språkval

   programmering;

   val av algoritm och datastruktur;

   modulprogrammering;

   polering av modulens text;

   modulkontroll;

   modulsammanställning.

   Det första steget i utvecklingen av en mjukvarumodul är till stor del en kontinuerlig kontroll av programmets struktur underifrån: genom att studera specifikationen för modulen måste utvecklaren försäkra sig om att den är förståelig och tillräcklig för honom att utveckla denna modul. I slutet av detta steg väljs ett programmeringsspråk: även om programmeringsspråket redan kan vara fördefinierat för hela PS, kan i vissa fall (om programmeringssystemet tillåter det), ett annat språk väljas som är mer lämpligt för implementeringen av denna modul (till exempel assemblerspråk).

   I det andra steget i utvecklingen av en mjukvarumodul är det nödvändigt att ta reda på om några algoritmer redan är kända för att lösa problemet eller nära det. Och om det finns en lämplig algoritm, är det lämpligt att använda den. Valet av lämpliga datastrukturer som kommer att användas när modulen utför sina funktioner bestämmer till stor del logiken och kvalitetsindikatorerna för modulen som utvecklas, så det bör betraktas som ett mycket viktigt beslut.

   I det tredje steget byggs modulens text i det valda programmeringsspråket. Överflödet av alla typer av detaljer som måste beaktas vid implementering av funktionerna som specificeras i modulspecifikationen kan lätt leda till att det skapas en mycket förvirrande text som innehåller många fel och felaktigheter. Att hitta fel i en sådan modul och göra nödvändiga ändringar i den kan vara en mycket tidskrävande uppgift. Därför är det mycket viktigt att använda en tekniskt motiverad och praktiskt beprövad programmeringsdisciplin för att bygga modulens text. För första gången uppmärksammade Dijkstra detta och formulerade och underbyggde de grundläggande principerna för strukturerad programmering. Många av de programmeringsdiscipliner som används flitigt i praktiken bygger på dessa principer. Den vanligaste är drill down-disciplinen, som diskuteras i detalj i avsnitt 8.2 och 8.3.

   Nästa steg i utvecklingen av modulen är relaterat till att föra modulens text till den slutliga formen i enlighet med PS kvalitetsspecifikation. När du programmerar en modul fokuserar utvecklaren på korrekt implementering av modulens funktioner, lämnar kommentarer oavslutade och tillåter vissa överträdelser av kraven för programmets stil. När han polerar texten i en modul bör han redigera kommentarerna i texten och eventuellt inkludera ytterligare kommentarer för att tillhandahålla de nödvändiga kvalitetsprimitiven. För samma ändamål är programtexten redigerad för att möta stilistiska krav.

   Modulverifieringssteget är en manuell kontroll av modulens interna logik innan dess felsökning (med användning av dess exekvering på en dator), implementerar den allmänna principen formulerad för den diskuterade programmeringsteknologin, om behovet av att kontrollera de beslut som fattas i varje steg av PS-utveckling (se föreläsning 3). Modulvalideringsmetoder diskuteras i avsnitt 8.4.

   Slutligen innebär det sista steget av att utveckla en modul att slutföra modulvalidering (med hjälp av kompilatorn) och gå vidare till modulfelsökningsprocessen.

8. 8.2. Strukturell programmering.

9. När du programmerar en modul bör man komma ihåg att programmet måste vara förståeligt inte bara för en dator utan också för en person: både modulutvecklaren och de personer som kontrollerar modulen och textförfattarna som förbereder tester för felsökning av modulen, och de PS-underhållare som gör de nödvändiga ändringarna i modulen måste upprepade gånger analysera modulens logik. I moderna programmeringsspråk finns det tillräckligt med verktyg för att förvirra denna logik så mycket du vill, vilket gör modulen svår att förstå för en person och som ett resultat gör den opålitlig eller svår att underhålla. Därför måste man vara noga med att välja lämpliga språkverktyg och följa en viss programmeringsdisciplin. För första gången uppmärksammade Dijkstra detta och föreslog att bygga ett program som en sammansättning av flera typer av kontrollstrukturer (strukturer), vilket avsevärt kan öka begripligheten för programmets logik. Programmering med endast sådana konstruktioner kallades strukturell programmering.

   Huvudkonstruktionerna för strukturerad programmering är: följ, förgrena och upprepa (se figur 8.1). Komponenterna i dessa konstruktioner är generaliserade operatorer (bearbetningsnoder) S, S1, S2 och ett villkor (predikat) P. Som en generaliserad operator kan det antingen finnas en enkel operator för det programmeringsspråk som används (tilldelning, input, output, procedur) anrop), eller ett programfragment , som är en sammansättning av huvudkontrollstrukturerna för strukturerad programmering. Det är väsentligt att var och en av dessa strukturer endast har en ingång och en utgång när det gäller kontroll. Den generaliserade operatorn har alltså bara en ingång och en utgång.

   Det är också mycket viktigt att dessa konstruktioner redan är matematiska objekt (vilket i huvudsak förklarar orsaken till framgången med strukturerad programmering). Det är bevisat att för varje ostrukturerat program är det möjligt att konstruera ett funktionellt ekvivalent (det vill säga att lösa samma problem) strukturerat program. För strukturerade program kan vissa egenskaper bevisas matematiskt, vilket gör det möjligt att upptäcka vissa fel i programmet. En separat föreläsning kommer att ägnas åt denna fråga.

   Strukturerad programmering kallas ibland för "programmering utan GO TO". Men poängen här är inte GO TO-satsen, utan dess urskillningslösa användning. Mycket ofta, när du implementerar strukturerad programmering i vissa programmeringsspråk (till exempel i FORTRAN), används övergångsoperatören (GO TO) för att implementera strukturella strukturer utan att minska de viktigaste fördelarna med strukturerad programmering. Det är de "icke-strukturella" jump-satserna som förvirrar programmet, speciellt hoppet till en sats som finns i modultexten ovan (tidigare) den hoppsats som körs. Försöket att undvika jump-satsen i vissa enkla fall kan dock leda till strukturerade program som är för krångliga, vilket inte förbättrar deras tydlighet och innehåller risken för ytterligare fel i modulens text. Därför kan det rekommenderas att undvika användningen av jump-satsen när det är möjligt, men inte på bekostnad av programmets tydlighet.

   Användbara fall av användning av övergångsoperatören inkluderar att lämna en loop eller procedur på ett speciellt villkor som "tidigt" avslutar arbetet med denna loop eller denna procedur, d.v.s. avsluta arbetet för någon strukturell enhet (generaliserad operatör) och därigenom endast lokalt kränka programmets strukturering. Stora svårigheter (och komplikation av strukturen) orsakas av den strukturella implementeringen av svaret på exceptionella (ofta felaktiga) situationer, eftersom detta inte bara kräver ett tidigt utträde från den strukturella enheten, utan också den nödvändiga bearbetningen (uteslutningen) av denna situation (till exempel utfärda en lämplig diagnostisk information). Undantagshanteraren kan placeras på vilken nivå som helst i programstrukturen och den kan nås från olika lägre nivåer. Helt acceptabelt ur teknisk synvinkel är följande "icke-strukturella" implementering av reaktionen på exceptionella situationer. Undantagshanterare placeras i slutet av en eller annan strukturell enhet, och varje sådan hanterare är programmerad på ett sådant sätt att den, efter att ha avslutat sitt arbete, lämnar den strukturella enhet i vars ände den är placerad. En sådan hanterare anropas av hoppoperatorn från den givna strukturella enheten (inklusive alla kapslade strukturella enheter).

11. 8.3. Steg-för-steg-detaljering och begreppet pseudokod.

12. Strukturerad programmering ger rekommendationer om vad texten i en modul ska vara. Frågan uppstår om hur en programmerare ska agera för att konstruera en sådan text. Ibland börjar programmeringen av en modul med konstruktionen av dess blockschema, som i allmänna termer beskriver logiken i dess funktion. Men modern programmeringsteknik rekommenderar inte att du gör detta. Även om flödesscheman ger en mycket visuell representation av logiken i en modul, när de är kodade i ett programmeringsspråk, uppstår en mycket specifik felkälla: kartläggning av väsentligen tvådimensionella strukturer, såsom flödesscheman, på linjär text som representerar en modul, innehåller risken att förvränga modulens logik, dessutom är det psykologiskt ganska svårt att upprätthålla en hög uppmärksamhetsnivå när man granskar den igen. Ett undantag kan vara fallet när en grafisk editor används för att bygga flödesscheman och de är formaliserade så att text i ett programmeringsspråk automatiskt genereras från dem (som t.ex. kan göras i R - teknik).

    Som den huvudsakliga metoden för att konstruera modultext, rekommenderar modern programmeringsteknik steg-för-steg-detaljering. Kärnan i denna metod är att dela upp processen för att utveckla modulens text i ett antal steg. Det första steget beskriver allmän ordning driften av modulen i en synlig linjär textform (dvs med mycket stora begrepp), och denna beskrivning är inte helt formaliserad och fokuserar på mänsklig perception. Vid varje nästa steg förfinas och detaljeras ett av begreppen (vi kommer att kalla det förfinat), vilket används (som regel inte formaliserat) i någon beskrivning som utvecklats i ett av de föregående stegen. Som ett resultat av detta steg skapas en beskrivning av det valda konceptet som förfinas antingen i termer av basprogrammeringsspråket (dvs den modul som valts för representation), eller i samma form som i det första steget med användning av nya koncept som förfinas . Denna process slutar när alla begrepp som förfinas så småningom uttrycks i det underliggande programmeringsspråket. Det sista steget är att erhålla modulens text i basprogrammeringsspråket genom att ersätta alla förekomster av de förfinade begreppen med deras specificerade beskrivningar och uttrycka alla förekomster av strukturerade programmeringskonstruktioner med detta programmeringsspråk.

    Den steg-för-steg-drill-down involverar användningen av ett delvis formaliserat språk för att representera nämnda beskrivningar, vilket kallas pseudokod. Detta språk tillåter användning av alla strukturerade programmeringskonstruktioner som är formaliserade, tillsammans med informella naturliga språkfragment för att representera generiska uttalanden och villkor. Motsvarande fragment i basprogrammeringsspråket kan också anges som generaliserade operatorer och villkor.

    Huvudbeskrivningen i pseudokod kan betraktas som den externa designen av modulen i basprogrammeringsspråket, vilket

    början av modulen i basspråket, dvs. den första meningen eller rubriken (specifikationen) i denna modul;

    en sektion (uppsättning) av beskrivningar på basspråket, och istället för beskrivningar av procedurer och funktioner - endast deras externa design;

    informell beteckning av sekvensen av modultextsatser som ett generaliserat uttalande (se nedan), såväl som informellt betecknande av sekvensen av kroppssatser för varje procedur eller funktionsbeskrivning som ett generaliserat uttalande;

    sista meningen (slutet) av modulen i basspråket.

    Den externa utformningen av beskrivningen av en procedur eller funktion presenteras på liknande sätt. Men efter Dijkstra skulle det vara bättre att presentera avsnittet av beskrivningar här också med en informell notation, och specificera den som en separat beskrivning.

    En informell beteckning av en generaliserad operator i pseudokod görs på naturligt språk av en godtycklig mening som avslöjar dess innehåll i allmänna termer. Det enda formella kravet för utformningen av en sådan beteckning är följande: denna mening måste uppta en eller flera grafiska (tryckta) linjer i sin helhet och sluta med en prick.

    För varje informell generaliserad operatör måste en separat beskrivning skapas som uttrycker logiken i dess arbete (med detaljerad information om dess innehåll) med hjälp av sammansättningen av huvudstrukturerna för strukturerad programmering och andra generaliserade operatörer. Rubriken på en sådan beskrivning bör vara den informella beteckningen av den generaliserade operatör som förfinas. De grundläggande konstruktionerna av strukturerad programmering kan representeras enligt följande (se figur 8.2). Här kan villkoret antingen uttryckligen specificeras i det underliggande programmeringsspråket som ett booleskt uttryck, eller informellt representeras i naturligt språk av något fragment som beskriver innebörden av detta villkor. I det senare fallet bör en separat beskrivning skapas som beskriver detta tillstånd, som anger beteckningen av detta tillstånd (fragment på naturligt språk) som titel.

13. Ris. 8.2. Grundläggande konstruktioner av strukturerad programmering i pseudokod.

14. Ris. 8.3. Särskilda fall av övergångsoperatören som en generaliserad operatör.

    Som en generaliserad operator i pseudokod kan du använda ovanstående specialfall av övergångsoperatorn (se fig. 8.3). Sekvensen av undantagshanterare (undantag) specificeras i slutet av en beskrivning av en modul eller procedur (funktion). Varje sådan hanterare ser ut så här:

    EXCEPTION undantagsnamn

    generisk_operatör

    ALLA UNDANTAG

    Skillnaden mellan en undantagshanterare och en procedur utan parametrar är följande: efter att proceduren har körts, återgår kontrollen till satsen efter anropet till den, och efter att undantaget exekveras, återgår kontrollen till satsen efter anropet till modulen eller procedur (funktion), i slutet av vilken (som) detta undantag placeras.

    Det rekommenderas att vid varje steg av detaljeringen skapa en tillräckligt meningsfull beskrivning, men lätt synlig (visuell), så att den placeras på en sida med text. Som regel innebär detta att en sådan beskrivning bör vara en sammansättning av fem eller sex strukturerade programmeringskonstruktioner. Det rekommenderas också att placera kapslade strukturer med en förskjutning åt höger med flera positioner (se fig. 8.4). Som ett resultat kan du få en beskrivning av arbetets logik när det gäller synlighet som är ganska konkurrenskraftig med flödesscheman, men har en betydande fördel - beskrivningens linjäritet bevaras.

15. RADERA I FILPOSTERNA INNAN DEN FÖRSTA, PASSAR FÖR SÄTT FILTER: STÄLL IN BÖRJAN PÅ FILEN. OM ETT ANNAT REKORD TILLFÄLLER FILTRERA TILL RADERA EN ANNAN POST FRÅN FILEN. ALLT OM HEJDÅ OM INGIFT INTE RADERAS DÅ TYP "RECORDS NOT DELETED". SKRIV UT "REMOVED n RECORDS". ALLT OM

Ris. 8.4. Ett exempel på ett steg för detaljering i pseudokod.

16. Idén med steg-för-steg-detaljering tillskrivs ibland Dijkstra. Dijkstra föreslog dock en fundamentalt annorlunda metod för att konstruera modultexten, som för oss förefaller vara djupare och mer lovande. Först, tillsammans med förfining av operatörer, föreslog han att gradvis (steg för steg) förfina (detaljera) de använda datastrukturerna. För det andra, vid varje steg, föreslog han att skapa en viss virtuell maskin för detaljering och, i dess termer, detaljerade alla de raffinerade koncept som denna maskin tillåter att göra detta. Sålunda föreslog Dijkstra, i huvudsak, detaljering med horisontella lager, vilket är överföringen av hans idé om skiktade system (se föreläsning 6) till nivån för modulutveckling. Denna metod för modulutveckling stöds för närvarande av ADA-språkpaket och objektorienterade programmeringsverktyg.

18. 8.4. Programvarumodulkontroll.

19. Följande metoder för programmodulstyrning tillämpas:

    statisk kontroll av modultext;

    spårning från slut till ände;

    bevis på mjukvarumodulens egenskaper.

    Vid statisk kontroll av texten i en modul läses denna text från början till slut för att hitta fel i modulen. Vanligtvis är, förutom modulutvecklaren, ytterligare en eller till och med flera programmerare inblandade för en sådan kontroll. Det rekommenderas att fel som upptäcks under en sådan kontroll korrigeras inte omedelbart, utan efter att du har läst modulens text.

    End-to-end-spårning är en av typerna av dynamisk kontroll av modulen. Det involverar också flera programmerare som manuellt loopar igenom exekveringen av modulen (påstående för påstående i den sekvens som följer av modulens logik) på en viss uppsättning tester.

    Nästa föreläsning ägnas åt att bevisa programmens egenskaper. Det bör bara noteras här att denna metod fortfarande används mycket sällan.

21. Litteratur till föreläsning 8.

22. 8.2. E. Dijkstra. Notes on Structured Programming// W. Dahl, E. Dijkstra, K. Hoor. Strukturell programmering. - M.: Mir, 1975. - S. 24-97.

    8.3. N. Wirth. Systematisk programmering. - M.: Mir, 1977. - S. 94-164.

24. Föreläsning 9

25. Begreppet programmotivering. Formalisering av programegenskaper, Hoors triad. Regler för att ställa in egenskaperna för en tilldelningsoperator, villkorlig operator och sammansatt operator. Regler för att fastställa egenskaperna hos en loopoperator, konceptet med en loopinvariant. Avslutande av programexekvering.

27. 9.1. Program motiveringar. Formalisering av programegenskaper.

28. För att förbättra programvarans tillförlitlighet är det mycket användbart att förse program med ytterligare information, med hjälp av vilken du avsevärt kan öka kontrollnivån för programvaran. Sådan information kan ges i form av informella eller formaliserade uttalanden som är knutna till olika programfragment. Vi kommer att kalla sådana påståenden för programberättigande. Icke-formaliserade motiveringar av program kan till exempel förklara motiven för att fatta vissa beslut, vilket i hög grad kan underlätta sökandet efter och korrigering av fel, liksom att studera program under deras underhåll. Formaliserade motiveringar gör det möjligt att bevisa vissa egenskaper hos program både manuellt och att kontrollera (ställa in) dem automatiskt.

    Ett av de för närvarande använda begreppen för formella motiveringar för program är användningen av de så kallade Hoors triader. Låt S vara någon generaliserad operatör över informationsmiljön IS, P och Q - några predikat (påståenden) över denna miljö. Sedan kallas notationen (P)S(Q) Hoor-triaden, där predikatet P kallas förvillkoret, och predikatet Q kallas eftervillkoret med avseende på operatorn S. Operatören (i synnerhet programmet) S sägs ha egenskapen (P)S(Q), om när predikatet P är sant innan S exekveras, är predikatet Q sant efter att S exekveras.

    Enkla exempel på programegenskaper:

    (9.1) (n=0) n:=n+1 (n=1),

    (9.2) (n

    (9.3) (n

    (9,4) (n>0) p:=1; m:=1;

    MEDAN m /= n DO

29. HEJDÅ

    För att bevisa egenskapen hos programmet S använder vi egenskaperna hos enkla operatörer av programmeringsspråket (här begränsar vi oss till den tomma operatören och tilldelningsoperatören) och egenskaperna hos kontrollstrukturer (kompositioner) med vilka programmet är byggt från enkla operatörer (vi begränsar oss här till de tre huvudsammansättningarna av strukturerad programmering, se föreläsning 8). Dessa egenskaper kallas vanligtvis programverifieringsregler.

31. 9.2. Enkla operatörers egenskaper.

32. För en tom operatör,

    Sats 9.1. Låt P vara ett predikat över informationsmiljön. Då gäller egenskapen (P)(P).

    Beviset för detta teorem är uppenbart: den tomma operatorn ändrar inte informationsmiljöns tillstånd (i enlighet med dess semantik), så dess förutsättning förblir sann efter dess exekvering.

    För uppdragsoperatören,

    Sats 9.2. Låt informationsmiljön IS bestå av variabeln X och resten av informationsmiljön RIS:

33. Sedan fastigheten

    (Q(F(X, RIS), RIS)) X:= F(X, RIS) (Q(X, RIS)) ,

    där F(X, RIS) är någon funktion med en enda värde, Q är ett predikat.

    Bevis. Låt predikatet Q(F(X0, RIS0), RIS0) vara sant före exekveringen av tilldelningsoperatorn, där (X0, RIS0) är något godtyckligt tillstånd för informationsmiljön IS, sedan efter exekveringen av tilldelningsoperatorn predikatet Q(X, RIS) kommer att vara sant, så hur X kommer att få värdet F(X0, RIS0) och tillståndet för RIS ändras inte av den givna tilldelningssatsen, och därför efter exekveringen av denna tilldelningssats i detta fall

    Q(X, RIS)=Q(F(X0, RIS0), RIS0).

    I kraft av godtyckligheten i valet av informationsmiljöns tillstånd bevisas satsen.

    Ett exempel på en egenskap hos en uppdragsoperatör är exempel 9.1.

35. 9.3. Egenskaper för de grundläggande strukturerna för strukturell programmering.

36. Betrakta nu egenskaperna hos huvudstrukturerna för strukturerad programmering: följning, förgrening och upprepning.

    Successionens egenskaper uttrycks av följande

    Sats 9.3. Låt P, Q och R vara predikat över informationsmiljön, och S1 och S2 vara generaliserade operatorer som har egenskaperna respektive

    (P)S(Q) och (Q)S2(R).

    Sedan för den sammansatta operatören

    S1; S2<.blockquote>

    det finns en fastighet

    (P) SI; S2(R).

    Bevis. Låt predikatet P vara sant för något tillstånd i informationsmiljön före exekveringen av operatorn SI. Sedan, på grund av egenskapen hos operatorn SI, efter dess exekvering, kommer predikatet Q att vara sant genom att utföra operatorn S2. Följaktligen, efter exekveringen av operatorn S2, i kraft av sin egenskap, kommer predikatet R att vara sant, och eftersom operatorn S2 slutför exekveringen av den sammansatta satsen (i enlighet med dess semantik), kommer predikatet R att vara sant efter verkställandet av detta sammansatta uttalande, vilket krävdes bevisat.

    Till exempel, om egenskaperna (9.2) och (9.3) håller, då

    plats och egendom

    (n

    Förgreningsegenskapen uttrycks med följande

    Sats 9.4. Låt P, Q och R vara predikat över informationsmiljön, och S1 och S2 vara generaliserade operatorer som har egenskaperna respektive

    (P,Q)S1(R) och (`P,Q)S2(R).

    Sedan för den villkorliga operatören

    OM P SÅ S1 ANNAT S2 ALLA OM

    det finns en fastighet

    (Q) OM P SÅ S1 ANNAT S2 ALLA OM (R) .

    Bevis. Låt predikatet Q vara sant för något tillstånd i informationsmiljön före exekveringen av den villkorliga operatorn. Om predikatet P också är sant, reduceras exekveringen av den villkorliga operatorn i enlighet med dess semantik till exekveringen av operatorn S1 . På grund av egenskapen hos operatören S1, efter dess exekvering (och i detta fall, efter exekveringen av den villkorliga operatören), kommer predikatet R att vara sant. är falsk (och Q är fortfarande sant), reduceras exekveringen av den villkorliga operatorn i enlighet med dess semantik till exekveringen av operatorn S2. På grund av egenskapen hos operatorn S2, efter dess exekvering (och i detta fall, efter exekveringen av den villkorliga operatorn), kommer predikatet R att vara sant.. Således är satsen fullständigt bevisad.

    Innan du går vidare till upprepningskonstruktionens egendom bör det noteras att det är användbart för ytterligare

    Sats 9.5. Låt P, Q, P1 och Q1 vara predikat över informationsmiljön för vilken implikationerna

    P1=>P och Q=>Q1,

    och låt egenskapen (P)S(Q) hålla för operatören S. Då gäller egenskapen (P1)S(Q1).

    Denna sats kallas också satsen för försvagning av egenskaper.

    Bevis. Låt predikatet P1 vara sant för något tillstånd i informationsmiljön innan operatören S körs. Då kommer predikatet P också att vara sant (på grund av implikationen P1=>P). Följaktligen, på grund av egenskapen hos operatorn S, efter dess exekvering, kommer predikatet Q att vara sant, och följaktligen predikatet Q1 (i kraft av implikationen Q=>Q1). Därmed är satsen bevisad.

    Upprepningsegenskapen uttrycks av följande

    Sats 9.6. Låt I, P, Q och R vara predikat över informationsmiljön för vilken implikationerna

    P=>I och (I,`Q)=>R ,

    och låt S vara en generaliserad operator med egenskapen (I)S(I).

    Sedan för slingoperatören

    BYE Q DO S ALL BYE

    det finns en fastighet

    (P) BYE Q DO S ALL BYE (R) .

    Predikatet I kallas invarianten av loopoperatorn.

    Bevis. För att bevisa detta teorem räcker det att bevisa egenskapen

    (I) BYE Q DO S ALL BYE (I,`Q)

    (genom sats 9.5 på grundval av implikationerna i villkoren för denna sats). Låt predikatet I vara sant för något tillstånd i informationsmiljön innan cykeloperatorn körs. Om, i det här fallet, predikatet Q är falskt kommer cykeloperatorn att motsvara en tom operator (i enlighet med dess semantik) och, i kraft av sats 9.1, efter exekveringen av cykeloperatören, uttalandet (I ,`Q). Om predikatet Q är sant före exekveringen av loopoperatorn, då kan loopoperatorn, i enlighet med sin semantik, representeras som en sammansatt operator S; BYE Q DO S ALL BYE

    I kraft av egenskapen hos operatören S, efter dess utförande, kommer predikatet I att vara sant, och initialsituationen uppstår för att bevisa cykeloperatörens egendom: predikatet I är sant före utförandet av cykeloperatören, men för ett annat (förändrat) tillstånd för informationsmiljön (för vilket predikatet Q kan vara antingen sant eller falskt). Om exekveringen av loop-satsen slutar, kommer vi genom att tillämpa metoden för matematisk induktion, i ett ändligt antal steg, komma till en situation där satsen (I,`Q) kommer att vara sann innan den körs. Och i det här fallet, som bevisades ovan, kommer detta uttalande att vara sant även efter exekveringen av cykelsatsen. Teoremet har bevisats.

    Till exempel, för loopoperatorn från exempel (9.4), äger egenskapen rum

    m:= m+1; p:= p*m

    ALLA ÄNNU (p=n.!}

    Detta följer av sats 9.6, eftersom invarianten för denna slingoperator är predikatet p=m! och implikationerna (n>0, p=1, m=1) => p=m! och (p=m!, m=n) => p=n!

38. 9.4. Avslutande av programexekvering.

39. En av programegenskaperna som vi kan vara intresserade av för att undvika eventuella fel i PS är dess avslutning, d.v.s. frånvaron av cykling i den för vissa initiala data. I de strukturerade programmen vi har övervägt kan endast upprepningskonstruktionen vara källan till looping. För att bevisa avslutningen av ett program räcker det därför att kunna bevisa avslutandet av en slingoperatör. Följande är användbart för detta.

    Sats 9.7. Låt F vara en heltalsfunktion som beror på informationsmiljöns tillstånd och som uppfyller följande villkor:

    (1) om predikatet Q är sant för ett givet tillstånd i informationsmiljön, då är dess värde positivt;

    (2) det minskar när tillståndet i informationsmiljön förändras som ett resultat av utförandet av operatören S.

    Sedan körningen av loop-satsen

    MEDAN Q GÖR ALLT MEDAN den är klar.

    Bevis. Låt är vara tillståndet för informationsmiljön före exekveringen av cykelsatsen och låt F(är)=k. Om predikatet Q(is) är falskt, avslutas exekveringen av loop-satsen. Om Q(är) är sant, då genom antagandet av satsen k>0. I detta fall kommer sats S att exekveras en eller flera gånger. Efter varje exekvering av operatorn S, enligt villkoret för satsen, minskar värdet på funktionen F, och eftersom före exekveringen av operatorn S måste predikatet Q vara sant (enligt cykeloperatörens semantik) , värdet på funktionen F i detta ögonblick måste vara positivt (enligt satsens tillstånd). Därför, på grund av integriteten hos funktionen F, kan operatorn S i denna cykel exekveras mer än k gånger. Teoremet har bevisats.

    Till exempel, för exemplet med cykeloperatören som betraktas ovan, är villkoren i sats 9.7 uppfyllda av funktionen f(n, m)= n-m. Eftersom innan exekveringen av loop-satsen m=1 kommer kroppen av denna loop att exekveras (n-1) gånger, dvs. denna loop-sats avslutas.

41. 9.5. Ett exempel på ett programegenskapsbevis.

42. Baserat på de beprövade reglerna för programverifiering är det möjligt att bevisa egenskaperna hos program som består av uppdragssatser och tomma satser och med hjälp av tre grundläggande sammansättningar av strukturerad programmering. För att göra detta, genom att analysera programmets struktur och använda dess för- och eftervillkor, är det nödvändigt att tillämpa en lämplig verifieringsregel vid varje steg i analysen. I fallet med repetitionssammansättning kommer det att vara nödvändigt att välja en lämplig cykelinvariant.

    Låt oss som ett exempel bevisa egendom (9.4). Detta bevis kommer att bestå av följande steg.

    (Steg 1). n>0 => (n>0, p - vilken som helst, m - vilken som helst).

    (Steg 2). Förekommer

    (n>0, p - vilken som helst, m - vilken som helst) p:=1 (n>0, p=1, m - vilken som helst).

    Genom sats 9.2.

    (Steg 3). Förekommer

    (n>0, p=1, m - vilken som helst) m:=1 (n>0, p=1, m=1).

    Genom sats 9.2.

    (Steg 4). Förekommer

    (n>0, p - vilken som helst, m - vilken som helst) p:=1; m:=1 (n>0, p=1, m=1).

    Genom sats 9.3, på grund av resultaten av steg 2 och 3.

    Låt oss bevisa att predikatet p=m! är en cykelinvariant, dvs. (p=m m:=m+1; p:=p*m {p=m!}.!}

    (Steg 5). Utspelar sig (p=m m:=m+1 {p=(m-1)!}.!}

    Genom sats 9.2, om vi representerar förutsättningen i formen (p=((m+1)-1).!}

    (Steg 6). Utspelar sig (p=(m-1) p:=p*m {p=m!}.!}

    Genom sats 9.2, om vi representerar förutsättningen i formen (p*m=m.!}

    (Steg 7). Det finns en invariant cykel

    (p=m m:=m+1; p:=p*m {p=m!}.!}

    Genom sats 9.3, på grund av resultaten av steg 5 och 6.

    (Steg 8). Förekommer

    (n>0, p=1, m=1) MEDAN m /= n DO

    m:= m+1; p:= p*m

    ALLA ÄNNU (p=n.!}

    Genom sats 9.6, i kraft av resultatet av steg 7 och med tanke på att (n>0, p=1, m= 1)=>p=m!; (p=m!, m=n)=>p=n!.

    (Steg 9). Förekommer

    (n>0, p - vilken som helst, m - vilken som helst) p:=1; m:=1;

    MEDAN m /= n DO

    m:= m+1; p:= p*m

    ALLA ÄNNU (p=n.!}

    Genom sats 9.3, på grund av resultaten av steg 3 och 8.

    (Steg 10). Egendom (9.4) innehas av sats 9.5 på grund av resultaten av steg 1 och 9.

44. Litteratur till föreläsning 9.

45. 9.1. S.A. Abramov. Delar av programmering. - M.: Nauka, 1982. S. 85-94.

    9.2. M. Zelkovets, A. Shaw, J. Gannon. Principer för mjukvaruutveckling. - M.: Mir, 1982. S. 98-105.

47. Föreläsning 10

48. Grundläggande koncept. Testa designstrategi. Felsökning av bud. Offlinefelsökning och testning av en mjukvarumodul. Omfattande felsökning och testning av programvara.

50. 10.1. Grundläggande koncept.

51. Felsökning av PS är en aktivitet som syftar till att upptäcka och korrigera fel i PS med hjälp av processerna för att köra dess program. PS-testning är processen att köra sina program på en viss datamängd, för vilken resultatet av applikationen är känt i förväg eller reglerna för dessa programs beteende är kända. Den angivna datamängden kallas ett test eller bara ett test. Således kan felsökning representeras som en upprepad upprepning av tre processer: testning, som ett resultat av vilket närvaron av ett fel i PS kan fastställas, sökning efter platsen för ett fel i programmen och dokumentationen av PS, och redigeringsprogram och dokumentation för att eliminera det upptäckta felet. Med andra ord:

    Debugging = Testa + Hitta fel + Redigering.

    I utländsk litteratur förstås felsökning ofta endast som en process för att hitta och korrigera fel (utan testning), vars närvaro fastställs under testning. Ibland anses testning och felsökning synonymt. I vårt land inkluderar begreppet felsökning vanligtvis testning, så vi kommer att följa den etablerade traditionen. Men det gemensamma övervägandet av dessa processer i denna föreläsning gör att den angivna avvikelsen inte är så betydande. Det bör dock noteras att testning också används som en del av PS-certifieringsprocessen (se föreläsning 14).

52. 10.2. Principer och typer av felsökning.

53. Framgången med felsökning bestäms till stor del av den rationella organisationen av testning. Under felsökning hittas och elimineras huvudsakligen dessa fel, vars närvaro i PS fastställs under testning. Som redan nämnts kan testning inte bevisa riktigheten av PS, i bästa fall kan det visa närvaron av ett fel i den. Med andra ord kan det inte garanteras att det genom att testa programvaran med en praktiskt genomförbar uppsättning tester är möjligt att fastställa närvaron av varje fel som finns i programvaran. Därför uppstår två problem. Förbered först en sådan uppsättning tester och använd PS på dem för att upptäcka så många fel som möjligt i den. Men ju längre testprocessen (och felsökning i allmänhet) fortsätter, desto högre blir kostnaden för programvaran. Därav den andra uppgiften: att bestämma ögonblicket när felsökningen av PS (eller dess individuella komponenter) är klar. Ett tecken på möjligheten till slutet av felsökningen är fullständigheten av täckningen av testerna som passerats genom PS (dvs. de tester som PS tillämpas på) av många olika situationer som uppstår under körningen av PS-program, och relativt sällsynt manifestation av fel i PS vid det sista segmentet av testprocessen. Den senare bestäms i enlighet med den erforderliga graden av tillförlitlighet hos PS, specificerad i specifikationen av dess kvalitet.

    För att optimera testsviten, d.v.s. för att förbereda en sådan uppsättning tester som skulle tillåta ett givet antal av dem (eller för ett givet tidsintervall som tilldelas för testning) för att upptäcka ett större antal fel, är det nödvändigt för det första att planera denna uppsättning i förväg och för det andra , att använda en rationell planering strategi (design) tester. Testdesign kan påbörjas omedelbart efter avslutad etapp extern beskrivning PS. Det finns olika tillvägagångssätt för att utveckla en testdesignstrategi, som kan placeras villkorligt grafiskt (se figur 9.1) mellan följande två extrema tillvägagångssätt. Vänsterextern tillvägagångssätt är att tester utformas endast på basis av att studera PS-specifikationerna (extern beskrivning, arkitekturbeskrivning och modulspecifikation). Modulernas struktur beaktas inte på något sätt, d.v.s. de behandlas som svarta lådor. Faktum är att detta tillvägagångssätt kräver en fullständig uppräkning av alla indatauppsättningar, eftersom när man bara använder en del av dessa uppsättningar som test, kanske vissa delar av PS-programmen inte fungerar på något test och därför kommer felen i dem inte att fungera. dyka upp. Det är dock praktiskt taget omöjligt att testa PS:n med en hel uppsättning indatauppsättningar. Det högra extrema tillvägagångssättet är att tester utformas utifrån studiet av programtexter för att testa alla sätt på vilka varje PS-program exekveras. Om vi ​​tar hänsyn till förekomsten av cykler med ett varierande antal repetitioner i program, så kan det också finnas ett extremt stort antal olika sätt att exekvera PS-program, så att testa dem också blir praktiskt taget omöjligt.

    Den optimala testdesignstrategin ligger inom intervallet mellan dessa extrema tillvägagångssätt, men närmare vänster. Det innebär att utforma en betydande del av testerna enligt specifikationer, baserat på principerna: för varje funktion eller funktion som används - minst ett test, för varje område och för varje förändringsgräns i någon indatavariabel - minst ett test, för varje specialfall eller för varje undantag som anges i specifikationerna - minst ett test. Men det kräver också design av vissa tester och programtexter, baserat på principen (minst): varje kommando i varje PS-program måste fungera på minst ett test.

    Den optimala testdesignstrategin kan specificeras baserat på följande princip: för varje programdokument (inklusive programtexter), som är en del av PS, bör utforma sina egna tester för att identifiera fel i den. Denna princip måste i alla fall iakttas i enlighet med definitionen av mjukvara och innehållet i begreppet programmeringsteknik som en teknik för att utveckla tillförlitlig programvara (se föreläsning 1). I detta avseende definierar Myers till och med olika typer av testning, beroende på vilken typ av programdokument som testerna bygger på. I vårt land finns det två huvudtyper av felsökning (inklusive testning): fristående och komplex felsökning. Offline-felsökning innebär att endast testa en del av programmet som ingår i PS, med sökning och korrigering av fel registrerade under testning. Det inkluderar faktiskt felsökning av varje modul och felsökning av modulparning. Omfattande felsökning innebär att testa PS som helhet med sökning efter och korrigering av fel som registrerats under testning i alla dokument (inklusive texter i PS-program) relaterade till PS som helhet. Sådana dokument inkluderar definitionen av krav för PS, kvalitetsspecifikationen för PS, funktionsspecifikationen för PS, beskrivningen av PS-arkitekturen och texterna i PS-programmen.

55. 10.3. Felsökning av bud.

56. Det här avsnittet ger allmänna riktlinjer för hur du organiserar felsökning. Men först bör ett fenomen noteras som bekräftar vikten av felförebyggande i tidigare utvecklingsstadier: när antalet upptäckta och korrigerade fel i programvaran växer, ökar också den relativa sannolikheten för förekomsten av oupptäckta fel i den. Detta förklaras av det faktum att med en ökning av antalet fel som upptäckts i PS, förfinas vår förståelse av det totala antalet fel som gjorts i den, och därmed, i viss mån, antalet fel som ännu inte upptäckts. Detta fenomen bekräftar vikten av tidig upptäckt av fel och behovet av noggrann kontroll av beslut som fattas i varje steg av mjukvaruutvecklingen.

    Budord 1. Betrakta testning som en nyckeluppgift för mjukvaruutveckling, anförtro den till de mest kvalificerade och begåvade programmerarna; det är inte önskvärt att testa ditt eget program.

    Bud 2. Ett bra test är ett som har stor sannolikhet att hitta ett fel, inte ett som visar att programmet fungerar korrekt.

    Bud 3. Förbered tester för både korrekta och felaktiga data.

    Bud 4. Undvik icke-reproducerbara tester, dokumentera deras passage genom datorn; studera resultaten av varje test i detalj.

    Budord 5. Anslut varje modul till programmet endast en gång; ändra aldrig ett program för att göra det lättare att testa.

    Befallning 6. Hoppa över alla tester relaterade till att kontrollera funktionen av något PS-program eller dess interaktion med andra program om ändringar har gjorts i det (till exempel som ett resultat av att en bugg åtgärdats).

58. 10.4. Offline modulfelsökning.

59. Vid offline-felsökning testas faktiskt varje modul i någon programmeringsmiljö, såvida inte programmet som felsöks består av endast en modul. Den här miljön består av andra moduler, av vilka några är moduler i programmet som felsöks som redan är felsökta, och några av vilka är moduler som styr felsökning (felsökningsmoduler, se nedan). Sålunda, under offline-felsökning, testas alltid något program, byggt specifikt för att testa modulen som felsöks. Detta program matchar endast delvis programmet som felsöks, förutom när den sista modulen i programmet som felsöks avlusas. Allt eftersom felsökningen av programmet fortskrider, kommer en allt större del av miljön för nästa modul som felsöks att vara redan felsökta moduler i detta program, och vid felsökning av den sista modulen i detta program kommer miljön för den modul som felsöks helt att bestå av alla andra (redan felsökta) moduler i programmet som felsöks (utan några) felsökningsmoduler, moduler, dvs. i det här fallet kommer själva det felsökta programmet att testas. Denna process att bygga upp ett felsökt program med felsökta och felsökta moduler kallas programintegration.

    Felsökningsmodulerna som ingår i miljön för modulen som felsöks beror på i vilken ordning modulerna i det programmet felsöks, vilken modul som felsöks och eventuellt vilket test som kommer att hoppas över.

    I bottom-up-testning (se kapitel 7) kommer denna miljö alltid endast att innehålla en felsökningsmodul (förutom när den sista modulen i programmet som felsöks avlusas), som kommer att vara huvudet för programmet som testas och som kallas befälhavaren (eller föraren). Den ledande felsökningsmodulen förbereder informationsmiljön för att testa modulen som felsöks (dvs. den bildar sitt tillstånd som krävs för att testa denna modul, i synnerhet kan den mata in en del testdata), anropar modulen som felsöks och, efter dess arbete är avslutat, utfärdar de nödvändiga meddelandena. Vid felsökning av en modul kan olika huvudfelsökningsmoduler kompileras för olika tester.

    I nedåttestning (se kapitel 7) innehåller miljön för modulen som felsöks, som felsökningsmoduler, simulatorer av alla moduler som kan nås av modulen som felsöks, samt simulatorer av de moduler som kan nås av den felsökta moduler i programmet som felsöks (ingår i denna miljö), men som ännu inte har felsökts. Vissa av dessa simulatorer kan ändras för olika tester vid felsökning av en modul.

    Faktum är att miljön för modulen som felsöks kan i många fall innehålla båda typerna av felsökningsmoduler av följande skäl. Både uppåt- och nedåttestning har sina fördelar och nackdelar.

    Fördelarna med bottom-up-testning inkluderar

    enkel förberedelse av tester och

    förmågan att fullt ut implementera modultestplanen.

    Detta beror på att testtillståndet för informationsmiljön förbereds omedelbart före anropet till modulen som felsöks (ledande felsökningsmodul). Nackdelarna med bottom-up-testning är följande funktioner:

    testdata förbereds, som regel, inte i den form som är designad för användaren (förutom när den sista huvudmodulen i programmet som felsöks är felsökt);

    en stor mängd felsökningsprogrammering (när du felsöker en modul måste du ofta komponera många ledande felsökningsmoduler för olika tester);

    behovet av speciell testning av gränssnittsmoduler.

    Fördelarna med top-down-testning inkluderar följande funktioner:

    de flesta tester är förberedda i en form utformad för användaren;

    i många fall en relativt liten mängd felsökningsprogrammering (modulsimulatorer är som regel mycket enkla och var och en lämpar sig för ett stort antal, ofta för alla, tester);

    det finns inget behov av att testa ihopparningen av moduler.

    Nackdelen med top-down-testning är att testtillståndet för informationsmiljön innan man kommer åt modulen som felsöks förbereds indirekt - det är resultatet av att redan felsökta moduler tillämpas på testdata eller data som utfärdats av simulatorer. Detta gör det för det första svårt att förbereda tester, kräver högt kvalificerad testexekutor och för det andra gör det svårt eller till och med omöjligt att implementera en komplett testplan för modulen som felsöks. Denna brist tvingar ibland utvecklare att använda bottom-up-testning även i fallet med top-down-utveckling. Oftare används dock någon modifiering av top-down-testning, eller någon kombination av top-down och bottom-up-testning.

    Med utgångspunkt i det faktum att top-down-testning i princip är att föredra, låt oss uppehålla oss vid tekniker som gör att vi till viss del kan övervinna dessa svårigheter. Först och främst är det nödvändigt att organisera felsökningen av programmet på ett sådant sätt att modulerna som utför datainmatning felsöks så snart som möjligt - sedan kan testdata förberedas i en form utformad för användaren, vilket i hög grad kommer att förenkla förberedelserna av efterföljande tester. Denna inmatning utförs ingalunda alltid i head-modulen, så du måste först felsöka de kedjor av moduler som leder till modulerna som utför den specificerade inmatningen (jfr metoden för målmedveten konstruktiv implementering i föreläsning 7). Tills ingångsmodulerna har felsökts, levereras testdata av vissa simulatorer: de ingår antingen i simulatorn som en del av den eller matas in av denna simulator.

    I top-down-testning kan det hända att vissa informationsmiljötillstånd där det krävs att testa modulen som felsöks inte inträffar under exekveringen av programmet som felsöks för någon indata. I dessa fall skulle det vara möjligt att inte testa modulen som felsöks alls, eftersom de fel som hittas i detta fall inte kommer att visas när programmet som felsöks körs under någon indata. Det rekommenderas dock inte att göra detta, eftersom när programmet som felsöks ändras (till exempel vid underhåll av PS), kan tillstånden i informationsmiljön som inte användes för att testa modulen som felsöks redan uppstå, vilket kräver ytterligare testning av denna modul (och detta, med en rationell organisation av felsökning, kunde inte göras om själva modulen inte har ändrats). För att testa modulen som felsöks i dessa situationer används ibland lämpliga simulatorer för att skapa önskat tillstånd för informationsmiljön. Oftare används en modifierad version av top-down-testning, där modulerna som felsöks förtestas separat innan de integreras (i detta fall visas en ledande felsökningsmodul i miljön för den modul som felsöks, tillsammans med modulen simulatorer som kan nås av modulen som felsöks). En annan modifiering av top-down-testning verkar dock vara mer lämplig: efter att top-down-testningen av modulen som felsöks för nåbara testtillstånd i informationsmiljön har slutförts, bör den testas separat för de återstående nödvändiga tillstånden av informationen miljö.

    Ofta används också en kombination av bottom-up- och bottom-up-testning, som kallas sandwichmetoden. Kärnan i denna metod ligger i den samtidiga implementeringen av både uppåt- och nedåttestning tills dessa två testprocesser möts på någon modul någonstans i mitten av strukturen för programmet som felsöks. Denna metod gör det möjligt att med ett rimligt tillvägagångssätt dra nytta av fördelarna med både bottom-up och top-down tester och i stor utsträckning neutralisera deras brister. Denna effekt är en manifestation av en mer allmän princip: den största tekniska effekten kan uppnås genom att kombinera top-down- och bottom-up-metoder för COP-programmering. Det är för att stödja denna metod som det arkitektoniska tillvägagångssättet för mjukvaruutveckling är tänkt (se föreläsning 7): ett lager av väldesignade och noggrant testade moduler underlättar i hög grad implementeringen av en familj av program inom motsvarande ämnesområde och deras efterföljande modernisering.

    Mycket viktigt vid offline-felsökning är modulparningstestning. Faktum är att specifikationen för varje programmodul, med undantag för huvud ett, används i detta program i två situationer: för det första när man utvecklar texten (ibland säger de: kroppen) i denna modul och för det andra när man skriver en vädja till denna modul i andra programmoduler. I båda fallen, som ett resultat av ett fel, kan den erforderliga överensstämmelsen med en given modulspecifikation kränkas. Sådana fel måste upptäckas och korrigeras. Detta är syftet med att testa ihopparningen av moduler. Vid top-down-testning utförs parningstestning längs vägen med varje överhoppat test, vilket anses vara den starkaste fördelen med top-down-testning. Under nedifrån och upp-testning nås den felsökta modulen inte från modulerna i programmet som felsöks, utan från den ledande felsökningsmodulen. I detta avseende finns det en risk att den sista modulen kan anpassa sig till vissa "missuppfattningar" av modulen som felsöks. Därför, när du startar (i processen för programintegrering) felsökning av en ny modul, är det nödvändigt att testa varje anrop till en tidigare felsökt modul för att upptäcka inkonsekvenser mellan detta anrop och kroppen i motsvarande modul (och det är möjligt att den tidigare felsökta modulen är skyldig till detta). Således är det nödvändigt att delvis upprepa testning av en tidigare felsökt modul under nya förhållanden, och samma svårigheter uppstår som vid top-down-testning.

    Autonom testning av modulen bör utföras i fyra på varandra följande steg.

    Steg 1: Baserat på specifikationen för modulen du felsöker, förbered ett test för varje möjlighet och situation, för varje gräns för intervallen för alla ingångar, för varje intervall av dataändringar, för varje ogiltigt intervall av alla ingångar, och varje ogiltigt tillstånd.

    Steg 2. Kontrollera modulens text för att försäkra dig om att varje riktning i varje gren kommer att klara minst ett test. Lägg till saknade tester.

    Steg 3. Verifiera från modultexten att det för varje slinga finns ett test för vilket slingkroppen inte exekveras, ett test för vilket slingkroppen exekveras en gång och ett test för vilket loopkroppen exekveras maximalt antal gånger. Lägg till saknade tester.

    Steg 4. Kontrollera modulens text för dess känslighet för individuella speciella indatavärden - alla sådana värden bör inkluderas i testerna. Lägg till saknade tester.

61. 10.5. Komplex felsökning av programvaran.

62. Som nämnts ovan, med komplex felsökning, testas PS som helhet och tester förbereds för vart och ett av PS-dokumenten. Testning av dessa dokument utförs vanligtvis i omvänd ordning av deras utveckling (enda undantaget är testning av applikationsdokumentation, som utvecklas enligt den externa beskrivningen parallellt med utvecklingen av programtexter; denna testning görs bäst efter testning av den externa beskrivningen är ifylld). Testning i komplex felsökning är tillämpningen av PS på specifik data som i princip kan härröra från användaren (särskilt alla tester är förberedda i en form utformad för användaren), men möjligen i en simulerad (snarare än verklig) miljö. Till exempel kan vissa in- och utdataenheter som är otillgängliga under komplex felsökning ersättas av deras mjukvarusimulatorer.

    PS-arkitekturtestning. Syftet med testning är att hitta en diskrepans mellan beskrivningen av arkitekturen och uppsättningen av program i PS. När testningen av PS-arkitekturen börjar bör den autonoma felsökningen av varje delsystem redan vara klar. Arkitekturimplementeringsfel kan i första hand associeras med interaktionen mellan dessa delsystem, i synnerhet med implementeringen av arkitektoniska funktioner (om några). Därför skulle jag vilja kontrollera alla sätt för interaktion mellan PS-delsystemen. Men eftersom det kan finnas för många av dem skulle det vara önskvärt att testa åtminstone alla exekveringskedjor av delsystem utan att återinträda i de senare. Om den givna arkitekturen representerar PS som ett litet system av utvalda delsystem, kommer antalet sådana kedjor att vara ganska synliga.

    Testa externa funktioner. Syftet med testningen är att hitta avvikelser mellan funktionsspecifikationen och uppsättningen av mjukvaruprogram för PS. Trots att alla dessa program redan har felsökts oberoende av varandra kan dessa avvikelser till exempel bero på en bristande överensstämmelse mellan de interna specifikationerna för programmen och deras moduler (baserat på vilka autonoma tester utfördes) och den externa funktionsspecifikationen av MS. Testning av externa funktioner sker i regel på samma sätt som att testa moduler i första steget, d.v.s. som en svart låda.

    PS kvalitetstestning. Syftet med testning är att söka efter överträdelser av kvalitetskraven formulerade i PS kvalitetsspecifikation. Detta är den svåraste och minst studerade typen av testning. Det är bara tydligt att inte alla PS-kvalitetsprimitiv kan testas genom att testa (se nästa föreläsning om PS-kvalitetsbedömning). Fullständigheten av PS kontrolleras redan vid test av externa funktioner. På detta stadium testning av denna kvalitetsprimitiva kan fortsätta om det krävs för att erhålla någon probabilistisk uppskattning av graden av tillförlitlighet hos PS. Metodiken för sådana tester behöver dock fortfarande utvecklas. Noggrannhet, robusthet, säkerhet, tidseffektivitet, minneseffektivitet i viss mån, enhetseffektivitet, utbyggbarhet och, delvis, enhetsoberoende kan testas. Var och en av dessa typer av tester har sina egna detaljer och förtjänar separat övervägande. Vi kommer att begränsa oss här till att lista dem. Användarvänligheten för PS (ett kvalitetskriterium som inkluderar flera kvalitetsprimitiver, se Föreläsning 4) utvärderas när dokumentation om användningen av PS testas.

    Testdokumentation om tillämpningen av PS. Syftet med testning är att söka efter inkonsekvenser mellan dokumentationen på applikationen och uppsättningen av program, samt besväret med att använda programvaran. Detta steg föregår omedelbart användarens anslutning till slutförandet av utvecklingen av PS (testning av kraven för PS och certifiering av PS), så det är mycket viktigt för utvecklare att först använda PS själva på det sätt som användaren kommer att göra Det. Alla tester i detta skede är förberedda enbart på grundval av dokumentationen om tillämpningen av PS. Först och främst bör programvarans kapacitet testas som den gjordes vid testning av externa funktioner, men endast på basis av applikationsdokumentationen. Alla otydliga platser i dokumentationen bör testas, liksom alla exempel som används i dokumentationen. Därefter testas de svåraste fallen av applicering av PS för att upptäcka en överträdelse av kraven för relativiteten av användarvänlighet för PS.

    Testar definitionen av krav för PS. Syftet med testningen är att ta reda på i vilken utsträckning programvaran inte motsvarar den presenterade kravdefinitionen för den. Det speciella med denna typ av testning är att den utförs av inköpsorganisationen eller användarorganisationen av PS som ett av sätten att övervinna barriären mellan utvecklaren och användaren (se föreläsning 3). Vanligtvis utförs denna testning med hjälp av kontrolluppgifter - typiska uppgifter för vilka resultatet av lösningen är känt. I de fall den utvecklade PS:en ska ersätta en annan version av PS:en som löser åtminstone en del av uppgifterna för den utvecklade PS:en, utförs testning genom att lösa vanliga problem med både den gamla och den nya PS:en, följt av en jämförelse av resultaten erhållits. Ibland, som en form av sådan testning, används provdrift av PS - en begränsad tillämpning av en ny PS med analys av användningen av resultaten i praktiken. I huvudsak har denna typ av testning mycket gemensamt med testningen av PS under dess certifiering (se föreläsning 14), men utförs före certifiering, och ibland istället för certifiering.

64. Litteratur till föreläsning 10.

65. 10.1. G. Myers. Programvarans tillförlitlighet. - M.: Mir, 1980. - S. 171-262.

    10.2. D. Van Tassel. Stil, utveckling, effektivitet, felsökning och testprogram. - M.: Mir, 1985. - S. 179-295.

    10.3. J. Hughes, J. Michtom. Strukturellt förhållningssätt till programmering. - M.: Mir, 1980. - S. 254-268.

    10.4. J. Fox. Programvara och dess utveckling. - M.: Mir, 1985. - S. 227-241.

    10.5. M. Zelkowitz, A. Shaw, J. Gannon. Principer för mjukvaruutveckling. - M.: Mir, 1982. - S. 105-116.

    10.6. Yu.M. Bezborodov. Individuell felsökning av program. - M.: Nauka, 1982. - S. 9-79.

    10.7. V.V. Lipaev. Programtestning. - M.: Radio och kommunikation, 1986. - S. 15-47.

    10.8. E.A. Zhogolev. Introduktion till programmeringsteknik (föreläsningsanteckningar). - M.: "DIALOG-MGU", 1994.

    10.9. E. Dijkstra. Anteckningar om strukturerad programmering. //U. Dahl, E. Dijkstra, K. Hoor. Strukturell programmering. - M.: Mir, 1975. - S. 7-13.

67. Föreläsning 11

69. 11.1. Funktionalitet och tillförlitlighet som obligatoriska kriterier för programvarans kvalitet.

70. I de tidigare föreläsningarna tog vi hänsyn till alla stadier av utvecklingen av PS, förutom dess certifiering. Samtidigt berörde vi inte frågorna om kvalitetssäkring av PS i enlighet med dess kvalitetsspecifikation (se föreläsning 4). Det är sant att när vi implementerade den funktionella specifikationen för PS diskuterade vi därigenom huvudfrågorna för att säkerställa funktionalitetskriteriet. Efter att ha deklarerat mjukvarans tillförlitlighet som dess huvudattribut (se föreläsning 1), har vi valt felförebyggande som huvudmetod för att säkerställa mjukvarans tillförlitlighet (se föreläsning 3) och diskuterat dess implementering i olika stadier av mjukvaruutvecklingen. Således manifesterades tesen om den obligatoriska funktionaliteten och tillförlitligheten hos PS som kriterier för dess kvalitet.

    Programvarans kvalitetsspecifikation kan dock innehålla ytterligare egenskaper hos dessa kriterier, vars tillhandahållande kräver särskild diskussion. Dessa frågor är i fokus för denna föreläsning. Att säkerställa andra kvalitetskriterier kommer att diskuteras i nästa föreläsning.

    Tillhandahållandet av MS-kvalitetsprimitiven som uttrycker kriterierna för MS:s funktionalitet och tillförlitlighet diskuteras nedan.

72. 11.2. Säkerställande av programvarans fullständighet.

73. Fullständigheten hos PS är en allmän PS-kvalitetsprimitiv för att uttrycka både funktionalitet och tillförlitlighet hos PS, och för funktionalitet är den den enda primitiva (se Föreläsning 4).

    Funktionaliteten hos PS bestäms av dess funktionsspecifikation. Fullständigheten hos en PS som en primitiv av dess kvalitet är ett mått på hur denna specifikation implementeras i en given PS. Att tillhandahålla denna primitiva i sin helhet innebär att implementera var och en av funktionerna som definieras i funktionsspecifikationen, med alla detaljer och funktioner som anges där. Alla tidigare diskuterade tekniska processer visar hur detta kan göras.

    Flera nivåer av implementering av funktionaliteten hos PS kan dock definieras i PS-kvalitetsspecifikationen: någon förenklad (initial eller start) version kan definieras, som måste implementeras först, och flera mellanversioner kan också definieras. I det här fallet uppstår ett ytterligare tekniskt problem: organisationen av att öka funktionaliteten hos PS. Det är viktigt att notera här att utvecklingen av en förenklad version av PS inte är utvecklingen av dess prototyp. Prototypen utvecklas för att bättre förstå förutsättningarna för användningen av den framtida PS, för att förtydliga dess externa beskrivning. Den är designad för utvalda användare och kan därför skilja sig mycket från den erforderliga PS inte bara i de funktioner som utförs, utan också i funktionerna i användargränssnittet. En förenklad version av den obligatoriska PS bör utformas för praktisk användning av alla användare som den är avsedd för. Därför är huvudprincipen för att säkerställa funktionaliteten hos ett sådant operativsystem att utveckla operativsystemet från allra första början på ett sådant sätt som om hela operativsystemet krävs, tills utvecklarna hanterar dessa delar eller detaljer i operativsystemet, implementering av som kan skjutas upp i enlighet med dess kvalitetsspecifikation. Såväl den externa beskrivningen som beskrivningen av PS-arkitekturen måste utvecklas i sin helhet. Det är möjligt att endast skjuta upp implementeringen av de mjukvaruundersystem som definieras i arkitekturen för den utvecklade PS, vars funktion inte krävs i den ursprungliga versionen av denna PS. Implementeringen av själva mjukvaruundersystemen görs bäst med metoden för målmedveten konstruktiv implementering, och lämnar i den ursprungliga versionen av PS lämpliga simulatorer av de programvarumoduler som inte krävs i denna version. En förenklad implementering av vissa mjukvarumoduler är också acceptabel, och utelämnar implementeringen av vissa detaljer av motsvarande funktioner. Men ur teknisk synvinkel är det bättre att betrakta sådana moduler som deras ursprungliga imitatorer (om än långt avancerade).

    På grund av felen i den utvecklade PS:en kan den fullständighet som uppnåtts för att säkerställa dess funktionalitet (i enlighet med specifikationen för dess kvalitet) faktiskt inte vara som förväntat. Vi kan bara säga att denna fullständighet har uppnåtts med en viss sannolikhet, bestämd av volymen och kvaliteten på testningen. För att öka denna sannolikhet är det nödvändigt att fortsätta testa och felsöka PS. Att uppskatta en sådan sannolikhet är dock en mycket specifik uppgift (med hänsyn till det faktum att manifestationen av felet i PS är en funktion av de initiala uppgifterna), som fortfarande väntar på lämpliga teoretiska studier.

75. 11.3. Säkerställa noggrannheten hos mjukvaruverktyget.

76. Att tillhandahålla denna primitiva är kopplad till operationer på värden av verkliga typer (mer exakt, med värden representerade med något fel). Att säkerställa den erforderliga noggrannheten vid beräkning av värdet för en viss funktion innebär att erhålla detta värde med ett fel som inte går utöver de angivna gränserna. Typerna av fel, metoder för att uppskatta dem och metoder för att uppnå erforderlig noggrannhet (de så kallade ungefärliga beräkningarna) behandlas med beräkningsmatematik. Här uppmärksammar vi bara en viss struktur av felet: felet för det beräknade värdet (totalfel) beror på

    på felet i den använda beräkningsmetoden (där vi inkluderar felaktigheten i den använda modellen),

    från felet i presentationen av de använda uppgifterna (från det så kallade fatala felet),

    från avrundningsfelet (oexakthet i utförandet av de operationer som används i metoden).

78. 11.4. Säkerställa programvarans autonomi.

79. Denna kvalitetsprimitiva tillhandahålls vid kvalitetsspecifikationen genom att man fattar ett beslut om att använda någon lämplig underliggande programvara i den utvecklade PS:en eller inte använda någon underliggande programvara i den. Samtidigt är det nödvändigt att ta hänsyn till både dess tillförlitlighet och de resurser som krävs för dess användning. Med ökade krav på tillförlitligheten hos den utvecklade PS, kan tillförlitligheten hos den grundläggande programvaran som är tillgänglig för utvecklarna visa sig vara otillfredsställande, därför måste dess användning överges och implementeringen av dess funktioner i den erforderliga volymen måste inkluderas i PS. Liknande beslut måste fattas under stränga restriktioner för de resurser som används (enligt PS effektivitetskriteriet).

81. 11.5. Säkerställa programvarans hållbarhet.

82. Denna kvalitetsprimitiva tillhandahålls med hjälp av så kallad defensiv programmering. Generellt sett används defensiv programmering för att förbättra tillförlitligheten hos MS vid programmering av modulen i bredare bemärkelse. Som Myers säger, "Defensiv programmering bygger på en viktig premiss: Det värsta en modul kan göra är att acceptera dålig input och sedan returnera ett felaktigt men troligt resultat." För att undvika detta innehåller modulens text kontroller av dess in- och utdata för att se om de är korrekta i enlighet med specifikationen för denna modul, i synnerhet uppfyllandet av begränsningarna för in- och utdata och relationerna mellan dem som anges i modulspecifikationen bör kontrolleras. Vid negativt resultat av kontrollen höjs motsvarande undantag. I detta avseende ingår fragment av det andra slaget i slutet av denna modul - hanterare av motsvarande exceptionella situationer, som, förutom att utfärda den nödvändiga diagnostiska informationen, kan vidta åtgärder antingen för att eliminera fel i data (till exempel, kräva att de matas in igen) eller för att mildra effekten av felet (till exempel mjukt stopp av enheter som kontrolleras av PS för att undvika att de går sönder i händelse av en nödstopp av programkörningen).

    Användningen av skyddsprogrammering av moduler leder till en minskning av effektiviteten hos PS både i tid och i minne. Därför är det nödvändigt att rimligen reglera graden av tillämpning av defensiv programmering, beroende på kraven på tillförlitlighet och effektivitet hos PS, formulerade i kvalitetsspecifikationen för den utvecklade PS. Indata från den utvecklade modulen kan komma antingen direkt från användaren eller från andra moduler. Det vanligaste fallet med att använda defensiv programmering är dess användning för den första gruppen av data, vilket innebär förverkligandet av PS-stabiliteten. Detta bör göras närhelst kvalitetsspecifikationen för PS innehåller ett krav för att säkerställa PS:s stabilitet. Användningen av defensiv programmering för den andra gruppen av indata innebär ett försök att upptäcka ett fel i andra moduler under exekveringen av den utvecklade modulen, och för utdata från den utvecklade modulen, ett försök att upptäcka ett fel i själva modulen under dess utförande. I huvudsak innebär detta en partiell implementering av metoden för självdetektering av fel för att säkerställa programvarans tillförlitlighet, vilket diskuterades i föreläsning 3. Detta fall av defensiv programmering används extremt sällan - endast när kraven på programvarans tillförlitlighet är extremt höga.

84. 11.6. Säkerställa programvarans säkerhet.

85. Skilja på följande typer skydd av PS från informationsförvrängning:

    skydd mot hårdvarufel;

    skydd från påverkan av ett "utländskt" program;

    skydd mot fel i "eget" program;

    skydd mot operatörs(användar)fel;

    skydd mot obehörig åtkomst;

    skydd mot skydd.

    Skydd mot hårdvarufel är för närvarande inte en särskilt brådskande uppgift (med hänsyn till vilken nivå av datortillförlitlighet som uppnåtts). Men det är ändå bra att veta hennes lösning. Detta säkerställs genom organisationen av de så kallade "dubbeltrippelfelberäkningarna". För att göra detta delas hela databehandlingsprocessen, som bestäms av PS, i tid i intervall av de så kallade "referenspunkterna". Längden på detta intervall bör inte överstiga hälften av datorns genomsnittliga drifttid. En kopia av minnets tillstånd som ändrats i denna process för varje referenspunkt skrivs till sekundärminnet med en viss kontrollsumma (ett tal beräknat som en funktion av detta tillstånd) i det fall det kommer att anses att behandlingen av data från den tidigare referenspunkten till denna (d.v.s. en "felberäkning") är korrekt gjord (utan datorfel). För att ta reda på det görs två sådana "felräkningar". Efter den första "beräkningen" beräknas och lagras den specificerade kontrollsumman, varefter minnestillståndet för den föregående referenspunkten återställs och den andra "beräkningen" görs. Efter den andra "felberäkningen" beräknas den angivna kontrollsumman igen, som sedan jämförs med kontrollsumman för den första "felberäkningen". Om dessa två kontrollsummor matchar, anses den andra beräkningen vara korrekt, annars lagras även kontrollsumman för den andra "beräkningen" och den tredje "beräkningen" utförs (med den preliminära återställningen av minnestillståndet för föregående referenspunkt). Om kontrollsumman för den tredje "felberäkningen" matchar kontrollsumman för en av de två första "felberäkningarna", anses den tredje felberäkningen vara korrekt, annars krävs en teknisk kontroll av datorn.

    Skydd mot påverkan av ett "främmande" program avser i första hand operativsystem eller program som delvis utför sina funktioner. Det finns två typer av detta skydd:

    felskydd,

    skydd mot skadlig påverkan av ett "utländskt" program.

    När ett multiprogrammeringsläge för en dator visas, kan flera program köras samtidigt i dess minne, växelvis ta emot kontroll som ett resultat av avbrott (den så kallade kvasi-parallella exekveringen av program). Ett av dessa program (vanligtvis: operativsystemet) hanterar avbrott och hanterar multiprogrammering. I vart och ett av dessa program kan fel uppstå (fel dyker upp) som kan påverka prestanda för funktioner i andra program. Därför måste styrprogrammet (operativsystemet) skydda sig själv och andra program från sådan påverkan. För att göra detta måste datorhårdvaran implementera följande funktioner:

    minnesskydd,

    två lägen för datordrift: privilegierad och arbete (användare),

    två typer av transaktioner: privilegierade och vanliga,

    korrekt implementering av avbrott och initial uppstart av datorn,

    tillfälligt avbrott.

    Minnesskydd innebär möjligheten att programmässigt ställa in minnesområden för varje program som är otillgängliga för det. I privilegierat läge kan alla operationer (både vanliga och privilegierade) utföras, och i körläge, endast vanliga. Ett försök att utföra en privilegierad operation, såväl som att komma åt skyddat minne i driftläge, orsakar motsvarande avbrott. Dessutom inkluderar privilegierade operationer operationer för att ändra minnesskyddet och driftläget, samt åtkomst till den externa informationsmiljön. Den första påslagning av datorn och eventuella avbrott bör automatiskt aktivera privilegierat läge och åsidosätta minnesskydd. I det här fallet kan styrprogrammet (operativsystemet) helt skydda sig från påverkan av andra program, om alla kontrollöverföringspunkter vid första uppstart och avbrott tillhör detta program, om det inte tillåter något annat program att fungera i privilegierat läge (när kontrollen överförs till något annat kommer programmet endast att slå på driftläget) och om det helt skyddar sitt minne (som innehåller, i synnerhet, all dess kontrollinformation, inklusive de så kallade avbrottsvektorerna) från andra program. Då kommer ingen att hindra den från att utföra några skyddsfunktioner implementerade i den för andra program (inklusive åtkomst till den externa informationsmiljön). För att underlätta lösningen av detta problem placeras en del av ett sådant program i permanent minne, d.v.s. oskiljaktig från själva datorn. Närvaron av ett temporärt avbrott gör att kontrollprogrammet kan skydda sig från looping i andra program (utan ett sådant avbrott kan det helt enkelt förlora förmågan att styra).

    Skydd mot misslyckanden i "det egna" programmet säkerställs av tillförlitligheten hos detta program, som är i fokus för hela programmeringstekniken som diskuteras i denna föreläsningskurs.

    Skydd mot användarfel (utöver indatafel, se säkerställa PS-stabilitet) tillhandahålls genom att utfärda varningsmeddelanden om försök att ändra tillståndet för den externa informationsmiljön med kravet att bekräfta dessa åtgärder, samt möjligheten att återställa tillstånd för enskilda komponenter i den externa informationsmiljön. Det senare bygger på implementering av arkiveringsförändringar i den externa informationsmiljöns tillstånd.

    Skydd mot obehörig åtkomst tillhandahålls genom användning av hemliga ord (lösenord). I det här fallet förses varje användare med viss information och procedurresurser (tjänster), vars användning kräver presentation av ett lösenord till PS, som tidigare registrerats i PS av denna användare. Med andra ord, användaren, så att säga, "hänger ett lås" på de resurser som tilldelats honom, "nyckeln" som bara denna användare har. Ihärdiga försök kan dock göras att bryta ett sådant skydd i enskilda fall om de skyddade resurserna är av extremt värde för någon. I ett sådant fall måste ytterligare åtgärder vidtas för att skydda mot säkerhetsintrång.

    Skydd mot säkerhetsintrång är förknippat med användningen av speciella programmeringstekniker i PS som gör det svårt att övervinna skyddet mot obehörig åtkomst. Användningen av vanliga lösenord räcker inte när det handlar om en extremt ihärdig önskan (till exempel av kriminell karaktär) att få tillgång till värdefull information. För det första eftersom informationen om lösenord som PS:n använder för att skydda mot obehörig åtkomst kan erhållas relativt enkelt av en "kracker" av detta skydd om han har tillgång till denna PS själv. För det andra, med hjälp av en dator, är det möjligt att utföra en tillräckligt stor uppräkning av möjliga lösenord för att hitta ett lämpligt för att komma åt informationen av intresse. Du kan skydda dig mot ett sådant hack på följande sätt. Det hemliga ordet (lösenordet) eller bara det hemliga heltal X är endast känt för ägaren av den skyddade informationen, och för att kontrollera åtkomsträttigheterna lagras ett annat nummer Y=F(X) i datorn, vilket är unikt beräknat av PS varje gång ett försök görs att komma åt denna information vid uppvisande av det hemliga ordet. Samtidigt kan funktionen F vara välkänd för alla PS-användare, men den har en sådan egenskap att det är praktiskt taget omöjligt att återställa ordet X från Y: med en tillräckligt stor längd på ordet X (till exempel flera hundra tecken ), kräver detta astronomisk tid. Ett sådant nummer Y kommer att kallas den elektroniska (dator) signaturen för ägaren av det hemliga ordet X (och därmed den skyddade informationen).

    En annan typ av sådant skydd är relaterat till skydd av meddelanden som skickas över datornätverk, avsiktlig (eller skadlig) förvrängning. Ett sådant meddelande kan fångas upp vid "omlastnings"-punkter i datornätverket och ersättas av ett annat meddelande från författaren till det avlyssnade meddelandet. Denna situation uppstår främst vid genomförandet av bankverksamhet med hjälp av ett datornätverk. Genom att ersätta ett sådant meddelande, som är en order från ägaren av ett bankkonto att utföra någon bankverksamhet, kan pengar från hans konto överföras till kontot för ett "hacker"-skydd (ett slags datorbankrån). Skydd mot ett sådant säkerhetsintrång kan göras enligt följande. Tillsammans med funktionen F, som bestämmer datorsignaturen för ägaren av det hemliga ordet X, som är känd för adressaten för det skyddade meddelandet (om bara dess ägare är en klient till denna adressaten), definieras en annan stämpelfunktion i PS, från vilken avsändaren av meddelandet måste beräkna antalet S=Stamp(X,R ) med hjälp av det hemliga ordet X och texten i det överförda meddelandet R. Stämpelfunktionen anses också vara välkänd för alla MS-användare och har sådana en egenskap att det är praktiskt taget omöjligt att återställa talet X från S, eller att välja ett annat meddelande R med motsvarande datorsignatur. Själva det överförda meddelandet (tillsammans med dess skydd) bör se ut så här:

    dessutom tillåter Y (datorsignatur) adressaten att fastställa sanningen om klienten, och S, så att säga, fäster det skyddade meddelandet R med datorsignaturen Y. I detta avseende kommer vi att kalla numret S en elektronisk (dator) ) täta. PS definierar ytterligare en Notarius-funktion, enligt vilken mottagaren av det skyddade meddelandet kontrollerar sanningen i det överförda meddelandet:

86. Detta gör att du entydigt kan fastställa att meddelandet R tillhör ägaren av det hemliga ordet X.

    Skydd mot skydd är nödvändigt i händelse av att användaren har glömt (eller tappat) sitt lösenord. I ett sådant fall bör det vara möjligt för en särskild användare (PS-administratör) som ansvarar för skyddssystemets funktion att tillfälligt ta bort skyddet från obehörig åtkomst för ägaren av det glömda lösenordet för att göra det möjligt för honom att fixa ett nytt lösenord.

88. Litteratur till föreläsning 11.

89. 11.1. ÄR. Berezin, N.P. Zhidkov. Beräkningsmetoder, vol. 1 och 2. - M.: Fizmatgiz, 1959.

    11.2. N.S. Bakhvalov, N.P. Zhidkov, G.M. Kobelkov. Numeriska metoder. - M.: Nauka, 1987.

    11.3. G. Myers. Programvarans tillförlitlighet. - M.: Mir, 1980. S. 127-154.

    11.4. EN. Lebedev. Skydd av bankinformation och modern kryptografi//Issues of information security, 2(29), 1995.

91. Föreläsning 12. Kvalitetssäkring av programvara

93. 12.1. Allmänna egenskaper för kvalitetssäkringsprocessen för programvara.

94. Som redan noterats i föreläsning 4, definierar kvalitetsspecifikationen de huvudsakliga riktlinjerna (målen) som i alla skeden av utvecklingen av PS på ett eller annat sätt påverkar valet av lämpligt alternativ vid olika beslut. Varje kvalitetsprimitiv har dock sina egna egenskaper för sådant inflytande, så att säkerställa dess närvaro i PS kan kräva sina egna tillvägagångssätt och metoder för att utveckla PS eller dess enskilda delar. Dessutom noterades också inkonsekvensen av PS-kvalitetskriterierna och de kvalitetsprimitiv som uttrycker dem: bra tillhandahållande av en av PS-kvalitetsprimitiven kan avsevärt komplicera eller göra det omöjligt att tillhandahålla några av de andra av dessa primitiver. Därför består en väsentlig del av processen för att säkerställa kvaliteten på PS i att hitta acceptabla avvägningar. Dessa avvägningar bör delvis definieras redan i PS-kvalitetsspecifikationen: PS-kvalitetsmodellen bör specificera den erforderliga graden av närvaro i PS av var och en av dess kvalitetsprimitiver och bestämma prioriteringarna för att uppnå dessa grader.

    Kvalitetssäkring utförs i varje teknisk process: de beslut som tas i den påverkar i en eller annan grad kvaliteten på programvaran som helhet. I synnerhet eftersom en betydande del av kvalitetsprimitiven inte är förknippad så mycket med egenskaperna hos de program som ingår i PS, utan med egenskaperna hos dokumentationen. På grund av den noterade inkonsekvensen av kvalitetsprimitiver är det mycket viktigt att följa de valda prioriteringarna i deras tillhandahållande. Men i alla fall är det användbart att följa två allmänna principer:

    För det första är det nödvändigt att säkerställa den nödvändiga funktionaliteten och tillförlitligheten hos PS, och sedan bringa de återstående kvalitetskriterierna till en acceptabel nivå av deras närvaro i PS;

    det finns inget behov, och det kan till och med vara skadligt, att söka en högre nivå av närvaro i PS av någon primitiv kvalitet än den som definieras i PS-kvalitetsspecifikationen.

    Att säkerställa funktionaliteten och tillförlitligheten hos PS övervägdes i föregående föreläsning. Tillhandahållandet av andra OS-kvalitetskriterier diskuteras nedan.

    12.2.. Säkerställa enkel användning av mjukvaruverktyget

    P-dokumentation av PS bestämmer sammansättningen av användardokumentationen

    I den föregående föreläsningen övervägdes redan tillhandahållandet av två av de fem kvalitetsprimitiv (stabilitet och säkerhet) som bestämmer användarvänligheten för PS.

    P-dokumentation och informativitet avgör sammansättningen och kvaliteten på användardokumentationen (se nästa föreläsning).

    Kommunikation säkerställs genom skapandet av en lämplig användargränssnitt och motsvarande undantagshantering. Vad är problemet här?

96. 12.3. Säkerställa programvarans effektivitet.

97. Effektiviteten hos PS säkerställs genom att fatta lämpliga beslut i olika stadier av dess utveckling, med början i utvecklingen av dess arkitektur. Valet av datastruktur och presentation påverkar effektiviteten hos PS särskilt starkt (särskilt när det gäller minne). Men valet av algoritmer som används i vissa programvarumoduler, såväl som funktionerna i deras implementering (inklusive valet av programmeringsspråk) kan avsevärt påverka effektiviteten av PS. Samtidigt måste man ständigt lösa motsättningen mellan tidsmässig effektivitet och effektivitet från minnet. Därför är det mycket viktigt att kvalitetsspecifikationen uttryckligen anger det kvantitativa sambandet mellan indikatorerna för dessa kvalitetsprimitiver, eller åtminstone sätter kvantitativa gränser för en av dessa indikatorer. Och ändå har olika programvarumoduler olika effekt på effektiviteten hos PS som helhet: både när det gäller deras bidrag till de totala kostnaderna för PS i termer av tid och minne, och i termer av inverkan på olika kvalitetsprimitiver (vissa moduler kan starkt påverka uppnåendet av tidseffektivitet och praktiskt taget inte påverka minneseffektiviteten, medan andra avsevärt kan påverka den totala minnesförbrukningen utan att nämnvärt påverka driftstiden för PS). Dessutom kan denna effekt (främst i termer av tidseffektivitet) i förväg (innan genomförandet av PS slutförts) inte alltid bedömas korrekt.

    först måste du utveckla en pålitlig PS, och först därefter uppnå dess erforderliga effektivitet i enlighet med kvalitetsspecifikationen för denna PS;

    för att förbättra effektiviteten hos PS, använd först och främst en optimerande kompilator - detta kan ge den nödvändiga effektiviteten;

    om den uppnådda effektiviteten för PS inte uppfyller specifikationen för dess kvalitet, hitta de mest kritiska modulerna när det gäller den erforderliga effektiviteten för PS (i fallet med tidsmässig effektivitet kommer detta att kräva att man erhåller distributionen av moduler av PS drifttid genom lämpliga mätningar under utförande av PS); dessa moduler och försök att optimera dem först genom att manuellt modifiera dem;

    optimera inte modulen om det inte krävs för att uppnå önskad effektivitet hos PS.

    12.4. Säkerställ underhåll.

    C-dokumentation, informationsinnehåll och förståelighet avgör underhållsdokumentationens sammansättning och kvalitet (se nästa föreläsning). Dessutom kan följande rekommendationer göras angående texterna till program (moduler).

    använda kommentarer i modulens text som förtydligar och förklarar egenskaperna hos de beslut som fattas; om möjligt, inkludera kommentarer (åtminstone i kort form) i det tidigaste skedet av utvecklingen av modulens text;

    använd meningsfulla (mnemoniska) och ständigt särskiljbara namn (den optimala längden på namnet är 4-12 bokstäver, siffror finns i slutet), använd inte liknande namn och nyckelord;

    var försiktig när du använder konstanter (en unik konstant måste ha en enda förekomst i modultexten: när den deklareras eller, i sista utvägen, när en variabel initieras som en konstant );

    var inte rädd för att använda valfria parenteser (parenteser är billigare än buggar ;

    placera inte mer än ett påstående per rad; för att förtydliga modulens struktur, använd extra mellanslag (indrag) i början av varje rad ;

    undvika knep d.v.s. sådana programmeringstekniker när fragment av en modul skapas, vars huvudeffekt inte är uppenbar eller dold (beslöjad), till exempel biverkningar av funktioner.

    Utökningsbarhet säkerställs genom att skapa en lämplig installatör.

    Struktureradhet och modularitet förenklar både förståelsen av programtexter och deras modifiering.

    12.5. Säkerställa rörlighet.

99. Litteratur till föreläsning 12.

100. 12.1. Ian Somerville. Mjukvaruutveckling. - Addison-Wesley Publishing Company, 1992. P.

     12.3. D. Van Tassel. Stil, utveckling, effektivitet, felsökning och testprogram. - M.: Mir, 1985. S. 8-44, 117-178.

     12.4. Programvaruanvändardokumentation/ANSI/IEEE Standard 1063-1987.

102. Föreläsning 13

104. 13.1. Dokumentation skapad under mjukvaruutvecklingsprocessen.

105. När man utvecklar en PS skapas en stor mängd olika dokumentation. Det är nödvändigt som ett sätt att överföra information mellan utvecklarna av PS, som ett sätt att hantera utvecklingen av PS, och som ett sätt att överföra till användarna den information som är nödvändig för tillämpning och underhåll av PS. Skapandet av denna dokumentation står för en stor del av kostnaden för PS.

     Denna dokumentation kan delas in i två grupper:

     PS utvecklingshanteringsdokument.

     Dokument som ingår i PS.

     PS utvecklingshanteringsdokument (processdokumentation) registrerar processerna för att utveckla och underhålla PS, tillhandahåller kommunikation inom utvecklingsteamet och mellan utvecklingsteamet och chefer (chefer) - personer som leder utvecklingen. Dessa dokument kan vara av följande typer:

     Planer, uppskattningar, scheman. Dessa dokument skapas av chefer för att förutse och hantera utvecklings- och underhållsprocesser.

     Rapporter om resursanvändning under utveckling. Skapad av chefer.

     Standarder. Dessa dokument föreskriver för utvecklare vilka principer, regler, överenskommelser de måste följa i processen för att utveckla PS. Dessa standarder kan vara antingen internationella eller nationella, eller speciellt skapade för den organisation där denna PS utvecklas.

     Arbetsdokument. Dessa är de viktigaste tekniska dokumenten som tillhandahåller kommunikation mellan utvecklare. De innehåller en fixering av idéer och problem som uppstår under utvecklingsprocessen, en beskrivning av de strategier och tillvägagångssätt som används, samt fungerande (tillfälliga) versioner av dokument som bör ingå i PS.

     Anteckningar och korrespondens. Dessa dokument fångar olika detaljer om interaktionen mellan chefer och utvecklare.

     Dokumenten som ingår i PS (produktdokumentation) beskriver PS-programmen både ur synvinkeln av deras användning av användare och ur synvinkeln för deras utvecklare och underhållare (i enlighet med syftet med PS). Det bör noteras här att dessa dokument kommer att användas inte bara i driftstadiet av PS (i dess tillämpnings- och underhållsfaser), utan också vid utvecklingsstadiet för att hantera utvecklingsprocessen (tillsammans med arbetsdokument) - i alla fall bör de kontrolleras (testas) för överensstämmelse med PS-program. Dessa dokument utgör två uppsättningar med olika syften:

     PS användardokumentation (P-dokumentation).

     Dokumentation för stöd av PS (C-dokumentation).

107. 13.2. Programvaruanvändardokumentation.

108. Användardokumentationen för PS (användardokumentation) förklarar för användarna hur de måste gå tillväga för att tillämpa denna PS. Det är nödvändigt om PS involverar någon interaktion med användare. Sådan dokumentation inkluderar dokument som vägleder användaren vid installation av PS (vid installation av PS med lämplig inställning för miljön för användning av PS), när PS används för att lösa sina problem och vid hantering av PS (till exempel när denna PS interagerar med andra system). Dessa dokument täcker delvis frågorna om mjukvarustöd, men behandlar inte frågor som rör modifiering av program.

     I detta avseende bör två kategorier av PS-användare särskiljas: vanliga PS-användare och PS-administratörer. En vanlig användare av PS (slutanvändare) använder PS för att lösa sina problem (inom sitt ämnesområde). Det kan vara en ingenjör som designar en teknisk anordning eller en kassörska som säljer tågbiljetter med hjälp av en PS. Han kanske inte känner till många detaljer om datordrift eller programmeringsprinciper. PS-administratören (systemadministratören) hanterar användningen av PS av vanliga användare och tillhandahåller support för PS som inte är relaterad till modifiering av program. Till exempel kan det reglera åtkomsträttigheterna till OS mellan vanliga användare, kommunicera med OS-leverantörerna eller utföra vissa åtgärder för att hålla OS i funktionsdugligt skick om det ingår som en del av ett annat system.

     Sammansättningen av användardokumentationen beror på målgruppen för användare som denna PS riktar sig till och på hur dokumenten används. Publiken här förstås som kontingenten av användare av PS, som har ett behov av viss användardokumentation av PS. Ett framgångsrikt användardokument beror i huvudsak på den exakta definitionen av den målgrupp som det är avsett för. Användardokumentationen bör innehålla den information som krävs för varje publik. Användningssättet för ett dokument avser det sätt på vilket dokumentet används. Vanligtvis kräver användaren av tillräckligt stora programvarusystem antingen dokument för att studera PS (använd i instruktioner), eller för att förtydliga viss information (använd som referens).

     I enlighet med verken kan följande sammansättning av användardokumentation för tillräckligt stor PS anses vara typisk:

     Allmän funktionsbeskrivning av PS. Ger en kort beskrivning av PS:ns funktionalitet. Den är avsedd för användare som måste bestämma hur mycket de behöver denna PS.

     PS Installationsguide. Designad för systemadministratörer. Den bör i detalj beskriva hur man installerar system i en viss miljö. Den ska innehålla en beskrivning av det maskinläsbara medium på vilket MS tillhandahålls, filerna som representerar MS och kraven för minimikonfigurationen av hårdvaran.

     Instruktioner för användning av PS. Designad för vanliga användare. Innehåller nödvändig information om tillämpningen av PS, organiserad i en form som är lämplig för dess studie.

     Referensbok om tillämpningen av PS. Designad för vanliga användare. Innehåller nödvändig information om tillämpningen av PS, organiserad i en form som är bekväm för selektiv sökning av individuella detaljer.

     PS Management Guide. Designad för systemadministratörer. Den bör beskriva de meddelanden som genereras när MS interagerar med andra system och hur man svarar på dessa meddelanden. Dessutom, om MS använder systemhårdvara, kan detta dokument förklara hur man underhåller den hårdvaran.

     Som tidigare nämnts (se föreläsning 4) börjar utvecklingen av användardokumentation direkt efter att en extern beskrivning skapats. Kvaliteten på denna dokumentation kan avsevärt avgöra framgången för en PS. Det borde vara ganska enkelt och användarvänligt (annars var denna PS i allmänhet inte värd att skapa). Därför, även om utkastversioner (utkast) av användardokument skapas av huvudutvecklarna av PS, är professionella tekniska skribenter ofta involverade i skapandet av deras slutliga versioner. För att säkerställa kvaliteten på användardokumentationen har dessutom ett antal standarder utvecklats (se t.ex.), som föreskriver tillvägagångssättet för att utveckla denna dokumentation, formulerar krav för varje typ av användardokument och bestämmer deras struktur och innehåll. .

     13.3. Underhållsdokumentation för programvara.

     Dokumentation för underhåll av PS (systemdokumentation) beskriver PS ur dess utvecklingssynpunkt. Denna dokumentation är nödvändig om PS innefattar studiet av hur det är arrangerat (designat) och moderniseringen av dess program. Som nämnts är underhåll en pågående utveckling. Därför, om det är nödvändigt att uppgradera PS, är ett speciellt team av medföljande utvecklare involverat i detta arbete. Detta team kommer att behöva hantera samma dokumentation som avgjorde aktiviteterna för teamet av initiala (huvud)utvecklare av PS, med den enda skillnaden är att denna dokumentation som regel kommer att vara någon annans för underhållarutvecklingsteamet ( det skapades av ett annat team). Underhållsteamet kommer att behöva studera denna dokumentation för att förstå strukturen och utvecklingsprocessen för den uppgraderade PS:n och göra nödvändiga ändringar i denna dokumentation, och i stor utsträckning upprepa de tekniska processer genom vilka den ursprungliga PS skapades.

     Dokumentation om stöd för PS kan delas in i två grupper:

     (1) dokumentation som definierar strukturen för program och datastrukturer för PS och tekniken för deras utveckling;

     (2) dokumentation för att göra ändringar i PS.

     Dokumentationen för den första gruppen innehåller de slutliga dokumenten för varje tekniskt stadium i utvecklingen av PS. Den innehåller följande dokument:

     Extern beskrivning av PS (kravdokument).

     Beskrivning av systemarkitekturen för PS, inklusive den externa specifikationen för vart och ett av dess program.

     För varje PS-program, en beskrivning av dess modulära struktur, inklusive en extern specifikation för varje modul som ingår i det.

     För varje modul - dess specifikation och beskrivning av dess struktur (designbeskrivning).

     Modultexter på valt programmeringsspråk (programkällkodslistor).

     OS-valideringsdokument som beskriver hur giltigheten för varje OS-program fastställdes och hur valideringsinformationen associerades med kraven för OS.

     Programvaruverifieringsdokument inkluderar i första hand testdokumentation (testdesign och beskrivning av testsviten), men kan också inkludera resultaten av andra typer av programvaruvalidering, såsom bevis på programegenskaper.

     Dokumentationen för den andra gruppen innehåller

     Systemunderhållsguiden, som beskriver kända problem tillsammans med mjukvaran, beskriver vilka delar av systemet som är hård- och mjukvaruberoende samt hur utvecklingen av mjukvaran beaktas i dess struktur (design).

     Ett vanligt underhållsproblem för en PS är att se till att alla dess representationer håller takt (förblir konsekventa) när PS ändras. För att underlätta detta måste relationer och beroenden mellan dokument och deras delar fångas in.

110. Litteratur till föreläsning 13.

111. 13.1. Ian Somerville. Mjukvaruutveckling. - Addison-Wesley Publishing Company, 1992. P.

     13.2. ANSI/IEEE Std 1063-1988, IEEE-standard för användardokumentation för programvara.

     13.3. ANSI/IEEE Std 830-1984, IEEE Guide för programvarukravspecifikation.

     13.4. ANSI/IEEE Std 1016-1987, IEEE Rekommenderad praxis för Software Design Description.

     13.5. ANSI/IEEE Std 1008-1987, IEEE-standard för testning av mjukvaruenhet.

     13.6. ANSI/IEEE Std 1012-1986, IEEE Standard för programvaruverifiering och valideringsplaner.

     13.7. ANSI/IEEE Std 983-1986, IEEE Guide for Software Quality Assurance Planning.

     13.8. ANSI/IEEE Std 829-1983, IEEE-standard för mjukvarutestdokumentation.

113. Föreläsning 14

114. Utnämning av mjukvarucertifiering. Testning och utvärdering av mjukvarukvalitet. Typer av tester och metoder för att bedöma programvarans kvalitet.

116. 14.1. Utnämning av mjukvarucertifiering.

117. PS-certifiering är en auktoritativ bekräftelse på kvaliteten på PS. Vanligtvis skapas en representativ (attestering) kommission för certifiering av ett mjukvarusystem, bestående av experter, representanter för kunden och representanter för utvecklaren. Denna kommission genomför tester av PS för att få nödvändig information för att bedöma dess kvalitet. Under testet av PS menar vi processen att utföra en uppsättning åtgärder som undersöker PS:ns lämplighet för dess framgångsrika drift (applikation och underhåll) i enlighet med kundens krav. Detta komplex inkluderar att kontrollera fullständigheten och noggrannheten hos programvarudokumentationen, studera och diskutera dess övriga egenskaper, såväl som nödvändiga tester av programmen som ingår i mjukvarupaketet, och i synnerhet dessa programs överensstämmelse med tillgänglig dokumentation.

     Baserat på den information som erhållits under testningen av PS:en måste det först och främst fastställas att PS:en utför de deklarerade funktionerna, och det måste också fastställas i vilken utsträckning PS:en har de deklarerade primitiverna och kvalitetskriterierna. Således är bedömningen av kvaliteten på PS det huvudsakliga innehållet i certifieringsprocessen. Bedömningen av kvaliteten på PS registreras i det relevanta beslutet från attestationskommissionen.

119. 14.2. Typer av mjukvarutestning.

120. Följande typer av PS-tester är kända, utförda i syfte att certifiera PS:

     PS-komponenttestning;

     systemtester;

     acceptanstest;

     fältförsök;

     industriella tester.

     PS-komponenttestning är en verifiering (testning) av funktionsdugligheten hos enskilda delsystem i PS. De hålls endast i undantagsfall genom särskilt beslut av attestnämnden.

     Systemtestning av PS är en kontroll (testning) av funktionaliteten hos PS som helhet. Det kan innehålla samma typer av testning som i den komplexa felsökningen av PS (se föreläsning 10). Det utförs genom beslut av attestationskommissionen, om det finns tvivel om kvaliteten på felsökningen av utvecklarna av PS.

     Acceptanstest är den huvudsakliga typen av test för certifiering av PS. Det är med dessa tester som certifieringskommissionen börjar sitt arbete. Dessa tester börjar med att studera den inlämnade dokumentationen, inklusive dokumentation om testning och felsökning av PS. Om dokumentationen inte innehåller tillräckligt fullständiga resultat av mjukvarutestning kan certifieringskommittén besluta att genomföra systemtestning av programvaran eller att avsluta certifieringsprocessen med en rekommendation till utvecklaren att genomföra ytterligare (mer fullständig) testning av programvaran. Dessutom, under dessa tester, kan utvecklartester selektivt hoppas över, liksom användarkontrolluppgifter (se föreläsning 10) och ytterligare tester som utarbetats av kommissionen för att bedöma kvaliteten på den certifierade PS.

     Fälttestning av PS är en demonstration av PS tillsammans med det tekniska systemet som styrs av denna PS för en smal krets av kunder under verkliga förhållanden, och PS:s beteende övervakas noggrant. Kunderna ska ges möjlighet att sätta sina egna testfall, i synnerhet från utgångar till kritiska driftssätt för det tekniska systemet, såväl som med anropet av nödsituationer i det. Dessa är ytterligare tester som utförs av attesteringskommissionens beslut endast för vissa PS:er som kontrollerar vissa tekniska system.

     Industriell testning av PS är processen att överföra PS till permanent drift till användarna. Det är en period av provdrift av PS (se föreläsning 10) av användare med insamling av information om PS:s beteende och dess funktionella egenskaper. Dessa är de slutliga testerna av PS, som utförs av attestationskommissionens beslut, om otillräckligt fullständig eller tillförlitlig information erhölls under de tidigare testerna för att bedöma kvaliteten på den certifierade PS.

122. 14.3. Metoder för att bedöma programvarans kvalitet.

123. Utvärderingen av kvaliteten på PS för vart och ett av kriterierna reduceras till utvärderingen av var och en av de primitiver som är associerade med detta kriterium för kvaliteten på PS, i enlighet med deras specifikation, som görs i kvalitetsspecifikationen för denna PS. Metoder för att utvärdera PS-kvalitetsprimitiver kan delas in i fyra grupper:

     direkt mätning av primitiva kvalitetsindikatorer;

     bearbetningsprogram och dokumentation av PS med speciella mjukvaruverktyg (processorer);

     testning av PS-program;

     expertutvärdering baserad på studier av program och dokumentation av PS.

     Direkt mätning av primitiva kvalitetsindikatorer utförs genom att räkna antalet händelser i ett visst programdokument av karakteristiska enheter, objekt, strukturer etc., samt genom att mäta drifttiden för olika enheter och volym använt minne dator när testfall utförs. Till exempel kan ett mått på minneseffektivitet vara antalet rader i ett program i ett programmeringsspråk, och ett mått på tidseffektivitet kan vara svarstiden på en fråga. Användningen av alla indikatorer för kvalitetsprimitiver kan definieras i MS:s kvalitetsspecifikation. Metoden för direkt mätning av primitiva kvalitetsindikatorer kan kombineras med användning av programtestning.

     Vissa mjukvaruverktyg kan användas för att avgöra om en MS har vissa kvalitetsprimitiver. Sådana mjukvaruverktyg bearbetar programtexter eller mjukvarudokumentation för att kontrollera eventuella kvalitetsprimitiver eller få några indikatorer på dessa kvalitetsprimitiver. För att bedöma struktureringen av PS-program, om de var programmerade i en lämplig strukturell dialekt av basprogrammeringsspråket, skulle det räcka att skicka dem genom en strukturerad programomvandlare som utför syntaktisk och viss semantisk kontroll av denna dialekt och översätter texterna i dessa program till basöversättarens inmatningsspråk. Men bara ett litet antal kvalitetsprimitiver kan för närvarande kontrolleras på detta sätt, och även då i sällsynta fall. I vissa fall, istället för mjukvaruverktyg som kontrollerar kvaliteten på programvaran, är det mer användbart att använda verktyg som transformerar presentationen av program eller programdokumentation. En sådan är till exempel en programformaterare som för programtexter till en läsbar form - bearbetning av texter i PS-program med ett sådant verktyg kan automatiskt säkerställa att PS har en lämplig kvalitetsprimitiv.

     Testning används för att utvärdera vissa primitiver av PS-kvalitet. Sådana primitiver inkluderar i första hand PS:ns fullständighet, såväl som dess noggrannhet, stabilitet, säkerhet och andra kvalitetsprimitiver. I vissa fall används testning i kombination med andra metoder för att utvärdera individuella PS-kvalitetsprimitiver. Så för att bedöma kvaliteten på dokumentationen om användningen av PS (P-dokumentation) används testning i kombination med en expertbedömning av denna dokumentation. Om en tillräckligt fullständig testning utfördes under den komplexa felsökningen av PS, kan samma tester användas under certifieringen av PS. I det här fallet kan certifieringskommittén använda de testprotokoll som utförs under komplex felsökning. Men även i det här fallet är det nödvändigt att utföra några nya tester eller åtminstone köra om några av de gamla. Om testning under komplex felsökning visar sig vara otillräckligt komplett, är det nödvändigt att utföra mer fullständig testning. I det här fallet kan ett beslut fattas om att utföra komponenttester eller systemtester av PS, samt att returnera PS till utvecklare för revision. Det är mycket viktigt att för att utvärdera PS enligt kriteriet för användarvänlighet (under felsökning och certifiering av PS) utförs fullständig testning på tester som är förberedda på basis av dokumentationen för applikationen, och enligt till underhållskriteriet - på tester förberedda för vart och ett av de dokument som föreslås för underhåll PS.

     För att bedöma majoriteten av PS-kvalitetsprimitiven kan för närvarande endast metoden för expertbedömningar användas. Denna metod består av följande: en grupp experter utses, var och en av dessa experter, som ett resultat av att studera den inlämnade dokumentationen, gör sin åsikt om innehavet av PS av den erforderliga kvalitetsprimitiv, och sedan bedömningen av den nödvändiga kvalitet primitiv av PS etableras genom omröstning av medlemmarna i denna grupp. Denna bedömning kan göras både på ett tvåpunktssystem ("besittar" - "har inte") och ta hänsyn till graden av innehav av PS av denna kvalitetsprimitiva (till exempel kan den göras på en femma -poängsystem). Samtidigt bör expertgruppen vägledas av specifikationen av denna primitiva och en indikation på metoden för dess bedömning, formulerad i kvalitetsspecifikationen för den certifierade PS.

     Litteratur till föreläsning 14.

     14.2. V.V. Lipaev. Programtestning. - M.: Radio och kommunikation, 1986. - S. 231-245.

     14.3. D. Van Tassel. Stil, utveckling, effektivitet, felsökning och testprogram. - M.: Mir, 1985. - S. 281-283.

     14.4. B. Schneiderman. Programmeringspsykologi. - M.: Radio och kommunikation, 1984. - S. 99-127.

125. Föreläsning 15. Objektsmetod för mjukvaruutveckling

127. 15.1. Objekt och relationer i programmering. Kärnan i objektstrategin för mjukvaruutveckling.

128. Världen omkring oss består av föremål och relationer mellan dem. Ett objekt förkroppsligar någon entitet och har något tillstånd som kan förändras över tiden som ett resultat av påverkan av andra objekt som på något sätt är med data. Den kan ha en intern struktur: den kan bestå av andra föremål som också står i någon relation med varandra. Med utgångspunkt från detta är det möjligt att bygga en hierarkisk struktur av världen från objekt. Men för varje specifik övervägande av världen omkring oss anses vissa objekt vara odelbara ("punkt"), och beroende på hänsynsmålen kan sådana (odelbara) objekt av olika nivåer av hierarki accepteras. En relation förbinder vissa objekt: vi kan anse att föreningen av dessa objekt har en viss egenskap. Om en relation förbinder n objekt, så kallas en sådan relation n-plats (n-är). På varje plats för förening av objekt som kan kopplas samman med någon specifik relation, kan det finnas olika objekt, men ganska bestämda (i det här fallet säger de: objekt av en viss klass). En enplatsrelation kallas en egenskap hos ett objekt (motsvarande klass). Tillståndet för ett objekt kan studeras av värdet av egenskaperna hos detta objekt eller implicit av värdet av egenskaperna hos föreningarna av objekt kopplade till en given en eller annan relation.

     I processen att känna till eller förändra världen omkring oss tar vi alltid hänsyn till en eller annan förenklad modell av världen (modellvärld), där vi inkluderar några av objekten och några av relationerna i världen omkring oss och, som regel en nivå av hierarki. Varje objekt som har en intern struktur kan representera sin egen modellvärld, inklusive objekten i denna struktur och de relationer som binder dem. Således kan världen omkring oss betraktas (i viss approximation) som en hierarkisk struktur av modellvärldar.

     För närvarande, i processen att lära sig eller förändra världen omkring oss, används datorteknik i stor utsträckning för att bearbeta olika typer av information. I detta avseende används en dator (information) representation av objekt och relationer. Varje objekt kan representeras informellt av någon datastruktur som visar dess tillstånd. Egenskaperna för detta objekt kan ställas in direkt som separata komponenter i denna struktur, eller av speciella funktioner på denna datastruktur. N-ära relationer för N>1 kan representeras antingen i aktiv form eller i passiv form. I sin aktiva form representeras en N-platsrelation av något programfragment som implementerar antingen en N-platsfunktion (bestämmer värdet på egenskapen för motsvarande förening av objekt) eller en procedur som ändrar tillstånden för några av dem baserat på på tillståndet för representationer av objekt kopplade till den representerade relationen. I en passiv form kan en sådan relation representeras av en viss datastruktur (som kan innefatta representationer av objekt kopplade till denna relation), tolkad utifrån accepterade överenskommelser om allmänna förfaranden som är oberoende av specifika relationer (till exempel en relationsdatabas). I båda fallen definierar representationen av relationen vissa databehandlingsaktiviteter.

     När man utforskar modellvärlden kan användaren ta emot (eller vilja ta emot) information från datorn på olika sätt. I ett tillvägagångssätt kan han vara intresserad av att få information om de individuella egenskaperna hos föremålen som är av intresse för honom eller resultatet av någon interaktion mellan vissa föremål. För att göra detta beordrar han utvecklingen av en eller annan PS som utför de funktioner som är av intresse för honom, eller något informationssystem som kan utfärda information om relationerna av intresse för honom, med hjälp av lämplig databas. Under den inledande perioden av utvecklingen av datorteknik (med inte tillräckligt hög effekt av datorer) var ett sådant tillvägagångssätt för användningen av datorer ganska naturligt. Det var han som provocerade fram det funktionella (relationella) förhållningssättet till utvecklingen av PS, som diskuterades i detalj i tidigare föreläsningar. Kärnan i detta tillvägagångssätt är den systematiska användningen av nedbrytningen av funktioner (relationer) för att bygga strukturen för PS och programtexterna som ingår i den. Samtidigt presenterades själva objekten, på vilka de beställda och implementerade funktionerna tillämpades, fragmentariskt (i den utsträckning det var nödvändigt för att utföra dessa funktioner) och i en form som var lämplig för implementeringen av dessa funktioner. Således tillhandahölls inte en fullständig och adekvat datorrepresentation av modellvärlden av intresse för användaren: att visa den på den använda PS:en kan visa sig vara en ganska mödosam uppgift för användaren, ett försök att något utöka volymen och karaktären av information om modellvärlden av intresse för användaren. från en sådan transformatorstation kan leda till en allvarlig modernisering. Detta tillvägagångssätt för utvecklingen av PS stöds av de flesta av de använda programmeringsspråk, allt från assemblerspråk och procedurspråk (FORTRAN, Pascal) till funktionella språk (LISP) och logiska programmeringsspråk (PROLOG).

     Med ett annat tillvägagångssätt för studiet av modellvärlden med hjälp av en dator, kan användaren vara intresserad av att observera förändringen i objektens tillstånd som ett resultat av deras interaktioner. Detta kräver en ganska solid representation i datorn av objektet av intresse för användaren, och programvarukomponenterna som implementerar relationerna som detta objekt deltar i är explicit associerade med det. För att implementera detta tillvägagångssätt var det nödvändigt att bygga mjukvaruverktyg som simulerar processerna för interaktion mellan objekt (modellvärlden). Med hjälp av traditionella utvecklingsverktyg visade sig detta vara en ganska mödosam uppgift. Visserligen har det dykt upp programmeringsspråk som är specifikt inriktade på sådan modellering, men detta förenklade bara delvis uppgiften att utveckla den nödvändiga PS. Den mest kompletta lösningen på detta problem är objektets inställning till utvecklingen av PS. Dess väsen ligger i den systematiska användningen av nedbrytningen av objekt i konstruktionen av strukturen för PS och texterna i program som ingår i den. Samtidigt uttrycktes funktionerna (relationerna) som utfördes av en sådan PS genom relationerna mellan objekt på olika nivåer, d.v.s. deras nedbrytning berodde väsentligt på nedbrytningen av föremål.

     På tal om objektsmetod bör man också tydligt förstå vilken typ av objekt i fråga: objekt av användarens modellvärld, om deras informationsrepresentation, om programobjekten, med hjälp av vilka PS:n byggs. Dessutom bör man skilja mellan de faktiska objekten ("passiva" objekten) och subjekten ("aktiva" objekten).

130. 15.2. Objekt och ämnen i programmering.

132. 15.3. Objektiva och subjektiva förhållningssätt till mjukvaruutveckling.

133. Descartes noterade att människor vanligtvis har en objektorienterad syn på världen (c).

     De tror att objektorienterad design bygger på principerna om:

     lyfta fram abstraktioner,

     Åtkomstbegränsning,

     modularitet,

     hierarki,

     skriver,

     parallellitet,

     hållbarhet.

     Men allt detta kan tillämpas i ett funktionellt tillvägagångssätt.

     Det är nödvändigt att skilja mellan fördelarna och nackdelarna med den allmänna objektsstrategin och dess speciella fall - den ämnesorienterade strategin.

     Fördelar med det allmänna objektiva tillvägagångssättet:

     Naturlig kartläggning av den verkliga världen på PS-strukturen (naturlig mänsklig uppfattning om PS-kapaciteten, inget behov av att "uppfinna" PS-strukturen, utan använd naturliga analogier).

     Användningen av tillräckligt meningsfulla strukturella enheter i PS (ett objekt som integriteten hos icke-redundanta föreningar, informationsstarka moduler).

     Att minska komplexiteten i mjukvaruutveckling genom att använda en ny nivå av abstraktioner (med hjälp av en hierarki av "icke-program" abstraktioner i utvecklingen av mjukvara: klassificering av verkliga objekt, metoden för analogier i naturen) som en ny nivå av arv.

135. 15.4. En objektsmetod för utveckling av en extern beskrivning och mjukvaruarkitektur.

136. Objektorienterad design är en metod som använder objektnedbrytning; objektorienterat tillvägagångssätt har sitt eget system symboler och erbjuder en rik uppsättning logiska och fysiska modeller för att designa mycket komplexa system. .

     Den objektorienterade analysen (OOA) återgav objektmetoden. OOA syftar till att skapa modeller som ligger närmare verkligheten med hjälp av ett objektorienterat tillvägagångssätt; det är en metodik där krav ställs utifrån begreppen klasser och objekt som utgör ämnesområdets vokabulär. .

     Funktioner i objektorienterad programmering.

     Objekt, klasser, objektbeteende, egenskaper, händelser.

138. Litteratur till föreläsning 15.

139. 15.1. K. Futi, N. Suzuki. Programmeringsspråk och VLSI-kretsar. - M.: Mir, 1988. S. 85-98.

     15.2. Ian Somerville. Mjukvaruutveckling. - Addison-Wesley Publishing Company, 1992. P. ?-?

     15.3. G. Butch. Objektorienterad design med exempel på tillämpning: per. från engelska. - M.: Concord, 1992.

     15.4. V.Sh.Kaufman. Programmeringsspråk. Koncept och principer. Moskva: Radio och kommunikation, 1993.

UTBILDNINGSMINISTERIET

DONETSK FOLKREPUBLIKEN

STAT PROFESSIONELL

LÄROANSTALT

"DONETSK INDUSTRIAL AND ECONOMIC COLEGE"

ARBETSPROGRAM

Pedagogisk praktik UP.01

yrkesmodul PM.01 Utveckling av mjukvarumoduler för datorsystem

specialitet 09.02.03 "Programmering i datorsystem"

Sammanställd av:

Volkov Vladimir Aleksandrovich, lärare i datordiscipliner i kvalifikationskategorin "specialist av högsta kategori", statlig utbildningsinstitution "Donetsk Industrial and Economic College"

Programmet är godkänt av: Vovk Pavel Andreevich, chef för "Smart IT Service"

1. PASS FÖR ÖVNINGSPROGRAMMET
2. RESULTAT AV ÖVNING
3. STRUKTUR OCH INNEHÅLL I PRAKTIKEN
4. VILLKOR FÖR ORGANISERING OCH UTFÖRANDE AV ÖVNING
5. ÖVERVAKNING OCH UTVÄRDERING AV ÖVNINGSRESULTAT

1 PASS PÅ UTBILDNINGSPROGRAMMET UPP. 01

1.1 Utbildningsplats UP.01

Programmet för utbildningspraktik UP.01 av den professionella modulen PM.01 "Utveckling av mjukvarumoduler för datorsystem" specialitet 09.02.03 "Programmering i datorsystem » utökad grupp 09.00.00 "Datavetenskap och datateknik", när det gäller att behärska huvudtypen av yrkesverksamhet (VPD):

Utveckling av mjukvarumoduler för datorsystem och relaterade yrkeskompetenser (PC):

	Utför utveckling av specifikationer för enskilda komponenter.
	Genomför utveckling av mjukvaruproduktkod baserad på färdiga specifikationer på modulnivå.
	Utför felsökning av programmoduler med hjälp av specialiserade mjukvaruverktyg.
	Utför testning av mjukvarumoduler.
	För att optimera modulens programkod.
	Utveckla design- och tekniska dokumentationskomponenter med hjälp av grafiska specifikationsspråk.

Programmet för utbildningspraktik UP.01 i den professionella modulen PM.01 "Utveckling av mjukvarumoduler för datorsystem" kan användas i ytterligare professionell utbildning och yrkesutbildning av anställda för specialiteter 09.02.03 Programmering i datorsystem med en sekundär ( fullständig) allmän utbildning. Arbetslivserfarenhet krävs inte.

1.2 Mål och målpedagogisk praktik UP.01

För att bemästra den angivna typen av yrkesverksamhet och relevanta yrkeskompetenser måste studenten under utbildningspraktiken UP.01:

har praktisk erfarenhet:

utveckling av algoritmen för uppgiften och dess implementering med hjälp av datorstödd design;

utveckling av en programvaruproduktkod baserad på en färdig specifikation på modulnivå;

användning av verktyg i skedet av felsökning av en mjukvaruprodukt;

testa en mjukvarumodul enligt ett specifikt scenario;

kunna:

utföra utvecklingen av programmodulkoden i moderna programmeringsspråk;

skapa ett program enligt den utvecklade algoritmen som en separat modul;

felsöka och testa programmet på modulnivå;

upprätta programvarudokumentation;

använda verktyg för att automatisera utarbetandet av dokumentation;

känna till:

huvudstadier av mjukvaruutveckling;

grundläggande principer för strukturell och objektorienterad programmeringsteknik;

grundläggande principer för felsökning och testning av mjukvaruprodukter;

metoder och medel för att utveckla teknisk dokumentation.

1.3 Antal veckor(timmar) för utvecklingen av programmetpedagogisk praktik UP.01

Bara 1,5 vecka, 54 timmar.

2 RESULTAT AV ÖVNING

Resultatet av den pedagogiska praktiken UP.01 av yrkesmodulen PM.01 "Utveckling av mjukvarumoduler för datorsystem" är utvecklingen av generella kompetenser (OK):

	Namn på övningsresultatet
	-
OK 2. Organisera sina egna aktiviteter, välj standardmetoder och metoder för att utföra professionella uppgifter, utvärdera deras effektivitet och kvalitet.
OK 3. Ta beslut i vanliga och icke-standardiserade situationer och ta ansvar för dem.
OK 4. Sök och använd den information som behövs för ett effektivt genomförande av professionella uppgifter, professionell och personlig utveckling.
OK 5. Använd informations- och kommunikationsteknik i yrkesverksamhet.
OK 6. Arbeta i ett team och i ett team, kommunicera effektivt med kollegor, ledning, konsumenter.
OK 7. Ta ansvar för teammedlemmarnas (underordnade) arbete för resultatet av att slutföra uppgifter.	-
	kvalifikationer
OK 9. Navigera i förhållanden med frekventa förändringar av teknik i yrkesverksamhet.

professionella kompetenser (PC):

Typ av yrkesverksamhet		Namn på övningsresultat
Att bemästra den huvudsakliga typen av yrkesverksamhet		användning av resurser från lokala och globala datornät; hantering av datafiler på lokala, flyttbara lagringsenheter, såväl som på diskar i ett lokalt datornätverk och på Internet; utskrift, replikering och kopiering av dokument på en skrivare och annan kontorsutrustning. löpande kontroll i form av en rapport över varje praktiskt arbete. modulkvalificerande prov.
		läskunnighet och noggrannhet i arbetet i applikationsprogram: text- och grafikredigerare, databaser, presentationsredigerare; hastigheten för att söka information i innehållet i databaser.
		noggrannhet och läskunnighet för e-postinställningar, server- och klientprogramvara: hastigheten för informationssökning med hjälp av teknik och tjänster på Internet; noggrannhet och läskunnighet för inmatning och överföring av information med hjälp av Internettekniker och tjänster.
		läskunnighet i användningen av metoder och medel för att skydda information från obehörig åtkomst; korrekthet och noggrannhet Reserv exemplar och dataåterställning;
		läskunnighet och noggrannhet i att arbeta med filsystem, olika filformat, filhanteringsprogram;
		underhåll av rapporter och teknisk dokumentation.

3 PROGRAMMETS STRUKTUR OCH INNEHÅLLTRÄNING ÖVNING UPP.01

3.1 Tematisk plan

Koder för genererade kompetenser	Namn på yrkesmodulen	Tidens omfattning, tilldelas praktik (om veckor, timmar)	Datum
PC 1.1 - PC 1.6	PM.01 "Utveckling av mjukvarumoduler för datorsystem"	1,5 vecka 54 timmar

3.2 Öva innehåll

Aktiviteter	Typer av jobb		Namn på akademiska discipliner, tvärvetenskapliga kurser som anger ämnen, säkerställa utförandet av typer av arbete	Antal timmar (veckor)
"Bemästra huvudtypen av yrkesverksamhet »	Ämne 1. Introduktion. Algoritmer för att lösa problem. Strukturera linjär algoritm. Strukturera cyklisk algoritm. Algoritm för en subrutin (funktion).	Bildade kunskap om grunderna för att skapa speciella föremål
	Ämne2 . Miljö Skratch (Scratch).	Formad kunskap om grunderna i processautomatiseringsverktyg Formad kunskap om grunderna för animeringseffekter till objekt; användning av hyperlänkar och knappar; demo inställning; presentationer sparade i olika format.	MDK.01.01 "Systemprogrammering"
	Ämne 3 . Skapa ett träningsprogram (läxa från ämnet).	Bildade kunskaper om grunderna i dataanalys med hjälp av processorfunktioner	MDK.01.02 "Tillämpad programmering"
	Ämne 4. Utveckling av spelprogram.	Bildade kunskaper om grunderna för att beräkna de slutliga egenskaperna	MDK.01.01 "Systemprogrammering"
	Ämne 5. Grafiskt programmeringsspråk LabVIEW.	Bildade kunskap om grunderna för att skapa ett processortest.	MDK.01.02 "Tillämpad programmering"
	Ämne 6. Bygga en applikation med LabVIEW.	Bildade kunskaper om grunderna i användarens dialog med systemet	MDK.01.02 "Tillämpad programmering"
	Ämne 7 Återanvändning av ett fragment av programmet.	Bildade kunskap om systemets operatörer och funktioner.	MDK.01.02 "Tillämpad programmering"
	Ämne 8 Workshop om LabVIEW. Arbetsskydd vid arbete med dator på användarens arbetsplats.	Bildade kunskaper om beräkning av elementära funktioner. Bildade kunskap om arbetarskydd.	MDK.01.02 "Tillämpad programmering". OP.18 "Arbetsskydd"
	Ämne 9 Slutsatser. Sammanställa en övningsrapport.	Färdigheter i analys av datorteknik, problemlösning bildas Färdigheter bildas.	MDK.01.01 "Systemprogrammering" MDK.01.02 "Tillämpad programmering" MDK.04.01 "Kontorsprogramvara"

4 VILLKOR FÖR ORGANISATION OCH UTFÖRANDE

UTBILDNING ÖVNING UPP. 01

4.1 Dokumentationskrav, nödvändigt för praktiken:

Arbetsprogram för pedagogisk praktik UP.01 i yrkesmodulen PM.01. "Utveckling av mjukvarumoduler för datorsystem" är en del av utbildningsprogrammet för specialister på mellannivå av den statliga yrkesutbildningsinstitutionen "Donetsk Industrial and Economic College" i enlighet med den statliga utbildningsstandarden för gymnasieutbildning i specialitet 09.02.03 "Programmering i datorsystem", grundad på läroplanen i specialiteten, arbetsprogram i disciplinerna MDK.01.01 "Systemprogrammering", MDK01.02 "Tillämpad programmering", metodologiska rekommendationer för pedagogiskt och metodologiskt stöd för praktiken av studenter som behärskar utbildningsprogram för gymnasieutbildning.

4.2 Krav på utbildnings- och metodstöd för praktiken:

en lista över godkända uppgifter efter typ av arbete, riktlinjer för studenter om utförandet av arbetet, rekommendationer för implementering av praktikrapporter.

4.3 Logistikkrav:

organisationen av industriell praktik kräver närvaro av klassrum och laboratorier.

Kontorsutrustning och arbetsplatser:

platser enligt antalet elever (bord, dator, stol);

lärarens arbetsplats (bord, dator, stol);

skåp för förvaring av läromedel och informationsbärare;

uppgifter för ett individuellt förhållningssätt till lärande, organisering av självständigt arbete och övningar, en student på en dator;

referenslitteratur och metodisk litteratur;

en uppsättning system, applikationer och utbildningsprogram för PC på optiska och elektroniska medier;

tidskrift för att instruera studenter om arbetarskydd;

en uppsättning läromedel.

Tekniska träningshjälpmedel:

klassrumstavla;

persondator med licensierad programvara;

laserskrivare;

• pedagogiska datorer;

  uppsättning interaktiv utrustning (projektor, skärm, högtalare);

  brandsläckningsmedel (brandsläckare).

Utrustning av skåpet och arbetsstationer för utvecklingsverktyg: persondatorer (skärm, systemenhet, tangentbord, mus), en uppsättning pedagogisk och metodologisk dokumentation, programvara i enlighet med innehållet i disciplinen (skal av programmeringsspråk).

Alla datorer i klassen är anslutna till ett lokalt nätverk, har tillgång till nätverkslagring av information och har tillgång till Internet.

Kommunikationsutrustning:

nätverkskort;

nätverkskablar;

WiFi trådlös utrustning.

Komponenter för installation av nätverk, utrustning för installation.

4.4 Lista över pedagogiska publikationer, Internetresurser, ytterligare litteratur

Huvudsakliga källor:

Olifer V.G. Nätverksoperativsystem: en lärobok för universitet / V.G. Olifer, N.A. Olifer. - 2:a uppl. - St Petersburg: Peter, 2009,2008. - 668 s.:

E. Tanenbaum. OS. Utveckling och implementering. St Petersburg: Piter, 2006. - 568 s.

Pupkov K.A. Bemästra Unix-operativsystemet / K.A. Pupkov, A.S. Chernikov, N.M. Yakusheva. - Moskva: Radio och kommunikation, 1994. - 112 s.

L. Beck Introduktion till systemprogrammering - M.: Mir, 1988.

Grekul V.I., Denishchenko G.N., Korovkina N.L. Design av informationssystem / Moskva: Binom, 2008. - 304 s.

Lipaev, V.V. Programvaruteknik. Metodologiska grunder [Text]: Proc. / V. V. Lipaev; Stat. un-t - Högre Handelshögskolan. - M.: TEIS, 2006. - 608 sid.

Lavrishcheva E. M., Petrukhin V. A. Metoder och medel för mjukvaruutveckling. - Lärobok

Ian Somerville. Programvaruteknik, 6:e upplagan.: Per. från engelska. -M. : Williams Publishing House, 2002.—624 sid.

Excel 2010: professionell programmering i VBA.: Per. från engelska. - M.: LLC "I.D. Williams”, 2012. - 944 sid. : sjuk. - Paral. mes. engelsk

Fowler M. Refactoring: Improving Existing Code. Från engelska.—St. Petersburg: Symbol Plus, 2003.—432 sid.

Ytterligare källor:

Volkov V.A. METODOLOGISKA INSTRUKTIONER för genomförande av praktiskt arbete inom disciplinen "Systemprogrammering", Donetsk: DONPEK, 2015.

Volkov V.A. Riktlinjer till genomförandet av kursprojektet, Donetsk: DONPEC, 2015.

Internet- Resurser:

Systemprogrammering [elektronisk resurs] / Åtkomstläge: http://www.umk3.utmn.ru.

Programvara och Internetresurser: http://www.intuit.ru

Litteratur efter disciplin - http://www.internet-technologies.ru/books/

Elektronisk lärobok "Introduktion till mjukvaruteknik" - http://www.intuit.ru/studies/professional_skill_improvements/1419/info

Elektronisk lärobok "Programmeringsteknik" - http://bourabai.kz/alg/pro.htm

4.5 Krav på praktikledare från en läroanstalt och organisation

Krav för praktikledare från en utbildningsinstitution:

ingenjörs- och lärarpersonal: utexaminerade - lärare i tvärvetenskapliga kurser och allmänna yrkesdiscipliner. Erfarenhet av organisationer inom relevant yrkesområde är ett krav.

Bemästra industriell utbildning: tillgänglighet av 5–6 kvalifikationskategorier med obligatorisk praktik i specialiserade organisationer minst en gång vart tredje år. Erfarenhet av organisationer inom relevant yrkesområde är ett krav.

5 ÖVERVAKNING OCH UTVÄRDERING AV RESULTAT

UTBILDNING ÖVNING UPP. 01

Form för redovisning av pedagogisk praxis UP.01 - en redovisning av praxis, upprättad i enlighet med kraven i metodrekommendationer.

resultat (bemästrade professionella kompetenser)	Grundläggande indikatorer resultatet av förberedelserna	Former och metoder kontrollera
PC 1.1. Genomför utveckling av specifikationer för enskilda komponenter	Utveckling av en algoritm för uppgiften och dess implementering med hjälp av datorstödd design	Expertobservation och utvärdering av studentens aktiviteter i processen att bemästra utbildningsprogrammet i praktiska klasser, när man utför arbete med pedagogisk och industriell praktik.
PC 1.2. Genomför utveckling av mjukvaruproduktkod baserad på färdiga specifikationer på modulnivå.	Känna till de grundläggande principerna för strukturell och objektorienterad programmeringsteknik. Att genomföra utvecklingen av programmodulkoden i moderna programmeringsspråk.
PC 1.3. Utför felsökning av programmoduler med hjälp av specialiserade mjukvaruverktyg	Utför felsökning och testning av programmet på modulnivå.
PC 1.4. Utför testning av mjukvarumoduler.	Skapa ett program enligt den utvecklade algoritmen som en separat modul.
PC 1.5. Utför modulkodoptimering	Utveckling av en mjukvaruproduktkod baserad på en färdig specifikation på modulnivå.
PC 1.6. Utveckla design- och tekniska dokumentationskomponenter med hjälp av grafiska specifikationsspråk	Känna till metoder och medel för att utveckla teknisk dokumentation. Förbered mjukvarudokumentation. Använd verktyg för att automatisera dokumentation.

Former och metoder för att övervaka och utvärdera läranderesultat bör göra det möjligt för eleverna att kontrollera inte bara bildandet av professionella kompetenser, utan också utvecklingen av allmänna kompetenser och de färdigheter som ger dem.

resultat (behärskar generella kompetenser)	Huvudindikatorer för att utvärdera resultatet	Former och metoder för kontroll och utvärdering
OK 1. Förstå essensen och den sociala betydelsen av din framtida yrke visa ett ihållande intresse för det.	Demonstration av ständigt intresse för det framtida yrket; - giltigheten av tillämpningen av behärskad yrkeskompetens;	Expertobservation och bedömning i praktiska klasser när du utför arbete på industriell praxis;
OK 2. Organisera sina egna aktiviteter, bestämma metoder och sätt att utföra professionella uppgifter, utvärdera deras effektivitet och kvalitet.	Motivering av målsättning, urval och tillämpning av metoder och metoder för att lösa professionella problem; Genomföra självanalys och korrigering av resultatet av sitt eget arbete	Utvärdering i praktiska klasser i utförandet av arbete; Observation under praktiken; Introspektion
OK 3. Lös problem, bedöm risker och fatta beslut i icke-standardiserade situationer.	Effektiviteten av beslutsfattande av standard och icke-standardiserade professionella uppgifter under en viss tid; Effektiviteten av planen för att optimera kvaliteten på utfört arbete	Tolkning av resultaten av att övervaka studentens aktiviteter i processen att slutföra uppgifter
OK 4. Sök, analysera och utvärdera den information som behövs för att fastställa och lösa professionella problem, professionell och personlig utveckling.	Urval och analys av nödvändig information för en tydlig och snabbt utförande professionella uppgifter, professionell och personlig utveckling	Expertbedömning under arbetets gång; Självkontroll i samband med att ställa och lösa problem
OK 5. Använd informations- och kommunikationsteknik för att förbättra professionella aktiviteter.	förmåga att använda informations- och kommunikationsteknik för att lösa professionella problem	bedömning av uppdrag
OK 6. Arbeta i ett team och ett team, säkerställ dess sammanhållning, kommunicera effektivt med kollegor, ledning, konsumenter.	Förmåga att interagera med en grupp, lärare, mästare i industriell utbildning
OK 7. Sätt upp mål, motivera underordnades aktiviteter, organisera och kontrollera deras arbete med ansvar för resultatet av uppgifterna.	- självanalys och korrigering av resultatet av det egna arbetet och lagets arbete	Observation av hur arbetet fortskrider i gruppen under produktionsprocessen
OK 8. Bestäm självständigt uppgifterna för professionell och personlig utveckling, engagera sig i självutbildning, planera medvetet avancerad utbildning.	Organisation av självständigt arbete för bildandet av en kreativ och professionell bild; Organisation av arbetet med egenutbildning och förbättring kvalifikationer	Observation och utvärdering i processen för industriell praxis; Reflekterande analys (algoritm för elevhandlingar); Övningsdagbok; Studentportföljanalys
OK 9. Var beredd att förändra teknik i yrkesverksamhet.	Analys av innovationer inom området tekniska processer för utveckling och tillverkning av plagg	Utvärdering av lösningar på situationsproblem; Affärs- och organisations-pedagogiska spel; Observation och utvärdering i praktiska klasser, i produktionsprocessen