Investeringer 

Programvare blokkdiagram. Blokkdiagram over programvaren som utvikles. Kvalitetsvurderingskriterier

KURSPROSJEKT

i disiplinen "Programmering i et språk på høyt nivå"

Utvikling av et programvareverktøy for langsiktig lagring og behandling av informasjon ved å bruke eksemplet på spillet "Hester"

Forklarende merknad

OSU 27.03.03.0316.000PZ

Veileder

lærer

V. V. Chekrygina “___”_____ 2016

Elev av gruppe 14SAU(ba)SAUIT ____ _________I.O. Etternavn

"__"____________ 2016

Orenburg 2016


merknad

Kursarbeidet inneholder 18 sider, inkludert 4 figurer, 5 kilder og en programoversikt.

Dette kursarbeidet undersøker i detalj teknologien for å lage et programvareprodukt ved å bruke det objektorienterte programmeringssystemet Delphi. Eksisterende objektorienterte programmeringsspråk blir kort gjennomgått. Det er laget en beskrivelse av de tekniske spesifikasjonene og selve algoritmeprogrammet. På slutten av arbeidet presenteres testing av programvareproduktet og dets liste.


Introduksjon. 5

1 Tekniske spesifikasjoner. 6

2 Beskrivelse av programmet.. 7

3 Brukerhåndbok... 9

4 Testing av programmet.. 10

Konklusjon. elleve

Liste over kilder som er brukt. 12

Vedlegg A... 13


Introduksjon

For tiden er det objektorienterte programmeringssystemet Delphi populært blant et bredt spekter av brukere, som er grunnlaget for Object Pascal-språket, som opprinnelig ble utviklet av N. Wirth på begynnelsen av 60-tallet av forrige århundre, spesielt som et språk for undervisning. programmering. Delphi lar deg raskt lage applikasjoner av ulik grad av kompleksitet basert på visuell programmeringsteknologi.



Delphi-systemet legemliggjør de beste prestasjonene til moderne programmeringsteori. Dette integrerte miljøet kombinerer mange nyttige verktøy og ferdige komponenter som brukerprogrammer - prosjekter - er satt sammen av. Delphi er et visuelt programvareutviklingsmiljø. Dette betyr at hvert programs utseende (grensesnitt) skapes ved å flytte rundt på komponenter.

Det grunnleggende programmeringsspråket er Object Pascal - objektorientert Pascal. Den grunnleggende forskjellen mellom programmeringssystemene Delphi og Turbo Pascal (Turbo er et varemerke for systemutvikleren Borland International, Inc. (USA)) er bruken av skjermens skjermmodus: Turbo Pascal er fokusert på tekstmodusen til DOS-system, og Delphi, som Windows, er fokusert på grafikk. Derfor kan en av de nyeste versjonene av Delphi 7 allerede lage applikasjoner for det nyeste .NET-miljøet. Dessuten tillater de nyeste versjonene programmering for Linux-operativsystemet.

Delphi-systemet implementerer objektorientert virtuell programmeringsteknologi (OOP). Det skiller seg fra alle andre programmeringsspråk ved sin strenghet i å definere alle variabler og konstanter, modulær programmering, gode muligheter til å lage dine egne datastrukturer, bruken av objektorientert programmering og fraværet av maskinorienterte konstruksjoner. Borland Corporation, som er grunnleggeren av Delphi, stolte helt fra begynnelsen på visuell objektorientert programmering med muligheten til å jobbe med hvilken som helst database. For øyeblikket er programmeringssystemet Delphi på ingen måte dårligere i sine evner enn programmeringsspråk som C++, C#, Visual C++, C–Builder, Visual Basic, etc.


1 Mandat

Oppgaven ble satt: å utvikle et spill med temaet hesteveddeløp på en hippodrome i Delphi-miljøet med et organisert spillsystem.

I prosessen med å løse dette problemet mottok vi følgende søknad:

Det er 5 hester som skal løpe i en rett linje, med en organisert bevegelsesanimasjon bestående av 2 bilder, og det skal også være en spilleautomat. Hester må vinne i forskjellige rekkefølger.

Spillerens oppgave er å vinne så mye "penger" som mulig på spillebordet.

Minimumskrav for å bruke programmet: IBM-kompatibel 486dx eller høyere, 5 MB. ledig harddiskplass, OS Win9x/Me, Win2000/XP/Vista/Seven.

Programmet gir:

Mulighet med null saldo, kan du ta opp gjeld;

Hester beveger seg i forskjellige hastigheter og det er umulig å vite vinneren på forhånd.


2 Beskrivelse av programmet

Programblokkskjema

Figur 1 viser plasseringen av hovedprogramelementene, slik ser hovedvinduet til programvareproduktet ut.

Figur 1 – Hovedprogramvindu

I konseptet programstruktur (program struktur) inkluderer sammensetningen og beskrivelsen av tilkoblingene til alle moduler som implementerer de uavhengige funksjonene til programmet og en beskrivelse av media for inn- og utdata, samt data som deltar i utvekslingen mellom individuelle subrutiner.

For å utvikle store og komplekse programmer, må programmereren mestre spesielle teknikker for å oppnå en rasjonell programstruktur, som sikrer en nesten to ganger reduksjon i mengden programmering og en multippel reduksjon

