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 vähem oluliste või ebaoluliste ignoreerides. ü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. Objektorienteeritud disaini peamine väljakutse on antud probleemvaldkonna jaoks õige abstraktsioonikomplekti valimine. 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ääsu piiramine) takistab kasutajaobjektidel objekti sisemist struktuuri eristamast.

Kapseldamine sarnaneb teabe peitmise mõistega. See on võime peita objekti arvukalt detaile välismaailma eest. Objekti välismaailm on kõik 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älimuselt 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 väikseim sisu. See on antud hierarhia kõrgeim abstraktsioonitase. Siis täpsustatakse seda üldmõistet, 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 seni, kuni madalaimal tasemel saadakse mõiste, mille edasine konkretiseerimine antud kontekstis on kas võimatu või ebaotstarbekas.

Probleemi objektimudeli 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: kasutusjuhud, klassid (liides, andmed) ja iga funktsiooni järjestused.

NÄIDISÜLESANNE:

On vaja tagada, et andmebaasis oleks salvestatud järgmine teave:

- õ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 loend" ja "Õpilaste loend" lisamis-, muutmis- ja kustutamistoimingud välja jäetud, et vältida joonise segamist. 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 koostatakse 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”.

Rakendussüsteem esindab üksteisest sõltuvate objektide kogumit. Iga objekti iseloomustab atribuutide komplekt, mille väärtused määravad objekti oleku, ja toimingute komplekt, mida saab sellele objektile rakendada.

Rakendussüsteemide arendamisel on mugav eeldada, et kõik objektide omadused on privaatsed (st väljaspool objekti pole neile ligipääsetav). Objekti toimingud võivad olla avalikud või privaatsed.

Seega on igal objektil rangelt määratletud liides, s.t. avalike toimingute kogum, mida saab sellele objektile rakendada. Kõigil sama klassi objektidel on sama liides.

Objektmudel esindab kavandatava süsteemi (allsüsteemi) statistilist struktuuri. Staatilise struktuuri tundmisest ei piisa aga robotite alamsüsteemi mõistmiseks ja hindamiseks. Vaja on omada vahendeid alamsüsteemi töö käigus objektide ja nende seostega toimuvate muutuste kirjeldamiseks.

Üks neist vahenditest on dünaamiline mudel allsüsteemid. See ehitatakse pärast seda, kui alamsüsteemi objektmudel on üles ehitatud ja eelnevalt kokku lepitud ning silutud. Alamsüsteemi dünaamiline mudel koosneb selle allsüsteemi objektide olekuskeemidest.

Objekti praegust olekut iseloomustab selle atribuutide ja ühenduste praeguste väärtuste kogum. Süsteemi töötamise ajal interakteeruvad selle koostisosad üksteisega, mille tulemusena nende olekud muutuvad. Mõjuühik on sündmus: iga sündmus viib süsteemi ühe või mitme objekti oleku muutumiseni või uute sündmuste ilmnemiseni. Süsteemi toimimist iseloomustab selles toimuvate sündmuste jada.

Sündmus toimub mingil ajahetkel. Näited sündmustest: raketi start, 100 m jooksu start, juhtmestiku algus, raha väljastamine jne. Sündmusel ei ole kestust (täpsemalt võtab see vähe aega).

Kui sündmustel puudub põhjuslik seos (st nad on loogiliselt sõltumatud), kutsutakse neid sõltumatu(samaaegselt). Sellised sündmused ei mõjuta üksteist. Sõltumatuid sündmusi pole mõtet järjestada, kuna need võivad toimuda mis tahes järjekorras. Hajutatud süsteemimudel peab tingimata sisaldama sõltumatuid sündmusi ja tegevusi.

Sündmuste jada nimetatakse skriptiks. Pärast stsenaariumide väljatöötamist ja analüüsimist määratakse iga stsenaariumisündmust genereerivad ja vastuvõtvad objektid.

Sündmuse toimumisel ei lähe mitte ainult objekt uude olekusse, vaid sooritatakse ka selle sündmusega seotud toiming. Toiming on sündmusega seotud vahetu toiming.

Objektimudeli koostamise protsess hõlmab järgmisi samme:

Objektide ja klasside määratlemine;

Andmesõnastiku ettevalmistamine:

Objektide vaheliste sõltuvuste määramine;

Objektide ja seoste omaduste määramine;

klasside korraldamine ja lihtsustamine pärimise kasutamisel;

Mudeli edasine uurimine ja täiustamine.

4. TEEMA: Äriprotsesside modelleerimise metoodika

1. Modelleerimise olemus ja mudelite klassifitseerimine ümberehituses

Põhinõuded äriprotsesside mudelite ehitamiseks ettevõttes

Pretsedentmudeli koostamise metoodika

Objektimudeli koostamise metoodika

küsimus 1

Modelleerimine on peamine tööriist keeruliste süsteemide analüüsimisel ja kujundamisel. Erinevat tüüpi mudeleid on tohutult palju. Mudeleid saab liigitada mitmel viisil. Vastavalt teostusmeetodile saab mudeleid jagada materiaalseteks (reaalne, käegakatsutav) ja abstraktseks (ideaalne). Kuna materjalimudelite kasutusala on üsna piiratud, liigume edasi abstraktsete mudelite käsitlemise juurde.

Abstraktne mudel on reaalse objekti peegeldus ideaalsete struktuuride kujul, mis on tehtud mõtlemise abil. Eristagem kahte peamist abstraktsete mudelite klassi: ametlik (matemaatika) ja semantiline (tähenduslik).

Ametlikes mudelites kajastuvad kvantitatiivsete parameetrite vahel eksisteerivad matemaatilised mustrid. Sellesse mudelite klassi kuuluvad eelkõige võrrandisüsteemid, statistilised mudelid, operatsioonide uurimise mudelid jne. Matemaatilised mudelid on universaalsed selles mõttes, et sama mudel võib kirjeldada väga erinevaid füüsikalisi protsesse või nähtusi. Matemaatiliste mudelite peamine eelis on see, et need võimaldavad leida lahendus etteantud tingimustel. Peamine raskus seisneb selles, et kõiki süsteeme ei saa ühe matemaatilise mudeliga adekvaatselt kirjeldada.

