Funktionsdiagram og funktionel sammensætning af programmet. Struktureret programdesign
Emne 1.3: Systemsoftware
Emne 1.4: Servicesoftware og grundlæggende algoritmer
Introduktion til økonomisk informatik
1.3. PC system software
1.3.1. PC software struktur
Et sæt programmer designet til at løse problemer på en pc kaldes software. Sammensætningen af pc-software kaldes softwarekonfiguration.
Software kan opdeles i tre kategorier:
- systemsoftware (programmer til almindelig brug), der udfører forskellige hjælpefunktioner, såsom at oprette kopier af brugt information, give hjælpeoplysninger om computeren, kontrollere computerens funktionalitet osv.
- applikationssoftware, der giver det nødvendige arbejde på en pc: redigering af tekstdokumenter, oprettelse af tegninger eller billeder, behandling af informationsarrays mv.
- værktøjssoftware (programmeringssystemer), der sikrer udvikling af nye computerprogrammer i et programmeringssprog.
Ris. 1.
Systemsoftware
Disse programmer til almindelig brug er ikke forbundet med en specifik pc-applikation og udfører traditionelle funktioner: planlægning og opgavestyring, I/O-styring osv.
Med andre ord udfører systemprogrammer forskellige hjælpefunktioner, for eksempel at lave kopier af brugt information, give hjælpeoplysninger om computeren, kontrollere funktionaliteten af computerenheder osv.
Systemsoftware inkluderer:
- operativsystemer (dette program indlæses i RAM, når computeren er tændt);
- shell-programmer (giver en mere bekvem og visuel måde at kommunikere med en computer på end at bruge DOS-kommandolinjen, for eksempel Norton Commander);
- operationsskaller - grænsefladesystemer, der bruges til at skabe grafiske grænseflader, multiprogrammering osv.;
- Drivere (programmer designet til at styre porte til eksterne enheder, normalt indlæst i RAM, når computeren starter);
- hjælpeprogrammer (hjælpe- eller hjælpeprogrammer, der giver brugeren en række yderligere tjenester).
Hjælpeprogrammer omfatter:
- filadministratorer eller filadministratorer;
- midler til dynamisk datakomprimering (giver dig mulighed for at øge mængden af information på disken på grund af dens dynamiske komprimering);
- visnings- og afspilningsværktøjer;
- diagnostiske værktøjer; kontrolværktøjer giver dig mulighed for at kontrollere computerens konfiguration og kontrollere ydeevnen af computerenheder, primært harddiske;
- kommunikationsværktøjer (kommunikationsprogrammer) er designet til at organisere udveksling af information mellem computere;
- Computersikkerhedsværktøjer (backup, antivirussoftware).
Det skal bemærkes, at nogle af hjælpeprogrammerne er inkluderet i operativsystemet, mens den anden del fungerer autonomt. Det meste af den generelle (system)software er inkluderet i OS. Noget af den generelle software er inkluderet i selve computeren (nogle af OS-programmerne og kontroltestene er skrevet i ROM eller PROM installeret på bundkortet). Nogle af de almindelige software er selvstændige programmer og leveres separat.
Applikations software
Applikationsprogrammer kan bruges uafhængigt eller som en del af softwaresystemer eller pakker.
Applikationssoftware - programmer, der direkte gør det muligt at udføre det nødvendige arbejde på en pc: redigering af tekstdokumenter, oprettelse af tegninger eller billeder, oprettelse af regneark mv.
Applikationssoftwarepakker er et system af programmer, der efter deres anvendelsesområde er opdelt i problemorienterede pakker til generelle formål og integrerede pakker. Moderne integrerede pakker indeholder op til fem funktionelle komponenter: test- og regnearksprocessor, DBMS, grafisk editor, telekommunikationsværktøjer.
Applikationssoftware inkluderer for eksempel:
- MS OFFICE suite af kontorapplikationer.
- Regnskabssystemer.
- Finansielle analytiske systemer.
- Integrerede kontoradministrationspakker.
- CAD – systemer (computer-aided design systems).
- HTML eller web-editorer.
- Browsere er et middel til at se websider.
- Grafisk redaktør.
- Ekspertsystemer.
Værktøjssoftware
Værktøjssoftware eller programmeringssystemer er systemer til automatisering af udviklingen af nye programmer i et programmeringssprog.
I det mest generelle tilfælde, for at oprette et program i det valgte programmeringssprog (systemprogrammeringssprog), skal du have følgende komponenter:
- Teksteditor til at oprette en fil med programmets kildetekst.
- Kompiler eller tolk. Kildeteksten oversættes til mellemobjektkode ved hjælp af et compilerprogram. Kildekoden til et stort program består af flere moduler(kildefiler). Hvert modul er kompileret til en separat fil med objektkode, som derefter skal kombineres til en helhed.
- En link editor eller assembler, der udfører sammenkædning af objektmoduler og genererer en fungerende applikation som en output - eksekverbar kode. Eksekverbar kode er et komplet program, der kan køres på enhver computer, der har det operativsystem, som programmet blev oprettet til. Som regel har den resulterende fil filtypenavnet .EXE eller .COM.
- For nylig er visuelle programmeringsmetoder (ved hjælp af scriptsprog) rettet mod at skabe Windows-applikationer blevet udbredt. Denne proces er automatiseret i hurtige designmiljøer. I dette tilfælde bruges færdige visuelle komponenter, som er konfigureret ved hjælp af specielle editorer.
De mest populære redaktører (programmeringssystemer ved hjælp af visuelle værktøjer) til visuelt design:
- Borland Delphi - designet til at løse næsten ethvertm.
- Borland C++ Builder er et fremragende værktøj til udvikling af DOS- og Windows-applikationer.
- Microsoft Visual Basic er et populært værktøj til at lave Windows-programmer.
- Microsoft Visual C++ - dette værktøj giver dig mulighed for at udvikle alle applikationer, der kører i et OS-miljø som Microsoft Windows.
Et sæt programmer designet til at løse problemer på en pc kaldes software. Sammensætningen af pc-software kaldes softwarekonfiguration. Software kan opdeles i tre kategorier (fig. 1):
Figur 1. Softwareklassifikation
systemsoftware (programmer til almen brug), der udfører forskellige hjælpefunktioner, såsom at oprette kopier af brugt information, give hjælpeoplysninger om computeren, kontrollere funktionaliteten af computerenheder osv.
applikationssoftware, der giver det nødvendige arbejde på en pc: redigering af tekstdokumenter, oprettelse af tegninger eller billeder, behandling af informationsarrays mv.
værktøjssoftware (programmeringssystemer), der sikrer udvikling af nye computerprogrammer i et programmeringssprog.
Systemsoftware er et sæt programmer, der giver effektiv styring af computersystemkomponenter, såsom processor, RAM, input/output-enheder, netværksudstyr, der fungerer som et "mellemlagsinterface", på den ene side er hardwaren, og på den anden side, brugerapplikationer. I modsætning til applikationssoftware løser systemsoftware ikke specifikke applikationsproblemer, men sikrer kun driften af andre programmer, styrer computersystemets hardwareressourcer osv.
Disse programmer til almindelig brug er ikke forbundet med en specifik pc-applikation og udfører traditionelle funktioner: planlægning og opgavestyring, I/O-styring osv. Med andre ord udfører systemprogrammer forskellige hjælpefunktioner, for eksempel at lave kopier af brugt information, give hjælpeoplysninger om computeren, kontrollere funktionaliteten af computerenheder osv. Systemsoftware inkluderer:
operativsystemer (dette program indlæses i RAM, når computeren tændes)
shell-programmer (giver en mere bekvem og visuel måde at kommunikere med en computer på end at bruge DOS-kommandolinjen, for eksempel Norton Commander)
operationsskaller er grænsefladesystemer, der bruges til at skabe grafiske grænseflader, multiprogrammering mv.
Drivere (programmer designet til at styre porte til eksterne enheder, normalt indlæst i RAM, når computeren starter)
hjælpeprogrammer (hjælpe- eller hjælpeprogrammer, der giver brugeren en række yderligere tjenester)
Hjælpeprogrammer omfatter:
filadministratorer eller filadministratorer
dynamiske datakomprimeringsværktøjer (giver dig mulighed for at øge mængden af information på disken på grund af dens dynamiske komprimering)
visnings- og afspilningsværktøjer
diagnostiske værktøjer; kontrolværktøjer giver dig mulighed for at kontrollere computerens konfiguration og kontrollere funktionaliteten af computerenheder, primært harddiske
kommunikationsværktøjer (kommunikationsprogrammer) er designet til at organisere udvekslingen af information mellem computere
Computersikkerhedsværktøjer (backup, antivirussoftware).
Hjælpeprogrammer er programmer designet til at løse en snæver række af hjælpeopgaver.
Nogle gange er hjælpeprogrammer klassificeret som servicesoftware
Hjælpeprogrammer bruges til:
Overvågning af sensorindikatorer og udstyrs ydeevne - overvågning af processor- og videoadaptertemperaturer; læser S.M.A.R.T. harddiske;
Håndtering af udstyrsparametre - begrænsning af cd-drevets maksimale rotationshastighed; ændring af blæserhastighed.
Overvågningsindikatorer - kontrol af referentiel integritet; rigtigheden af dataregistreringen.
Udvidede muligheder - formatering og/eller genpartitionering af disken, mens du gemmer data, sletning uden mulighed for gendannelse.
Typer af hjælpeprogrammer:
Diskværktøjer
Registry hjælpeprogrammer
Værktøjer til overvågning af udstyr
Udstyrsprøver
Defragmentere
Diskscanning - søgning efter filer og diskområder, der var forkert optaget eller beskadiget på forskellige måder, og deres efterfølgende fjernelse for effektiv udnyttelse af diskplads.
Diskoprydning - sletning af midlertidige filer, unødvendige filer, tømning af papirkurven.
Diskpartitionering er opdelingen af en disk i logiske diske, som kan have forskellige filsystemer og af operativsystemet opfattes som flere forskellige diske.
Backup - oprettelse af sikkerhedskopier af hele diske og individuelle filer, samt gendannelse fra disse kopier.
Diskkomprimering - komprimering af information på diske for at øge kapaciteten på harddiske.
Figur 2. Stedet for open source-software i en computers flerniveaustruktur
Det skal bemærkes, at nogle af hjælpeprogrammerne er inkluderet i operativsystemet, mens den anden del fungerer autonomt. Det meste af den generelle (system) software er inkluderet i OS (fig. 2). Noget af den generelle software er inkluderet i selve computeren (nogle af OS-programmerne og kontroltestene er skrevet i ROM eller PROM installeret på bundkortet). Nogle af de almindelige software er selvstændige programmer og leveres separat.
Applikations software.
MS OFFICE suite af kontorapplikationer
Regnskabssystemer
Finansielle analytiske systemer
Integrerede kontoradministrationspakker
CAD – systemer (computerstøttede designsystemer)
HTML eller web-editorer
Browsere – midler til at se websider
Grafisk redaktør
Ekspertsystemer.
Værktøjssoftware. Værktøjssoftware eller programmeringssystemer er systemer til automatisering af udviklingen af nye programmer i et programmeringssprog. I det mest generelle tilfælde, for at oprette et program i det valgte programmeringssprog (systemprogrammeringssprog), skal du have følgende komponenter: 1. Teksteditor til at oprette en fil med programmets kildetekst. 2. Kompiler eller tolk. Kildeteksten oversættes til mellemobjektkode ved hjælp af et compilerprogram. Kildekoden til et stort program består af flere moduler(kildefiler). Hvert modul er kompileret til en separat fil med objektkode, som derefter skal kombineres til en helhed.3. En link editor eller assembler, der udfører sammenkædning af objektmoduler og genererer en fungerende applikation som en output - eksekverbar kode. Eksekverbar kode er et komplet program, der kan køres på enhver computer, der har det operativsystem, som programmet blev oprettet til. Som regel har den resulterende fil filtypenavnet .EXE eller .COM.4. For nylig er visuelle programmeringsmetoder (ved hjælp af scriptsprog) rettet mod at skabe Windows-applikationer blevet udbredt. Denne proces er automatiseret i hurtige designmiljøer. I dette tilfælde bruges færdige visuelle komponenter, som er konfigureret ved hjælp af specielle editorer. De mest populære redaktører (programmeringssystemer ved hjælp af visuelle værktøjer) til visuelt design:
Borland Delphi - designet til at løse næsten ethvertm
Borland C++ Builder er et fremragende værktøj til udvikling af DOS- og Windows-applikationer
Microsoft Visual Basic er et populært værktøj til at lave Windows-programmer
Microsoft Visual C++ - dette værktøj giver dig mulighed for at udvikle alle applikationer, der kører i et OS-miljø som Microsoft Windows
Kontrolspørgsmål:
Definer operativsystem.
Hvilken software betragtes som systemsoftware?
Navngiv hjælpesoftwaren.
Hvilken software betragtes som applikationssoftware?
Hvad er formålet med softwaren?
Hvad er hovedklasserne af programmer? Giv eksempler på programmer i hver klasse i henhold til deres formål.
Strukturelle og funktionelle diagrammer af programmet
Et strukturdiagram er et sæt af elementære links af et objekt og forbindelserne mellem dem, en af typerne af grafiske modeller. Et elementært led forstås som en del af et objekt, et kontrolsystem osv., der implementerer en elementær funktion. I fig. 2.1 viser blokdiagrammet for det udviklede program.
Figur 2.1 - Programblokdiagram
Et funktionsdiagram er et dokument, der forklarer de processer, der forekommer i individuelle funktionelle kredsløb af et produkt (installation) eller produktet som helhed. Et funktionelt diagram er en forklaring af visse typer processer, der forekommer i integrerede funktionelle blokke og kredsløb i en enhed. Figur 2.2 viser funktionsdiagrammet for det udviklede program.
Figur 2.2 - Funktionsdiagram af programmet
Beskrivelse af procedurer, funktioner og moduler
Modulerklæring:
Hver kildefil skal indeholde en modulerklæring. Ordenheden er et nøgleord, så det skal skrives med små bogstaver. Modulnavnet kan indeholde både store og små bogstaver og skal være det samme som det navn, der bruges af operativsystemet til denne fil.
Standardmoduler i Delphi-sproget. Delphi-miljøet inkluderer et fremragende sæt moduler, hvis muligheder vil tilfredsstille selv den mest kræsne programmør. Alle moduler kan opdeles i to grupper: systemmoduler og visuelle komponentmoduler.
Systemmoduler inkluderer System, SysUtils, ShareMem, Math. De indeholder de mest almindeligt anvendte datatyper i programmer, konstanter, variabler, procedurer og funktioner. Systemmodulet er hjertet i Delphi-miljøet; underrutinerne indeholdt i den sikrer driften af alle andre moduler i systemet. Systemmodulet er automatisk inkluderet i hvert program og skal ikke specificeres i uses-sætningen.
Visuelle komponentmoduler (VCL - Visual Component Library) bruges til den visuelle udvikling af fuldt udstyrede GUI-applikationer - applikationer med en grafisk brugergrænseflade (Graphical User Interface). Disse moduler repræsenterer tilsammen et objektorienteret bibliotek på højt niveau med alle slags brugergrænsefladeelementer: knapper, etiketter, menuer, paneler osv. Derudover indeholder modulerne i dette bibliotek enkle og effektive metoder til at få adgang til databaser. Disse moduler forbindes automatisk, når komponenter placeres på formularen.
Beskrivelse af procedurer:
Denne procedure lukker titelsiden og siden og afslutter programmet.
procedure TForml.Button2Click(Afsender: TObject);
Denne procedure åbner programmets hovedmenu og fjerner titelsiden fra skærmen.
procedure TForm2.Button1Click(Afsender: TObject);
Denne procedure åbner et vindue med valg af metode til at løse transportproblemet og fjerner menuvinduet fra skærmen.
Denne procedure åbner et vindue med information om det udviklede program og fjerner menuvinduet fra skærmen.
Denne procedure åbner et vindue med hjælpeoplysninger til programmet, som gør brugerens arbejde lettere og fjerner menuvinduet.
Denne procedure åbner et vindue om udvikleren og fjerner menuvinduet.
procedure TForm2.Button5Click(Afsender: TObject);
Denne procedure lukker menuvinduet og afslutter programmet.
procedure TForm3.Button1Click(Afsender: TObject);
Denne procedure afslutter hovedmenuen og lukker vinduet med valg af metode til løsning af transportproblemet:
procedure TForm3.Button3Click(Afsender: TObject);
Denne procedure lukker vinduet med løsninger på transportproblemet ved hjælp af tre metoder og viser en formular med løsningen af problemet ved hjælp af minimumsomkostningsmetoden:
Denne procedure lukker vinduet med løsninger på transportproblemet ved hjælp af tre metoder og viser en formular med en løsning på problemet ved hjælp af dobbeltpræferencemetoden:
procedure TForm2.Button2Click(Afsender: TObject);
procedure TForm2.Button3Click(Afsender: TObject);
procedure TForm2.Button4Click(Afsender: TObject);
Disse procedurer giver brugeren mulighed for at gå fra hovedmenuen til ethvert punkt i programmet: "Løsningsformular", "Brugervejledning", "Udviklerinformation", "Afslut".
procedure TRIN FOR TRIN;
Dette er en procedure til at udføre trinvise beregninger i programmet, du kan spore hvert trin i at udfylde tabellen. Efter at have udført én beregning, afbryder proceduren beregningen og venter på kommandoer fra brugeren.
procedure TForm4.Label2Click(Afsender: TObject);
procedure TForm4.Label3Click(Afsender: TObject);
procedure TForm4.Label4Click(Afsender: TObject);
procedure TForm4.Label5Click(Afsender: TObject);
Disse procedurer indlæser Memo-tekstfeltet med indholdet af et tekstdokument, afhængigt af det valgte menupunkt. Tekstdokumenter indeholder oplysninger om brug af applikationen.
procedure TForm1.Button8Click(Afsender: TObject);
Denne procedure udfører beregninger ved hjælp af formler, erstatter de indtastede værdier og skriver til sidst resultatet til en variabel.
procedure TForm1.Button9Click(Afsender: TObject);
Denne procedure viser svaret i et tekstfelt.
procedure TForm1.Button2Click(Afsender: TObject);
Denne procedure udfylder inputfelterne med startdata i overensstemmelse med opgaven for kursusprojektet.
procedure TForm3.Button4Click(Afsender: TObject);
procedure TForm4.Button1Click(Afsender: TObject);
Disse procedurer lukker vinduet og viser en formular med et menupunktvalg.
procedure rengøring;
Denne procedure rydder input- og outputfelterne og frigør variablerne fra den værdi, de har.
Udviklingen af et programblokdiagram (arkitektur) er et af de vigtigste stadier i softwareudviklingsprocessen af følgende årsager:
det forkerte valg af arkitektur fører til risikoen for fejl i hele projektet i fremtiden;
denne fase er grundlæggende for hele udviklingsprocessen;
en gennemtænkt arkitektur gør det nemt at ændre softwareproduktet, hvis kravene til det ændrer sig.
På baggrund af analysen af kravene til systemet fastlægges et sæt af alle funktioner, som programmet skal understøtte. Dernæst kombineres de opnåede funktioner i logisk indbyrdes forbundne grupper. Hver af disse grupper kan blive en af komponenterne i softwaresystemet. Du skal være forberedt på, at den første version af sættet af komponenter ikke vil være komplet. Under funktionsanalyseprocessen og i de tidlige stadier af arkitektonisk design kan der identificeres yderligere funktioner, som skal inkluderes i det program, der udvikles. For det meste vil disse funktioner være nødvendige for at udføre teknologiske processer for at holde systemet i en intakt og operationel tilstand. Det er helt naturligt at antage, at disse funktionelle funktioner ikke kan kendes af kunden af softwaresystemet og for udviklerne i de første udviklingsstadier.
Først og fremmest skal programarkitekturen indeholde en generel beskrivelse af systemet. Uden en sådan beskrivelse er det ret svært at skabe et sammenhængende billede ud fra mange små detaljer eller mindst et dusin separate klasser. Arkitekturen bør indeholde dokumentation for, at alternative muligheder blev overvejet under udviklingen og begrunde valget af den endelige systemorganisation.
Arkitekturen skal klart definere hver komponents ansvar. En komponent skal have ét ansvarsområde og vide så lidt som muligt om andre komponenters ansvarsområde. Ved at minimere mængden af information, som komponenter kender til andre komponenter, kan du nemt lokalisere applikationsdesignoplysninger til individuelle komponenter.
Arkitekturen skal klart definere reglerne for kommunikation mellem programkomponenter og beskrive, hvilke andre komponenter en given komponent kan bruge direkte, hvilke indirekte, og hvilke den slet ikke skal bruge.
Brugergrænsefladen er ofte designet i kravfasen. Hvis dette ikke er tilfældet, bør det fastlægges i arkitekturdesignfasen. Arkitekturen skal beskrive hovedelementerne i websideformatet, grafisk grænseflade (GUI) osv. Brugervenligheden af grænsefladen kan i sidste ende bestemme populariteten eller fiaskoen af et program.
Programmets arkitektur er modulopbygget, så den grafiske grænseflade kan ændres uden at påvirke programmets kernelogik.
Programmet til behandling af elevundersøgelsesspørgeskemaer kan opdeles i to dele med forskellige funktioner og adgangsniveauer for brugerne:
studerende undersøgelse system;
system til behandling af undersøgelsesresultater;
kontrolsystem.
Figur 2.1. - Systemstruktur
Undersøgelsessystemet indeholder følgende funktioner:
udsendelse af et spørgsmål fra spørgeskemaet;
automatisk kontrol af typen og rigtigheden af de indtastede data;
gemme data til en database.
vise eller udskrive undersøgelsesrapporter;
se oplysninger om undersøgelsen af en specifik elev;
sammenligne resultaterne af nuværende og tidligere undersøgelser med de samme spørgsmål.
kontrollere gennemførelsen af undersøgelsen;
administrere data - tilføje, slette og ændre;
serverdel, skrevet i PHP-programmeringssproget og udført på serveren;
klientdelen, skrevet i HTML markup-sproget og JavaScript-programmeringssproget ved hjælp af jQuery-biblioteket og udført i brugerens browser.
Serverdelen af programmet i dets struktur svarer til MVC (Model-View-Controller) eller model-view-controller-arkitekturen. MVC er en softwarearkitektur, hvor applikationens datamodel, brugergrænseflade og kontrollogik er adskilt i tre separate komponenter, så ændring af en komponent har minimal indvirkning på de andre komponenter.
Figur 2.2. – Model-View-Controller-arkitektur
Denne tilgang giver dig mulighed for at adskille data, præsentation og behandling af brugerhandlinger i tre separate komponenter.
Model(Model) - et modul, der er ansvarlig for direkte at beregne noget ud fra data modtaget fra brugeren. Resultatet opnået af dette modul skal videregives til controlleren og må ikke indeholde noget relateret til direkte output (det vil sige, det skal præsenteres i systemets interne format). Hovedmålet er at gøre modellen fuldstændig uafhængig af de andre dele og næsten intet vide om deres eksistens, hvilket ville tillade at ændre både controlleren og visningen af modellen uden at røre selve modellen, og endda tillade funktionen af flere tilfælde af visninger og controllere med samme model på samme tid. Som følge heraf kan en model under ingen omstændigheder indeholde referencer til visnings- eller kontrollerobjekter.
Udsigt- informationsudgangsmodul. Ansvaret for visningen omfatter visning af data modtaget fra modellen. Typisk har visningen fri adgang til modellen og kan tage data fra den, men dette er skrivebeskyttet adgang, det er forbudt for visningen at ændre noget i modellen eller blot kalde metoder, der fører til ændringer i dens interne tilstand. For at interagere med en controller implementerer en visning typisk en grænseflade, der er kendt af controlleren, hvilket gør det muligt at ændre visninger uafhængigt og have flere visninger pr. controller.
Controller- data input og output kontrolmodul. Controllerens opgaver omfatter at reagere på eksterne hændelser og ændre modellen og/eller visningen i overensstemmelse med den logik, der er indlejret i den. En controller kan arbejde med flere visninger, afhængigt af situationen, interagere med dem gennem en bestemt (forudkendt) grænseflade, som disse visninger implementerer. En vigtig nuance - i den klassiske version af MVC overfører controlleren ikke data fra modellen til visningen.
Controlleren modtager data fra brugeren og videregiver dem til modellen. Derudover modtager den beskeder fra modellen og sender dem videre til visningen. Det er vigtigt at bemærke, at både visningen og controlleren er modelafhængige. Modellen afhænger dog ikke af hverken controlleren eller adfærden. Dette er en af de vigtigste fordele ved en sådan opdeling. Det giver dig mulighed for at bygge en model uafhængig af den visuelle repræsentation, samt oprette flere forskellige repræsentationer til én model.
systemgennemsigtighed;
enkelt indgangspunkt til systemet;
kode genbrug;;
hurtig udvikling;
tilgængelighed af færdige løsninger;
let støtte;
let at foretage ændringer.
2.Udvikling af programdatabasestrukturen
Organiseringen af databasestrukturen er dannet ud fra følgende overvejelser:
tilstrækkelighed til det beskrevne objekt - på niveau med en konceptuel og logisk model;
brugervenlighed til regnskab og dataanalyse - på niveau med den såkaldte fysiske model.
I dette tilfælde er den relationelle datamodel bedst egnet, da al information let kan præsenteres i form af tabeller. Den relationelle datamodel er en logisk datamodel, der beskriver det strukturelle aspekt, integritetsaspektet og databehandlingsaspektet af relationelle databaser.
Strukturelt aspekt- Data i en database er et sæt af relationer.
Integritetsaspekt- forhold opfylder visse integritetsbetingelser.
Behandlingsaspekt- operatører til relationsmanipulation understøttes.
Et vigtigt aspekt af databasedesign er normalisering - processen med at konvertere en database til en form, der svarer til normale former. Normalisering hjælper med at beskytte din database mod logiske og strukturelle problemer kaldet dataanomalier. For eksempel, når der er flere identiske poster i en tabel, er der risiko for dataintegritetskrænkelse ved opdatering af tabellen. Et bord, der har gennemgået normalisering, er mindre modtageligt for sådanne problemer, fordi dens struktur involverer at definere relationer mellem data, hvilket eliminerer behovet for poster med duplikerede oplysninger.
Det gratis databasestyringssystem MySQL blev valgt som DBMS. Fleksibiliteten i MySQL DBMS er sikret ved understøttelse af et stort antal tabeltyper: Brugere kan vælge både MyISAM-tabeller, der understøtter fuldtekstsøgning, og InnoDB-tabeller, der understøtter transaktioner på det enkelte postniveau. Takket være den åbne arkitektur og GPL-licens (GNU General Public License - en gratis softwarelicens, hvis formål er at give brugeren rettigheder til at kopiere, ændre og distribuere programmer, og også at sikre, at brugere af alle afledte programmer modtager ovenstående rettigheder), MySQL DBMS vises konstant nye typer tabeller.
En vigtig fordel ved MySQL DBMS er, at den er blevet overført til en lang række platforme, såsom AIX, FreeBSD, HP-UX, GNU/Linux, Mac OS X, NetBSD, OpenBSD, Solaris og Windows. Bemærk, at MySQL AB giver gratis download ikke kun DBMS-kildekoderne, men også færdige eksekverbare moduler kompileret og optimeret til specifikke operativsystemer.
MySQL har en applikationsprogrammeringsgrænseflade (API) til sprog som Delphi, C, C++, Java, Perl, PHP, Python og Ruby, biblioteker til .NET platformsprog og yder også support til ODBC gennem ODBC-driveren (Åben DataBase Connectivity er en programgrænseflade til adgang til databaser) MyODBC.
MyISAM-typen blev valgt som hovedtabeltype. MyISAM-tabeller er ideelt optimeret til brug i forbindelse med webapplikationer, hvor læseforespørgsler dominerer. Tabeller som MyISAM viser meget gode resultater for SELECT-forespørgsler. Dette skyldes i høj grad manglen på support til transaktioner og fremmednøgler. Men når du ændrer og tilføjer poster, er hele tabellen kortvarigt låst, hvilket kan føre til alvorlige forsinkelser under tung belastning. Men i tilfælde af et program til analyse af spørgeskemaer, er dette ikke et alvorligt problem, da der ikke er planlagt en høj belastning af systemet.
En anden fordel ved tabeller som MyISAM er platformsuafhængighed. Tabelfiler kan flyttes mellem computere med forskellige arkitekturer og forskellige operativsystemer uden nogen konvertering.
MyISAM-tabeller kan have faste, dynamiske eller komprimerede poster. Valget mellem fast og dynamisk format er dikteret af kolonnedefinitionerne.
Strukturen af databasen er vist i figur 2.4.
R 
Figur 2.3. – Databasestruktur
Relationer mellem tabeller organiseret i databasen giver dig mulighed for at udføre kaskadesletninger og opdateringer af data. Brugen af linktabeller gjorde det muligt at reducere dataredundans til et minimum.
Tabellen it_students indeholder data om elever, der har gennemført undersøgelsen.
Tabel 2.1 – "it_students" datatabel
|
Mark |
Type |
Længde |
Beskrivelse |
|
id |
Numerisk |
11 |
Indeks |
|
num |
Numerisk |
11 |
Studienummer |
|
navn |
Symbolsk |
100 |
Navn |
|
efternavn |
Symbolsk |
100 |
Efternavn |
|
efternavn |
Symbolsk |
100 |
Efternavn |
|
fødsel |
dato |
- |
Fødselsdato |
|
år_postupl |
år |
- |
Optagelsesår |
|
adresse |
Symbolsk |
500 |
Adresse |
|
telefon_h |
Symbolsk |
15 |
Hjemmetelefon |
|
phone_m |
Symbolsk |
15 |
Mobiltelefon |
|
post |
Symbolsk |
250 |
Email adresse |
|
icq |
Numerisk |
10 |
ICQ nummer |
Tabellen it_answers_var indeholder muligheder for at besvare undersøgelsesspørgsmål.
Tabel 2.2 – Datatabel "it_answers_var"
Tabellen it_questions indeholder undersøgelsesspørgsmål.
Tabel 2.3 – "it_questions" datatabel
Tabellen it_tests_cfg linker undersøgelsesspørgsmål til et specifikt spørgeskema.
Tabel 2.4 – Datatabel "it_tests_cfg"
Tabellen it_tests indeholder data om alle spørgeskemaer og datoerne for undersøgelserne.
Tabel 2.5 – "it_tests" datatabel
Tabellen it_text_answers indeholder data om elevsvar indtastet manuelt.
Tabel 2.6 – Datatabel "it_text_answers"
Tabellen it_students_answers indeholder data om elevsvar.
Tabel 2.6 – Datatabel "it_students_answers"
3.Udvikling af en databaseinformationsflowmodel
Da programmet til analyse af spørgeskemaer til elevundersøgelser er bygget på MVC-princippet, kan informationsstrømme repræsenteres som følger. Når en anmodning modtages fra en bruger, der sender en browser til webserveren, kvalificerer controlleren, efter programmerede algoritmer, den modtagne anmodning, ændrer og sender den til modellen. Modellen, som er forbindelsen mellem controlleren og DBMS'en, fortolker anmodningen og foretager det passende opkald til MySQL DBMS'et, og returnerer resultaterne til controlleren.Det er bemærkelsesværdigt, at det for controlleren forbliver skjult, hvilken type eller implementering af DBMS, den arbejder med, sker gennem modellen, hvis hovedopgave er at abstrahere arbejdet med data. I stedet for en database kan du endda bruge en tekst- eller XML-fil, dette vil ikke have nogen betydning for controlleren. Sideløbende sender controlleren en anmodning til visningskomponenten, som sammensætter den endelige skabelon og returnerer den til controlleren. Det er også muligt, at dataudveksling sker direkte mellem modellen og visningen. Controlleren kombinerer valget fra databasen og visningsskabelonen og sender det til brugerens browser.
Figur 2.4. - Skema for informationsstrømme i MVC-arkitekturen
4.Udvikling af algoritmisk støtte
Den algoritmiske understøttelse af alle programkomponenter har betydelige forskelle, da de har forskellig funktionalitet.Når en elev første gang logger på undersøgelsessystemet, oprettes et nyt sessions-id. En session eller session giver serveren mulighed for at identificere en bruger ved hjælp af et specielt nummer, der er unikt og tildelt, når brugeren interagerer med serveren. Derudover giver sessioner dig mulighed for at binde variabler til den pågældende bruger og gemme disse variable på serveren. Med andre ord giver sessioner dig mulighed for at gøre variabler globale for alle programkomponenter. Opmålingssystemet kan således entydigt bestemme, fra hvilken bruger, der arbejder med programmet, visse data kom.
D 
Dernæst besvarer eleven en række undersøgelsesspørgsmål, og først efter at have gennemført undersøgelsen gemmes alle data i databasen. Algoritmen til at betjene undersøgelsessystemet er vist i figur 2.5.
Figur 2.5. – Algoritme til driften af undersøgelsessystemet
Et af de vigtigste sikkerhedspunkter for en webapplikation er at tjekke alle indgående data, så du bør altid tjekke de data, brugeren indtaster i søgeformularer, udfylde registreringsfelter og så videre for tilstedeværelsen af "farlige" data. Dette kan være ondsindet JavaScript-kode, PHP- eller PERL-kommandoer eller (mest farligt) kommandoer til serveren.
Du skal altid huske, at absolut enhver bruger er en fare for en ubeskyttet webapplikation, så det er altid værd at tjekke anmodninger og variabler, der kommer fra brugeren.
analyse af POST og GET variabler og superglobale arrays;
adskillelse af variabler;
filtrering af strengvariabler.
Absolut enhver variabel i et program skal allerede have sin egen type på designstadiet, hvad enten det er et tal eller en streng. Dette problem er især akut for programmeringssprog med svag eller manglende indtastning, som inkluderer PHP og JavaScript. Derfor, i de mest kritiske områder af programmet, kontrolleres variabler for typeoverensstemmelse.
Tekstvariabler er særligt farlige, for eksempel et felt til at indtaste et svar på et undersøgelsesspørgsmål. De skal blot tjekkes for skadelig kode. For at eliminere faren fjernes nogle elementer fra teksten eller erstattes med andre symboler. Algoritmen til behandling af indgående data i CodeIgniter-rammeværket er vist i figur 2.6.
R 
Figur 2.6. – Algoritme til behandling af indgående data i CodeIgniter-rammeværket
2.5 Udvikling af programgrænsefladen
Et af de vigtigste spørgsmål ved udvikling af et softwaresystem er udviklingen af en brugergrænseflade. Ethvert system, der bruger tekniske midler i sin drift, tilhører klassen af "mand-maskine"-systemer. Det ville være korrekt at fremsætte følgende krav til grænsefladen af testsystemer:
grænsefladen skal være klar, enkel og nem at bruge
brugeren bør ikke blive distraheret af handlinger, der ikke er relateret til den opgave, der udføres.
TIL 
For eksempel blev et tekstfelt til indtastning af en dato ved hjælp af jQuery konverteret til en kompakt kalender, der har funktionen til automatisk at kontrollere rigtigheden af den indtastede dato (se figur 2.7).
Figur 2.7. – Kalendergrænseflade til valg af fødselsdato
Den brugergrænseflade, der er tilgængelig for studerende, der deltager i undersøgelsen, er noget minimalistisk. Som et resultat bliver eleverne ikke distraheret af smuk grafik og koncentrerer sig om at tænke på svaret på spørgsmålet. Interface med en af de 
undersøgelser er vist i figur 2.8.
Figur 2.8. – Interface til besvarelse af et spørgeskemaspørgsmål
Hvis en elev af en eller anden grund ikke vælger nogen af svarene på et spørgsmål, men forsøger at gå videre til næste spørgsmål, vil undersøgelsessystemet automatisk vise en fejlmeddelelse og tilbyde at besvare det aktuelle spørgsmål igen (se figur 2.9).
Figur 2.9. - Fejlmeddelelse om dataindtastning
Systemet til behandling af undersøgelsesresultater kan vise resultater i flere tilstande - tekst, grafik og udskrivningstilstand. Grænsefladen til visning af undersøgelsesresultater i grafisk form er vist i figur 2.10.
Figur 2.10. – Interface til visning af undersøgelsesresultater
En browser, som er en klient i forhold til serveren og sender den en anmodning om at behandle en webside, kan være en implementering af såkaldte tynde klienter. Browseren er i stand til at vise websider og er som udgangspunkt en del af operativsystemet, og funktionerne til at opdatere og vedligeholde det påhviler operativsystemleverandøren. Applikationslogikken er centreret på serveren, og browserens funktion er hovedsageligt at vise information downloadet over netværket fra serveren og sende brugerdata tilbage. En fordel ved denne tilgang er, at klienter er uafhængige af brugerens specifikke operativsystem, og webapplikationer er således tjenester på tværs af platforme.
En væsentlig fordel ved at bygge webapplikationer til at understøtte standard browserfunktionalitet er, at funktionaliteten skal køre uafhængigt af klientens operativsystem. I stedet for at skrive forskellige versioner til Microsoft Windows, Mac OS X, GNU/Linux og andre operativsystemer, er applikationen bygget én gang og installeret på enhver platform.
3. Teknologisk afsnit
3.1 Programudviklingsteknologi
3.1.1 Grundlæggende om webserverSådan fungerer en webserver: Det er kendt, at webservere gemmer information i form af tekstfiler, også kaldet sider. Ud over tekst kan sådanne sider indeholde links til andre sider (placeret på samme eller en anden server), links til grafiske billeder, lyd- og videooplysninger, forskellige dataindtastningsobjekter (felter, knapper, formularer osv.) og samt andre objekter og programmer udført på serveren. Faktisk repræsenterer sider en form for forbindelsesled mellem objekter af forskellige typer. De er designet ved hjælp af et særligt hypertekst-markup-sprog, HyperText Markup Language eller HTML for kort. For at få adgang til oplysninger på webservere bruger brugere specielle klientprogrammer - browsere. Der er i øjeblikket snesevis af forskellige browsere, men kun nogle få af dem er i øjeblikket de mest populære:
Microsoft Internet Explorer;
Opera;
Mozilla Firefox
Google Chrome.
3.1.2 Passive og aktive webservere
Der er passive og aktive webservere. Hvis serversider kun indeholder statisk tekst og multimedieinformation, samt hypertekstlinks til andre sider, kaldes serveren passiv. Når serversiderne opfører sig på samme måde som vinduerne i almindelige interaktive applikationer og går i dialog med brugeren, har vi at gøre med en aktiv server.
3.1.3 Objektorienteret tilgang
I øjeblikket bliver brugen af en objektorienteret tilgang til udvikling af webapplikationer stadig mere populær. Og selvom fordelene ved denne tilgang ikke er så indlysende som for eksempel i programmeringssprog som C++ eller Java, flytter et stigende antal frit distribuerede biblioteker og programmer skrevet i PHP programmeringssproget til en objektorienteret grænseflade . Ved at gøre dette tvinger de udviklerne, der bruger dem, til at vende sig til de objektorienterede funktioner i PHP. Introduktionen af fuld understøttelse af den objektorienterede model i den femte version af PHP-fortolkeren giver yderligere næring til interessen for denne metode.
Ofte vil brug af en objektorienteret tilgang til sted og ikke sted gøre et projekt vellykket. Programmering som nybegynder i den objektorienterede programmeringsstil føles ofte som at navigere i et minefelt – hvis du ikke ved, hvor minerne er, er det umuligt at nå slutningen af projektet. Objektorienteret programmering i sig selv er ikke et vidundermiddel - det er en fungerende teknologi, der giver dig mulighed for at:
øge procentdelen af genbrugt kildekode;
Når du programmerer, skal du arbejde med begreber og objekter fra den virkelige verden (elev, gruppe, kursus osv.), snarere end computerudtryk på lavt niveau (fil, linje osv.), som giver dig mulighed for at skabe større projekter med færre fejl og mere effektiv kort tid.
Ved begyndelsen af computeræraen var et program en enkelt tråd, der behandlede en række data. Med tiden steg programmernes kompleksitet og kravene til dem, og denne måde at organisere data på viste sig at være uacceptabel. Der blev foreslået en strukturel tilgang, hvor dataarrayet blev tilgængeligt fra et hvilket som helst sted i programmet, men programmets hovedflow var opdelt i flere procedurer. En separat lille procedure, selvom den bruger almindelige data, er meget nemmere at udvikle end en stor mængde kildekode.
Hver procedure har en lokal variabel, hvis levetid bestemmes af varigheden af proceduren. Nogle procedurer kan kalde andre, men dataarrayet i programmet forbliver fælles og tilgængeligt for alle procedurer. Denne tilgang bruges i proceduremæssig programmering i PHP og giver dig mulighed for at skabe store softwarekomplekser. Men udvikling, fejlretning og support af programmer, der opererer med store mængder data (såsom en afdelingsdatabase) er stadig kompleks og kræver betydelig dygtighed og erfaring.
Svaret på stigende kompleksitet var fremkomsten af en objektorienteret tilgang til programmering: Et program er opdelt i flere dataarrays, som hver har sine egne procedurer, såvel som procedurer, der interagerer med andre dataarrays.
Som et resultat bliver en kompleks opgave opdelt i en række simplere underopgaver, og udviklere får en mere fleksibel måde at styre projektet på – at redigere én enorm monolitisk kodeblok er meget vanskeligere end en samling af små, løst forbundne blokke.
Uanset tilknytningen til et programmeringssprog har den objektorienterede tilgang en række generelle principper, nemlig:
evnen til at skabe abstrakte datatyper, som tillader, sammen med foruddefinerede datatyper (såsom heltal, streng osv.), at introducere dine egne datatyper (klasser) og erklære "variable" af sådanne datatyper (objekter). Ved at skabe sine egne datatyper opererer programmøren ikke med maskintermer (variable, funktion), men med objekter fra den virkelige verden, og stiger derved til et nyt abstraktionsniveau;
indkapsling, som begrænser brugerinteraktion af abstrakte datatyper til kun deres grænseflade og skjuler den interne implementering af objektet, hvilket forhindrer indflydelse på dets interne tilstand. Menneskets hukommelse er begrænset og kan ikke indeholde alle detaljerne i et stort projekt, hvorimod brugen af indkapsling giver dig mulighed for at designe et objekt og bruge det uden at bekymre dig om intern implementering og kun ty til et lille antal grænseflademetoder;
arv, som giver dig mulighed for at udvikle en eksisterende abstrakt datatype - en klasse, ved at oprette en ny klasse baseret på den. I dette tilfælde får den nye klasse automatisk mulighederne for en eksisterende abstrakt datatype. Ofte er abstrakte datatyper for komplekse, så de tyer til deres sekventielle udvikling og opbygger et hierarki af klasser fra generelle til specifikke;
polymorfi, der tillader konstruktion af hele kæder og forgrenede træer, der arver abstrakte datatyper (klasser) fra hinanden. I dette tilfælde vil hele sættet af klasser have et antal metoder med de samme navne: enhver af klasserne i dette træ er garanteret at have en metode med samme navn. Dette princip hjælper med automatisk at behandle datasæt af forskellige typer.
3.1.4 Funktioner i CodeIgniter-rammen
Den anvendte CodeIgniter-ramme er skrevet ved hjælp af en objektorienteret tilgang. Alle klasser af controllere, visninger og modeller introduceret af programmøren arver de originale klasser introduceret i selve rammen. Dette gør det muligt at skrive mindre kildekode, da alle de nødvendige grundlæggende funktioner er umiddelbart tilgængelige.
Ud over de controllerklasser, visninger og modeller, der er tilgængelige for programmøren, har CodeIgniter-rammeværket også plugins og hjælpefunktioner, der er tilgængelige for programmøren. Hjælpere, som navnet antyder, er designet til at hjælpe med at udføre en mindre funktion. For eksempel er der hjælpere til at bygge webformularer, downloade filer eller arbejde med sessioner. I modsætning til alle andre hovedelementer i rammen er hjælpere sæt af elementære funktioner, skrevet selv uden at bruge en objektorienteret tilgang. Hver funktion udfører en lille, strengt begrænset opgave. Men sættet er ret stort, og sådan en "bagatel" bliver meget nyttig i arbejdet.
Plugins er næsten det samme som hjælpere, bortset fra den største forskel: de er ikke et sæt funktioner, de er én funktion. Derudover kan du være opmærksom på, at hjælpere mere er en del af kernen af systemet, mens plugins er noget eksternt, udviklet af tredjepartsprogrammører. I virkeligheden er det sådan, det bliver. Selv de plugins, der følger med hovedsættet, er skrevet af CodeIgniter-brugere i fællesskabet.
3.1.5 Eclipse IDE
Når vi udviklede et program til behandling af spørgeskemaundersøgelser til instituttets studerende, brugte vi også et så vigtigt og nyttigt programmørværktøj som et integreret udviklingsmiljø (IDE - Integrated Development Environment), nemlig Eclipse. Eclipse er en gratis ramme til udvikling af modulære applikationer på tværs af platforme. Udviklet og vedligeholdt af Eclipse Foundation.
De mest kendte applikationer baseret på Eclipse-platformen er de forskellige "Eclipse IDE'er" til softwareudvikling på en række forskellige sprog (for eksempel den mest populære "Java IDE", som oprindeligt blev understøttet). I dette tilfælde blev udvidelser brugt til programmering i programmeringssprogene PHP (PDT-modul) og JavaScript (JSEclipse-modul) samt layout ved hjælp af HTML-markupsproget.
3.2 Programtestteknologi
Programtest er processen med at identificere fejl i software. I øjeblikket er der mange metoder til at teste programmer, men de garanterer ikke for at identificere og eliminere alle defekter og fejl, eller at etablere den korrekte funktion af det analyserede program. Derfor fungerer alle eksisterende testmetoder inden for rammerne af en formel verifikationsproces for den software, der undersøges eller udvikles.Denne formelle verifikationsproces kan bevise, at der ikke er nogen fejl kun med hensyn til den anvendte metode, men garanterer ikke, at de fuldstændigt fraværes.
En test er information, der består af særligt udvalgte indledende data for det program, der debugges, og de tilsvarende referenceresultater, der bruges til at overvåge den korrekte drift af programmet.
Programkontrol handler om at vælge tests, hvis modtagelse af korrekte resultater vil garantere den korrekte drift af programmet for resten af inputdata fra hele det tilladte værdiområde.
Systemet blev testet ved hjælp af flere metoder:
Stresstestning;
manuel debugging og programsporing ved hjælp af XDebug-udvidelsen;
Enhedstest med phpUnit.
intet vises på skærmen, eller der vises en systemfejl med den tilsvarende kode (autorisationsfejl, webserverfejl osv.);
der opstod en fejl under arbejdet med databasen, og en fejlrapport genereres;
serverfejl forbundet med høj belastning af applikationen eller databasen;
Der er opstået en programafviklingsfejl, hvilket resulterer i, at forkerte data eller en fejlrapport vises.
3.2.1 Belastningstest af programmet
En af de vigtigste test er belastningstest, som giver dig mulighed for at finde flaskehalse i kildekoden eller databasekald.Der er mange værktøjer, der forenkler opgaven med at øge antallet af anmodninger og kalde flere operationer på serveren. Belastningsgrænsetesten skal designes til nøjagtigt at replikere den forventede arbejdsbelastning af applikationen.
Til belastningstest af programmet til behandling af spørgeskemaundersøgelser for instituttets studerende blev curl-loader-programmet brugt. Curl-loader er et frit distribueret værktøj til test af webapplikationer skrevet i programmeringssproget C. Det er i stand til at simulere hundredvis og endda tusindvis af serverkald over HTTP- og HTTPS-protokoller og bruger libcurl-biblioteket, som giver dig mulighed for nemt at teste applikationer. kræver autorisation. Og understøttelse af HTTPS-protokollen giver dig mulighed for at bruge curl-loader-værktøjet til belastningstest af webapplikationer, der arbejder gennem krypterede transportmekanismer SSL (Secure Sockets Layer) og TLS (Transport Layer Security).
3.2.2 Fejlretning ved hjælp af indbyggede PHP-værktøjer
Standardadfærden for en applikation skrevet i PHP, når der opstår en fejl i koden, afhænger i høj grad af konfigurationsindstillinger. Som regel er de indstillet i php.ini-konfigurationsfilen:
parameteren display_errors, sat til on eller off, angiver, om fejlmeddelelser skal vises til brugeren eller om de skal skjules;
parameteren log_errors, sat til eller fra, får PHP-fortolkeren til at skrive beskeder til hændelseslogfilen;
Fejlrapporteringsdirektivet bestemmer i hvilke tilfælde en advarsel skal genereres, og i hvilke tilfælde den kan ignoreres.
I en fungerende version af programmet skal du tværtimod deaktivere parameteren display_errors, men aktivere log_errors. På den ene side vil dette gøre livet sværere for angribere, som ikke længere vil være i stand til at se fejlretningsoplysninger. På den anden side vil det i en kritisk situation hjælpe dig med at forstå, hvad der præcist skete, og rette fejlen, selvom den ikke er reproducerbar i testmiljøet.
I begge tilfælde er det praktisk at sætte parameteren error_reporting til den mest detaljerede tilstand - E_ALL, hvilket tvinger PHP til at rapportere de mest mindre fejl i koden.
3.2.3 Fejlretning af et program ved hjælp af XDebug
Mens programmeringssproget PHP kan bruges til at oprette kommandolinjescripts til opgaver som systemadministration og traditionel databehandling, er sprogets kraft særligt tydelig i webapplikationer.I betragtning af den korte varighed af webapplikationer og deres lagdelte design (klientapplikation, netværk, webserver, applikationskode og underliggende database), kan det være svært at fange fejl i kildekoden. Selvom vi antager, at alle lag undtagen PHP-koden fungerer fejlfrit, kan det være svært at spore tilbage til en programfejl, især hvis applikationen bruger et stort antal klasser.
PHP-ekkoudtrykket og funktioner såsom var_dump(), debug_zval_dump() og print_r() er almindelige og meget populære fejlfindingsværktøjer, der kan hjælpe med at løse forskellige mindre problemer. Men som test- og fejlfindingsværktøjer er disse udtryk (og endnu mere pålidelige værktøjer, f.eks. PEAR Log-pakken) til lidt hjælp og ikke altid.
Derudover er denne type debugging en brute force-tilgang. Hvis de nødvendige oplysninger mangler, skal du gentage kildekoden, gentage de foregående trin og begynde at søge efter fejlen igen. En meget mere effektiv strategi er at teste applikationen, mens den kører. Du kan katalogisere forespørgselsparametre, se stakken af procedurekald og finde ud af værdien af enhver variabel eller objekt. Du kan midlertidigt afbryde udførelsen af applikationen og modtage meddelelse om ændringer i værdien af en variabel
Denne "live" eller interaktive udforskning leveres af en speciel applikation kaldet en debugger. En debugger kører eller knytter sig til en proces for at manipulere den og undersøge dens hukommelse. Eller, i tilfælde af fortolkede sprog, kan debuggeren fortolke koden direkte. En typisk moderne debugger kan indeksere og se kildekode, vise komplekse datastrukturer i en læsbar form og samtidigt vise programtilstand, opkaldsstakken, programoutput og værdierne af alle variabler. For eksempel er det almindeligt, at en debugger katalogiserer og viser egenskaberne og metoderne for en klasse.
I stedet for manuelt at tilføje forskellige debug-outputfunktioner, kan du bruge XDebug til at oprette en sporingslog. Sporingsloggen er en liste over kald til funktioner og metoder i en klasse gennem hele programmets udførelse. Dens fordel er, at absolut alle opkald vil blive afspejlet i loggen.
Sporingsloggen varierer normalt fra kørsel til kørsel, fordi den afhænger af de indgående data, som varierer fra anmodning til anmodning.
Sporing af loggen hjælper dig med at forstå, hvordan et program kører, men det er meget vanskeligt at visualisere alle mulige grene, medmindre programmet er meget simpelt. Det er på grund af dette, at det er ret svært at teste store programmer: Der er for mange forskellige udviklingsveje, og hver enkelt skal testes.
XDebug-applikationsfejlfindingsværktøjet, som navnet antyder, giver flere funktioner til visning af programtilstand og er et meget værdifuldt forskningsværktøj. Når det er installeret, griber XDebug ind for at forhindre uendelige rekursioner, tilføjer stak- og funktionssporingsoplysninger til fejlmeddelelser, overvåger hukommelsesallokering og udfører adskillige andre funktioner. Xdebug indeholder også et sæt funktioner, der kan føjes til kildekoden for at opnå diagnostiske data under kørslen.
Resultaterne af XDebug-modulet kan ses ved hjælp af KCachegrind-programmet, som giver dig mulighed for at visualisere de processer, der forekommer i kildekoden (se figur 3.1).
For at opsummere er XDebug et lille, men meget nyttigt værktøj til PHP-udvikleren og bør installeres på hver PHP-fortolker, der bruges til udvikling. Men du bør ikke bruge XDebug på produktionsservere, da dette vil reducere ydeevnen betydeligt.
R 
Figur 2.1. – KCachegrind-programgrænseflade
3.2.4 Enhedstest vha phpUnit
Enhedstest er en proces i programmering, der giver dig mulighed for at kontrollere individuelle moduler af et programs kildekode for korrekthed. Ideen er at skrive valideringstests for hver ikke-triviel funktion eller metode. Dette giver dig mulighed for hurtigt at kontrollere, om den næste kodeændring har ført til, at der opstår fejl i allerede skrevne og testede dele af programmet, og det gør det også lettere at opdage og eliminere sådanne fejl. Formålet med enhedstestning er at isolere individuelle dele af et program og vise, at disse dele fungerer individuelt.Ved debugging og test af programmet til behandling af spørgeskemaer til instituttets studerende blev phpUnit-systemet brugt, som giver mulighed for enhedstest af webapplikationer skrevet i PHP-programmeringssproget.
For at skrive et minimalt sæt af tests ved hjælp af phpUnit, skal du:
inkludere PHPUnit.php-biblioteket;
oprette en underklasse af TestCase-basisklassen;
tilføje et vilkårligt antal testmetoder, hvis navne begynder med "test". Kendte parametre vil blive leveret som input, og resultatet vil blive sammenlignet med referencen ved hjælp af Assert-familien af funktioner, nedarvet af testklassen fra TestCase-basisklassen;
opret PHPUnit_TestSuite-klassen, giv den navnet på klassen med et sæt tests som en parameter;
Kør et sæt test, og kontroller udførelsesresultatet.
6 (?). Liste over grafisk materiale
6.1 Problemstilling
6.2 Programblokdiagram
3. STRUKTURDIAGRAM FOR PROGRAMMET
De vigtigste funktioner, der skal implementeres i vores program, følger af formuleringen og analysen af problemet:
1)Visning af brugerdata i form af en tabel og arbejde med dem.
2) Tilføjelse og sletning af objekttyper.
3) Grafisk fremstilling af planen med mulighed for skalering.
4) Arbejde med filer og udskrivning af resultater.
5) Praktisk brugergrænseflade.
Nedenfor er et funktionelt blokdiagram af programmet, afbildet i form af hovedmoduler og forbindelser mellem dem. Det repræsenterer klart implementeringen af ovenstående krav i programmet.
Ris. 3.1. Funktionel struktur af programmet.
Hoveddelen af programmet er styre- og interfacegenereringsmodulet. Det repræsenterer hovedformen, hvorpå der er kontroller, der tillader andre funktioner at blive udført og også danner brugergrænsefladen.
4. GRUNDLÆGGENDE ALGORITMER
Hovedalgoritmen er at konstruere et billede ved hjælp af data fra hovedtabellen, implementeret i form af plandraw() metoden.
Nedenfor er dets blokdiagram og beskrivelse.
4.1 Beskrivelse af algoritmen
Hvis fanen med vores planbillede ikke er aktiveret, aktiverer vi den.
Vi forbereder en tabel over afstande, og rydder den for tidligere poster.
Vi indstiller baggrundsparametrene (farve) og tegner det, derefter indstiller vi penneparametrene (linjetykkelse og stil), som bestemmer visningen af rutelinjerne i tegningen. I begyndelsen er linjetykkelsen lig med en - til tegning af et koordinatgitter.
Ved at bruge egenskaben RecordCount table finder vi antallet af rækker i hovedtabellen.
Vi sætter den aktuelle rekordmarkør til den første, og organiserer en løkke gennem alle tabelposter, hvor vi tæller antallet af ruter.
Allerede i begyndelsen af cyklussen forbereder vi os på at vise skalaen - vi tildeler en forstørrelsesfaktor (i hele enheder) til skalavariablen, og for begge rullebjælker bestemmer vi den maksimale værdi, som afhænger af forstørrelsesgraden og størrelsen på billedet.
Hvis rutenummeret er nul, så er betingelsen for at tegne et koordinatgitter – meridianer og paralleller – opfyldt. Først udføres en cyklus med tegning af meridianer - vi går fra 0 til 360 grader i trin afhængigt af graden af forstørrelse (15, 6, 3 eller 1 grader), og nær hver meridian er den tilsvarende længdegrad underskrevet (østlig længdegrad - med et "+"-tegn), vestlig - med et "-"-tegn). Primmeridianen er afbildet i sort. Lignende handlinger udføres i cyklussen med at tegne paralleller, den eneste forskel er, at cyklussen løber fra 0 til 180 grader. "+"-tegnet angiver nordlig breddegrad, og "-"-tegnet angiver sydlig breddegrad.
Skift linjetykkelsen til 2 for at vise rutelinjer.
Vi opretter tre arrays, hvor vi indtaster indekserne for de aktuelle ruteposter og koordinater. Dernæst organiserer vi en løkke, hvor vi gennemgår tabelposterne og udfylder disse arrays for den aktuelle rute. Desuden indtastes allerede skalerede værdier i koordinatarrayerne. I samme cyklus tæller vi antallet af rutepunkter.
I den næste løkke sorterer vi indholdet af indeksarrayet, så vi derefter kan tegne waypointene i den rækkefølge, de vises i tabellen.
Indstil farven på linjen afhængigt af rutenummeret. Og vi organiserer en løkke, der tegner linjer.
I stregtegningscyklussen gør vi følgende: under hensyntagen til rullebjælkernes positioner beregnes vinduets position i forhold til kortet, og koordinaterne for punktet i vinduet beregnes i forhold til denne position. Hvis dette er vores første gennemløb, så flytter vi blot markøren til punktet med de beregnede koordinater, hvis ikke, og stregtegningsflaget er slået til, trækker vi en linje fra det forrige punkt til dette. Hvis afkrydsningsfeltet er deaktiveret, placeres kun punkter på kortet.
Derefter beregnes afstanden mellem punkter placeret på kloden, hvis projektioner vi netop har afbildet på vores kort. Afstande beregnes i kilometer, Jordens radius antages at være 6371 km. Afstanden beregnes, hvis i ikke er lig med 0, og dette er ikke første gang gennem cyklussen. Denne betingelse er nødvendig, fordi vi bruger koordinaterne for det foregående punkt til at finde afstanden til det nuværende.
Da jordens overflade er kugleformet, skal vi beregne længden af buen. Hovedproblemet her er at finde den vinkel, som buen hviler på.
Tre tilfælde behandles:
1) hvis punkterne er på samme længdegrad, er vinklen let at bestemme - den vil være lig med forskellen mellem de større og mindre breddegrader.
2) hvis punkterne er på samme breddegrad, så er dens bestemmelse heller ikke vanskelig - den er lig med forskellen mellem de større og mindre længdegradsværdier ganget med korrektionen cos(f), hvor f er den aktuelle breddegrad.
3) hvis punkterne er placeret på forskellige breddegrader og længdegrader, er dette tilfælde af at finde vinklen mere komplekst. Lad os se på det i detaljer.
Først finder vi forskellen i længdegraden af punkterne, som om de var på samme breddegrad, gange med korrektionen cos(f), og beregne den lineære afstand mellem dem ved hjælp af cosinussætningen (de to andre sider af trekanten er jordens radier). På samme måde beregner vi afstanden mellem punkter, som om de var på samme længdegrad. Vi betegner disse afstande som l1 og l2.
Nu har vi en retvinklet trekant med benene l1, l2, hvis hypotenus er afstanden l3. Vi beregner det ved hjælp af Pythagoras sætning. Vores mål er at finde vinkel a. Ved hjælp af cosinussætningen finder vi cosinus for denne vinkel. Efter at have beregnet buecosinus ud fra det, får vi vinklen! Nedenfor er en forklarende tegning.
Ris. 4.1. Forklaring af afstandsberegninger ved forskellige bredde- og længdegrader.
Efter at have fundet vinklen, beregner vi længden af buen og indtaster den resulterende afstand i afstandstabellen sammen med nummeret på den aktuelle rute.
Bemærk: da cosinus- og arccosinusfunktionerne fungerer med vinkler angivet i radianer, konverterer programmet radianer til grader og omvendt. Alle disse beregninger fører til akkumulering af fejl.
Alle nævnte formler er angivet i appendiks E.
Efter at have beregnet afstanden, viser vi den på planen ved siden af det aktuelle punkt, hvis det tilsvarende flag er tændt. På grund af betingelsen for at estimere længden af ruten viser figuren desuden ikke længden af et segment, men summen af længderne af de segmenter, der går forud for dette punkt. Brugeren kan se på længderne af individuelle segmenter i afstandstabellen.
Kortet viser også objekttypen for et givet punkt, hvis afkrydsningsfeltet "vis objekttype" er markeret.
Hvis afkrydsningsfeltet "vis ikke afstandstabel" er deaktiveret, skal du gøre det synligt.
Efter at alle ruterne er tegnet, frigør vi den hukommelse, der er allokeret til indeks- og koordinatarrays.
4.2 Algoritme-flowchart
Ris. 4.2. Flowchart af plantegningsalgoritmen.
5. SOFTWAREIMPLEMENTERING 5.1 Valg af et programudviklingsmiljø
Som allerede nævnt i "Problem Statement", blev Borland C++Builder 5-udviklingsmiljøet valgt til at oprette dette program. Denne beslutning skyldes det faktum, at processen med at skabe en grænseflade ikke er svær, selv for en programmør, der har stødt på Builder for første gang, og de fungerer godt med databaser og grafik, hvilket er præcis, hvad vi skal bruge for at udvikle vores program.
Ulempen er efter min mening programmets store eksekverbare kode - for at det kan fungere på en maskine, hvor Builder ikke er installeret, er det nødvendigt at inkludere alle de biblioteker, der bruges i det, hvorfor størrelsen af programmet bliver flere gange større.
Derudover er det gode ved Builder, at komponenter har mange egenskaber, som ikke kun kan ændres under byggeriet, men også under programafviklingen, hvilket gør arbejdet med dem mere fleksibelt.
5.2 Arbejde med tabeller
Vi bruger Paradox som databasedriver. Denne databasetype blev valgt først, fordi Builder har indbyggede værktøjer til at arbejde med Paradox-tabeller, såsom Borland Database Engine, og også kommer med Database Desktop-programmet. For det andet er fordelen ved Paradox, at databasenavnet kan angives som stien til det bibliotek, hvor tabelfilen er placeret, og alle tabeller gemmes i separate filer. For det tredje fylder de lidt og er de enkleste af de lokale borde. For det fjerde giver Paradox-tabeller dig mulighed for at oprette nøglefelter.
For at sikre arbejdet med bordet har vi installeret følgende komponenter på formularen:
Et DBGrid, hvormed vi kan indsætte, slette eller redigere data i en tabel eller blot vise dem.
En DBComboBox-liste, hvormed vi kan indsætte data fra objekttabellen i den aktuelle post i hovedtabellen. Før du bruger denne liste, skal den udfyldes med værdier fra objekttabellen. For at gøre dette, når vi starter programmet, gennemgår vi alle dets optegnelser og indtaster deres indhold i feltet Elementer på denne liste.
Navigator DBNavigator - med den kan du slette, tilføje, redigere poster i tabellen og også navigere gennem dem. Vi forbinder det til nettet, hvor vores bord vil blive vist.
Alle disse komponenter er forbundet til tabellen gennem DataSourse, i hvis egenskaber vi angiver dens navn. Desuden er selve bordet også repræsenteret som en komponent, tabel, hvor der skal lægges størst vægt på tre egenskaber:
1)Aktiv – viser om tabellen er aktiv. Hvis du forsøger at få adgang til den, hvis denne egenskab er deaktiveret, vil programmet generere fejlen "Kan ikke udføre denne handling på lukket datasæt". Under testen blev alle mulige situationer, der kunne føre til denne fejl, sporet og håndteret.
2) DatabaseName – navnet på databasen til den mappe, hvorfra tabellen blev åbnet eller oprettet.
3) TableName – navnet på tabellen – en fil med filtypenavnet .db, hvori tabellen er gemt.
Alle disse egenskaber ændres under programafvikling.
Vi har brug for tabelkomponenten for at slippe af med specifikationer. Vi kan, under dække af tabel, åbne enhver specifik tabel og kun ændre tabellens egenskaber uden at påvirke andre komponenter. For eksempel, når vi åbner en tabel, lukker og deaktiverer vi den forrige, mens databasenavnet og tabelnavnet i egenskaberne for tabelkomponenten slettes, og vi åbner og aktiverer en ny, skriver nye mappe- og filnavne til DatabaseName og Tabelnavn ved åbning. (Se metoderne TBpenFileClick og TBCloseFileClick i appendiks A).
DataSourse- og Table-komponenterne er placeret på formularen, men de er kun synlige, når du arbejder med programmet i Builder.
5.3 Arbejde med grafik
Til at tegne planen bruger vi Image-komponenten. Dette objekt har to vigtige egenskaber:
1)Picture – er et objekt af TPicture-klassen, som er en beholder til grafik af enhver art. De der. denne komponent kan gemme bitmap-grafik, ikoner eller anden brugerdefineret grafik. Billedet er, hvor vores tegning er placeret. Med dens hjælp gemmer vi den resulterende tegning i en fil. (Se appendiks A, TBSaveFileClick-metoden). Bemærk også, at billed- og billedstørrelserne muligvis ikke er de samme. Dette problem vil blive diskuteret mere detaljeret nedenfor.
2) Lærred - lærred. Hele tegneprocessen udføres på billedkomponentens lærred. Canvas giver dig mulighed for at indstille parametrene for pennen, penslen, skrifttypen, tegne objekter såsom linjer, rektangler, ellipser og også vise tekst.
I vores program bruger vi linjetegning ved hjælp af MoveTo- og LineTo-konturmetoderne, tegning af punkter ved hjælp af Ellipse og tekstoutput ved hjælp af TextOut-metoden. (Se bilag A, plantegning).
De der. canvas giver os mulighed for at arbejde med Windows GDI-funktioner uden at få direkte adgang til dem, hvilket gør arbejdet med grafik meget lettere.
5.4 Interfaceudvikling
Der bør også lægges særlig vægt på udviklingen af grænsefladen, da det er nødvendigt at gøre det brugervenligt. Builder-værktøjerne gør det nemt at implementere grænsefladen i Windows-standarder.
Hovedelementerne i standard Windows-programgrænsefladen:
1) Menuer - giver en nem måde for brugere at udføre logisk grupperede kommandoer.
Hovedmenuen oprettes ved hjælp af MainMenu-komponenten, og det er meget praktisk at redigere det, når du opretter et program, da du ikke behøver at køre det for at kontrollere det - alt dets indhold er allerede vist på formularen.
2) Værktøjslinje - indeholder værktøjsknapper, der svarer til punkter i programmets menu og giver brugeren mere direkte adgang til dets kommandoer.
Værktøjslinjen implementeres ved hjælp af ToolBar-komponenten, som giver dig mulighed for hurtigt at tilføje og placere knapper. Alle værktøjsknapper på værktøjslinjen har samme bredde og højde.
For hver knap kan du indstille et ikon, der viser den handling, den implementerer, ved at vælge ikonnummeret fra billederne, der er gemt i ImageList-komponenten. Dette er praktisk, fordi du nemt kan ændre ikonet uden at indlæse et ikon fra en fil hver gang.
I overensstemmelse med Windows-standarden oprettede jeg knapper på panelet svarende til menupunkterne "Ny", "Åbn", "Gem", "Udskriv".
3) Knapper - med deres hjælp starter brugeren udførelsen af den handling, der er tildelt denne knap.
Typisk, ifølge Windows-grænsefladestandarden, bruges knapper næsten aldrig for ikke at rode i programvinduet. I stedet bruges værktøjslinjer og menuer.
Men da vores program ikke udfører et særligt stort antal handlinger, kan vi også bruge knapper. Dette er praktisk, fordi de i modsætning til menuer er placeret ved siden af det element, i forhold til hvilket handlingen, de kalder, udføres (f.eks. er knapper til tilføjelse og sletning af objekter placeret ved siden af listen over objekter, og zoomknapper er ved siden af til billedet), hvilket naturligvis vil være praktisk for brugeren.
Derudover kan du sætte signaturer på dem, der forklarer deres formål, hvilket også er praktisk.
En knap oprettes ved at placere en knapkomponent på en formular. Når man udvikler et program, bruges dets Caption-egenskab - inskriptionen på knappen, og under kørsel bruges egenskaben Enabled til at gøre knappen inaktiv eller tværtimod til at aktivere den. (Se appendiks A, HideButtons() og ShowButtons()). For eksempel, når vi åbner et bord, aktiverer vi plantegningsknapperne, og når vi lukker, gør vi dem inaktive.
4) Rullelister – bruges til at give brugeren mulighed for at vælge et element fra en liste. Dette er meget mere praktisk end at indtaste det manuelt.
I dette program bruges en kombinationsboks til at indtaste en objekttype i tabellen (DBComboBox, diskuteret ovenfor) og til at fjerne en objekttype fra objekttabellen (ComboBox).
Forskellen mellem DBComboBox og ComboBox er, at den første er knyttet til et tabelfelt, og den anden er en simpel liste. Ved at bruge en simpel ComboBox-liste kan du løse de problemer med interaktion med tabellen og DBComboBox, der opstår, når du sletter et objekt fra tabellen.
5) Rullebjælker – implementeret ved hjælp af ScrollBox-komponenten i vores tilfælde er de nødvendige for at rulle planbilledet, når det er forstørret. Programmet ændrer Max parameteren, som bestemmer den maksimale rullemængde, afhængigt af skalaen.
6) Afkrydsningsfelter (switches) – afgør, om den mulighed, de repræsenterer, er aktiveret eller deaktiveret.
I Builder er dette CheckBox-komponenten.
I programmet bestemmer afkrydsningsfelter, om følgende funktioner er aktiveret eller deaktiveret:
Tegning af rutelinjer;
Visning af afstanden på planen;
Visning af objekttypen på planen;
Vis afstandstabel.
Afkrydsningsfelterne findes normalt i indstillingsmenuen. Men på grund af vores programs enkelhed vises de på panelet ved siden af tegnefeltet, hvilket er meget praktisk for brugeren.
7) Faner - i dette program er bordet og plantegningen placeret på forskellige faner. Jeg tror, at dette vil være mere bekvemt for brugeren, da hele programmet er indeholdt i et vindue, og samtidig er både bordområdet og tegneområdet ikke placeret til skade for hinanden.
Der er to typer faner i Builder: TabControl og PageControl.
Programmet bruger PageControl, da denne komponent i modsætning til den første kan indeholde heterogene kontroller på faner. I TabControl er alle sider ens.
8) Dialoger er et meget praktisk værktøj, der hjælper med at implementere dialoger med brugeren som at gemme, åbne en fil, udskrive og vælge en farve, der bruges i dette program.
Alle nødvendige dialogbokse er placeret på formularen, men forbliver usynlige for brugeren. De kaldes af programmet og implementerer standard Explorer-grænsefladen.
Ved at bruge dialogboksene OpenDialog og SaveDialog modtager programmet navnet på den fil og den mappe, som brugeren vælger. Ved hjælp af PrintDialog kaldes udskrivningsindstillinger frem. Og ColorDialog hjælper dig med at vælge en farve (den bruges til at vælge baggrundsfarven på billedet).
Formålet med hver brugersynlig grænsefladekomponent er beskrevet i brugermanualen.
Det er værd at bemærke, at hvert grænsefladeobjekt har en egenskab kaldet Align. Det giver dig mulighed for at justere et kontrolelement til højre, venstre, toppen eller bunden af en formular og et panel, og kontrolelementet forbliver der, selvom formularens størrelse ændres. For eksempel er panelet med knapper i nærheden af billedet justeret til højre, tabellen over afstande er justeret til venstre, og billedets felt er justeret til alClient, som optager al den ledige plads mellem bordet og panelet . Når du strækker formularen, strækkes disse kontroller også, mens de forbliver på plads.
Det er praktisk at bruge egenskaben Align, fordi du på designstadiet kan arrangere komponenterne efter behov, og så behøver du ikke manuelt at indstille deres størrelser, hver gang formen ændres.
5.5 Nogle funktioner i algoritmerne
Tegnealgoritme
Da det allerede er blevet beskrevet i nogen detaljer, vil jeg kun tilføje en bemærkning om dets udvikling: det tegner et kort i en konform projektion. De bevarer vinklernes lighed mellem retningerne på kortet og i naturen. Samtidig er territoriernes dimensioner fordrejet.
Denne type projektion blev valgt, fordi det er nemmest at tegne et koordinatgitter til det, da det består af lige linjer. (Se appendiks E for mere information om kortprojektioner og gitterkoordinater.)
Afstande beregnes i rigtige størrelser.
Algoritme til beregning af afstand.
Det er også beskrevet detaljeret i "Beskrivelse af algoritmen". Det er en del af tegnealgoritmen.
Det blev afledt af forfatteren af programmet, da dets analoger ikke blev fundet nogen steder. Dens ejendommelighed er, at det er nødvendigt at tage højde for krumningen af jordens overflade og beregne længden af buen. Dette er især svært, hvis punkterne er placeret på samme bredde- og længdegrad.
En kugle tages som formen af jordens overflade. Dette kan føre til fejl, da jordens form faktisk er en ellipsoide, men det forenkler beregningerne meget. Jordens gennemsnitlige radius antages at være 6371 km. Dette giver en fejl på omkring 0,3 %.
Det skal også bemærkes, at for at beregne afstanden, især i det mest komplekse tilfælde, bruges flere sekventielle beregninger, som et resultat af, at fejlen akkumuleres. Størrelsen af fejlen påvirkes også af konverteringen af gradmålet for en vinkel til radianer og omvendt. Men med den moderne nøjagtighed af computerberegninger vil denne fejl være lille, og desuden indikerede opgaven ikke, at ruteestimatet skulle være nøjagtigt.
Oprettelse af et bord
Her skal det siges, at jeg ikke har fundet en algoritme til at oprette en tabel programmatisk i nogen bog jeg har. Al litteraturen talte om at oprette tabeller i DatabaseDesktop, hvilket ville være ubelejligt for brugeren at installere et endnu større program bare for at løse problemet med at oprette nye tabeller.
Men alligevel blev denne algoritme fundet i Builder-hjælpen, selvom den indeholdt fejl der.
Programmet præsenterer også et fungerende eksempel på det (se appendiks A, TBNewFileClick).
Som en funktion af denne algoritme skal det bemærkes, at før du kalder tabeloprettelsesproceduren CreateTable(), skal du initialisere alle felter med angivelse af deres navn, type, længde (hvis påkrævet) og den påkrævede værdi (om det er påkrævet) eller ikke) . Efter initialisering af felterne erklærer vi et nøglefelt og kalder først derefter tabeloprettelsesproceduren. Herefter skal du binde den nye tabel til tabelkomponenten, så du kan arbejde med den ved hjælp af gitteret og navigatoren. Filnavnet på den nye tabel anmodes om ved hjælp af SaveDialog.
Problem med grafikstørrelse
Under udviklingen af programmet opstod der et ret alvorligt problem med at tegne et billede - ved ændring af formstørrelsen skulle størrelsen på billedet have ændret sig, men det skete ikke.
Årsagen var, at størrelsen på billedkomponenten stadig ændrede sig, men størrelsen på billedet forblev den samme. I den forbindelse blev ResizeForm-proceduren oprettet (se bilag A), som reagerede på ændringer i formularens størrelse og ændrede størrelsen på billedet i overensstemmelse med den ændrede størrelse af billedkomponenten.
5.6 Test
Under hele designet af programmet blev det testet og fejlrettet. Der blev lagt særlig vægt på to punkter - rigtigheden af at arbejde med tabeller og rigtigheden af at tegne en plan.
Når du arbejdede med tabeller, var det første skridt at spore eventuelle problemer i forbindelse med åbning, oprettelse af tabeller og tegning. For eksempel, hvis du ikke deaktiverer tegneknapperne, kan det føre til en fejl at klikke på dem, mens bordet ikke er åbent. For at eliminere denne fejl, hvis der ikke er et åbent bord, gøres knapperne inaktive.
En anden vigtig fejl, der er blevet rettet, er problemet med grafikstørrelsen (se ovenfor).
Det var også nødvendigt at sikre, at ved deaktivering/aktivering af afkrydsningsfelter og ændring af formularens størrelse, ville der ikke blive tegnet et billede, hvis brugeren endnu ikke havde klikket på "tegn"-knappen. Denne sporing udføres i programmet af tegneflaget, som indstilles, når brugeren klikker på tegneknappen, og slettes, når der klikkes på sletknappen. Under testprocessen blev alle situationer, hvor det var nødvendigt at kontrollere dette flag, overvåget og fejlrettet.
Det vigtigste aspekt ved testning var at tjekke programmets funktionalitet på en computer, der ikke har Builder installeret. Dette hjalp med at bestemme følgende:
1) når du kompilerer et program, skal du inkludere alle de anvendte biblioteker. Dette opnås ved at deaktivere to muligheder i compilerindstillingerne. Samtidig bliver programmets eksekverbare kode større, men det kan også fungere på en maskine uden Builder.
2) programmet kræver Borland Database Engine. Hvis det ikke er på din computer, skal du installere det.
6. PROGRAMBESKRIVELSE
Programmet er beregnet til at give informationsstøtte til oprettelse af en siteplan. Det giver dig mulighed for at gemme data om planpunkter i en tabel, vise dem grafisk, oprette en ny tabel, tilføje og slette typer objekter, beregne afstande og estimere længden af en rute, tegne flere ruter, gemme resultaterne i en fil eller Print.
Programmet er skabt til Windows-operativsystemet og har en standardiseret og brugervenlig grænseflade. Sammen med det følger et eksempel i form af en tabel med togstrækninger.
7. INSTALLATIONSVEJLEDNING
For at installere programmet skal følgende krav være opfyldt: processor 233 MHz eller højere, RAM 16 MB, OS Windows98 eller højere.
For at installere programmet skal du gøre følgende:
1) Opret en ny mappe til programmet.
2) Fra det medie, som programarkivet er placeret på (diskette eller diskette), kopier det til denne mappe.
3) Pak arkivet ud i denne mappe.
4) Sørg for, at filerne objects.db og rasst.db er i samme mappe som programmet.
5) Sørg for, at "Read Only"-attributten er ryddet for disse filer. Hvis ikke, fjern den.
6) Pak arkivet med biblioteker ud i Windows-mappen.
7) Nu kan du starte programmet og bruge det.
8. BRUGERVEJLEDNING 8.1 Hovedmenu "Filer" menu
For at begynde at arbejde i programmet skal du åbne en fil med en tabel eller oprette en ny. Dette kan gøres ved at bruge menupunkterne Filer, Åbn og Ny.
"Åben" - åbn en eksisterende tabel. Kalder en dialog frem, hvor brugeren skal vælge en fil med filtypen .db.
"Ny" - oprettelse af en ny tabel. En dialog kaldes, hvor brugeren angiver navnet på den nye tabel.
"Udskriv" - afhængigt af den åbne fane, udskriver et billede eller en tabel. Når du vælger dette punkt, åbnes dialogboksen for udskriftsindstillinger, efter at du har klikket på knappen "OK", sendes jobbet til udskrivning.
Tabel menu
"Byg plan" - hvis bordet er åbent, aktiverer fanen "Plan" og tegner en plan.
"Tilføj objekttype" - kalder formularen til tilføjelse af en objekttype.
"Slet objekttype" - kalder formularen til sletning af en objekttype.
Hjælp menu
"Om programmet" - viser navnet på programmet og oplysninger om forfatteren.
8.2 Hurtigknappanel
Disse knappers handlinger ligner elementerne med samme navn i menuen "Filer".
- "Ny" - oprettelse af en ny tabel.
- "Åbn" - åbner en eksisterende tabel.
- "Udskriv" - udskriv et billede eller en tabel.
8.3 Tabel faneblad
Tabelgitter – bordet er indlæst i det. Ved at bruge dette gitter kan brugeren redigere og se tabelposter.
Navigator – placeret under gitteret, giver dig mulighed for at redigere og se tabellen.
Navigator knapper
- "Første post" - flytter til den første post i tabellen.
- "Forrige post" - flytter til den forrige post i tabellen.
- "Næste post" - flytter til næste post i tabellen.
- "Sidste post" - flytter til den sidste post i tabellen.
- "Tilføj post" - tabellen sættes i redigeringstilstand, en ny tom post indsættes før den aktive post.
- "Slet post" - sletter den aktuelle post, efter at have anmodet om bekræftelse.
- "Rediger" - redigering af den aktuelle post.
- "Annuller ændringer" - annullerer ændringer til den aktuelle post og returnerer dens tidligere værdi.
- "Opdater". Opdaterer en tabel i et gitter.
Under navigatoren er der en liste over objekter og knapper til sletning og tilføjelse af objekter.
Liste over objekter – indeholder en liste over objekttyper. Når du vælger en type fra listen, indtastes den i den aktuelle post i tabellen.
Tilføj objekttype – kalder tilføjelsestypeformen. Når du tilføjer det, tilføjes det straks til listen.
Slet objekttype – kalder formularen til sletning af en objekttype.
Tilføj objekttypeformular
Indeholder et redigeringsfelt til indtastning af tekst, hvori navnet på den nye type er indtastet.
"Tilføj" - tilføjer en objekttype til listen og tabellen uden at lukke formularen.
"Ok" - hvis objektet ikke er tilføjet, indtaster du det i listen og tabellen og lukker formularen.
"Annuller" - lukker formularerne uden at tilføje.
Slet objekttypeformular
Liste over objekter - fra den vælger brugeren hvilket objekt der skal slettes.
"Slet" - sletter den valgte objekttype fra tabellen og listen.
"Slet alle" - rydder fuldstændig objekttabellen og listerne.
"OK" - lukker formularen.
8.4 Fanen "Plan".
Tegnefelt er det område, hvor plantegningen vises.
Rullebjælker – vises, når du forstørrer et billede ved at klikke på knappen "Forstør". Giver dig mulighed for at rulle det forstørrede billede.
Afstandstabel – viser for hver rute dens nummer og længden af segmenterne i kilometer. Tabellen er synlig, hvis afkrydsningsfeltet "Skjul afstandstabel" er fjernet.
"Ryd kort" - rydder billedfeltet.
"Tegn" - tegner en plan.
"Baggrundsfarve" - giver dig mulighed for at vælge baggrundsfarven på billedet. Når du klikker på denne knap, vises en farvevalgsdialogboks.
"+ Forstør" - forstørrer billedet på planen.
"- Zoom ud" - reducerer billedet på planen. Denne knap bliver aktiv, når du trykker på øgningsknappen.
"Standard" - indstiller den oprindelige billedstørrelse.
"Tegn rutelinjer" - hvis det er markeret, vil ruter blive tegnet på planen, hvis ikke, vil kun punkter blive angivet.
"Vis afstande på kort" - hvis afkrydsningsfeltet er markeret, vises afstanden ud for hvert rutepunkt i form af summen af længderne af segmenterne forud for dette punkt. "0" er placeret nær det første punkt på ruten.
"Vis objekttype på kort" - hvis afkrydsningsfeltet er markeret, vises objekttypen ud for hvert punkt.
"Skjul afstandstabel" - hvis afkrydsningsfeltet er markeret, er afstandstabellen usynlig. Hvis den er ryddet, vises tabellen til højre for tegnefeltet.
Alle afkrydsningsfelter er markeret som standard.
9. TESTCASE
Som et testeksempel vil vi afbilde ruterne for flere tog på Gorky Railway.
Lad os tage følgende tog:
N 497G Gorky-Mosk - Adler
N 471G Gorky-Mosk - Novorossiysk
N 431G Gorky-Mosk - Adler
N 367G Gorky-Mosk - Samara
N 059A Gorky-Mosk - Skt. Petersborg-Glavn
N 039G Gorky-Mosk - Moskva Kursk
Lad os i tabellen indtaste koordinaterne for de største befolkede områder som punkter på hver rute. Vi vil bruge bynavne som objekter.
Ris. 9.1. Generel visning af programmet på fanen "Tabel", indtastning af navnet på et objekt i en post ved hjælp af en liste.
Tidligere føjede vi Red Knot-stationen til objekttabellen, men da vi ikke har brug for den, sletter vi den.
Ris. 9.2. Slet en objekttype.
Når vi ringer til ruten for tog 431, har vi brug for Vladimir. Da det ikke er på listen, skal du tilføje det.
Ris. 9.3. Tilføjelse af en objekttype.
Så vi samlede alle de ruter, vi ønskede. Som et resultat endte vi med et bord som dette.
Ris. 9.4. Bord
Nu, ved hjælp af vores tablet, vil vi bygge en plan.
Ris. 9.5. Billede af planen med alle inskriptioner.
Som standard viser vi linjer, afstande og bynavne.
Lad os se, hvordan ruterne vil se ud uden signaturer.
Ris. 9.6. Billede af planen uden alle inskriptioner.
Lad os nu lige se på afstandene.
Ris. 9.7. Billede af planen med kun afstande.
Faktisk blev de ikke beregnet særlig nøjagtigt, men det skyldes, at vi ikke tog højde for alle punkterne på disse ruter, og også de koordinater, der blev taget, var ikke helt korrekte - de blev bestemt fra kortet "ved øje".
Lad os nu se på vores plan med kun navnene på byer.
Ris. 9.8. Billede af planen, der kun viser typer objekter.
Ris. 9.9. Billede af planen i form af prikker med alle signaturer.
Du kan også se en tabel over afstande.
Ris. 9.11. Generel visning af programmet på fanen "Plan" med en synlig tabel over afstande.
KONKLUSION
Opgaven i opgaven med bachelorarbejdet blev gennemført med succes. Det udviklede program opfylder fuldt ud de indledende betingelser beskrevet i problemformuleringen. Programmet implementerede især arbejde med tabeller, grafik og filer.
Programbrugerens arbejde udføres ved hjælp af en simpel grænseflade lavet i henhold til Windows programgrænsefladestandarder.
Yderligere forbedringer og udvidelse af mulighederne i dette projekt omfatter tilføjelsen af beregning af den korteste rute, tegning af ikoner af objekter, reliefbilleder og muligheden for at indlæse et kortbillede som baggrund.
BIBLIOGRAFI
1. P. Gustafson, M. Cashman, B. Swart, J. Holingworth. Borland C++ Builder 6. Udviklervejledning. – Williams, 2004.
2. A. Arkhangelsky. Programmering i C++ Builder 6. – Binom, 2002.
3. T.A. Pavlovskaya. C/C++. Programmering på et højt niveau sprog. – Peter, 2001.
APPENDIKS APPENDIKS E. Kortprojektioner og gitterkort
Det er umuligt at udfolde en sfærisk overflade på et plan uden brud og folder, det vil sige, at dets planbillede på et plan ikke kan repræsenteres uden forvrængninger med fuldstændig geometrisk lighed af alle dets konturer. Fuldstændig lighed mellem konturerne af øer, kontinenter og forskellige objekter projiceret på en plan overflade kan kun opnås på en bold (globe). Billedet af Jordens overflade på en kugle (globe) er lige i skala, lige i vinkel og lige store.
Det er umuligt samtidigt og fuldstændigt at bevare disse geometriske egenskaber på kortet. Et geografisk gitter bygget på et plan, der viser meridianer og paralleller, vil have visse forvrængninger, så billederne af alle objekter på jordens overflade vil blive forvrænget. Arten og omfanget af forvrængninger afhænger af metoden til at konstruere det kartografiske gitter, som kortet er kompileret ud fra.
Visningen af overfladen af en ellipsoide eller kugle på et plan kaldes en kortprojektion. Der findes forskellige typer kortprojektioner. Hver af dem svarer til et specifikt kartografisk gitter og dets iboende forvrængninger. I en type projektion er dimensionerne af områder forvrænget, i en anden - vinkler, i en tredje - områder og vinkler. I dette tilfælde, i alle fremspring, uden undtagelse, er længderne af linjerne forvrænget.
Kartografiske projektioner er klassificeret efter arten af forvrængning, typen af billede af meridianer og paralleller (geografisk gitter) og nogle andre karakteristika. Baseret på arten af forvrængninger skelnes følgende kortprojektioner:
Ensvinklet, bevarer vinklernes lighed mellem retninger på kortet og i naturen. Figur E.1 viser et verdenskort, hvor det kartografiske gitter bevarer egenskaben ækvikantet. Kortet bevarer ligheden i hjørnerne, men størrelserne på områderne er forvrænget. For eksempel er områderne Grønland og Afrika på kortet næsten de samme, men i virkeligheden er Afrikas areal omkring 15 gange Grønlands areal.
Fig.E.1 Verdenskort i konform projektion.
Lige i størrelse, bevarer proportionaliteten af områderne på kortet til de tilsvarende områder på jordens ellipsoide. Figur E.2 viser et kort over verden tegnet i en projektion med lige areal. Det bevarer proportionaliteten af alle områder, men ligheden mellem tallene er forvrænget, det vil sige, at der ikke er nogen ækvikantethed. Den indbyrdes vinkelrethed af meridianer og paralleller på et sådant kort er kun bevaret langs den midterste meridian.
Equidistant, opretholdelse af en konstant skala i enhver retning;
Vilkårlig, bevarer hverken vinklernes lighed, områdernes proportionalitet eller skalaens konstanthed. Pointen med at bruge vilkårlige projektioner er en mere ensartet fordeling af forvrængninger på kortet og bekvemmeligheden ved at løse nogle praktiske problemer.
Ris. E. 2 Verdenskort i lige areal projektion.
Baseret på typen af billede er gitteret af meridianer og paralleller af en kortprojektion opdelt i koniske, cylindriske, azimutale osv. Desuden kan der inden for hver af disse grupper være projektioner af forskellig karakter af forvrængning (konform, lige-areal) , etc.). Den geometriske essens af koniske og cylindriske fremspring ligger i det faktum, at et gitter af meridianer og paralleller projiceres på den laterale overflade af en kegle eller cylinder med den efterfølgende udbredelse af disse overflader i et plan. Den geometriske essens af azimutprojektioner ligger i det faktum, at et gitter af meridianer og paralleller projiceres på et plan, der tangerer kuglen ved en af polerne eller sekanterer langs en parallel. Den kartografiske projektion, der er bedst egnet med hensyn til arten, størrelsen og fordelingen af forvrængninger for et bestemt kort, vælges afhængigt af formålet, indholdet af kortet, samt størrelsen, konfigurationen og geografiske placering af det kortlagte territorium. Takket være det kartografiske gitter påvirker alle forvrængninger, uanset hvor store de måtte være, ikke i sig selv nøjagtigheden af at bestemme den geografiske position (koordinater) af objekterne afbildet på kortet på kortet. Samtidig giver det kartografiske gitter, som er et grafisk udtryk for projektionen, mulighed for at tage hensyn til arten, størrelsen og fordelingen af forvrængninger, når der foretages målinger på kortet. Derfor er ethvert geografisk kort et matematisk bestemt billede af jordens overflade.
Personlige datterselskaber af Aginsky Buryat Autonomous Okrug for 2005 - 2010," som blev udarbejdet i et udkast. 4. Hovedretningslinjerne for at forbedre regeringsorganernes aktiviteter til at støtte personlige underliggende grunde af landbefolkningen i Aginsky Buryat Autonome Okrug 4.1 Problemer og prioriteter for udviklingen af personlige datterselskaber i Aginsky...
Studiet af familier har ført til udviklingen af psykologiske, pædagogiske og sociologiske metoder, der uddyber og udvider ideer om den moderne familie. KAPITEL 3. SOCIALE PROBLEMER OG UDSIGT FOR SOCIALT ARBEJDE MED UNGE FAMILIER I LANDSBYEN VORONOVKA 3.1 Generelle karakteristika s. Voronovka, Shegarsky-distriktet, Tomsk-regionen, Shegarsky-distriktet ligger i den sydlige del af Tomsk...
Forsørgelse og støtte til børn; - i øjeblikket er der i Rusland udviklet og implementeret en mekanisme til finansiering af målrettede programmer til støtte for moderskab og barndom. 2. Finansiel mekanisme til gennemførelse af statens politik til støtte for moderskab og barndom 2.1 Proceduren og betingelserne for udbetaling af sociale ydelser Til dato har Rusland udviklet et ret udviklet system af ydelser, ...