Underordningen av programmoduler gjenspeiles i hierarkidiagrammet. Sistnevnte gjenspeiler imidlertid ikke rekkefølgen de kalles i eller hvordan programmet fungerer. Hierarkidiagrammet kan se ut som vist i fig. 5. Det er vanligvis supplert med en dekoding av funksjonene som utføres av modulene.

Før du lager et hierarkidiagram, er det lurt å utarbeide eksterne spesifikasjoner av programmet og skrive funksjonsbeskrivelser av programmet sammen med en beskrivelse av databærervariablene. Spesiell oppmerksomhet bør rettes mot hierarkiet av strukturerte datatyper og deres kommentarer.

Inndelingen av programmet i delprogram gjennomføres etter prinsippet fra generelt til spesifikt, mer detaljert. Prosessen med å kompilere en funksjonell beskrivelse og tegne et hierarkidiagram er iterativ, og å velge det beste alternativet er multi-kriterier. Disseksjonen skal gi en praktisk rekkefølge for å sette deler i drift.

Hierarkidiagrammet kan gis hvilken som helst topologisk design. Fragmenter med vertikale samtaler kan konverteres til samtaler på ett nivå ved å introdusere en ekstra modul, som kanskje ikke utfører noen nyttige funksjoner sett fra programalgoritmens synspunkt. Funksjonen til en ny modul kan bare være overvåking, det vil si å kalle andre moduler i en bestemt rekkefølge.

Fragmenter med horisontale samtaler på ett nivå kan konverteres til vertikale kall til moduler på forskjellige nivåer ved å introdusere tilleggsvariabler som ikke kunne oppnås ved å dekomponere funksjonsbeskrivelsen i underfunksjoner. Disse tilleggsvariablene er vanligvis av typen heltall eller boolsk og kalles flagg, semaforer eller hendelsesnøkler. Betydningen deres er vanligvis preget av uttrykket: avhengig av følgende handlingshistorie, utfør slike og slike handlinger.

Under designprosessen må du lage flere designiterasjoner, hver gang generere et nytt hierarkidiagram, og sammenligne disse hierarkiene i henhold til disse kriteriene for å velge det beste alternativet.

Nøkkel - verdien av en variabel som brukes til å bekrefte autoritet til å få tilgang til noe informasjon eller rutine.

Flagg- en variabel hvis verdi indikerer at en maskinvare- eller programvarekomponent er i en bestemt tilstand eller at en bestemt betingelse er oppfylt for den. Flagget brukes til å implementere betinget forgrening og andre beslutningsprosesser.

Semafor - en spesiell datatype som er et middel for å kontrollere tilgang til en kritisk ressurs ved samtidige sekvensielle prosesser.

Bare to operasjoner kan utføres på en semafor (ikke medregnet opprettelse og kansellering): vente operasjon(klasser) og alarmdrift(frigjøring). Semaforen aksepterer en heltallsverdi som ikke kan være negativ. Venteoperasjonen reduserer semaforverdien med én når det kan gjøres uten å resultere i en negativ verdi, og dette betyr at den ledige ressursen blir brukt. Signaleringsoperasjonen øker semaforverdien med én, noe som betyr at ressursen frigjøres.

Kritisk ressurs- en ressurs som ikke brukes av mer enn én prosess til enhver tid. Når det kreves flere asynkrone prosesser for å koordinere deres tilgang til en kritisk ressurs, brukes kontrollert tilgang gjennom en semafor.

Et sett med programmer utviklet for å løse problemer på en PC kalles programvare. Sammensetningen av PC-programvare kalles programvarekonfigurasjon. Programvare kan deles inn i tre kategorier (fig. 1):

Figur 1. Programvareklassifisering

    systemprogramvare (programmer for generell bruk) som utfører ulike hjelpefunksjoner, som å lage kopier av brukt informasjon, gi hjelpeinformasjon om datamaskinen, kontrollere funksjonaliteten til datamaskinenheter, etc.

    applikasjonsprogramvare som gir nødvendig arbeid på en PC: redigere tekstdokumenter, lage tegninger eller bilder, behandle informasjonsmatriser, etc.

    verktøyprogramvare (programmeringssystemer) som sikrer utvikling av nye dataprogrammer i et programmeringsspråk.

Systemprogramvare er et sett med programmer som gir effektiv styring av datasystemkomponenter, for eksempel prosessor, RAM, inngangs-/utgangsenheter, nettverksutstyr, som fungerer som et "mellomlagsgrensesnitt", på den ene siden av maskinvaren, og på den andre, brukerapplikasjoner. I motsetning til applikasjonsprogramvare, løser ikke systemprogramvare spesifikke applikasjonsproblemer, men sikrer bare driften av andre programmer, administrerer maskinvareressursene til datasystemet, etc.