Keerulisi süsteeme nimetatakse keerukateks, kuna neid on raske formaliseerida. Soovitav on neid kasutada semantilised mudelid. Erinevalt formaalsetest mudelitest säilitavad semantilised mudelid objekti semantika (keeleteaduse haru, mis uurib keeleüksuste semantilist tähendust). Semantiliste mudelite näideteks on organisatsiooni eesmärkide puu, organisatsiooni struktuuri mudel, ettevõtte infokommunikatsiooni mudel jne.

Reeglina kirjeldavad semantilised mudelid teatud objekte (olemid, süsteemid, alamsüsteemid, elemendid), objektide omadusi (parameetrid, karakteristikud), nende olekuid ja käitumist, samuti objektide vahelisi seoseid. Semantilised mudelid võivad olla sarnased staatiline , peegeldades objektide ja suhete konstantseid, stabiilseid seisundeid ja dünaamiline , kajastades sündmuste kulgu, s.o. objekti olekute ajamuutused, samuti objekti interaktsioonide jada. Semantiliste mudelite kirjeldamisel kasutatakse keeleliste vahenditena graafikuid, diagramme, tabeleid, vooskeeme ja loomulikku keelt (inimestevahelise suhtluse keel).

Enamiku semantiliste mudelite aluseks on süsteemianalüüsi põhimudelid (must kasti mudel, kompositsioonimudel ja struktuurimudel) ja semantilise võrgu mudelid. Viimasel ajal on seda tüüpi mudelite koostamiseks aktiivselt kasutatud objektorienteeritud lähenemist.

Semantilised mudelid on asendamatud keerukate süsteemide projekteerimise algfaasis, kui kujuneb välja süsteemi kontseptsioon. Süsteemi integreeritud semantiline mudel võimaldab esitada üldpilti, luua üldistatud kirjelduse, milles põhiolemid on rõhutatud ja detailid peidetud. Peamine asi sellises mudelis on lühidus ja selgus. Selline mudel võib olla aluseks üksikasjalikumate mudelite koostamisel, mis kirjeldavad üksikuid aspekte ja alamsüsteeme. Seega võib semantiline mudel olla raamistik teiste, sealhulgas matemaatiliste mudelite koostamisel. Selle eesmärk on struktureerida teavet objekti kohta.

2. küsimus

Iga ettevõte on keeruline süsteem, mille jaoks on võimatu ehitada ühtset formaalset mudelit, mis kataks absoluutselt kõik detailid. Seetõttu on vaja mitte ühte, vaid mitut kooskõlastatud mudelit, mis on aluseks detailsemate mudelite ehitamisel.

Ärimudel peaks kajastama:

1.Ettevõtte funktsioon välismaailmas: mida ta teeb, kelle jaoks, mis eesmärgil. Vajalik on kirjeldada ettevõtte keskkonda, sealhulgas kliente, koostööpartnereid, alltöövõtjaid jne, samuti ettevõtte suhtlust selle keskkonnaga.

2. Ettevõtte arhitektuur, st. ettevõtte olulisemad staatilised struktuurid. Konstruktsiooni elemendid peaksid olema:

Ettevõtte välis- ja siseprotsessid;

Funktsioonid (individuaalsed protsessietapid);

Tooted (protsesside ja funktsioonide väljund);

Ressursid, nii inimlikud kui tehnilised.

Elemente saab iseloomustada parameetritega, mis võimaldavad nende olekuid kirjeldada. Struktuuride kirjeldamiseks on vaja kajastada ka elementide vahelisi seoseid, sealhulgas:

Protsessidevahelised seosed, protsesside üksikud funktsioonid (sammud);

Suhted protsessis osalejate vahel – mitmesugused ressursid, vahendid ja tooted;

Inimestevahelised suhted (alluvussuhted, suhtlus jne).

3. Äri "dünaamika"., st. äriprotsesside õigeaegne elluviimine. Dünaamika peegeldub sündmuste vooluna, s.t. toimingute järjestus ja nende sooritamiseks stiimulite ülekandmine.

Ettevõtete mudelite koostamise metoodika peaks võimaldama koostada arusaadavaid ja jälgitavaid mudeleid. Mudel peaks välistama mittevajalikud detailid, keskendudes kõige olulisematele aspektidele. Mudeli kirjelduskeel peab olema piisavalt väljendusrikas.

Metoodika peab olema piisavalt vormistatud, s.t. peaks sisaldama mõningaid üsna selgeid protseduure või tehnikaid mudelikomponentide genereerimiseks. Soovitav on, et seda tehnikat toetaksid instrumentaalsed arvutisüsteemid. Instrumentaalsete tugisüsteemide kasutamine hõlbustab oluliselt suurte projektide arendusprotsessi, eriti kollektiivse arenduse käigus, milles osalevad erinevad arendajate rühmad.

3. küsimus

Kõige levinumad on 2 äriprotsesside modelleerimise metoodikate rühma:

1. P-O mudelite (pretsedent-objekti mudelid) koostamise metoodika See meetod hõlmab kahte tüüpi ärimudelite järjestikust konstrueerimist: välised (pretsedent või P-mudel) ja sisemised (objekt- või O-mudel).

Väline ehk pretsedentmudel (P-mudel) kirjeldab ettevõtet nii, nagu seda nähakse väljastpoolt, s.t. kuidas seda tajuvad kliendid ja teised keskkonnas. P-mudel peegeldab seda ideed Mida teeb äri, mitte Kuidas teeb.

Mis on juhtunud " pretsedent". Kasutusjuhtum on "väline" kliendile suunatud äriprotsess. Kasutusjuhtum lõpeb toote kättesaamisega – mõõdetav tarbijaväärtus mõne ärisüsteemi üksiku tarbija jaoks.

