Saada oma head tööd teadmistebaasi on lihtne. Kasutage allolevat vormi
Üliõpilased, magistrandid, noored teadlased, kes kasutavad teadmistebaasi oma õpingutes ja töös, on teile väga tänulikud.
Postitatud aadressil http://www.allbest.ru/
SISSEJUHATUS
1.1 Objektorienteeritud programmeerimise tehnoloogia teoreetilised aluspõhimõtted; Objektorienteeritud lähenemise põhimõisted
1.2 Kontseptsiooniobjekt
2. ehitus objekti mudel ainevaldkond“spordiklubi protsesside korraldamine”, kasutades UML-i modelleerimiskeelt
2.1 UML-i modelleerimiskeele omadused
2.1.1 UML-i lühiajalugu
2.1.2 UML keel
2.1.3 UML-i sõnavara
2.1.4 Mudeli juhtvaade.
3.1 Rakenduse struktuuri kirjeldus
KOKKUVÕTE
ALLIKATE LOETELU
Lisa A
SISSEJUHATUS
Spordiklubi viib läbi igakülgseid tegevusi kehakultuuri ja spordi arendamiseks noorte ja nende pereliikmete seas. Üha enam tekib spordiklubisid, sealhulgas palju spordisektsioone. Nendes osakondades osalevate noorte registreerimine võtab palju aega ja on keeruline protsess. Seetõttu muutub selle protsessi automatiseerimise küsimus üha aktuaalsemaks.
Arvuti kasutamisel muutub see protsess palju täpsemaks ja kiiremaks, ilma paljude tüsistusteta, mis tekivad selle käsitsi korraldamisel.
Spordiklubi protsesside korralduse tunnused tehakse kindlaks ainevaldkonna objektmudeli abil. Sellised mudelid on eriti kasulikud spordiklubi sektsioonides osalevate noorte arvestusprotsessi korraldamisel, kuna selle ainevaldkonna modelleerimine võimaldab objekti igast küljest uurida ja tänu sellele kõike ette näha. võimalikud probleemid. Näiteks ajakava koostamisel võimaldab õppeprotsessi korraldamise objektmudel vältida kattumisi, mis tekivad sektsioonide tundide jaotamisel, kuna see punkt nähakse ette arenduse käigus.
Domeeni objektmudeli saab ehitada visuaalse objekti modelleerimiskeele UML abil või tarkvaratootena mõnes otoetavas programmeerimiskeeles, mille näiteks on keel Object Pascal.
Käesoleva uurimistöö eesmärk on uurida objektorienteeritud metoodikat ja programmeerimistehnoloogiat Object Pascal keele näitel, meetodeid ja tööriistu ainevaldkondade objektimudelite koostamiseks ning omandatud teadmiste rakendamisel ainevaldkonna objektmudeli koostamiseks. Spordiklubi töö korraldus.»
Selle uuringu eesmärgi saavutamiseks püstitati järgmised ülesanded:
· Õppida objektorienteeritud metoodika teoreetilisi aluspõhimõtteid;
· Kaaluge UML-i keelt ja koostage selle keele abil ainevaldkonna objektmudel;
· Töötage välja rakendus, mis kasutab sportlaste kohta käiva teabe esitamiseks klasside komplekti.
Selle kursusetöö uurimisobjektiks on objektorienteeritud disaini metoodika.
Käesoleva uurimuse teemaks on ainevaldkonna “Spordiklubi töökorraldus” objektmudel ja selle peamised omadused.
Uurimishüpoteesiks on, et objektmudeli rakendamine Delphi visuaalses arenduskeskkonnas, kasutades objektorienteeritud metoodika aluspõhimõtteid, lihtsustab spordiklubis osalejate kohta info kogumise, säilitamise ja töötlemise protsessi.
Ainevaldkonna analüüsimise ja rakendusstruktuuri kujundamise etapis on vaja koostada UML klassiskeem.
Kursuseprojekti koostamisel kasutati järgmisi uurimismeetodeid:
· Kirjeldavat meetodit kasutatakse probleemi teoreetiliste aspektide esitamiseks ja uuritava objekti lühikirjelduseks;
· Võrdlus- ja analüüsimeetod. Võimaldab võrrelda erinevaid seisukohti vaadeldaval teemal ja diagnoosida uurimisobjekti;
· Süsteemne lähenemine. Seda kasutati saadud tulemuste kokkuvõtmiseks ja nende loogilise seose tuvastamiseks.
1. OBJEKTORIENTSETE METOODIKA TEOREETILISED PÕHISÄTTED
1.1 Objektorienteeritud lähenemise põhimõisted
ainekeele programmeerimismudel
Alates iidsetest aegadest on programmeerimine kasutanud struktureeritud, protseduuridele orienteeritud mudelit. Projekti eesmärkide valimine toimub kasutades ühte kahest lähenemisviisist, mida nimetatakse ülalt-alla ja vastavalt "alt-üles"
1. “Ülalt-alla” lähenemine eeldab, et ülesanne on jagatud alamülesanneteks, mis omakorda jagunevad järgmise taseme alamülesanneteks jne. See protsess, mida nimetatakse dekompositsiooniks, jätkub seni, kuni alamülesannete lihtsustamine taandub elementaarseteks funktsioonideks, mida saab formaliseerida.
2. Alt-üles lähenemine tähendab, et protseduurid kirjutatakse lihtsate probleemide lahendamiseks, seejärel kombineeritakse need järjest keerukamateks protseduurideks, kuni saavutatakse soovitud efekt.
Olulised programmeerimiskontseptsioonid on protseduuridele orienteeritud programmeerimine ja objektorienteeritud programmeerimine.
Protseduurile orienteeritud programmeerimine on programmeerimine imperatiivses keeles, mille puhul saab järjestikku täidetavaid lauseid keele enda mehhanisme kasutades kokku panna alamprogrammideks ehk koodi suuremateks terviklikeks üksusteks.
Objektorienteeritud programmeerimine (OOP) on programmeerimisstiil, mis jäädvustab reaalset käitumist viisil, mis varjab selle rakendamise üksikasju.
Objekt on eraldiseisev olem, mis paistab teiste olemite seas silma oma omaduste, käitumise ja koostoime tõttu teiste rakendusobjektidega.
Selle tehnoloogia kasutamine võimaldab esitada programmi struktuuri üksteisega suhtlevate objektide komplektina. Sellise suhtluse tulemusena, mis toimub sõnumite edastamisega objektide vahel, rakendatakse programmi määratud funktsioone. Pärast sõnumi saamist saab objekt sooritada konkreetse toimingu, mida nimetatakse meetodiks.
OOP-i ja protseduurile orienteeritud programmeerimise vahel on kaks olulist erinevust:
1. OOP-is valib programmeerija esmalt ainevaldkonna kirjeldusest klassid, seejärel ehitab ülesande lahendamiseks objektimudeli ning alles pärast seda asub analüüsima nende meetodeid ja omadusi.
2. Meetodid ja omadused on seotud vastavate toimingute sooritamiseks mõeldud klassiga.
Kui analüüsida, kuidas inimene lahendab erinevaid praktilisi probleeme ümbritsevas maailmas, siis saame aru, et ka see maailm on objektorienteeritud. Näiteks tööle jõudmiseks suhtleb inimene tavaliselt mõne objektiga, näiteks sõidukiga. Sõiduk koosneb omakorda objektidest, mis üksteisega suheldes panevad selle liikuma, tänu millele inimene realiseerib oma ülesande – jõuab soovitud ese. Samas ei pea ei juht ega kaasreisija teadma, kuidas sõiduki moodustavad objektid omavahel suhtlevad.
Objektorienteeritud programmeerimises, nagu ka reaalses maailmas, on programmide kasutajad ülesannete täitmiseks vajalikust loogikast isoleeritud. Näiteks lehe printimiseks tekstitöötlusprogrammis kutsub kasutaja tööriistaribal nuppu klõpsates välja teatud funktsiooni, kuid ei näe toimuvaid sisemisi protsesse. Lehekülje printimisel programmi töötamise ajal toimub objektide kompleksne interaktsioon, mis omakorda suhtleb printeriga.
Objektorienteeritud programmi loomisel kujutatakse ainevaldkonda objektide kogumina, mis on kombineeritud klassidesse. Programmi täitmine koosneb objektidest, mis vahetavad sõnumeid (üksteisega suhtlemist). Probleemide valdkonda kuuluva reaalse objekti kujutamisel programmiklassi abil tuleb reaalobjektis esile tuua selle olulised tunnused ja ignoreerida paljusid muid omadusi, piirdudes vaid lahendamiseks vajalikega. praktiline probleem. Seda tehnikat nimetatakse abstraktsiooniks.
Abstraktsioon on objekti oluliste omaduste tuvastamine, mis eristavad seda teistest objektidest. Lisaks sõltub oluliste omaduste loend modelleerimise eesmärkidest ja võib erinevate ülesannete puhul olla täiesti erinev. Näiteks objektil “rott” on rändebioloogi, loomaarsti või koka vaatenurgast täiesti erinevad omadused.
Klass on objektide kogum, millel on üldised omadused ja käitumine. Seega võib klassi määratleda kui teatud kindlate objektide kogukonda, kui kirjeldust selle kohta, millised need peaksid olema ja mida nad peaksid tegema. Kui objektid on rakendustes tegelikult olemas, siis klass on abstraktsioon, mis rühmitab objektid ühte rühma vastavalt nende omadustele ja käitumisele keskkonnas, kus nad eksisteerivad ja interakteeruvad. Näiteks vormil olev Button1 on kõigi oma spetsiifiliste omaduste ja toimingutega klassi Button objekt.
Käitumine on tunnus, kuidas üks objekt mõjutab teisi objekte või muudab end nende mõjul. Käitumine mõjutab seda, kuidas objekti olekud muutuvad.
Objektorienteeritud programmeerimistehnoloogia põhineb "kolmel sambal": kapseldamisel, pärilikkusel ja polümorfismil.
Kapseldamine on omadus ühendada olek ja käitumine ühes struktuuris ning peita objekti sisemine struktuur ja teostuse üksikasjad (alates sõnast "kapsel"). Iga objekti oluline omadus on selle isolatsioon. Objekti rakendamise üksikasjad, s.o. sisemised struktuurid andmed ja nende töötlemise algoritmid on objekti kasutaja eest varjatud ja tahtmatute muudatuste jaoks kättesaamatud. Objekti kasutatakse liidese kaudu - juurdepääsureeglite kogum. Näiteks teleprogrammi vahetamiseks peame kasutama ainult kaugjuhtimispulti Pult vali tema number, mis algab keeruline mehhanism, mis lõpuks viib soovitud tulemuseni. Me ei pea ilmtingimata teadma, mis puldis ja teleris toimub, peame lihtsalt teadma, et teleril on see võimalus (meetod) ja kuidas seda saab aktiveerida. Kapseldamine ehk teostuse peitmine on OOP põhiomadus. See võimaldab teil luua kohandatud objekte, millel on vajalikud meetodid, ja seejärel nendega töötada, ilma nende objektide struktuuri süvenemata. Seega on kapseldamine mehhanism, mis ühendab andmed ja meetodid nende andmete töötlemiseks (manipuleerimiseks) ning kaitseb nii välise sekkumise või väärkasutamine. Koodi kapseldamine klassi sees tagab, et koodi ei saa "murda" üksikute klasside rakendamise üksikasjade muudatustega. Seetõttu saate kasutada objekti teises keskkonnas ja olla kindel, et see ei riku mälupiirkondi, mis sellele ei kuulu. Kui ikka on vaja klassis midagi muuta või lisada, siis kasutatakse pärimise ja polümorfismi mehhanisme.
Pärand on klasside hierarhiapõhine võime kaasata esivanemate klasside omadusi ja käitumist ning lisada neile oma käitumist ja omadusi. Igal aastal kirjutatakse maailmas palju programme ja oluline on kasutada juba kirjutatud koodi. Objektorienteeritud programmeerimise eeliseks on see, et objektile on võimalik defineerida järeltulijaid, mis korrigeerivad või täiendavad selle käitumist. Sel juhul pole vaja mitte ainult korrata allikas vanemobjekt, kuid neil on sellele isegi juurdepääs. See muudab programmi muutmise ja olemasoleva põhjal uute programmide loomise lihtsamaks. Ainult pärimise teel saate kasutada objekte, mille lähtekood pole saadaval, kuid millesse peate tegema muudatusi. Seega ei saa pärimisel lihtsalt lisada uus funktsionaalsus, vaid ka muuta olemasolevat. Ja see saavutatakse suuresti tänu polümorfismile.
Polümorfism (“palju vorme”) - võimalus kasutada samu väljendeid erinevate operatsioonide tähistamiseks, järeltulijate klasside võime rakendada esivanemate klassi jaoks kirjeldatud meetodit erineval viisil, s.t. võimalus programmi täitmise ajal teha erinevaid toiminguid või pääseda ligi sama nimega objektidele erinevad tüübid. Polümorfismi rakendatakse meetodi alistamise kaudu järglaste klassides (meetodil on sama nimi ja samad parameetrid, kuid see töötab erinevalt) - see on mehhanism virtuaalsed meetodid läbi dünaamiline sidumine(dünaamiline sidumine). Polümorfismi rakendatakse ka meetodite "ülekoormana" (meetodil on üks nimi ja erinevad parameetrid) on näiteks + märgi kasutamine liitmise tähistamiseks reaal- või täisarvuklassis ja stringiklassis: sarnased teated annavad täiesti erinevaid tulemusi. Polümorfism annab võimaluse abstraheerida ühiseid omadusi.
Modulaarsus on süsteemi omadus, mis on lagunenud sisemiselt koherentseteks, kuid omavahel nõrgalt ühendatud mooduliteks.
Süsteemi mooduliteks jagamisel võib kasu olla kahest reeglist. Esiteks, kuna moodulid toimivad elementaarsete ja jagamatute programmiplokkidena, mida saab kogu süsteemis uuesti kasutada, peab klasside ja objektide jaotus moodulite vahel sellega arvestama. Teiseks loovad paljud kompilaatorid iga mooduli jaoks eraldi koodisegmendi. Seetõttu võivad mooduli suurusele olla piirangud. Alamprogrammikutsete dünaamika ja deklaratsioonide paigutus moodulites võivad oluliselt mõjutada lingi asukohta ja lehehaldust Virtuaalne mälu. Kui protseduurid on halvasti moduleeritud, muutuvad segmentidevahelised vastastikused kõned sagedasemaks, mis toob kaasa vahemälu efektiivsuse kaotuse ja sagedased lehevahetused.
Selliseid vastuolulisi nõudeid on üsna raske kokku viia, kuid peamine on mõista, et klasside ja objektide eraldamine projektis ning moodulstruktuuri korraldus on iseseisvad tegevused. Klasside ja objektide eraldamise protsess on osa süsteemi loogilisest projekteerimisprotsessist ning mooduliteks jagamine on füüsilise projekteerimise etapp. Muidugi on mõnikord võimatu lõpetada süsteemi loogilist ülesehitust ilma füüsilist kujundust lõpetamata ja vastupidi. Need kaks protsessi viiakse läbi iteratiivselt.
Tippimine on viis kaitsta ühe klassi objektide kasutamise eest teise asemel või vähemalt kontrollida sellist kasutamist.
Paralleelsus on omadus, mis eristab aktiivseid objekte passiivsetest.
Püsivus on objekti võime eksisteerida ajas, ellujäädes selle sünnitanud protsessi ja (või) ruumis, liikudes oma algsest aadressiruumist.
OOP põhimõisted on programmeerimisse üle kantud teistest teadmiste valdkondadest, nagu filosoofia, loogika, matemaatika ja semiootika, ilma eriliste muudatusteta, vähemalt mis puudutab nende mõistete olemust. Objekti lagundamise (esitusviisi) meetod on loomulik ja seda on kasutatud juba palju sajandeid. Seetõttu pole üllatav, et programmeerimistehnoloogia arenguprotsessis on see võtnud oma õige koha.
Seega on objektorienteeritud programmide väljatöötamise protsessis vaja:
1. määrata selle moodustavate objektiklasside hulk (dekomposiitsioon);
2. iga objektiklassi jaoks määrake vajalike andmete (väljade) kogum;
3. määrake iga objektiklassi jaoks objektide poolt sooritatavate toimingute (meetodite) kogum;
4. määrake iga objektiklassi jaoks sündmused, millele objektid reageerivad, ja kirjutage vastavad käitleja protseduurid.
Lähtekood peab sisaldama kõikide tarkvaraobjektide klasside kirjeldusi. Lisaks tuleb kirjeldada muutujaid, mille tüübid on vastavate klasside nimed. Klasside (objektide) eksemplarid luuakse programmi täitmise käigus.
Pärast selle loomist peab klassi eksemplar saama väärtused kõigi oma väljade jaoks. Sama klassi erinevatel eksemplaridel võivad olla erinevad välja väärtused, kuid neil on samad meetodid. Klassiväljad pole otseseks juurdepääsuks, sealhulgas määramiseks, saadaval. Seda tehakse programmide töökindluse parandamiseks. Objektiväljale väärtuse otsese määramise asemel tuleb helistada vastava klassi spetsiaalsele meetodile, mis sellise omistamise teostab ja sisestatud väärtuse õigsust jälgib. Samamoodi saab välja väärtuse lugemiseks kasutada ka eriklassi meetodeid. Väljade ühendamiseks nende väärtuste lugemise/kirjutamise meetoditega kasutatakse klassiliikmeid, mida nimetatakse omadusteks. Kasutaja tegeleb andmete sisestamisel nende salvestamiseks objekti väljadele või väljade väärtuste lugemisel neid välju esindavate omadustega. Seetõttu kasutatakse termini "välja väärtused" asemel tavaliselt mõistet "omaduste väärtused".
Klassi liikmed võivad olla:
1. andmete salvestamiseks kasutatavad väljad;
2. omadused kui privaatväljadele juurdepääsu vahend;
3. objektide funktsionaalsust täpsustavad meetodid;
4. sündmused ja nende käsitlejad kui programmijuhtimise vahendid.
1.2 Kontseptsiooniobjekt
Objektorienteeritud lähenemine programmeerimisele teeb ettepaneku, et kõike, mis on rakenduse osa, käsitletaks objektidena, mis suhtlevad üksteisega ja kasutajaga vastavalt programmis määratud omadustele ja käitumisele. vajalikud funktsioonid rakendusi. Seega on iga selle lähenemisviisiga rakendus omavahel ühendatud objektide kogum, mis rakendab rakenduse jaoks vajalikke funktsionaalseid nõudeid.
Objekt on alati konkreetne ja eksisteerib tegelikult vormis või rakenduses, omades samal ajal ainult oma omadusi ja käitumist. Objektide omadused, mis neid üksteisest eristavad, on nende omadused ja käitumine. Reaalses maailmas on igal objektil või protsessil hulk staatilisi ja dünaamilisi omadusi (omadused ja käitumine). Objekti käitumine sõltub selle olekust ja välismõjudest. Näiteks ei lähe objekt “auto” kuhugi, kui paagis pole bensiini ja rooli keerates muutub rataste asend. Seega on objekt kujutatud andmete kogumina, mis iseloomustab selle olekut ja meetodeid (protseduure ja funktsioone) nende töötlemiseks, käitumise modelleerimiseks. Protseduuri või funktsiooni käivitamiseks kutsumist nimetatakse sageli objektile sõnumi saatmiseks (näiteks protseduuri "pööra rooli" kutsumist tõlgendatakse sageli sõnumi "auto, keera rooli!") saatmiseks. Seega iseloomustavad iga objekti järgmised põhimõisted:
1. meetod on funktsioon või protseduur, mis realiseerib objektiga võimalikke toiminguid;
2. sündmus on vahend objektide omavaheliseks interaktsiooniks. Objektid genereerivad määratud sündmusi ja sooritavad toiminguid vastuseks määratud sündmustele. Sündmused on analoogsed sõnumitega, mida objektid vastu võtavad ja saadavad;
3. olek - iga objekt on alati teatud olekus, mida iseloomustab objekti omaduste kogum. Sündmuste mõjul läheb objekt teistesse olekutesse. Sellisel juhul võib objekt ise genereerida sündmusi teise olekusse üleminekul;
4. omadus - märk, mingi eseme eraldiseisev kvaliteet (parameeter).
Näiteks võivad omadused olla objekti mõõtmed, pealkiri, nimi. Objekti omaduste kogum määrab selle oleku. Tavaliselt on atribuudid muutujate ja konstantide kogum, mis salvestavad väärtused, mis määravad objekti parameetrid.
Tuleb märkida, et koos füüsiliste objektidega võivad eksisteerida ka abstraktsed objektid, mille tüüpilised esindajad on arvud. Seega on objekt domeeni mis tahes füüsiline või abstraktne selgelt identifitseeritav üksus.
Objekte iseloomustavad atribuudid. Nii et näiteks auto atribuutideks on maksimaalne kiirus, mootori võimsus, kere värvus jne.. Võimendi atribuudid on sagedusvahemik, väljundvõimsus, harmoonilised moonutused, müratase jne.
Objektidel on lisaks atribuutidele ka mõni funktsionaalsus, mida OOP-is nimetatakse operatsioonideks, funktsioonideks või meetoditeks. Niisiis, auto saab sõita, laev saab sõita, arvuti saab arvutusi teha.
Sel viisil kapseldab objekt atribuute ja meetodeid, varjates selle rakendamist teiste objektide eest, mis sellega suhtlevad ja selle funktsioone kasutavad.
Objektorienteeritud lähenemine põhineb mudelite süstemaatilisel kasutamisel tarkvarasüsteemi keelest sõltumatuks arendamiseks, lähtudes selle pragmaatikast.
Viimane termin vajab täpsustamist. Pragmaatika määrab tarkvarasüsteemi arendamise eesmärk: pangaklientide teenindamiseks, lennujaama töö juhtimiseks, jalgpalli MM-i teenindamiseks jne. Eesmärgi sõnastus hõlmab reaalse maailma objekte ja kontseptsioone, mis on olulised arendatava tarkvarasüsteemi jaoks (vt joonis 1.2.1).
Objektorienteeritud lähenemise korral asendatakse need objektid ja mõisted nende mudelitega, s.t. teatud formaalsed struktuurid, mis neid tarkvarasüsteemis esindavad.
Joon.1.2.1 Semantika.
Mudel ei sisalda kõiki esindatava objekti (kontseptsiooni) tunnuseid ja omadusi, vaid ainult neid, mis on arendatava tarkvarasüsteemi jaoks hädavajalikud. Seega on mudel "vaesem" ja seetõttu lihtsam kui objekt (kontseptsioon), mida see esindab. Kuid peamine pole isegi mitte see, vaid see, et mudel on formaalne konstruktsioon: mudelite formaalne olemus võimaldab meil määrata nende vahelisi formaalseid sõltuvusi ja nendega tehtavaid formaalseid tehteid. See lihtsustab nii mudelite väljatöötamist ja uurimist (analüüsi) kui ka nende arvutis rakendamist. Eelkõige võimaldab mudelite formaalne iseloom saada arendatava tarkvarasüsteemi formaalse mudeli selle komponentide formaalsete mudelite kompositsioonina.
Seega aitab objektorienteeritud lähenemine toime tulla keeruliste probleemidega nagu
· tarkvara keerukuse vähendamine;
· tarkvara töökindluse suurendamine;
· pakkudes võimalust muuta üksikuid tarkvarakomponente ilma selle ülejäänud komponente muutmata;
· üksikute tarkvarakomponentide taaskasutamise võimaluse tagamine.
Objektorienteeritud lähenemise süstemaatiline rakendamine võimaldab meil välja töötada hästi struktureeritud, töökindlaid ja üsna lihtsalt muudetavaid tarkvarasüsteeme. See seletab programmeerijate huvi objektorienteeritud lähenemise ja objektorienteeritud programmeerimiskeelte vastu. Objektorienteeritud lähenemine on teoreetilise ja rakendusliku programmeerimise üks kiiremini arenevaid valdkondi.
1.3 Tööriistad objektorienteeritud programmeerimistehnoloogia rakendamiseks
OOP-tehnoloogias on andmete ja algoritmi vaheline seos korrapärasem: esiteks ühendab klass (selle tehnoloogia põhikontseptsioon) andmed (struktureeritud muutuja) ja meetodid (funktsioonid). Teiseks on funktsioonide ja andmete interaktsiooni muster põhimõtteliselt erinev. Ühel objektil kutsutud meetod (funktsioon) ei kutsu tavaliselt teist funktsiooni otse. Esiteks peab tal olema juurdepääs teisele objektile (loo, hankige kursor, kasutage praeguses sisemist objekti jne), misjärel saab ta juba helistada ühele tuntud meetodid. Seega määrab programmi ülesehituse erinevate klasside objektide omavaheline interaktsioon. Reeglina eksisteerib klasside hierarhia ja muidu võib OOP-tehnoloogiat nimetada “klassist klassi” programmeerimiseks.
Iga programmeerimine toimub vastavalt ühele neljast põhimõttest:
modulaarsuse põhimõte
põhimõte "üldisest konkreetseni"
· samm-sammult põhimõte
· struktureerimispõhimõte
Modulaarne programmeerimine. Modulaarsuse põhimõte on sõnastatud nõudena programmi arendamiseks moodulite (funktsioonide) kogumi kujul. Sel juhul ei tohiks mooduliteks jaotamine olla mehaaniline, vaid lähtuda programmi loogikast:
1. mooduli suurus peab olema piiratud;
2. moodul peab sooritama loogiliselt tervikliku ja tervikliku toimingu;
3. moodul peab olema universaalne, st võimalusel parameetritega: kõik sooritatava toimingu muudetavad omadused peavad olema edastatud parameetrite kaudu;
4. sisendparameetrid ja mooduli tulemust on soovitav edastada mitte globaalsete muutujate, vaid formaalsete parameetrite ja funktsiooni tulemuse kaudu.
Üks veel, aga juba füüsiline ühik programm on tekstifail, mis sisaldab mitmeid funktsioone ning andmetüüpide ja muutujate määratlusi. Failitaseme modulaarne programmeerimine on eraldamise võimalus täistekst programmid mitme faili jaoks. Modulaarsuse põhimõte kehtib mitte ainult programmide, vaid ka andmete kohta: mis tahes loogilist või füüsilist objekti iseloomustav parameetrite kogum peab olema programmis esindatud ühtse andmestruktuuri (struktureeritud muutuja) kujul.
Modulaarsuse põhimõtte teostus on raamatukogu standardfunktsioonid. Tavaliselt annab see täiskomplekt parameetritega toimingud kasutades üldised struktuurid andmeid. Raamatukogud on sarnased programmid, mis on iseseisvalt tõlgitud ja paigutatud raamatukogu kataloogi.
Ülevalt alla programmeerimine. Ülevalt alla programmi ülesehitus on see, et arendus tuleneb mõne programmi tegevuse üldisest mitteametlikust sõnastusest loomulik keel, "üldisest konkreetseni": selle asendamine ühega kolmest formaalsest programmeerimiskeele konstruktsioonist:
· lihtne toimingute jada;
· valikukonstruktsioonid või if-laused;
· kordus- või tsüklikonstruktsioonid.
Algoritmi tähistuses vastab see liikumisele väliselt (hõlmavalt) struktuurilt sisemisele (pesastatud). Need kujundused võivad sisaldada ka tegevuste mitteametlikke kirjeldusi oma osades, st ülalt-alla kujundus on olemuselt samm-sammult. Märgime selle lähenemisviisi peamised omadused:
· algselt koostatakse programm mõne mitteametliku tegevuse vormis loomulikus keeles;
· algselt määratakse sisendparameetrid ja toimingu tulemus;
· detaileerimise järgmine samm ei muuda eelmistes sammudes saadud programmi struktuuri;
· kui projekteerimise käigus saadakse erinevates harudes identsed toimingud, siis see tähendab, et see tegevus on vajalik kujundada eraldi funktsioonina;
· vajalikud andmestruktuurid kujundatakse samaaegselt programmi detailiseerimisega.
Samm-sammult programmeerimine. Ülalt-alla kujundus on olemuselt järkjärguline, kuna see hõlmab iga kord ühe verbaalse sõnastuse asendamist ühe keelekonstruktsiooniga. Kuid programmi väljatöötamise protsessis võib esineda muid samme, mis on seotud sõnalise sõnastuse enda täpsustamisega üksikasjalikumaks.
Asjaolu, et see põhimõte on eraldi esile tõstetud, viitab vajadusele vältida kiusatust detailselt programm kohe algusest lõpuni ning arendada oskust tõsta esile ja koondada tähelepanu algoritmi põhidetailidele, mitte väiksematele detailidele.
Üldiselt allapoole samm-sammult disain Programm ei garanteeri “õige” programmi saamist, kuid võimaldab ummikseisu tuvastamisel naasta ühe detaili ülemise sammu juurde.
Struktureeritud programmeerimine. Programmi ülalt-alla samm-sammult viimistlemisel ilmnevad toimimiseks vajalikud andmestruktuurid ja muutujad, kui liigume mitteformaalsetelt definitsioonidelt keelekonstruktsioonide juurde, st algoritmi ja andmete detailiseerimise protsessid kulgevad paralleelselt. See kehtib aga eelkõige üksikute kohalike muutujate ja sisemiste parameetrite kohta. Kõige üldisemast vaatenurgast on objekt (meie puhul andmed) alati esmane temaga tehtavate toimingute (meie puhul algoritmi) suhtes. Seetõttu mõjutab tegelikult see, kuidas programm andmeid korraldab, selle algoritmi struktuurile olulisemat mõju kui miski muu ja andmestruktuuride kujundamise protsess peaks eelnema nende töötlemise algoritmi väljatöötamisele.
Struktureeritud programmeerimine on modulaarne, ülalt-alla, samm-sammult algoritmide ja andmestruktuuride kujundamine.
Objektorienteeritud lähenemine programmeerimisele sisaldab kolme põhikomponenti:
· objektorienteeritud analüüs (OOA),
· objektorienteeritud disain (OOD),
· objektorienteeritud programmeerimine (OOP).
Igas inseneridistsipliinis viitab disain tavaliselt ühtsele lähenemisele, mille kaudu otsime võimalusi konkreetse probleemi lahendamiseks, tagades ülesande täitmise. Tehnilise projekteerimise kontekstis on projekteerimise eesmärk määratletud kui süsteemi loomine, mis
rahuldab antud (võimalik, et mitteametlik) funktsionaalsed spetsifikatsioonid;
· kooskõlas seadmete poolt kehtestatud piirangutega;
· rahuldab otsesed ja kaudsed nõuded jõudluse ja ressursside tarbimise kohta;
· vastab otsestele ja kaudsetele tootekujunduse kriteeriumidele;
· rahuldab arendusprotsessi enda nõudeid, nagu kestus ja maksumus, samuti lisavahendite kasutamine.
Disain hõlmab vastuoluliste nõuete arvestamist. Selle tooted on mudelid, mis võimaldavad meil struktuurist aru saada tulevane süsteem, tasakaalustage nõuded ja visandage rakendusskeem.
Programm on projekteeritava süsteemi numbriline mudel (joonis 1.3.1.)
Riis. 1.3.1. Programmi struktuur.
Mudeli loomise tähtsus. Modelleerimine on laialt levinud kõigis inseneriteadustes, suuresti seetõttu, et see rakendab lagunemise, abstraktsiooni ja hierarhia põhimõtteid. Iga mudel kirjeldab teatud osa vaadeldavast süsteemist ja meie omakorda ehitame vanade põhjal uusi mudeleid, milles oleme enam-vähem kindlad. Mudelid võimaldavad meil oma ebaõnnestumisi kontrollida. Hindame iga mudeli käitumist tavalistes ja ebatavalistes olukordades ning seejärel teeme vastavad kohandused, kui me millegagi rahul ei ole.
Tarkvara disaini elemendid. Selge, et sellist asja pole universaalne meetod, mis juhendaks tarkvarainseneri keerulise tarkvarasüsteemi nõuetest nende rakendamiseni. Keerulise tarkvarasüsteemi kujundamine ei tähenda retseptide kogumi pimesi järgimist. Pigem on see järkjärguline ja korduv protsess. Ja veel, disainimetoodika kasutamine toob arendusprotsessi teatud organisatsiooni. Tarkvarainsenerid on välja töötanud kümneid erinevaid meetodeid, mille saame liigitada kolme kategooriasse. Vaatamata nende erinevustele on neil meetoditel midagi ühist. Eelkõige ühendab neid järgmine:
· sümbolid – iga mudeli kirjeldamise keel;
· protsess - mudeli kujundamise reeglid;
· tööriistad - tööriistad, mis kiirendavad mudelite loomise protsessi ja milles on juba kehastunud mudelite toimimise seadused. Tööriistad aitavad tuvastada vigu arendusprotsessi ajal.
Hea disainimeetod põhineb tahkel teoreetiline alus ja samas annab programmeerijale teatud väljendusvabaduse.
Objektorienteeritud mudelid. Kõige kasulikum on luua mudeleid, mis keskenduvad domeenis endas leiduvatele objektidele, moodustades nn objektorienteeritud dekompositsiooni.
Objektorienteeritud analüüs ja disain on meetod, mis loogiliselt viib objektorienteeritud lagunemiseni. Objektorienteeritud disaini kasutades luuakse programme, mis on paindlikud ja koostatud kuluefektiivselt. Olekuruumi targalt jagades saavutame suurema kindlustunde oma programmi õigsuses. Selle tulemusena vähendame kompleksi väljatöötamisel riski tarkvarasüsteemid.
Kuna mudelite ehitamine on projekteerimisel äärmiselt oluline keerulised süsteemid, objektorienteeritud disain pakub rikkalikku mudelivalikut, (näidatud joonisel 1.3.2) Objektorienteeritud disainimudelid peegeldavad nii klasside kui ka süsteemiobjektide hierarhiat. Need mudelid hõlmavad kogu kõige olulisemate spektrit disainilahendused, mida tuleb keeruka süsteemi kavandamisel arvesse võtta ja mis inspireerib meid looma disainilahendusi, millel on kõik viis hästi kavandatud komplekssüsteemide atribuuti.
Riis. 1.3.2 Objektorienteeritud mudelid.
OOP on programmeerimisideoloogia, mis põhineb andmete ja protseduuride kombineerimisel, mis võivad nende andmetega kollektiivselt töötada, mida nimetatakse klassideks.
OOP olemuseks on igapäevaelus tuttava objektimudeli kasutamine. Igal objektil on oma omadused ja saate teha sellele spetsiifilisi toiminguid. Klass on objektitüüp. Klass kirjeldab ja rakendab samu omadusi ja toiminguid. Objekt on meie mõistes muutuja, mille tüübiks on mingi klass. Klassi välju nimetatakse selle omadusteks ja meetoditeks toiminguteks, mida saab teha selle klassi eksemplariga (objektiga).
Klassi juurutamise näitena vaatame raamatu kontseptsiooni rakendamist, kasutades klassi, et määratleda raamatu TBook esitus ja funktsioonide komplekt seda tüüpi muutujatega töötamiseks:
PagesCount: täisarv;
funktsioon Võrdle raamatuga (muu raamat: TBook): täisarv;
protseduur ShowTitle;
konstruktor Loo (NewTitle, New
Inimese kognitiivsed võimed on piiratud; me saame nende piire nihutada dekompositsiooni, abstraktsiooni ja hierarhiate abil.
Keerulisi süsteeme saab uurida, keskendudes kas objektidele või protsessidele; On häid põhjusi kasutada objektorienteeritud dekompositsiooni, mille puhul maailma vaadeldakse objektide järjestatud kogumina, mis üksteisega suhtlemise käigus määravad süsteemi käitumise.
Objektorienteeritud analüüs ja disain on meetod, mis kasutab objektide dekompositsiooni; objektorienteeritud lähenemisel on oma süsteem sümbolid ning pakub rikkalikku loogiliste ja füüsiliste mudelite komplekti, mille abil saame neist ülevaate saada erinevaid aspekte vaadeldav süsteem.
2. AINEDOMEEENI “SPORDIKLUBI PROTSESSIDE KORRALDAMINE” OBJEKTMUDELI KONSTRUKTSIOON UML MODELLEERIMISKEELT
2.1 UML-keele kontseptsioon
UML (Unified Modeling Language) on ühtne graafiline modelleerimiskeel objektorienteeritud süsteemide kirjeldamiseks, visualiseerimiseks, kujundamiseks ja dokumenteerimiseks. UML on loodud toetama objektorienteeritud lähenemisviisil põhinevat tarkvara modelleerimise protsessi, korraldama seoseid kontseptuaalse ja programmi kontseptsioonid, peegeldavad keeruliste süsteemide skaleerimise väljakutseid. UML-i mudeleid kasutatakse kõikidel etappidel eluring tarkvaratööriistu, alustades ärianalüüsist ja lõpetades süsteemihooldusega. Erinevad organisatsioonid võivad UML-i kasutada oma äranägemise järgi, olenevalt nende probleemsetest valdkondadest ja kasutatavatest tehnoloogiatest.
2.1.1 UML-i lühiajalugu
90ndate keskpaigaks olid erinevad autorid välja pakkunud mitukümmend objektorienteeritud modelleerimismeetodit, millest igaüks kasutas oma graafilist tähistust. Samal ajal olid ühelgi neist meetoditest oma tugevad küljed, kuid see ei võimaldanud luua piisavalt terviklikku tarkvaramudelit, näidates seda "igast küljest", see tähendab kõiki vajalikke projektsioone. Lisaks raskendas objektorienteeritud modelleerimise standardi puudumine arendajatel sobivaima meetodi valimist, mis takistas tarkvaraarenduses objektorienteeritud lähenemisviisi laialdast kasutuselevõttu.
Valdkonna standardite vastuvõtmise eest vastutava organisatsiooni Object Management Group (OMG) palvel objekti tehnoloogiad ja andmebaasid, lahendasid kiireloomulise unifitseerimise ja standardimise probleemi kolme populaarseima objektorienteeritud meetodi autorid – G. Booch, D. Rambo ja A. Jacobson, kes lõid ühiselt versiooni UML 1.1, mille OMG 1997. aastal heaks kiitis. standard.
Seoses kasvava huviga UML-i vastu liitusid keele uute versioonide väljatöötamisega sellised ettevõtted nagu Digital Equipment Corporation, Hewlett-Packard, i-Logix, IntelliCorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle Corporation, Rational Software UML Partnersi konsortsiumi raames. Texase instrumendid ja Unisys. Ühise töö tulemuseks oli 1997. aasta jaanuaris välja antud spetsifikatsioon UML 1.0. Sellele järgnes sama aasta novembris versioon 1.1, mis sisaldas tähistuse täiustusi ja mõningaid semantilisi laiendusi. UML 1.4.2 on rahvusvahelise standardina vastu võetud standardiga ISO/IEC 19501:2005.
UML 2.0 uusima versiooni ametlik spetsifikatsioon avaldati 2005. aasta augustis. Keele semantikat on oluliselt täiustatud ja laiendatud, et toetada Model Driven Development – MDD metoodikat. Uusim versioon UML 2.4.1 avaldati 2011. aasta augustis. UML 2.4.1 on rahvusvahelise standardina vastu võetud standarditega ISO/IEC 19505-1, 19505-2.
2.1.2 UML keel
Iga keel koosneb sõnavarast ja sõnade kombineerimise reeglitest tähenduslike konstruktsioonide loomiseks. Eelkõige on see programmeerimiskeelte, sealhulgas UML-i ülesehitus. Selle eripäraks on see, et keele sõnavara moodustavad graafilised elemendid. Igale graafiline sümbol spetsiifiline semantika vastab, nii et ühe arendaja loodud mudelit saab üheselt mõista nii teine kui ka UML-i tõlgendav tarkvaratööriist. Siit tuleneb eelkõige, et UML-is esitatud tarkvaramudelit saab automaatselt tõlkida OO programmeerimiskeelde (nagu Java, C++, VisualBasic), st kui on olemas hea UML-i toetav visuaalse modelleerimise tööriist, millel on ehitanud mudeli , saame ka tooriku kätte programmi kood, mis vastab sellele mudelile.
Tuleb rõhutada, et UML on keel, mitte meetod. See selgitab, millistest elementidest mudeleid luua ja kuidas neid lugeda, kuid ei ütle midagi selle kohta, milliseid mudeleid ja millistel juhtudel tuleks välja töötada. UML-il põhineva meetodi loomiseks on vaja seda täiendada tarkvara arendusprotsessi kirjeldusega. Sellise protsessi näiteks on ratsionaalne ühtne protsess, mida arutatakse järgmistes artiklites.
2.1.3 UML sõnastik
Mudel on kujutatud olemite ja nendevaheliste suhete kujul, mis on näidatud diagrammidel.
Olemid on abstraktsioonid, mis on mudelite põhielemendid. Olemeid on nelja tüüpi – struktuurne (klass, liides, komponent, kasutusjuhtum, koostöö, sõlm), käitumuslikud (interaktsioon, olek), rühmitamine (paketid) ja annotatsioon (kommentaarid). Igal olemitüübil on oma graafiline esitus. Üksusi käsitletakse üksikasjalikult diagrammide uurimisel.
Seosed näitavad erinevaid seoseid olemite vahel. UML määratleb järgmised suhtetüübid:
· Sõltuvus näitab sellist seost kahe olemi vahel, kui muutus ühes neist - sõltumatus - võib mõjutada teise - sõltuva - semantikat. Sõltuvus on tähistatud punktiirjoonega noolega, mis on suunatud sõltuvast olemilt sõltumatule olemile.
· Seos on struktuurne seos, mis näitab, et ühe olemi objektid on seotud teise olemi objektidega. Graafiliselt näidatakse seost seostatud olemeid ühendava joonena. Seosed aitavad objektide vahel navigeerida. Näiteks klasside “Tellimus” ja “Toode” vahelist seost saab kasutada ühelt poolt kõigi konkreetses tellimuses märgitud toodete leidmiseks või teisalt kõikide seda toodet sisaldavate tellimuste leidmiseks. On selge, et vastavad programmid peavad rakendama mehhanismi, mis sellist navigeerimist pakub. Kui navigeerimine on vajalik ainult ühes suunas, on seda tähistatud noolega seose lõpus. Assotsiatsiooni erijuhtum on liitmine - suhe kujul "tervik" - "osa". Graafiliselt on see esile tõstetud teemandiga essentsi terviku lõpus.
· Üldistus on seos ema-olemi ja alamolemi vahel. Põhimõtteliselt peegeldab see suhe klasside ja objektide pärimise omadust. Üldistust näidatakse joonena, mis lõpeb kolmnurgaga, mis on suunatud emaüksuse poole. Laps pärib vanema struktuuri (atribuudid) ja käitumise (meetodid), kuid samal ajal võib sellel olla uusi struktuurielemente ja uusi meetodeid. UML lubab mitmekordne pärimine kui (majandus)üksus on seotud rohkem kui ühe emaüksusega.
· Rakendamine – suhe käitumise spetsifikatsiooni (liidese) määratleva olemi ja selle käitumise rakendamist määratleva olemi (klass, komponent) vahel. Seda seost kasutatakse tavaliselt komponentide modelleerimisel ja seda kirjeldatakse üksikasjalikumalt järgmistes artiklites.
Diagrammid. UML pakub järgmisi diagramme:
· Süsteemi käitumist kirjeldavad skeemid:
Oleku diagrammid
· tegevusskeemid,
· Objekti diagrammid,
Järjestusskeemid
· Koostöö diagrammid;
· Süsteemi füüsilist rakendamist kirjeldavad skeemid:
· Komponentide diagrammid;
· Paigaldusskeemid.
2.1.4 Juhtimisstruktuuri mudel
Selleks, et mudel oleks inimestele hästi arusaadav, on vaja see korraldada hierarhiliselt, jättes hierarhia igale tasemele väikese arvu üksusi. UML sisaldab vahendit mudeli hierarhilise esituse korraldamiseks – paketid. Iga mudel koosneb pakettide komplektist, mis võivad sisaldada klasse, kasutusjuhtumeid ja muid oleme ja diagramme. Pakett võib sisaldada teisi pakette, mis võimaldab luua hierarhiaid. UML ei paku eraldi pakettide diagramme, kuid need võivad esineda teistes diagrammides. Pakend on kujutatud järjehoidjaga ristkülikuna.
UML pakub.
· kompleksse süsteemi hierarhiline kirjeldamine pakettide esiletõstmisega;
· süsteemi funktsionaalsete nõuete vormistamine kasutusjuhtude aparatuuri abil;
· süsteeminõuete täpsustamine tegevusskeemide ja stsenaariumide koostamise teel;
· andmeklasside tuvastamine ja kontseptuaalse andmemudeli konstrueerimine klassidiagrammide kujul;
· kasutajaliidest kirjeldavate klasside tuvastamine ja ekraanil navigeerimisskeemi loomine;
· objektide interaktsiooni protsesside kirjeldamine süsteemi funktsioonide täitmisel;
· objektide käitumise kirjeldus tegevus- ja olekudiagrammide kujul;
· tarkvara komponentide ja nende interaktsiooni kirjeldus liideste kaudu;
· süsteemi füüsilise arhitektuuri kirjeldus.
UML-i oleks tegelikus tarkvara modelleerimises raske kasutada ilma visuaalse modelleerimise tööriistadeta. Sellised tööriistad võimaldavad teil kiiresti kuvaril diagramme esitada, dokumenteerida, genereerida programmikoodi malle erinevates objektorienteeritud programmeerimiskeeltes ja koostada andmebaasi diagramme. Enamik neist sisaldab võimalust programmikoode ümber kujundada – tarkvaramudeli teatud projektsioone taastada, analüüsides automaatselt programmide lähtekoode, mis on väga oluline mudeli ja koodide järjepidevuse tagamiseks ning eelkäijasüsteemide funktsionaalsust pärivate süsteemide kavandamisel.
2.2 Ainevaldkonna “Spordiklubi töökorraldus” toimimise kirjeldus
Sõltuvalt ettevõtte osakondade vaheliste seoste olemusest eristatakse järgmist tüüpi organisatsioonilisi struktuure: lineaarne, funktsionaalne, lineaar-funktsionaalne ja maatriks.
Selle spordiklubi töös kasutatakse lineaarset juhtimisstruktuuri.
Spordiklubi lahendab järgmisi probleeme:
· noorte ja nende pereliikmete kaasamine süsteemsesse kehakultuuri ja sporti;
· füüsiliste ja kõlbelis-tahtlike omaduste kasvatamine, tervise tugevdamine ja haigestumuse vähendamine, noorte tööalase valmisoleku ja sotsiaalse aktiivsuse taseme tõstmine;
· massiliste vabaaja-, kehalise kasvatuse ja spordiürituste korraldamine ja läbiviimine;
· spordis harrastusspordi ühenduste, klubide, sektsioonide ja võistkondade loomine;
· kehakultuuri ja spordi edendamine, tervislikud eluviisid, sisuka vaba aja veetmise korraldamine, laiade noorte masside kaasamine ühiskondlik-poliitilistesse massiüritustesse
Spordiklubi täidab järgmisi funktsioone:
· rakendab kehakultuuri ja sporti noorte tegemistes, nende elus ja puhkamises; propageerib tervislikku eluviisi, võitleb selle ületamiseks halvad harjumused;
· loob vajalikud organisatsioonilised ja metoodilised tingimused erinevate kehakultuuri- ja spordivormide ja -liikide harrastamiseks vastavalt riigis väljakujunenud traditsioonidele;
· tutvustab uusi vorme ja meetodeid kehaline kasvatus, kõrgetasemelised kogemused ja teadussaavutused; kasutab ratsionaalselt ja tõhusalt materiaalne baas;
· arendab igakülgselt sotsiaalseid põhimõtteid massilises kehalises kasvatuses, tervise- ja sporditöös;
· osutab abi keskkoolidele ja kõrgkoolidele massilise huvitegevuse, kehalise kasvatuse ja sporditegevuse korraldamisel;
· korraldab õppe- ja treeningprotsessi spordisektsioonides (koondised);
· töötab välja ja viib ellu massiliste vabaaja-, kehalise kasvatuse ja spordiürituste kalenderplaane, tagab nende elluviimise ohutuse;
· annab kontrolli spordiklubi kõrgeima spordikvalifikatsiooniga sportlaste ettevalmistamise osakondades õppe- ja treeningprotsessi üle, aitab kaasa vajalikud tingimused suurendada oma sportlikkust;
· korraldab koos tervishoiuasutustega arstlikku kontrolli asjaosaliste tervisliku seisundi üle füüsiline kultuur ja sport sektsioonides (rahvuskoondised);
· koostab massilise kehakultuuri, tervise-, kasvatus- ja sporditöö arendamise jooksvad ja pikaajalised plaanid ning kalkuleerib klubi kulutusi.
· teostab oma pädevuse piires kehalise kasvatuse personali valikut ja paigutamist;
· võib olla lipp, embleem, spordivorm, tempel, kirjaplank;
· viib läbi massivõistlusi, spordipäevi (universiaadi), õppe- ja treeninglaagreid;
· saadab vastavalt kinnitatud korrale võistkondi ja üksiksportlasi võistlustele;
· väljastab ülikooli meeskondade liikmetele vastavaid tunnistusi (märke);
2.3 Ainevaldkonna “Spordiklubi protsesside korraldamine” klassiskeemi koostamine
Spordiklubil on klubipõhiselt neli sektsiooni:
· Korvpall
· Võrkpall
· Tennis.
Kui kandidaat-sportlane taotleb spordiklubisse registreerumist mis tahes sektsioonis, toimub registreerimine, mis hõlmab järgmisi toiminguid:
· Andmed sportlaste kohta kantakse tabelisse, kus on märgitud 5 välja: Perekonnanimi, Eesnimi, Vanus, Telefon, Jaotis.
· Sportlased jagunevad sektsioonidesse, kuhu taotlus esitati.
· Sportlaste vanematele antakse spordiklubi sektsioonide ajakava.
Organisatsiooni jaoks õige toimimine klubi, sektsioonide töö koordineerimine, treenerite palkamine, ajakava täidab spordiklubi administraator.
Klubiga liitumisel kantakse sportlane sektsiooni tähistavasse tabelisse. Kõik klubiga seotud sportlased tuleb kanda jaotist tähistavasse põhitabelisse.
Sest visuaalne esitus Spordiklubi tööprotsesside jaoks koostati UML diagramm (joonis 2.3.1).
Riis. 2.3.1 Spordiklubi objektorienteeritud mudel.
3. AINEDOMEENI “SPORDIKLUBI TÖÖKORRALDUS” OBJEKTMUDELI KONSTRUKTSIOON DELPHI VISUAALSE PROGRAMMEERIMISKESKKONNA KASUTAMINE
3.1 Rakenduse struktuuri kirjeldus
See rakendus on osa spordipaketist. See koosneb klassist: klass Tinimesed.
Klass “TPimesed” võimaldab teil luua ja koguda teavet sellega seotud laste kohta Spordiklubi, mis kandis nime "Ogonyok". Sellel on viis välja: nimi määratakse stringiga “Nimi”; Perekonnanime määrab string "Perekond"; Vanus salvestatakse arvmuutujas (int) "Age"; telefoninumber on määratud stringiga “Tel”; Lõik, milles sportlane treenib, on määratud stringiga "Sekc".
TInimesed = klass
Nimi: String;
Perekond: Keel;
Vanus: täisarv;
tel: String;
sekc: String;
konstruktor Loo(ANimi: String);
lõpp;
Sel juhul sisestatakse väljad kahel viisil:
Väärtuse laadimine LST-laiendiga salvestatud failist. (Joonis 3.1.1.)
Meetod on korraldatud funktsiooni OpenDlg abil, kusjuures iga klassi rida loetakse eraldi väärtusena.
var F: TextFile;
i: täisarv;
alustada
proovi
OpenDlg-ga, PersonsList.Items teeb seda
alustada
kui ei teosta, siis välju;
LoadFromFile(Failinimi);
AssignFile(F, Copy(Failinimi,1,Pikkus(Failinimi)-4)+.lso");
Lähtesta(F);
i:= 0;
samas kui mitte EOF(F) seda teevad
alustada
Objektid[i] := TInimesed.Loo("");
Readln(F, (Objektid[i] kui TInimesed).Nimi);
Readln(F, (Objektid[i] kui TInimesed).Perekond);
Readln(F, (Objektid[i] kui TInimesed).Vanus);
Readln(F, (Objektid[i] kui TInimesed).tel);
Readln(F, (Objektid[i] kui TInimesed).sekc);
Inc(i);
lõpp;
CloseFile(F);
lõpp;
välja arvatud
on E: EFOpenError do ShowMessage("Viga faili avamisel");
lõpp;lõpp;
Riis. 3.1.1 Faili üleslaadimine.
Teine tabeli täitmise viis on sisestamine Redigeerimiskomponentide abil (joonis 3.1.2.).
Riis. 3.1.2 Tabeli täitmine komponendi Redigeerimine abil.
Lisaks valitakse välja „Sektsioon” väärtus komponendi Combobox väärtuste hulgast ja määratakse reale „Sekc”. (joonis 3.1.3)
Riis. 3.1.3 Liitkasti komponent.
Sisestatud väärtusi saab muuta, valides soovitud väärtuse ja klõpsates nuppu "Muuda" (joonis 3.1.4).
Riis. 3.1.4 Väärtuste muutmine.
Programm näeb ette väärtuse kustutamise, kustutades ühe kirje (joonis 3.1.5) ja kustutades kõik kirjed (joonis 3.1.6).
Ühe kirje kustutamiseks tuleb valida väärtus ja klõpsata nuppu "Kustuta".
Riis. 3.1.5 Ühe kirje kustutamine.
Kõigi kirjete kustutamiseks klõpsake nuppu "Tühjenda".
Riis. 3.1.6 "Tühjenda" nupp.
Mõlemad eemaldamismeetodid viiakse läbi järgmiste meetodite abil:
protseduur TMainForm.ToolButton4Click(Saatja: TObject);
alustada
koos Isikuteloendiga tee Üksused.Kustuta(ItemIndex);
lõpp;
protseduur TMainForm.ToolButton5Click(Saatja: TObject);
alustada
PersonsList.Items.Clear;
lõpp;
Pärast sportlaste tabeli täitmist on vaja see edaspidiseks kasutamiseks salvestada. Seda saab teha vajutades nuppu “Salvesta” (joonis 3.1.7). Pärast sellel nupul klõpsamist avaneb dialoogiboks, kus näidatakse faili salvestamise kaust ja selle nimi. (joonis 3.1.8).
Sarnased dokumendid
lühikirjeldus ainevaldkond. Objektorienteeritud infosüsteemi mudeli väljatöötamise asjakohasus haridusraamatukogu. Looge kasutusjuhtumiskeem, järjestusskeem, koostööskeem, klassiskeem.
kursusetöö, lisatud 01.06.2009
Objektorienteeritud alamsüsteemi arendamine laoarvestus ettevõttele "KavkazYugAvto". Teemavaldkonna lühikirjeldus. Paigutuse, kasutusjuhtude, järjestuse, komponentide ja klasside diagrammide joonistamine. C++ koodi genereerimine.
kursusetöö, lisatud 26.06.2011
Objektimudeli põhielemendid. Objektorienteeritud lähenemise olemus ja eelised, objekti ja klassi mõiste. Unified Modeling Language UML. Klassi- ja interaktsiooniskeemid: eesmärk, ehitus ja kasutusnäited.
abstraktne, lisatud 06.09.2009
Teemavaldkonna „Müügi pood arvuti komponendid". ER ehitus ja relatsiooniline mudel andmed, olemid ja suhted. ER ja relatsioonilise andmemudeli loomine, päringud, vaated, ainevaldkonna salvestatud protseduurid.
kursusetöö, lisatud 15.06.2014
Tarkvarasüsteemide asjakohasus ja praktiline tähtsus arvutiklubi. Domeeni analüüs. Klassiskeem, süsteemi füüsiline mudel. Visuaalse IS projekti arendamine kasutades UML2.0 keelt ja Microsoft Visio modelleerimiskeskkonda.
kursusetöö, lisatud 21.06.2014
Ainevaldkonna "Luuletajate konkurss" analüüs objektkeskse lähenemise alusel. Areng akna rakendus ja kirjeldus teabemudel ainevaldkond. Väljatöötatud C++ protseduuride ja rakenduste testimise tulemuste kirjeldus.
kursusetöö, lisatud 18.06.2013
Funktsionaalne modelleerimine IDEF0. Kõikide tehnilise toe osakonna tööprotsesside kirjeldus. Konteksti diagrammi ja põhiprotsesside lagunemine. Domeeniprotsesside mudeli koostamine IDEF1X standardis. Liikluskorraldusprogrammi liides.
praktika aruanne, lisatud 22.11.2014
Ainevaldkonna infoloogilise mudeli konstrueerimine meetodil ER diagrammid. Andmebaasisuhete loomine kasutades SQL keel. Andmebaasi täitmine. Päringute loomine arvutiklubi andmebaasi. Looge aruanne rakendusega kasutades Microsofti Word ja Microsoft Excel.
kursusetöö, lisatud 26.02.2009
Teemavaldkonna lühikirjeldus. Looge kasutusjuhtumeid, järjestusi, koostööd, klassi, paigutust, komponentide diagramme. Toimingute kirjeldustele üksikasjade lisamine ja CLASS atribuutide määratlemine. C++ koodi genereerimine.
kursusetöö, lisatud 29.06.2011
Lao kui majandustegevuse objekti üldtunnused. Koostage kasutusjuhtum ja järjestusskeem. Ettevõtte koostööskeemi koostamine. Klassi- ja komponentdiagrammide eesmärk. C++ koodi genereerimine.
Probleemi objektmudeli loomine UML-i modelleerimiskeele abil.
TÖÖD TEHAB StarUMLis
Ettevalmistusaeg:
2-3 õppetundi
Oma töö kaitsmiseks peate esitama paketis Rational Rose loodud projekti, mis sisaldab kolme tüüpi diagramme: kasutusjuhtumid, klassid (liides, andmed) ja iga funktsiooni järjestused.
NÄIDISÜLESANNE:
Vajalik on anda talletus andmebaasis järgmist teavet:
- õpilaste teave
o TÄISNIMI.,
o aadress,
o passi andmed,
o rekordnumber,
o Sünnikuupäev,
o Grupp);
- teave erialade kohta
o eriala nimi,
o šifr;
- teave rühmade kohta
o eriala,
o sisseastumisaasta,
o rühma number.
Tagage järgmisi välju sisaldava rühmaloendi dokumendi väljastamine:
· seerianumber,
· TÄISNIMI.,
· rekordnumber.
Töökäsk
Objekti mudeli ehitamine toimub paketis Rational Rose. Selleks loome tühja projekti. Tööd tuleks alustada kasutusjuhtude diagrammiga. See on ehitatud jaotise Kasutusjuhtumi vaate põhialasse, nagu on näidatud joonisel 9.
Enne diagrammi koostamise alustamist on vaja määratleda süsteemi kasutajate (toimijate) rollid ja nende funktsioonid (kasutusjuhud). Meie puhul töötab süsteemiga kaks tegijat: “Haridusosakonna töötaja” ja “Dekanaadi töötaja”. Haridusosakonna töötaja ülesannete hulka kuulub erialade nimekirja pidamine (all nimekirja pidamine me mõistame kirjete lisamist, korrigeerimist ja kustutamist). Dekanaaditöötaja ülesannete hulka kuulub üliõpilaste nimekirja pidamine ja rühmade nimekirja pidamine.
Konstrueeritud diagramm on näidatud joonisel fig. 10.
Järgmisena peaksite jaotises Loogiline vaade looma kaks klassidiagrammi. Selleks saate luua kaks paketti. Esimene diagramm peaks sisaldama kavandatava rakenduse liideste klasse (vt joonis 11). Sellel joonisel on klassides “Rühmade nimekiri” ja “Õpilaste nimekiri” lisamise, muutmise ja kustutamise toimingud välja jäetud, et vältida joonise risustamist. Rühmanimekiri (alumine klass) on väljunddokument (sellele eelneb klass “Rühmavalik”, kuna on vaja hankida teatud rühma õpilaste nimekiri). Teine diagramm on andmebaasi olemid (vt joonis 12).
Koostatud klassidiagramm kuvab kõik tulevase rakenduse vormid ja nende seosed.
Peaksite sisestama võtmeväljad ja looma ühenduse (noole kontekstimenüüst - Mitmekülgsus).
Objektimudeli loomise järgmine etapp on järjestusskeemide loomine. Kasutusjuhtumi diagrammis luuakse iga kasutusjuhu jaoks järjestusskeemid. Kasutusjuhtumile järjestusdiagrammi lisamiseks peate selle puust valima ja kutsuma selle kontekstimenüü (NewàSequence Diagram), nagu on näidatud joonisel fig. 13.
„Erialade loetelu pidamine“ pretsedendi jada diagrammi näide on näidatud joonisel fig. 14.
Tuleb märkida, et seda tüüpi diagrammi koostamisel väljunddokumendi “Rühmade loend” jaoks tuleks meie puhul kõigepealt valida rühm vormil “Rühma valik” (see omakorda peaks saama andmeid “Grupist” ” olem) ja kuvage seejärel väljundvormi dokument, mille andmed pärinevad olemilt „Õpilane”.
Objektorienteeritud lähenemise kontseptuaalne alus on objektmudel. Selle ehitamise peamised põhimõtted on järgmised:
· abstraktsioon;
· kapseldamine;
· modulaarsus;
· hierarhia.
Abstraktsioon on mõne objekti kõige olulisemate, oluliste omaduste väljavalimine, mis eristavad seda kõigist teistest objektitüüpidest ja määratlevad seega selgelt selle kontseptuaalsed piirid edasise käsitlemise ja analüüsi seisukohalt ning ignoreerides vähem olulisi või ebaolulisi. üksikasjad.
Abstraktsioon võimaldab hallata süsteemi keerukust, keskendudes objekti olulistele omadustele. Abstraktsioon koondab tähelepanu objekti välistele tunnustele ja võimaldab eraldada selle käitumise kõige olulisemad tunnused nende rakendamise üksikasjadest. Antud probleemvaldkonna jaoks õige abstraktsioonide komplekti valimine on peamine ülesanne objektorienteeritud disain. Abstraktsioon sõltub valdkonnast ja vaatenurgast – mis on ühes kontekstis oluline, ei pruugi teises kontekstis olla oluline. Objektid ja klassid on domeeni põhilised abstraktsioonid.
Kapseldamine on omaduste ja käitumise füüsiline lokaliseerimine ühes abstraktsioonis (mida peetakse "mustaks kastiks"), peites nende rakendamise avaliku liidese taha.
Kapseldamine on protsess, mille käigus eraldatakse üksteisest objekti üksikud elemendid, mis määravad selle struktuuri ja käitumise. Kapseldamise eesmärk on isoleerida objekti liides, mis peegeldab selle välist käitumist, objekti sisemisest teostusest. Objekti käsitlus eeldab, et tema enda ressursid, millega saab manipuleerida ainult objekti enda toimingutega, on väliskeskkonna eest varjatud. Abstraktsioon ja kapseldamine täiendavad üksteist: abstraktsioon koondab tähelepanu objekti välistele tunnustele, samas kui kapseldamine (või muul viisil juurdepääsupiirang) takistab kasutajaobjekte eristamast. sisemine korraldus objektiks.
Kapseldamine sarnaneb teabe peitmise mõistega. See on võime peita objekti arvukalt detaile välismaailma eest. Välismaailm objekt on kõik, mis on sellest väljaspool, kaasa arvatud ülejäänud süsteem. Teabe peitmine annab sama eelise kui kapseldamine: paindlikkus.
Modulaarsus on süsteemi omadus, mis on seotud selle lagunemise võimalusega mitmeks sisemiselt tugevalt seotud, kuid omavahel nõrgalt seotud alamsüsteemideks (mooduliteks).
Modulaarsus vähendab süsteemi keerukust, võimaldades üksikute moodulite iseseisvat arendamist. Kapseldumine ja modulaarsus loovad takistused abstraktsioonide vahele.
Hierarhia on järjestatud või järjestatud abstraktsioonide süsteem, nende paigutus tasandite kaupa.
Peamised hierarhiliste struktuuride tüübid keeruliste süsteemide suhtes on klassistruktuur (hierarhia nomenklatuuri järgi) ja objektide struktuur (hierarhia koostise järgi). Klassihierarhiad on näiteks lihtsad ja mitmekordsed pärimised (üks klass kasutab vastavalt ühe või mitme teise klassi struktuurset või funktsionaalset osa) ja objektide hierarhiad on liitmine.
Klassid saab korraldada hierarhilises struktuuris, mis välimus meenutab kontseptuaalses loogikas klassifitseerimisskeemi. Mõistete hierarhia on üles ehitatud järgmiselt. Kõige üldisemaks mõisteks või kategooriaks peetakse mõistet, millel on suurim maht ja vastavalt ka kõige väiksem sisu. See on kõige rohkem kõrge tase antud hierarhia abstraktsioonid. Siis antud üldine kontseptsioon on täpsustatud, st selle maht väheneb ja sisaldus suureneb. Ilmub vähem üldine kontseptsioon, mis asub hierarhia diagrammil algsest ühe taseme võrra madalamal. Seda mõistete konkretiseerimise protsessi saab jätkata kuni madalam tase ei saada kontseptsiooni, mille edasine täpsustamine antud kontekstis on kas võimatu või ebaotstarbekas.
Iga tarkvaraprojekti loomisel on esimene (ja kõige olulisem) etapp alati disain. Igas inseneridistsipliinis viitab disain tavaliselt mingile ühtsele lähenemisele, mille kaudu otsime võimalusi konkreetse probleemi lahendamiseks, tagades ülesande täitmise. Stroustrupi eelduse taga: "Disaini eesmärk on tuvastada selge ja suhteliselt lihtne sisemine struktuur, mida mõnikord nimetatakse arhitektuuriks... Disain on projekteerimisprotsessi lõpptoode." Disaintooted on mudelid, mis võimaldavad mõista tulevase süsteemi ülesehitust, tasakaalustada nõudeid ja visandada rakendusskeemi.
Modelleerimine on laialt levinud kõigis inseneriteadustes, suuresti seetõttu, et see rakendab lagunemise, abstraktsiooni ja hierarhia põhimõtteid. Iga mudel kirjeldab teatud osa vaadeldavast süsteemist ja meie omakorda ehitame vanade põhjal uusi mudeleid, milles oleme enam-vähem kindlad. Mudelid võimaldavad meil oma ebaõnnestumisi kontrollida. Hindame iga mudeli käitumist tavalistes ja ebatavalistes olukordades ning seejärel teeme vastavad kohandused, kui me millegagi rahul ei ole.
Objektorienteeritud tehnoloogia põhineb nn objektmudelil. Selle peamised põhimõtted on: abstraktsioon, kapseldamine, modulaarsus, hierarhia, tippimine, paralleelsus ja püsivus. Kõik need põhimõtted ei ole tegelikult uued, kuid objektmudelis rakendatakse neid koos esimest korda. Esimesed neli mõistet on kohustuslikud, kuna ilma nendeta ei ole mudel objektorienteeritud. Teised on valikulised, mis tähendab, et need on objektimudelis kasulikud, kuid pole kohustuslikud.
Objektmudeli eelised
Objektimudel erineb põhimõtteliselt mudelitest, mis on seotud traditsioonilisemate struktuurianalüüsi, disaini ja programmeerimise meetoditega. See ei tähenda, et objektmudel eeldaks kõigist varem leitud ja ajaproovitud meetoditest ja tehnikatest loobumist. Pigem tutvustab see uusi elemente, mis täiendavad varasemat kogemust. Objektipõhine lähenemine pakub mitmeid olulisi mugavusi, mida teised mudelid ei pakkunud. Kõige tähtsam on see, et objektipõhine lähenemine võimaldab luua süsteeme, mis vastavad hästi struktureeritud keerukate süsteemide omadustele. Objektmudelil on veel viis eelist.
1. Objektimudel võimaldab täielikult kasutada objekt- ja objektorienteeritud programmeerimise väljendusvõimet. Stroustrup märgib: "Alati pole selge, kuidas sellist keelt nagu C++ täielikult ära kasutada. Tõhusust ja koodi kvaliteeti on võimalik oluliselt parandada, kui kasutada C++-i kui "täiustatud C-d" koos andmeabstraktsiooni elementidega. Kuid palju rohkem A märkimisväärne edasiminek on klassihierarhia kasutuselevõtt projekteerimisprotsessi. Seda nimetatakse objektorienteeritud disainiks ja see on koht, kus demonstreeritakse C++ eeliseid. parim viis"Kogemused on näidanud, et kui selliseid keeli nagu Smalltalk, Object Pascal, C++, CLOS ja Ada kasutatakse väljaspool objektimudelit, siis nende tugevaimaid omadusi kas ignoreeritakse või kasutatakse valesti.
2. Objektipõhise lähenemise kasutamine tõstab oluliselt arengu ühtlustamise ja sobivuse taset taaskasuta mitte ainult programmid, vaid ka projektid, mis lõpuks viib arengukeskkonna loomiseni. Objektorienteeritud süsteemid on sageli kompaktsemad kui nende mitteobjektorienteeritud ekvivalendid. Ja see ei tähenda mitte ainult programmikoodi mahu vähenemist, vaid ka projekti maksumuse vähenemist, mis on tingitud varasemate arenduste kasutamisest, mis annab kulusid ja aega.
3. Objektmudeli kasutamine toob kaasa stabiilsete vahekirjelduste alusel süsteemide ehitamise, mis lihtsustab muudatuste tegemise protsessi. See annab süsteemile võimaluse areneda järk-järgult ega too kaasa selle täielikku ümbertöötamist isegi esialgsete nõuete oluliste muudatuste korral.
4. Objektmudel vähendab keeruliste süsteemide väljatöötamise riski eelkõige seetõttu, et integreerimisprotsess venib pigem kogu arendusperioodiks kui muutuks ühekordseks sündmuseks Objekti käsitlus koosneb läbimõeldud projekteerimisetappidest, mis vähendab ka riskiastet ja suurendab kindlustunnet tehtud otsuste õigsuses.
5. Objektimudel on orienteeritud inimese maailmatajule ehk Robsoni sõnadega: "Paljud inimesed, kellel pole aimugi, kuidas arvuti töötab, peavad objektorienteeritud lähenemist süsteemidele täiesti loomulikuks."