Disse programmene for generell bruk er ikke knyttet til en spesifikk PC-applikasjon og utfører tradisjonelle funksjoner: planlegging og oppgaveadministrasjon, I/O-administrasjon, etc. Med andre ord, systemprogrammer utfører ulike hjelpefunksjoner, for eksempel å lage kopier av brukt informasjon, gi hjelpeinformasjon om datamaskinen, sjekke funksjonaliteten til datamaskinenheter, etc. Systemprogramvaren inkluderer:

    operativsystemer (dette programmet lastes inn i RAM når datamaskinen slås på)

    shell-programmer (gir en mer praktisk og visuell måte å kommunisere med en datamaskin enn å bruke DOS-kommandolinjen, for eksempel Norton Commander)

    operasjonsskall er grensesnittsystemer som brukes til å lage grafiske grensesnitt, multiprogrammering, etc.

    Drivere (programmer utviklet for å kontrollere porter for eksterne enheter, vanligvis lastet inn i RAM når datamaskinen starter)

    verktøy (hjelpe- eller hjelpeprogrammer som gir brukeren en rekke tilleggstjenester)

Verktøy inkluderer:

    filbehandlere eller filbehandlere

    verktøy for dynamisk datakomprimering (lar deg øke mengden informasjon på disken på grunn av dens dynamiske komprimering)

    visnings- og avspillingsverktøy

    diagnostiske verktøy; overvåkingsverktøy lar deg sjekke datamaskinens konfigurasjon og kontrollere funksjonaliteten til datamaskinenheter, først og fremst harddisker

    kommunikasjonsverktøy (kommunikasjonsprogrammer) er laget for å organisere utveksling av informasjon mellom datamaskiner

    Datasikkerhetsverktøy (sikkerhetskopiering, antivirusprogramvare).

Utilities er programmer utviklet for å løse et smalt utvalg av hjelpeoppgaver.

Noen ganger er verktøy klassifisert som serviceprogramvare

Verktøy brukes til:

    Overvåking av sensorindikatorer og utstyrsytelse - overvåking av prosessor- og videoadaptertemperaturer; leser S.M.A.R.T. harddisk;

    Administrere utstyrsparametere - begrense den maksimale rotasjonshastigheten til CD-stasjonen; endre viftehastighet.

    Overvåkingsindikatorer - kontroll av referanseintegritet; riktigheten av dataregistreringen.

    Utvidede muligheter - formatering og/eller re-partisjonering av disken mens du lagrer data, sletting uten mulighet for gjenoppretting.

Typer verktøy:

Diskverktøy

      Defragmentere

      Diskskanning - søk etter filer og diskområder som ble feil registrert eller skadet på forskjellige måter og påfølgende fjerning for effektiv bruk av diskplass.

      Diskopprydding - sletting av midlertidige filer, unødvendige filer, tømming av papirkurven.

      Diskpartisjonering er oppdelingen av en disk i logiske disker, som kan ha forskjellige filsystemer og oppfattes av operativsystemet som flere forskjellige disker.

      Sikkerhetskopiering - lage sikkerhetskopier av hele disker og individuelle filer, samt gjenopprette fra disse kopiene.

      Diskkomprimering - komprimering av informasjon på disker for å øke kapasiteten til harddisker.

      • Registerverktøy

        Utstyrsovervåkingsverktøy

        Utstyrsprøver

Figur 2. Plassering av åpen kildekode-programvare i flernivåstrukturen til en datamaskin

Det skal bemerkes at noen av verktøyene er inkludert i operativsystemet, mens den andre delen fungerer autonomt. Det meste av den generelle (system) programvaren er inkludert i operativsystemet (fig. 2). Noe av den generelle programvaren er inkludert i selve datamaskinen (noen av OS-programmene og kontrolltestene er skrevet i ROM eller PROM installert på hovedkortet). Noen av de vanlige programvarene er frittstående programmer og leveres separat.

          Applikasjonsprogramvare.

    MS OFFICE-pakken med kontorapplikasjoner

    Regnskapssystemer

    Økonomiske analytiske systemer

    Integrerte kontoradministrasjonspakker

    CAD – systemer (datastyrte designsystemer)

    HTML- eller nettredaktører

    Nettlesere – måte å se websider på

    Grafisk redaktør

    Ekspertsystemer.

          Verktøyprogramvare. Verktøyprogramvare eller programmeringssystemer er systemer for å automatisere utviklingen av nye programmer i et programmeringsspråk. I det mest generelle tilfellet, for å lage et program på det valgte programmeringsspråket (systemprogrammeringsspråk), må du ha følgende komponenter: 1. Tekstredigering for å lage en fil med kildeteksten til programmet. 2. Kompilator eller tolk. Kildeteksten oversettes til mellomobjektkode ved hjelp av et kompilatorprogram. Kildekoden til et stort program består av flere moduler(kildefiler). Hver modul er kompilert til en egen fil med objektkode, som deretter må kombineres til en helhet.3. En lenkeredigerer eller assembler som utfører kobling av objektmoduler og genererer en fungerende applikasjon som en utdata - kjørbar kode. Kjørbar kode er et komplett program som kan kjøres på hvilken som helst datamaskin som har operativsystemet som programmet ble opprettet for. Som regel har den resulterende filen filtypen .EXE eller .COM.4. Nylig har visuelle programmeringsmetoder (ved bruk av skriptspråk) rettet mot å lage Windows-applikasjoner blitt utbredt. Denne prosessen er automatisert i raske designmiljøer. I dette tilfellet brukes ferdige visuelle komponenter, som er konfigurert ved hjelp av spesielle redaktører. De mest populære redaktørene (programmeringssystemer som bruker visuelle verktøy) for visuell design:

    Borland Delphi - designet for å løse nesten allemer

    Borland C++ Builder er et utmerket verktøy for å utvikle DOS- og Windows-applikasjoner

    Microsoft Visual Basic er et populært verktøy for å lage Windows-programmer

    Microsoft Visual C++ - dette verktøyet lar deg utvikle alle applikasjoner som kjører i et OS-miljø som Microsoft Windows