Pretsedentidel võib olla palju võimalikke sündmuste kulgu. Iga konkreetne pretsedent (valik) kutsutakse välja kopeerida . Eksemplar rakendab konkreetse kliendi jaoks konkreetse sündmuste voo konkreetsetel tingimustel. Sarnased sündmuste käigu võimalused on rühmitatud klassid pretsedente.

Klassi võib pidada üldiseks pretsedendiks. Näiteks klass Müük kasutusjuhtumid kirjeldab üldist sündmuste voogu, mis toimuvad mis tahes toote müümisel mis tahes kliendile. Konkreetne müügijuhtumi juhtum võib üksikasjades erineda, näiteks olenevalt sellest, kas klient on uus või mitte, teadlik või asjatundmatu jne.

P-mudeli ehitamine algab pretsedentide ja keskkonnaelementide – klientide, partnerite, tarnijate – väljaselgitamisest. Keskkonda modelleeritakse näitlejate nn teemasid . Üksused esindavad kõike keskkonnas, mis suhtleb ettevõttega. Teemaks võib olla: isik (näiteks klient, ostja); teine ​​ettevõte (näiteks tarnijaorganisatsioon, alltöövõtja); tehniline süsteem (näiteks teise ettevõtte arvutisüsteem).

Nii nagu pretsedentide puhul, eristatakse ka ainete puhul klassi ja eksemplari mõisteid. Aineklass kirjeldab teatud tüüpi aine üldisi omadusi ja eksemplar kirjeldab konkreetse õppeaine omadusi.

Pärast ärisüsteemi subjektide ja pretsedentide väljaselgitamist on vaja kirjeldada nendevahelisi koostoimeid. Joonisel fig. Joonis 3.1 esitab pretsedentide ja subjektide koosmõju graafilise mudeli.

Selles mudelis esindatud seoseid nimetatakse suheteks side . Need peegeldavad pretsedentide tegelikke suhteid keskkonnaga, mis seisnevad aine (tooraine, tööriistad, valmistooted), energia ja teabe vahetuses. See. kommunikatsioonisuhted modelleerivad materjali-, energia- ja infovooge.

Järgmine samm P.mudeli koostamisel on pretsedendi kirjeldamine väikeste sammude jadana. Seda kirjeldust nimetatakse sündmuste voog. Süsteemikäsitluse seisukohalt lagundatakse protsess-pretsedent alamprotsessideks-sündmusteks.

Vaatleme näiteks “Tootemüügi” pretsedendi kirjeldust. Peamine sündmuste voog:

1. Müüja saab kliendi päringu

2. Kui taotluses on märgitud valmistoode, kontrollib müüja vajaliku toote saadavust laos. Seejärel jätkub kasutusjuht 5. sammust.

3. Kui tellimuses on täpsustatud kohandatud toode, täpsustab müüja tellimuse üksikasjad ja edastab need toote kujundajale

4. Disainer muudab toodet vastavalt kliendi nõudmistele

5. Müüja võtab kliendilt makse vastu

6. Müüja teatab saatjale kauba koguse ja kliendi aadressi ning tellib transpordi

7. Saatja toimetab toote kliendile.

Pretsedendi iga samm (sündmus) tähistab mõnda toimingut, mis kannab pretsedendi uude olekusse. Pretsedendi uus olek omakorda on stiimuliks järgmise sammu (sündmuse) sooritamiseks. Seega peetakse pretsedenti kui riigisündmuste masin .

4. küsimus

O-mudeli kirjeldus põhineb mõistel “objekt”. Objektid kohal osalejad protsessid ja erinevad tüübid olemus (tooted, esemed, ülesanded jne). Eristama klassid objektid, mis kirjeldavad teatud tüüpi objektide üldisi omadusi, ja koopiaid, mis kirjeldab konkreetse objekti omadusi. Objektiklasside lõikes esitatud O-mudelit nimetatakse ideaalmudeliks. Selline mudel ei võta arvesse mõningaid mudeli rakendamise üksikasju praktikas. Objekti eksemplaride kaudu kirjeldatud O-mudelit nimetatakse reaalseks. See võtab arvesse konkreetse rakenduse iseärasusi.

Silma paistavad järgmised: tüüpiline objekti klassid:

1. Liides - objektid, mis interakteeruvad keskkonnaga, s.t. õppeainetega. Liideseobjektide näideteks on müüja, registripidaja, sekretär. Liideseobjektina ei saa toimida mitte ainult inimene. See võib olla näiteks infosüsteemi osa – graafiline kasutajaliides.

2. Juhid - aktiivsed objektid, mis juhivad protsesse, kuid ei oma kontakti keskkonnaga. Tüüpilised näited ettevõtte juhtimisobjektidest on tootearendaja, projektijuht.

3. Olemiobjektid - passiivsed objektid, mida ettevõte töötleb. Tavaliselt ei ole olemiobjektid inim- ega tehnilised ressursid. Tüüpilised näited ettevõtte olemitest on Tooted, Tellimus, Teade.

Üks ja sama objekt võib osaleda mitte ainult ühel kasutusjuhul, vaid osaleda paljudel äriüritustel. Lisaks, nagu subjektide puhul, võib üks reaalne isik või tehniline süsteem täita mitme objekti rolle. Näiteks võib tootemüüja lisaks kliendiga kontakti loova liideseobjekti rollile täita ka juhi rolli.

Objektid (klassid ja eksemplarid) on seotud suhted . Binaarne seos ühendab kahte objekti. See võib olla kas ühe- või kahesuunaline.

Pretsedentobjektide interaktsiooni graafilises mudelis on objekte kujutatud kolmnurkadena (liidese omad tähega “i” sees, kontrollobjektid tähega “y” sees) ning objektidevahelisi seoseid kaarega (nool ). Joonisel fig. Joonisel 3.4 on toodud punktis 3.2.1 kirjeldatud pretsedendi “Kohandatud toote müük” objektisuhete mudel.

Selles mudelis kujutatud seoseid on kahte tüüpi: suhtlussuhted (kujutatud pideva noolega) ja kasutussuhted (kujutatud punktiirnoolega). Suhe side peegeldavad materjali-, energia- ja infovooge erinevate objektide vahel, aga ka objektide ja subjektide vahel. Suhtumine kasutada tähendab, et üks objekt kasutab teist mingil viisil. Näiteks müüja objekt genereerib kliendi aadressi objekti, toote saatja objekt kasutab kliendi aadressi teabe hankimiseks selle kohta, kuhu toode tarnida.