Kontrollspørsmål:

    Definer operativsystem.

    Hvilken programvare regnes som systemprogramvare?

    Gi verktøyet et navn.

    Hvilken programvare regnes som applikasjonsprogramvare?

    Hva er formålet med programvaren?

    Hva er hovedklassene av programmer? Gi eksempler på programmer i hver klasse i henhold til formålet.

Etter å ha lagt inn dataene, er det nødvendig å gi brukeren mulighet til å skrive ut sertifikatskjemaet og en kopi av klienten. Denne operasjonen må utføres uten feil. Utskrift kan gjøres på to typer skrivere: impact (matrise) og blekkskrivere. Utskrift av sertifikatet på laserskrivere er ikke mulig på grunn av økte krav til papirkvalitet. Når du skriver ut et sertifikat på en matriseskriver, kan du skrive ut to kopier (sertifikat + kopi) i en omgang ved å bruke karbonpapir. På en blekkskriver må du skrive ut hver kopi separat. Derfor er det nødvendig å ha en kopiteller som kan endres av brukeren eller en spesiell innstillingsfunksjon for skrivertypen.

Fig.2 Samhandlingsskjema og datakommunikasjon

Utvikling av funksjonsdiagram av programmet.

Den funksjonelle sammensetningen av programmet bør maksimalt gi det nødvendige settet med evner for OP-kassereren for å utføre sitt jobbansvar knyttet til dataregistrering, registrering av transaksjoner og utførelse av rapporteringsdokumenter. For å gjøre dette vil vi kompilere en omtrentlig liste over funksjoner som bør implementeres i systemet vårt.

En omtrentlig liste over systemfunksjoner.

1) Registrering av en byttetransaksjon

· Legge inn data om valutakjøp

· Dataregistrering for valutasalg

· Legge inn valutakonverteringsdata

· Skriv ut kundehjelp

2) Se dokumenter

· Se listen over dagens dokumenter

· Vis en liste over arkiverte dokumenter

3) Vedlikeholde kataloger

· Datainntasting med verdikoder

· Dataregistrering etter dokumenttyper

· Dataregistrering med valutakoder

· Angi valutakurser etter dato

4) Generering av rapporteringsdokumenter

· Skrive ut et register over kontanter utenlandsk valuta kjøpt for kontanterubler;

· Skrive ut registeret over kontanter utenlandsk valuta solgt for kontanterubler;

· Utskrift av registeret for utveksling (konvertering) av kontanter utenlandsk valuta;

5) Andre funksjoner

· Legge inn data i inndatafeltet fra katalogen

· Konvertering av et tall fra digitalt til små bokstaver (beløp i ord)

· Endre markørens utseende

· Lagre data i arkivfiler

Listen ovenfor dekker alle prosedyrene beskrevet i den teknologiske prosessdelen av OP og er supplert med noen funksjoner som vil være nødvendige i prosessen med datainntasting og korrigering.

Utvikling av et strukturdiagram av programmet.

Det strukturelle diagrammet til programvarepakken bestemmer i grunnleggende termer både utseendet til det utformede systemet og prinsippene for interaksjon med brukeren. Diagrammet for det utformede systemet vil være en hierarkisk trestruktur som beskriver prosedyrene for å legge inn, behandle og skrive ut data. Å konstruere informasjons- og referanseklasseprogrammer i henhold til dette prinsippet gjør det ganske enkelt å modifisere systemet som helhet og letter oppfatningen og forståelsen av driftsprinsippet til programmet. For å bygge et strukturelt diagram, er det nødvendig å bestemme hierarkiet og koblingen til de ovennevnte databehandlingsprosedyrene. Det er naturlig å etablere et hierarki av prosedyrer i den formen de ble beskrevet i forrige kapittel, siden en slik ordning tilsvarer ordningen med "viktighet" og "brukbarhet" av prosedyrer. Blokkdiagrammet til programmet, som tar hensyn til alt det ovennevnte, er presentert i fig. 2.

Utvikling av programmets skjermgrensesnitt

Eksisterende tilnærminger til design av skjermgrensesnitt

Programmets skjermgrensesnitt bestemmer i stor grad brukerens bekvemmelighet og er en av de viktige faktorene som påvirker effektiviteten til arbeidet hans. Et program som utfører alle funksjonene som er tildelt det og har høy ytelse, kan være helt uegnet for arbeid på grunn av et uakseptabelt brukergrensesnitt. For bare noen få år siden var det et tekstredigeringsprogram som perfekt illustrerer denne tilnærmingen til programvaredesign. Det er usannsynlig at noen vil like et tekstredigeringsprogram der du, for å sette inn et tegn i en linje, må skrive inn en bokstavskode for insert-kommandoen, nummeret på linjen som behandles (heldigvis ikke binært), nummeret av karakteren som den nye karakteren skal settes inn etter, og denne karakteren selv. Selvfølgelig er denne tilnærmingen helt uakseptabel.

De mest praktiske og brukervennlige systemene kan betraktes som de som har et skjermgrensesnitt bygget på grunnlag av et popup-menysystem. De vanligste for tiden er to ideologier (som betyr DOS-applikasjoner), som inkluderer en viss form på skjermvinduer og et fargeskjema og typen popup-lister. Dette er Borland-verktøymiljøene og Norton-operasjonsskallet fra Symantec. Begge ideologiene sørger for en viss inndeling av skjermrom i områder eller soner beregnet for spesifikke informasjonsobjekter og handlinger. Soner kan til en viss grad rekonfigureres på brukerens forespørsel: deres størrelser og plassering på skjermen endres. Databehandlingskommandoer kalles opp fra et menysystem som hele tiden er tilstede på skjermen (Borland), eller kalles opp av en funksjonstast (Symantec).

I begge tilfeller er alle systemkommandoer fordelt i henhold til funksjonalitet i grupper og finnes i hovedmenyen

de faktiske navnene på kommandogruppene. Ved å velge en gruppe får brukeren tilgang til en liste over gruppekommandoer, som også kan inkludere kommandoer gruppert i andrenivågrupper osv.

Dette skaper et popup-menysystem på flere nivåer. Bruken av en slik ideologi sikrer enkel navigering i et system som har en ganske kompleks meny på flere nivåer med mange valg. Naturligvis bør økningen i hekking og størrelse på utvalgslister ha rimelige grenser, som heldigvis finnes i form av begrenset skjermplass på skjermen. De fleste systemer har også mulighet til å tilpasse fargepaletten etter brukerens ønsker. Norton betjeningsskallet tilbyr et utvalg av farger fra flere standardalternativer i Borland-systemer kan du lage ditt eget fargevalg, ned til minste detalj. En omtrentlig visning av noen skjermobjekter er vist i fig. 4,5.

Velge en grensesnittsideologi på skjermen

Programvaredesign begynner med å definere strukturen.

5. 1. Utvikling av struktur- og funksjonsdiagrammer.

Prosessen med å designe kompleks programvare begynner med å klargjøre strukturen, det vil si å definere de strukturelle komponentene og forbindelsene mellom dem. Resultatet av avklaring av strukturen kan presenteres i form av strukturelle og/eller funksjonelle diagrammer og beskrivelser (spesifikasjoner) av komponenter.

Blokkdiagram over programvaren som utvikles

Et strukturdiagram er et diagram som gjenspeiler sammensetningen og interaksjonen i håndteringen av deler av programvaren som utvikles.

Strukturelle diagrammer programvarepakker er ikke informative, siden organiseringen av programmer i pakker ikke sørger for overføring av kontroll mellom dem. Derfor utvikles blokkdiagrammer for hvert program i pakken, og listen over programmer i pakken bestemmes ved å analysere funksjonene spesifisert i de tekniske spesifikasjonene.

Den enkleste typen programvare er et program som bare kan inkludere subrutiner og ressursbiblioteker som strukturelle komponenter.

Utviklingen av et programblokkdiagram utføres vanligvis ved hjelp av en trinn-for-trinn detaljeringsmetode.

De strukturelle komponentene til et programvaresystem eller programvarekompleks kan være programmer, undersystemer, databaser, ressursbiblioteker, etc.

Strukturopplegg Software pakke viser overføringen av kontroll fra dispatcher-programmet til det tilsvarende programmet (fig. 1.1).

Ris. 5.1. Et eksempel på et blokkskjema av en programvarepakke.

Strukturopplegg programvaresystem, som regel indikerer tilstedeværelsen av delsystemer eller andre strukturelle komponenter. I motsetning til et programvarekompleks, utveksler individuelle deler (delsystemer) av et programvaresystem intensivt data med hverandre og, muligens, med hovedprogrammet. Blokkskjemaet til et programvaresystem viser vanligvis ikke dette (fig. 1.2).


Ris. 5.2. Et eksempel på et blokkdiagram av et programvaresystem.

Et mer fullstendig bilde av programvaren som blir utformet når det gjelder samspillet mellom komponentene med hverandre og med det eksterne miljøet, er gitt av et funksjonelt diagram.

Funksjonsdiagram

Funksjonelt diagram eller datadiagram (GOST 19.701-90) - et diagram over samspillet mellom programvarekomponenter med en beskrivelse av informasjonsstrømmer, sammensetningen av data i strømmene og en indikasjon på filene og enhetene som brukes. For å skildre funksjonelle diagrammer brukes spesielle symboler etablert av standarden.

Funksjonelle diagrammer er mer informative enn strukturelle diagrammer. I fig. 1.3 viser funksjonsdiagrammer av programvarepakker og systemer for sammenligning.



Ris. 5.3. Eksempler på funksjonsdiagrammer: a - et sett med programmer, b - et programvaresystem.

Alle komponenter i struktur- og funksjonsdiagrammer skal beskrives. Med en strukturell tilnærming er det spesielt nødvendig å utarbeide spesifikasjonene til interprogram-grensesnitt, siden antallet av de mest kostbare feilene avhenger av kvaliteten på beskrivelsen. De dyreste feilene er de som oppdages under omfattende testing, siden deres eliminering kan kreve store endringer i allerede feilsøkte tekster.

5.2. Bruke den inkrementelle detaljeringsmetoden for å designe programvarestruktur.