Objekti kõikidest rollidest ja kohustustest aimu saamiseks peate koostama objekti kirjeldus . Objekti kirjeldus koosneb kahest osast: olekute kirjeldusest ja käitumise kirjeldusest. Koostamiseks olekukirjeldused objekti puhul tuleb esiteks esile tuua kõik selle omadused, omadused, mida nimetatakse atribuutideks. Atribuudil peab olema nimi, võimalike väärtuste vahemik ja objekti eksemplari puhul konkreetne praegune atribuudi väärtus. Näiteks objektil "Tellimus" võivad olla atribuudid, mis näitavad tellitava toote nime, selle omadusi, kogust, toote tellinud kliendi nime jne. Reeglina on atribuutide koosseis terve objektiklassi jaoks sama. Objekti erinevad eksemplarid erinevad ainult konkreetsete atribuutide väärtuste hulgast.

Seal on püsivad atribuudid, mille väärtused kasutusjuhtumi täitmisel ei muutu, ja muutujad, mis määravad objekti erinevad olekud. Näiteks võib Tellimusobjektil olla muutuja atribuut, mis näitab, kas tellimus on valmistamisel, tarnimisel või on juba lõpetatud.

Käitumise kirjeldus eesmärk on tuvastada kõik selle kohustusi , st. kõik objekti interaktsioonid teiste objektide ja subjektidega kasutusjuhtumi täitmise ajal.

©2015-2019 sait
Kõik õigused kuuluvad nende autoritele. See sait ei pretendeeri autorlusele, kuid pakub tasuta kasutamist.
Lehe loomise kuupäev: 2017-10-11

SISSEJUHATUS

Iga süsteemi kõige olulisemad omadused on selle struktuur ja toimimisprotsess. Süsteemi struktuuri mõistetakse kui ajastabiilset suhete kogumit selle elementide või komponentide vahel. See on struktuur, mis seob kõik elemendid kokku ja takistab süsteemi lagunemist eraldi komponentideks. Süsteemi struktuur võib kajastada mitmesuguseid seoseid, sealhulgas ühe süsteemi elementide pesastumist teise. Sel juhul on tavaks nimetada väiksemat ehk pesastatud süsteemi alamsüsteemiks. Süsteemi toimimise protsess on tihedalt seotud selle omaduste või käitumise muutumisega aja jooksul. Sel juhul on süsteemi oluliseks tunnuseks selle olek, mida mõistetakse omaduste või tunnuste kogumina, mis igal ajahetkel peegeldavad süsteemi käitumise kõige olulisemaid tunnuseid. Kõigi mudelite ühine omadus on nende sarnasus algse süsteemiga. Ehitusmudelite tähtsus seisneb võimaluses kasutada neid algse süsteemi omaduste või käitumise kohta informatsiooni hankimiseks. Sel juhul nimetatakse mudelite koostamise ja hilisema rakendamise protsessi algse süsteemi kohta teabe saamiseks modelleerimiseks. Üldine süsteemimudel sisaldab olulist teavet antud süsteemi funktsionaalsete omaduste kohta, mis annab ülevaate selle tulevasest käitumisest.

Selle kursusetöö uurimisobjektiks on modelleerimisprotsessi uurimine. Uurimise objektiks on konkreetse objektimudeli konstrueerimine ja selle käitumise uurimine. Selle eesmärgi saavutamiseks kasutatakse järgmisi meetodeid: vajaliku kirjanduse uurimine, võrdlus, näited elukogemusest Kuna objekti mudeli ehitamine toimub autoteeninduse näitel, on vaja uurida toimimist selle organisatsiooni põhimõte. Selleks piisab, kui külastada erinevate autoteeninduste ametlikke veebisaite. Aga objektimudeli konstrueerimise põhimõtete uurimiseks uurisin teaduslikku kodu- ja välismaist kirjandust. See osutus väga põnevaks tegevuseks.

Sellest tulenevalt oli minu kursusetöö eesmärgiks koostada Autoservice infosüsteemi objektmudel, uurida objektimudeli koostamise põhimõtet, kirjeldada ehitusprotsessi, tõestada nende teadmiste omamise olulisust ja oskust rakendada neid harjutada.

Kursusetöö ülesehitus on järgmine: esmalt õpitakse objektiivse mudeli konstrueerimise teooriat, seejärel testitakse teooria rakendamist praktilise näite varal.

1. Objektorienteeritud lähenemise põhimõisted

Objektorienteeritud lähenemine põhineb mudelite süstemaatilisel kasutamisel. Eesmärgi sõnastus hõlmab reaalse maailma objekte ja kontseptsioone, mis on arendatava tarkvarasüsteemi jaoks olulised. Objektorienteeritud lähenemise korral asendatakse need objektid ja mõisted nende mudelitega, s.t. teatud formaalsed struktuurid, mis neid tarkvarasüsteemis esindavad.

Mudel ei sisalda kõiki esindatava objekti või kontseptsiooni omadusi ja omadusi, vaid ainult neid, mis on arendatava tarkvarasüsteemi jaoks hädavajalikud. Seega on mudel lihtsam kui objekt (kontseptsioon), mida ta esindab. 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; üksikute tarkvarakomponentide muutmise võimaluse tagamine ilma selle ülejäänud komponente muutmata; üksikute tarkvarakomponentide taaskasutamise võimaluse tagamine.

Objektorienteeritud lähenemise süstemaatiline rakendamine võimaldab välja töötada hästi struktureeritud, töökindlaid ja üsna lihtsalt muudetavaid tarkvarasüsteeme. See seletab programmeerijate huvi objektorienteeritud lähenemise vastu. Objektorienteeritud lähenemine on teoreetilise ja rakendusliku programmeerimise üks kiiremini arenevaid valdkondi.

Objektorienteeritud tarkvaraarendus hõlmab objektorienteeritud mudelite kasutamist tarkvarasüsteemide ja nende komponentide arendamisel.

Objektorienteeritud arendus võib alata elutsükli kõige esimeses etapis; see ei ole seotud programmeerimiskeelega, milles arendatav tarkvarasüsteem peaks olema rakendatud: see keel ei pruugi olla objektorienteeritud. Arendusfaasis on objektid mingid formaalsed struktuurid (näiteks ümarate nurkadega ristkülikud, mille abil neid diagrammidel kujutatakse), mis pole veel kuidagi seotud nende tulevase rakendamisega ühes programmeerimiskeeles.

Objektorienteeritud tarkvaraarendus hõlmab objektorienteeritud metoodikate (tehnoloogiate) kasutamist. Tavaliselt toetavad neid objektorienteeritud metoodikaid tarkvaratööriistad, kuid isegi ilma selliste tööriistadeta on need kasulikud, kuna võimaldavad hästi mõista arendatava tarkvarasüsteemi erinevaid aspekte ja omadusi, mis hõlbustab hiljem oluliselt selle rakendamist, testimist, hooldus, uute versioonide väljatöötamine ja olulisemad muudatused.

Rakendustarkvarasüsteemi projekteerimine algab nõuete analüüsiga, millele see peab vastama. Selline analüüs viiakse läbi selleks, et mõista piisavalt süsteemi eesmärki ja töötingimusi, et oleks võimalik koostada selle eelprojekt.

Objektorienteeritud lähenemise korral taandub süsteeminõuete analüüs selle süsteemi mudelite väljatöötamisele. Süsteemi (või mõne muu objekti või nähtuse) mudel on süsteemi formaalne kirjeldus, mis identifitseerib peamised süsteemi moodustavad objektid ja nende objektidevahelised seosed. Mudelite loomine on laialt levinud viis keerukate objektide ja nähtuste uurimiseks. Mudelis on välja jäetud arvukad üksikasjad, mis muudavad selle mõistmise raskeks. Modelleerimine on laialt levinud nii teaduses kui ka tehnoloogias.

Mudelid aitavad kontrollida arendatava süsteemi jõudlust selle arendamise algfaasis, suhelda süsteemi kliendiga, selgitades tema nõudeid süsteemile ning teha (vajadusel) muudatusi süsteemi disainis (mõlemad alguses). selle konstruktsioonist ja elutsükli muudest etappidest).

Süsteemi elutsükli esimeses faasis välja töötatud ja silutud mudeleid kasutatakse jätkuvalt kõigis järgmistes faasides, hõlbustades süsteemi programmeerimist, silumist ja testimist, hooldust ja edasist muutmist.

Objektimudel kirjeldab süsteemi moodustavate objektide struktuuri, nende atribuute, toiminguid ja seoseid teiste objektidega. Objektimudel peaks kajastama neid reaalse maailma mõisteid ja objekte, mis on arendatava süsteemi jaoks olulised. Objektimudel peegeldab ennekõike arendatava süsteemi pragmaatikat, mis väljendub arendatava süsteemi kasutamisega seotud rakendusdomeeni terminoloogia kasutamises.

Vaatleme objektimudeli koostamisel kasutatavaid põhimõisteid.

Objekt on abstraktsioon või mis tahes asi, millel on selgelt määratletud piirid, mis on kasutatava probleemi kontekstis mõistlik. Objektide tutvustamisel on kaks eesmärki: rakendatava ülesande (probleemi) mõistmine ja arvutis realiseerimise aluste tutvustamine.

Objektimudeli väljatöötamise eesmärk on kirjeldada objekte, millest koosnev süsteem koosneb, samuti tuvastada ja näidata erinevaid objektidevahelisi sõltuvusi.

Klass on samade omadustega objektide komplekti deskriptor. Klass kirjeldab paljude objektide omadusi. Iga objekt on ainult ühe klassi eksemplar.

Kõiki sama klassi objekte iseloomustavad samad atribuutide komplektid. Objektide rühmitamist klassidesse määravad aga mitte atribuutide komplektid, vaid semantika. Nii võivad näiteks tallil ja hobusel olla samad atribuudid: hind ja vanus. Pealegi võivad need kuuluda samasse klassi, kui neid probleemis käsitletakse lihtsalt tootena, või erinevatesse klassidesse, mis on loomulikum.

Objektide kombineerimine klassidesse võimaldab probleemisse abstraktsiooni sisse viia ja seda üldisemas sõnastuses käsitleda. Klassil on nimi (näiteks hobune), mis kehtib kõigi selle klassi objektide kohta. Lisaks sisaldab klass objektide jaoks määratletud atribuutide nimesid. Selles mõttes on klassi kirjeldus sarnane struktuuri (kirje) tüübi kirjeldusega; Pealegi on igal objektil sama tähendus kui struktuuri eksemplaril (vastavat tüüpi muutuja või konstant).

Objekti atribuut on väärtus, mis iseloomustab objekti selle klassis. Näited atribuutidest: mark, tootmisaasta, värv (autoklassi esemete atribuudid) jne.

Operatsioon on funktsioon (või teisendus), mida saab rakendada antud klassi objektidele. Toimingute näited: kontrollimine, eemaldamine, paigaldamine (varuosade klassi objektide puhul).

Kõik antud klassi objektid kasutavad iga operatsiooni sama eksemplari (st teatud klassi objektide arvu suurendamine ei too kaasa laaditud programmikoodi hulga suurenemist). Objekt, millelt toimingut kutsutakse, edastatakse sellele selle kaudse argumendina (parameetrina).

Sama operatsiooni saab rakendada ka eri klasside objektide puhul: sellist operatsiooni nimetatakse polümorfseks, kuna sellel võib erinevate klasside jaoks olla erinev vorm.

Klassidevahelised sõltuvused on kahesuunalised: kõigil sõltuvuse klassidel on võrdsed õigused. See kehtib isegi juhtudel, kui sõltuvuse nimi näib suunavat sõltuvusse. Klassidevahelised sõltuvused vastavad nende klasside objektide vahelistele sõltuvustele. Sõltuvustel, nagu klassidel, võivad olla atribuudid.