Den strukturelle tilnærmingen til programmering, i den formen den ble formulert i på 70-tallet av 1900-tallet, foreslo å dekomponere programmer ved å bruke metoden for trinn-for-trinn-detaljering. Resultatet av dekomponeringen er et programblokkdiagram, som er et hierarkisk flernivådiagram over samspillet mellom kontrollunderrutiner. Som et minimum viser et slikt diagram to nivåer av hierarki, det vil si at det viser den generelle strukturen til programmet. Den samme metoden gjør det imidlertid mulig å få strukturelle diagrammer med et stort antall nivåer.

Trinn-for-trinn-metoden implementerer en ovenfra-ned-tilnærming og er basert på de grunnleggende konstruksjonene av strukturert programmering. Det innebærer trinnvis utvikling av algoritmen. Hvert trinn innebærer å dekomponere en funksjon i underfunksjoner. Så på det første stadiet beskriver de løsningen på problemet, og fremhever generelle deloppgaver på det neste, beskriver de på samme måte løsningen på deloppgaver, mens de formulerer deloppgaver på neste nivå. Dermed blir funksjonene til den utformede programvaren avklart ved hvert trinn. Prosessen fortsetter til de når deloppgaver, algoritmer hvis løsninger er åpenbare.

Når du dekomponerer et program ved hjelp av den trinnvise detaljeringsmetoden, bør du følge den grunnleggende regelen for strukturell dekomponering, som følger av prinsippet om vertikal styring: først og fremst detaljer kontrollprosessene til den dekomponerte komponenten, og la avklaringen være av dataoperasjoner til sist. Dette skyldes det faktum at prioritert detaljering av kontrollprosesser betydelig forenkler strukturen til komponentene på alle nivåer i hierarkiet og gjør det mulig å ikke skille beslutningsprosessen fra dens utførelse: dermed etter å ha bestemt betingelsen for å velge en visse alternativer, kaller de umiddelbart modulen som implementerer det.

Detaljering av operasjoner med strukturer sist vil tillate å utsette foredlingen av deres spesifikasjoner og vil gi mulighet for relativt smertefri modifikasjon av disse strukturene ved å redusere antall moduler som er avhengige av disse dataene.

I tillegg anbefales det å følge følgende anbefalinger:

Ikke separer initialiserings- og fullføringsoperasjoner fra den tilsvarende behandlingen, siden initialiserings- og fullføringsmodulene har dårlig kobling (temporal) og sterk kobling (kontroll);

Ikke design for spesialiserte eller for generelle moduler, siden utforming av altfor spesialiserte moduler øker antallet, og utforming av altfor generelle moduler øker kompleksiteten deres;

Unngå å duplisere handlinger i forskjellige moduler, siden når de endres, må korrigeringer gjøres på alle programfragmenter der de utføres - i dette tilfellet er det tilrådelig å bare implementere disse handlingene i en separat modul;

Å gruppere feilmeldinger i én modul etter type ressursbibliotek vil gjøre det lettere å bli enige om ordlyden, unngå dupliserte meldinger og oversette meldinger til et annet språk.

Samtidig, når du beskriver løsningen på hvert problem, er det tilrådelig å ikke bruke mer enn 1-2 strukturelle kontrollstrukturer, for eksempel en while-loop eller forgrening, som lar deg tydeligere forestille deg strukturen til den organiserte beregningen prosess.

Oppdeling i moduler i denne typen design utføres heuristisk, basert på anbefalte modulstørrelser (20-60 linjer) og kompleksiteten til strukturen (to eller tre nestede kontrollstrukturer). I prinsippet, som en modul (subrutine) er det mulig å implementere løsningen på underoppgaver formulert på et hvilket som helst trinn i detaljeringsprosessen, men den avgjørende rollen når du deler opp et program i moduler, spilles av prinsippene for å sikre at modulene kan produseres. .

For å analysere produserbarheten til det resulterende hierarkiet av moduler, er det tilrådelig å bruke Constantine eller Jackson strukturelle kart.

5. 3. Konstantins strukturkart.

På et strukturelt kart er relasjonene mellom moduler representert i form av en graf, hvis toppunkter tilsvarer moduler og felles dataområder, og buene tilsvarer intermodulanrop og tilganger til felles dataområder.

Det er fire typer hjørner (fig. 1.4.):

Modul - subrutine,

Undersystem - program,

Bibliotek - et sett med underrutiner plassert i en egen modul,

Et dataområde er en spesialdesignet samling av data som kan nås utenfra.

EN). b). V). G).

Ris. 5.4. Betegnelse av hjørner i henhold til IBM, ISO og ANSI standarder:

en – modul; b - delsystem; c - bibliotek; d – dataområde.

I dette tilfellet kan individuelle deler av programvaresystemet (programmer, subrutiner) kalles sekvensielt, parallelt eller som korutiner (fig. 1.5.).


Ris. 5.5. Anropstypebetegnelse:

en – sekvensiell samtale; b – parallellanrop; c – kalle en koroutin.

Oftest brukt konsistent en samtale hvor moduler, etter å ha overført kontroll, venter på at det oppkalte programmet eller subrutinen fullfører utførelse for å fortsette avbrutt behandling.