Diskriminaator on "loenduse" tüüpi atribuut, mis näitab, millistest objektide omadustest antud üldistus koosneb.

Roll määratleb sõltuvuse ühe poole. Binaarses sõltuvuses on määratletud kaks rolli. Rolli nimi identifitseerib üheselt sõltuvuse ühe poole. Rollid võimaldavad vaadelda binaarset sõltuvust kui seost objekti ja sõltuvate objektide kogumi vahel: iga roll on objekti või objektide kogumi tähistus, mis on sõltuvuse kaudu ühendatud objektiga, mis asub sõltuvuse teises otsas. Rolli nime võib pidada tuletatud atribuudiks, mille väärtuskomplekt on selle rolliga seotud objektide kogum. Binaarses sõltuvuses saab selle sõltuvuse tuvastamiseks kasutada paari rollinimesid.

Rollide nimed tuleb täpsustada juhtudel, kui sama klassi objektide vahel luuakse sõltuvus. Rollinimed peavad olema kordumatud, kuna neid kasutatakse sõltuvusega seotud objektide eristamiseks.

Kvalifitseerija on atribuut, mis võimaldab vähendada sõltuvuse tegelikku kordsust. Kvalifitseerijaid kasutatakse üks-mitmele või mitu-mitmele sõltuvustes.

Agregatsioon on sõltuvus liitobjektide klassi ja nende objektide komponente esindavate klasside vahel ("tervik"-"osa" suhe).

Üldistamine ja pärimine võimaldavad tuvastada analoogiaid erinevate objektide klasside vahel ning määrata objektide mitmetasandilist klassifikatsiooni. Seega võivad graafilistes süsteemides olla klassid, mis määravad erinevate geomeetriliste kujundite kujutamise: punktid, jooned (sirged, ringikujulised kaared ja splainidega määratletud kõverad), hulknurgad, ringid jne.

Diskriminaator on "loenduse" tüüpi atribuut, mis näitab, millistest objektide omadustest antud üldistus koosneb.

Tuleb märkida, et ulatuslikke mitmetasandilisi klassifikatsioone tuleks vältida, kuna mitmetasandilise klassifikatsiooni madalama taseme alamklasside käitumist võib olla raske mõista: enamik (ja sageli kõik) selliste klasside atribuute ja tehteid on määratletud. oma erineva tasemega superklassides. Kui klassifikatsioonitasemete arv on muutunud liiga suureks, peate süsteemi struktureerimist veidi muutma.

Üldistust ja pärimist kasutatakse laialdaselt mitte ainult tarkvarasüsteemidele esitatavate nõuete analüüsimisel ja nende eelprojekteerimisel, vaid ka nende rakendamisel.

Mõnikord on vaja, et alamklass alistaks mõnes oma ülemklassis määratletud operatsiooni. Selle saavutamiseks defineeritakse alamklassis ka tehe, mida saab pärimise tulemusena tuletada ülemklassist; see ümbermääratlus "varjab" selle definitsiooni ülemklassis, nii et rakendatakse alamklassis tühistatud, mitte päritud operatsiooni. Tuletame meelde, et iga toiming on määratletud selle allkirjaga; seetõttu peab operatsiooni alistamise signatuur ühtima selle operatsiooni allkirjaga superklassis, mille tehe alistab.

Alistamisel võib olla üks järgmistest eesmärkidest.

laiendus: uus tehe laiendab päritud operatsiooni, võttes arvesse alamklassi atribuutide mõju;

piirang: uus tehe piirdub ainult osa päritud tehte toimingute sooritamisega, kasutades alamklassi objektide spetsiifikat;

optimeerimine: alamklassi objektide spetsiifika kasutamine võimaldab vastavat meetodit lihtsustada ja kiirendada;

mugavus.

Soovitatav on järgida järgmisi semantilisi pärimise reegleid:

kõik päringutoimingud (toimingud, mis kasutavad atribuutide väärtusi, kuid ei muuda neid) peavad olema päritud kõigi alamklasside poolt;

kõik toimingud, mis muudavad atribuutide väärtusi, peavad olema päritud kõigis nende laiendustes;

kõik toimingud, mis muudavad piiratud atribuutide või sõltuvusi määratlevate atribuutide väärtusi, peavad olema kõigis nende laiendustes blokeeritud;

toiminguid ei tohiks põhimõtteliselt ümber määratleda; kõik sama toimingut rakendavad meetodid peavad sooritama sarnase atribuudi teisenduse;

Päritud toiminguid saab täpsustada lisatoimingute lisamisega.

Järgides neid reegleid, mida objektorienteeritud programmeerimiskeeled kahjuks harva toetavad, saate muuta arendatava programmi arusaadavamaks, hõlpsamini muudetavaks ning vähem vastuvõtlikuks erinevatele vigadele ja möödapanekutele.

Abstraktsel klassil ei saa olla objekte, kuna see ei määratle objektidega tehteid; objektid peavad kuuluma abstraktse klassi konkreetsetesse alamklassidesse. Abstraktseid klasse kasutatakse operatsioonide liideste määramiseks (neid toiminguid rakendavad meetodid määratletakse seejärel abstraktse klassi alamklassides). Abstraktsed klassid on süsteeminõuete analüüsimise faasis mugavad, kuna võimaldavad tuvastada analoogiaid analüüsitavas süsteemis määratletud näiliselt erinevates operatsioonides.

Mitu pärimist võimaldab klassil olla rohkem kui üks ülemklass, mis pärib kõigi oma ülemklasside omadused (atribuudid ja toimingud). Klassi, millel on mitu ülemklassi, nimetatakse liitklassiks. Esivanemate klassi omadused, mis esinevad pärimisgraafikus rohkem kui üks kord, päritakse ainult ühes eksemplaris. Konfliktid paralleelsete definitsioonide vahel tekitavad ebaselgust, mis tuleb juurutamise käigus lahendada. Praktikas tuleks selliseid ebaselgusi või puudulikku arusaamist vältida isegi siis, kui süsteemi rakendamiseks valitud konkreetne programmeerimiskeel võimaldab neid prioriteete või muid vahendeid kasutades lahendada.