Under parallell en utfordring forstås som parallellisering av beregninger på flere datamaskiner, når når en annen prosess aktiveres, fortsetter denne prosessen å fungere . På datamaskiner med én prosessor i flerprogrammiljøer, i dette tilfellet, begynner den alternative kjøringen av de tilsvarende programmene. Parallelle prosesser kan være synkrone eller asynkrone. For synkrone prosesser bestemmes synkroniseringspunkter - tidspunkter når informasjon utveksles mellom prosesser. Asynkrone prosesser utveksler informasjon kun når den parallelle prosessen er aktivert.

Under kaller en coroutine forstå muligheten for alternativ kjøring av to programmer som kjører samtidig, for eksempel hvis ett program har forberedt en datapakke for utgang, kan det andre sende den ut og deretter gå inn i en tilstand av å vente på neste pakke. Videre, i flerprogramsystemer, fortsetter hovedprogrammet, etter å ha overført data, å fungere og går ikke inn i en ventetilstand.

Constantines strukturelle kart lar deg visuelt presentere resultatet av å dekomponere et program i moduler og evaluere kvaliteten, det vil si samsvar med anbefalingene for strukturert programmering (sammenheng og sammenheng).

5.4. Design av datastrukturer.

Utformingen av datastrukturer refererer til utviklingen av deres representasjoner i minnet. De viktigste parameterne som må vurderes ved utforming av datastrukturer er:

Typen informasjon som er lagret for hvert dataelement;

Forhold mellom dataelementer og nestede strukturer;

Lagringstid for strukturdata ("levetid");

Et sett med operasjoner på dataelementer, nestede strukturer og strukturer som helhet

Type informasjon som er lagret bestemmer typen til det tilsvarende minnefeltet. Avhengig av programmeringsspråket som brukes, kan følgende betraktes som dataelementer:

Heltall og reelle tall i ulike formater;

Symboler;

Boolske verdier: sant og usant;

samt noen strukturelle datatyper, for eksempel:

Spesielt deklarerte klasser.

Samtidig er det for numeriske felt veldig viktig å bestemme rekkevidden av mulige verdier riktig, og for strengdata - maksimal mulig strenglengde.

Forbindelsene mellom elementer og nestede strukturer, samt deres stabilitet og settet med operasjoner på elementer og nestede strukturer bestemmer minnestrukturene som brukes til å representere data. Levetiden tas i betraktning når du plasserer data i statisk eller dynamisk minne, samt i eksternt minne.

La oss vurdere de eksisterende alternativene for intern representasjon av data, deres elementer og forbindelser mellom dem mer detaljert.

Representasjon av data i RAM

Det er to grunnleggende strukturer for å organisere data i RAM: vektor og liste.

Vektor struktur er en sekvens av minnebyte som brukes til å romme datafelt (fig. 1.6.).

Ris. 5.6. Vektorminnestruktur.

Sekvensiell plassering av organiserte datastrukturer gir direkte tilgang til elementer: etter indeks (sett med indekser) - i matriser eller strenger, eller etter feltnavn - i poster eller objekter.

Men å legge til og fjerne elementer når du bruker vektorstrukturer for å plassere matriseelementer kan kreve flere elementskift.

Datastrukturer i vektorrepresentasjon kan plasseres i både statisk og dynamisk minne. Plassering av vektorrepresentasjoner i dynamisk minne kan noen ganger øke effektiviteten ved bruk av RAM betydelig. Det er tilrådelig å plassere midlertidige strukturer i dynamisk minne som lagrer mellomresultater, og strukturer hvis størrelse avhenger sterkt av inndatakildedataene.

List strukturer bygges av spesialelementer som i tillegg til informasjonsdelen også inkluderer en eller flere pekere - adresser til elementer eller nestede strukturer knyttet til et gitt element. Ved å plassere slike elementer i dynamisk minne, kan du organisere ulike interne strukturer (fig. 1.7.).


Ris. 5.7. Eksempler på listeminnestrukturer:

a - lineær enkeltlenket liste; b - treliste; c er en n-lenket liste.

Men når du bruker listestrukturer, husk at:

Ekstra minne er nødvendig for å lagre pekere;

Søking etter informasjon i lineære lister utføres sekvensielt, og krever derfor mer tid;

Å konstruere lister og utføre operasjoner på dataelementer som er lagret i lister krever dyktigere programmerere, er mer arbeidskrevende, og de tilsvarende rutinene inneholder flere feil og krever derfor grundigere testing.

Vanligvis brukes vektorrepresentasjon til å lagre statiske sett, tabeller (endimensjonale og flerdimensjonale), for eksempel matriser, rader, poster, samt grafer representert av en tilstøtende matrise, en insidensmatrise eller analytisk. Listerepresentasjonen er praktisk for å lagre dynamiske (foranderlige) strukturer og strukturer med komplekse relasjoner.

I de mest kritiske tilfellene, når du velger en intern representasjon, er det tilrådelig å bestemme beregningskompleksiteten ved å utføre de vanligste operasjonene med en datastruktur eller dens elementer for ulike alternativer. Og evaluer også deres kapasitive kompleksitet.

Representasjon av data i eksternt minne

Moderne operativsystemer støtter to måter å organisere data på i eksternt minne: sekvensiell og direkte tilgang.

Med sekvensiell datatilgang er det mulig å utføre kun sekvensiell lesing av dataelementer eller sekvensiell skriving. Dette alternativet forutsettes når du arbeider med logiske enheter som et tastatur eller skjerm, når du behandler tekstfiler eller filer hvis postformat endres under drift.