Objektorienteeritud disainis käsitleme omavahel seotud objektide komplekte. Iga objekti saab käsitleda kui struktuuritüübi muutujat või konstanti (sel viisil käsitletakse objektis kirjeldatud meetodeid funktsioonide aadressidena, mida on lubatud sellele objektile rakendada). Seetõttu on objektide kogum omavahel seotud andmete kogum, st. midagi andmebaasiga väga sarnast. Seetõttu on andmebaasikontseptsioonide rakendamine sageli kasulik rakendustarkvarasüsteemide objektorienteeritud analüüsis ja objektorienteeritud projekteerimisel.

Metaandmed on andmed, mis kirjeldavad muid andmeid. Näiteks klassi määratlus on metaandmed, kuna klass kirjeldab teisi andmeid - selle klassi objekte. Mudelid on metaandmed, kuna need kirjeldavad modelleeritavaid objekte. Teine metaandmete näide on abstraktne klass.

Näitlejad on rollid, mida mängivad üksused, kes suhtlevad süsteemiga vahetult.

Näitleja määratleb rolli, mida mingi väline üksus teatud süsteemiga vahetult suheldes mängib. See võib esindada kasutajarolli või rolli, mida täidab mõni muu süsteem või riistvaraosa, mis puudutab süsteemi piire.

Mulle meeldis väga Jim Arlow ja Isle Neustadti teoses “UML 2 and the Unified Process” kirjeldus “näitleja” mõistest: “Näitlejate mõistmiseks on oluline mõista rollide mõistet. Rolli võib mõelda kui mütsi, mida teatud olukorras kantakse." (lk 92).

Kui põhikontseptsioonid on teada, võime kaaluda mudeli enda ehitamist

1. Objekti mudeli ehitamine

1. Klasside määratlemine

Kavandatud rakendussüsteemi väliste nõuete analüüs võimaldab meil määrata rakenduse probleemiga seotud objektid ja objektide klassid, mida see süsteem peab lahendama. Alustuseks peate tuvastama võimalikud klassid rakendatud probleemi kirjalikust avaldusest (tehnilised kirjeldused ja muu kliendi esitatud dokumentatsioon). See on väga raske ja vastutusrikas arenguetapp, kuna sellest sõltub suuresti projekti edasine saatus.

Võimalike klasside väljaselgitamisel tuleks püüda tuvastada võimalikult palju klasse, pannes kirja iga klassi nimi, mis pähe tuleb. Eelkõige võib igal ülesande esialgses lauses esineval nimisõnal olla vastav klass. Seetõttu seostatakse võimalike klasside tuvastamisel iga selline nimisõna tavaliselt võimaliku klassiga.

üleliigsed klassid: kui kaks või enam klassi väljendavad sama teavet, tuleks säilitada ainult üks neist;

ebaolulised (probleemiga otseselt mitte seotud) klassid: iga võimaliku klassi nimetuse puhul hinnatakse, kui vajalik see tulevases süsteemis on (seda on sageli väga raske hinnata); ebaolulised klassid on välja jäetud;

ebamääraselt määratletud (vaatatava probleemi seisukohalt) klassid;

atribuudid: mõned nimisõnad vastavad rohkem atribuutidele kui klassidele; sellised nimisõnad kirjeldavad reeglina objektide omadusi (näiteks nimi, vanus, kaal, aadress jne);

operatsioonid: mõned nimisõnad on tõenäolisemalt operatsioonide kui klasside nimed (näiteks phone_call ei tähenda tõenäoliselt ühtegi klassi);

rollid: mõned nimisõnad defineerivad objektimudelis rollinimesid (näiteks omanik, juht, ülemus, töötaja; kõik need nimed on seotud rollidega isikuklassi erinevates objektisõltuvustes);

teostuskonstruktsioonid: rohkem programmeerimise ja arvutiriistvaraga seotud nimesid ei tohiks selles etapis klassidega võrrelda, kuna need ei kajasta kavandatud rakendussüsteemi omadusi; näiteid sellistest nimedest: alamprogramm, protsess, algoritm, katkestus jne.

Pärast kõigi mittevajalike (üleliigsete) võimalike klasside nimede kõrvaldamist saadakse esialgne klasside loend, mis moodustavad kavandatud süsteemi.

1. Andmesõnastiku ettevalmistamine

Üksikutel sõnadel on liiga palju tõlgendusi. Seetõttu on vaja juba projekteerimise alguses koostada andmesõnastik, mis sisaldab selgeid ja ühemõttelisi määratlusi kõigi projektis käsitletavate objektide (klasside), atribuutide, operatsioonide, rollide ja muude üksuste kohta. Ilma sellise sõnastikuta on projekti arutamine kaasarendajate ja süsteemiklientidega mõttetu, kuna igaüks saab käsitletud termineid tõlgendada omal moel.

2.3. Sõltuvuste määratlemine

Objektimudeli loomise järgmises etapis määratakse klassidevahelised sõltuvused. Esiteks jäetakse klassidest välja atribuudid, mis on otsesed lingid teistele klassidele; sellised atribuudid asendatakse sõltuvustega. Selle asendamise mõte seisneb selles, et sõltuvused esindavad abstraktsiooni klassidega samal tasemel ja seetõttu ei mõjuta neil otsest mõju tulevasele juurutamisele (viide klassile on vaid üks viis sõltuvuste rakendamiseks).

Nii nagu võimalike klasside nimed saadi rakendusülesande eellauses leitud nimisõnadest, saab võimalike sõltuvuste nimed saada nimetatud dokumendis leiduvatest verbidest või verbifraasidest. Nii kirjeldavad nad tavaliselt: füüsilist asendit (jälgib_taga, on_osa, on_sisaldub), suunatud tegevust (viib_liikumiseni), suhtlemist (vestleb_toega), kuulumist (on, on_osa) jne.

Seejärel peaksite eemaldama mittevajalikud või valed sõltuvused, kasutades järgmisi kriteeriume.

välistatud klasside vahelised sõltuvused tuleb kõrvaldada või ülejäänud klasside osas ümber sõnastada;

Ebaolulised ja rakendamisega seotud sõltuvused tuleks kõrvaldada;

toimingud: sõltuvus peaks kirjeldama rakenduse domeeni struktuurseid omadusi, mitte ebaolulisi sündmusi;

trenaarsed sõltuvused: enamiku kolme või enama klassi vahelisi sõltuvusi saab lagundada mitmeks binaarseks sõltuvuseks, kasutades vajadusel määrajaid; mõnel (väga harvadel) juhtudel ei saa sellist lagunemist läbi viia; näiteks trenaarset sõltuvust “Professor õpetab kursust ruumis 628” ei saa infokaota binaarseteks lagundada;

tuletatud sõltuvused: on vaja välistada sõltuvused, mida saab väljendada teiste sõltuvuste kaudu, kuna need on üleliigsed; üleliigsete (tuletatud) sõltuvuste välistamisel peate olema eriti ettevaatlik, kuna mitte kõik klassidevahelised dubleerivad sõltuvused pole üleliigsed; mõnel juhul võimaldavad muud sõltuvused tuvastada ainult teise tuletatud sõltuvuse olemasolu, kuid ei võimalda tuvastada selle sõltuvuse paljusust.

Pärast üleliigsete sõltuvuste eemaldamist peate selgitama ülejäänud sõltuvuste semantikat järgmiselt:

valesti nimetatud sõltuvused: need tuleks ümber nimetada, et nende tähendus saaks selgeks;

rollinimed: vajadusel peate lisama rollinimed; rollinimi kirjeldab vastava klassi rolli antud sõltuvuses teise selles sõltuvuses osaleva klassi seisukohast; kui rolli nimi on klassi nimest selge, võib selle ära jätta;

kvalifikaatorid: lisades vajadusel määrajaid, tutvustame kontekstielemente, mis võimaldab saavutada objektide üheselt mõistetavat identifitseerimist; määrajad võimaldavad ka mõningaid sõltuvusi lihtsustada, vähendades nende paljusust;

paljusus: on vaja lisada tähistusi sõltuvuste paljususe kohta; Tuleb meeles pidada, et süsteeminõuete edasise analüüsi käigus võib sõltuvuste paljusus muutuda;

arvestamata sõltuvused tuleb tuvastada ja mudelisse lisada.

2.4. Atribuutide täpsustamine

Järgmises etapis täpsustatakse atribuutide süsteemi: kohandatakse klassi atribuute ja vajadusel võetakse kasutusele uusi atribuute. Atribuudid väljendavad kõnealuse klassi objektide omadusi või määravad nende hetkeoleku.

Atribuudid vastavad tavaliselt nimisõnadele; näiteks auto_värv (objekti omadus), kursori_positsioon (objekti olek). Atribuudid mõjutavad objekti mudeli struktuuri reeglina vähe.

Koos objektiatribuutidega on vaja sisestada ka klassidevaheliste sõltuvuste (objektidevahelised seosed) atribuudid.

Atribuutide määramisel juhindume järgmistest kriteeriumidest:

Atribuutide asendamine objektidega. Kui mingi olemi olemasolu on olulisem kui selle väärtus, siis on see objekt, kui väärtus on olulisem, siis on see atribuut: näiteks ülemus on objekt (pole vahet, kes on boss; , peaasi, et keegi on), palk on atribuut ( selle tähendus on väga märkimisväärne); linn on alati objekt, kuigi mõnel juhul võib tunduda, et see on atribuut (näiteks linn ettevõtte aadressi osana); juhtudel, kui soovite, et atribuut oleks linn, peaksite määratlema klasside firma ja linna vahel sõltuvuse (näiteks asukoha).

Kvalifitseeruvad. Kui atribuudi tähendus sõltub konkreetsest kontekstist, tuleks sellest teha täpsustaja.

Nimed. Nimed sobivad tavaliselt paremini tähistajate kui objekti atribuutide järgi; kõigil juhtudel, kui nimi lubab valida teatud hulga objektide hulgast, tuleks see teha täpsustajaks.

Identifikaatorid. Objekti identifikaatorid on seotud nende rakendamisega. Projekteerimise algfaasis ei tohiks neid atribuutidena käsitleda.

Ühenduste atribuudid. Kui mõni omadus ei iseloomusta mitte objekti ennast, vaid selle suhet teise objektiga (objektidega), siis on see ühenduse atribuut, mitte objekti atribuut.

Sisemised väärtused. Atribuudid, mis määravad ainult objekti sisemise oleku, mis on väljaspool objekti nähtamatud, tuleks vaatlusest välja jätta.

Ebaolulised detailid. Soovitatav on välja jätta atribuudid, mis ei mõjuta enamiku toimingute täitmist.

2.5. Alamsüsteemide isoleerimine

Rakendussüsteem on üksteisest sõltuvate objektide kogum. Iga objekti iseloomustab atribuutide komplekt, mille väärtused määravad objekti oleku, ja toimingute komplekt, mida saab sellele objektile rakendada. Rakendussüsteemide arendamisel on mugav eeldada, et kõik objekti atribuudid on privaatsed (st need ei ole väljaspool objekti ligipääsetavad ning objektis mõne teise objekti atribuudi väärtuse väljaselgitamiseks või selle muutmiseks, peate kasutama ühte selle objekti avalikest toimingutest , kui selline toiming on muidugi defineeritud). Objekti toimingud võivad olla avalikud või privaatsed.

Seega on igal objektil rangelt määratletud liides, s.t. avalike toimingute kogum, mida saab sellele objektile rakendada. Kõigil sama klassi objektidel on sama liides. Klassi (ja järelikult ka selle klassi iga objekti) liides määratakse selle avatud (avalike) operatsioonide (ja neid rakendavate meetodite) allkirjade loendiga; suletud operatsioonide signatuurid ei sisaldu vastava klassi objektide liideses.

jne.................