Direkte tilgang er bare mulig for diskfiler som utveksler informasjon med poster med fast lengde (binære C-filer eller Pascal-filer). Opptaksadressen til en slik fil kan bestemmes av dens Antall, som lar deg få direkte tilgang til ønsket post.

Når du velger type minne for å imøtekomme datastrukturer, husk at:

RAM lagrer data som krever rask tilgang, både for å lese og endre det;

I den eksterne - data som må lagres etter at programmet avsluttes.

Det er mulig at det under arbeidet er tilrådelig å lagre data i RAM for å øke hastigheten på tilgangen til dem, og når det er fullført, omskriv det til eksternt minne for langtidslagring. Dette er metoden de fleste tekstredigerere bruker: når du arbeider med tekst, legges hele eller deler av den i RAM, hvorfra den kopieres til eksternt minne etter behov. I slike tilfeller utvikles to datarepresentasjoner: i RAM og i eksternt minne.

Riktig valg av strukturer bestemmer i stor grad effektiviteten til programvaren som utvikles og dens teknologiske kvaliteter, så dette problemet bør vies tilstrekkelig oppmerksomhet uavhengig av tilnærmingen som brukes.

5.5. Programvaredesign basert på datanedbryting.

Nesten samtidig ble Jackson og Warnier-Orr programvaredesignmetoder basert på datanedbrytning foreslått. Begge teknikkene er designet for å lage "enkle" programmer som fungerer med komplekse, men hierarkisk organiserte datastrukturer. Hvis det er nødvendig å utvikle programvaresystemer, foreslås det i begge tilfeller først å dele opp systemet i separate programmer og deretter bruke disse teknikkene.

Jackson teknikk

Da han laget sin metodikk, tok M. Jackson utgangspunkt i det faktum at strukturene til de første dataene og resultatene bestemmer strukturen til programmet.

Teknikken er basert på å søke etter samsvar mellom strukturene til kildedataene og resultatene. Men når du bruker det, er situasjoner mulig der det ikke er samsvar på noen nivåer. For eksempel er postene i kildefilen ikke sortert i den rekkefølgen de tilsvarende radene skal vises i rapporten. Slike situasjoner ble kalt "kollisjoner." Det er flere typer kollisjoner som løses på forskjellige måter. Hvis rekkefølgen av poster er annerledes, sorteres de ganske enkelt før behandling.

Utviklingen av programstrukturer i samsvar med metodikken utføres som følger:

Konstruer et bilde av strukturene til input og output data;

Behandlingsforbindelsene (korrespondansen) mellom disse dataene identifiseres;

danne strukturen til programmet basert på datastrukturer og oppdagede korrespondanser;

legge til prosesseringsblokker for elementer som ingen treff er funnet for;

Analysere og behandle inkonsekvenser, dvs. løse "kollisjoner";

Legg til de nødvendige operasjonene (inndata, utdata, åpne/lukke filer, etc.); skrive programmet i strukturell notasjon (pseudokode).

Warnier-Orr-teknikk.

Varnier-Orr-metoden er basert på samme prinsipp som Jackson-metoden, men de viktigste når du konstruerer et diagram er strukturene til utdataene, og hvis strukturene til inngangsdataene ikke samsvarer med strukturene til utdataene, så kan de endres. Dermed er hovedårsaken til kollisjoner eliminert.

I praksis er det imidlertid ikke alltid mulig å omorganisere inputdatastrukturer: disse strukturene kan allerede spesifiseres strengt, for eksempel hvis data innhentet under programkjøring brukes, så denne teknikken brukes sjeldnere.

Som det følger av ovenstående, kan Jackson- og Varnier-Orr-metodene bare brukes hvis dataene til programmene som utvikles kan presenteres i form av et hierarki eller et sett med hierarkier.

5.6. Case-teknologier basert på strukturelle metoder for analyse og design.

Til dags dato har det blitt akkumulert erfaring med vellykket bruk av de fleste kjente strukturanalyse- og designmetodologier i de tilsvarende CASE-verktøyene. De mest utbredte metodene er: SADT (3,3%), Gain-Sarson strukturelle systemanalyse (20,2%), Jordan-De strukturelle analyser og design (36,5%), Jackson systemutvikling (7,7%), utvikling av strukturell DSSD (Data Structured) Systemutvikling) Varnier-Orr (5,8%), analyse av design av sanntidssystemer av Ward-Mellor og Hutley, informasjonsmodellering av Martin (22,1%).

Som det fremgår av statistikken som presenteres, er de mest brukte metodene de som bruker dataflytdiagrammer. Dette skyldes to årsaker:

Dataflytdiagrammer, mer detaljert sammenlignet med funksjonelle diagrammer, gjenspeiler detaljene til de for tiden mange informasjon systemer: krever ikke streng inntasting av informasjonen som behandles, sørger for muligheten for lagring av data, spesifiser interaksjon med omverdenen, sørger for å skaffe en omfattende programvaremodell, etc.;

Det er utviklet en metode for å konstruere designspesifikasjoner (Jackson eller Costantine strukturelle kart) ved bruk av dataflytdiagrammer, som tillater automatisk opprettelse av slike spesifikasjoner.