Klasside diagrammi sissejuhatus

Staatilist diagrammi, mis kujutab rakenduse staatilist vaadet, nimetatakse klassidiagrammiks. Lisaks süsteemi erinevate aspektide visualiseerimisele ja dokumenteerimisele konstrueerib klassidiagramm ka rakenduses käivitatava koodi.

Klassi atribuute, toiminguid ja süsteemi piiranguid kirjeldab klassidiagramm. Kuna neid on võimalik objektorienteeritud keeltega otse kaardistada, kasutatakse seda selliste süsteemide modelleerimiseks. Struktuuriskeemina tuntud ka piirangute, seoste, koostöö jms kogum.

Definitsioon

Klasside diagrammi võib määratleda UML-i osana, mis annab ülevaate süsteemist atribuutide, klasside osas ja kirjeldab ka nendevahelisi suhteid. See toimib süsteemi arendamise ressursina ja loob süsteemi funktsionaalse diagrammi.

Arendajatele süsteemi ülesehituse mõistmiseks on mõeldud klassidiagramm. See on ristkülikukujuliste kastidena esitatud vooskeemi sünonüüm. Sellel on kolm peamist osa - klassi nimi, atribuudid ja lõpuks klassi meetodid.

Suhted

Klasside skeemil on vajalik, et klasside vahel oleks seos. Erinevate suhete sarnasus raskendab selle mõistmist sageli. Allpool on toodud seosed, mis eksisteerivad klassidiagrammil.

1. Ühing

Kahe teise assotsieerumisklassi vahel moodustab sellest osa assotsiatsiooniklass. Lisateavet suhete kohta saab, kui lisate assotsieerimissuhte assotsiatsiooniklassiga. Ühinguklassis on mitmesuguseid toiminguid, atribuute jms. Allpool olev diagramm näitab panga ja konto seotust.

2. Mitmekesisus

Elementide arvu või kardinaalsust saab määratleda korrutamise abil. See on üks kõige valesti mõistetud seoseid, mis kirjeldab konkreetse elemendi jaoks lubatud eksemplaride arvu, pakkudes kaasava mittenegatiivse täisarvu intervalli. Sellel on nii alumine kui ka ülemine piir. Näiteks oleks pangal palju kontosid. Seega on kontoklassi lähedal tähtmärk.

3. Suunatud ühing

See on ühesuunaline suhe klassiskeemis, mis tagab juhtimisvoo ühelt klassifikaatorilt teisele. Laevatatavuse määrab üks seotuse lõpp. Kahe klassifitseerija suhet võiks kirjeldada ükskõik millist seost nimetades. Navigeerimise suunda tähistatakse noolega. Allpool toodud näide näitab noolepea suhet konteineri ja suletud toote vahel.

4. Refleksiivne ühendus

Klassi seost iseendaga tuntakse refleksiivse assotsiatsioonina, mille võib jagada sümmeetriliseks ja asümmeetriliseks. Sümmeetrilises refleksiivses assotsieerumises pole iga assotsiatsiooni otsa semantikal loogilisi erinevusi, samas kui asümmeetrilises refleksiivses assotsiatsioonis on seostatud klass sama, kuid seose otste vahel on semantiline erinevus.

5. liitmine

Seda tüüpi suhetes luuakse keerukam objekt erinevate objektide kokku panemisega. Erinevate objektide rühma koostoimimist määratleb liitmine. Objektide terviklikkus on kaitstud ja kokkupandud objektide reageerimise otsustab juhtimisobjekt. Kokkuvõttes toidavad klassid seost 'on'.

6. Koosseis

See on agregatsiooni vorm, mis tähistab kogu osa suhet. Osade klassifikaatori kasutusiga sõltub kogu klassifikaatori tööajast. Klassis tähistab tugevat elutsüklit kompositsioonisuhe. Siin toimub tavaliselt ühesuunaline andmevoog. Üldiselt tähistab seda kindel joon.

7. Üldistamine

Sellistes suhetes põhineb lapsemudel vanemmudelil. Suhet kasutatakse mitmesuguste kasutusjuhtumite diagrammide kirjeldamiseks ja see tagab, et lasteklass saab vanemal olevad omadused. Lapsemudel võiks üldistussuhte abil vanema mudeli atribuute uuesti kasutada. Seetõttu tuleb eristatavad atribuudid määratleda ainult lapses, ülejäänud pärandi pärandab see lapsevanemale. Selles suhtes võiks olla üksikvanem, mitu last või mitu vanemat, üksiklapse omadused. Üldistavates suhetes pole nimesid. Seda tuntakse ka suhtena.

8. Realiseerimine

Ühe mudelilemendi käitumine realiseerub teise mudelilemendi määratletud käitumisega. Seda tüüpi suhetel pole ühtegi nime.

Miks peaksime kasutama klassidiagrammi?

Süsteemi struktuuri määratleb klassidiagramm, näidates selle atribuute, seoseid objektide vahel jne. See on objektorienteeritud modelleerimise alustala ja seda saab kasutada ka andmete modelleerimisel. Klassiskeemid aitavad koostada eelplaane, mis hõlbustavad programmeerimisprotsessi. Lisaks võite klassiskeemi alati muuta, kuna faktide järel on erinevate funktsioonide kodeerimine tüütu tüütu. See on projekteerimisplaan, mille põhjal süsteem üles ehitatakse. Seda on lihtne mõista ilma vajalike tehniliste teadmisteta.

Klassidiagramm pakub rakendusele staatilist vaadet ning selle kaardistusvõime objektorienteeritud keelega teeb selle valmis kasutamiseks ehituses. Erinevalt järjestusskeemist, tegevusskeemist jms on klasside diagramm kõige populaarsem UML-diagramm. Allpool on toodud klassi diagrammi eesmärk.

  • Projekteeritakse ja analüüsitakse rakenduse staatilist vaadet.
  • Süsteem kirjeldab süsteemi kohustusi.
  • Komponendid ja paigaldusskeemi alus on klassidiagramm.
  • Edasist ja tagurpidi projekteerimist mõjutab klassidiagramm.

Klassiskeemi tüübid

Klassiskeemi võiks jagada kolmeks komponendiks -

Ülemine osa, mis koosneb klassi nimest ja on kohustuslik komponent. Keskmine osa kirjeldab klassi omadusi ja klassiklassi konkreetse eksemplari kirjeldamisel kasutatud kirjeldust. Alumine osa kirjeldab klassi suhtlemist andmetega.

Veelgi enam, UML jaguneb käitumisskeemiks ja struktuuriskeemiks koos klassiskeemiga, mis kuuluvad struktuuriskeemi alla.

Klassiskeemi eelised

Klasside diagrammi saab rakendada projekti erinevates etappides ja see on UML-i süda. Reaalsuse kujutise loob klassidiagramm, ilmudes domeeni mudelile analüüsi ajal. Tarkvara modelleerimine toimub projekteerimisetapis, kood genereeritakse juurutamisetapis. Tarkvaratoodete alustalaks on klassidiagrammid, mis on iga projekti oluline osa.

Orienteerumise tunde annavad klassidiagrammid. Süsteemi ülesehitust analüüsitakse detailselt klassiskeemiga ning samuti antakse ülevaade erinevate elementide koostoimest koos nende omadustega. See on kiire ja hõlpsasti loetav ning seda saab hõlpsasti luua, kui õige tarkvara on olemas. Mis tahes süsteem, mis tuleb luua, klassiskeemid loovad sellele aluse.

Kasu

  • Mis tahes lihtsat või keerulist andmemudelit saab illustreerida klassiskeemi abil, et saada maksimaalset teavet.
  • Rakenduse skeemidest võiks selle abil aru saada.
  • Igasuguse süsteemi vajaduse võib konkreetse tegevuse jaoks visualiseerida ja kogu ettevõttes edasi anda.
  • Iga konkreetse koodi rakendamise nõuet saab diagrammide kaudu esile tuua ja programmeerida kirjeldatud struktuuri.
  • Esitada võiks rakendustest sõltumatu kirjelduse, mida saaks edasi anda komponentidele.

Klassiskeemi puudused

Kuigi klassidiagramm on esimene, mida tootmiskeskkonnas veatu süsteemi ehitamisel kaaluda tuleb, on kindlasti ka õiglane osa miinustest.

  • Klassiskeemide haldamine ja haldamine võib sageli võtta kauem aega, mis on arendaja jaoks mõnikord tüütu. Tarkvarakoodiga sünkroonimiseks, selle seadistamiseks ja hooldamiseks on vaja aega. Sageli on arendajatel või väikestel ettevõtetel koodi sünkroonimine keeruline, kuna see nõudis lisatud tööd.
  • Puuduseks on ka selguse puudumine diagrammi saaja mõistmisel. Kuna tarkvaraarendajad töötavad koodiga, pole klasside diagrammid mõnikord sellest palju aidanud. Projektijuhtidele võiks diagrammidest siiski kasu olla, kuna see annab ülevaate konkreetse tööriista töökorraldusest. Seetõttu on sageli argument klasside diagrammidele aja raiskamise vältimiseks ning skeemi joonistamiseks tuleks keskenduda pigem tahvli või paberi kasutamisele.
  • Liiga keeruline või üle jõu käiv diagramm ei aita tarkvaraarendajaid nende töös. Võib esineda olukordi, kus arendajad on klassiskeemide ülesehituse tõttu pettunud. Iga stsenaariumi kaardistamine võib diagrammi muuta segaseks ja sellega töötada on keeruline. Kõrgetasemelise teabe kasutamine võiks kuidagi aidata selliste probleemidega võidelda.
  • Kujunduse ületähtsustamine võib arendajatele ja ettevõtetele takistusi pakkuda. Sidusrühmad võiksid pärast klassidiagrammi uurimist probleeme hõlpsalt analüüsida, ja kui tarkvara funktsioonidele liiga palju pingutada, võib see keskenduda. Inimesed peavad maha jääma tegelikust tööst, selle asemel et kulutada aega diagrammi uurimisele ja probleemide lahendamisele.

Nagu näete, hoolimata klassidiagrammi olulisusest tarkvaraarenduse elutsüklis, ei ole see kindlasti ilma puudusteta ja võib aruka kasutamise korral raskendada elu arendajate ja ettevõtete jaoks.

Klassiskeemi näide

Ilma tehniliste piiranguteta on diagrammi üsna lihtne koostada. Pangaautomaadi kasutamiseks on vaja, et klient vajutaks sularaha saamiseks vaid mõnda nuppu. Hoolimata sularaha väljavoolu lihtsusest, on tausttagatise süsteemil mitu turvalisuse kihti, mis tuli pettuste, rahapesu jms ennetamiseks rakendada.

Nagu siin näha, on mitu üksust, mis järgivad erinevate suhete omadusi, nagu eespool kirjeldatud. Need suhted kirjeldavad ATM-süsteemi ülesehitust ja turbekihte, mida see peab läbima, et tagada tehingu läbipaistvus ja terviklikkus.

Klasside diagrammi võib jagada kolmeks:

  1. Esiteks on kontseptuaalne perspektiiv, mida reaalse maailma objekte kirjeldatakse kontseptuaalsete diagrammide abil. Uuritavat domeeni tähistab diagramm. See on keelest sõltumatu ja klassiga seotud.
  2. Tarkvara komponente kirjeldatakse spetsifikatsiooni vaatenurga alt koos liideste ja spetsifikatsioonidega. Spetsiifilise rakendamise korral aga kohustusi ei võeta.
  3. Spetsiifilise keelelise rakendamise võiks teostada rakendusperspektiivi klassiskeemide abil.

Klassiskeemiga töötamine

Tarkvaraarenduse jaoks on kõige olulisem UML-diagramm klassidiagramm. Klassiskeemi joonistamiseks, mis kajastab rakenduse erinevaid aspekte, on mõned omadused, mida tuleb arvestada, järgmised:

  • Klasside skeemile, mis kirjeldab süsteemi tegelikku külge, tuleks anda asjalik nimi.
  • On vaja, et eelnevalt mõistetaks iga elemendi suhet.
  • Parema toote väljatöötamiseks tuleb tunnustada klasside vastutust.
  • Diagrammi keerukaks tegemise vältimiseks tuleks täpsustada klassi konkreetsed omadused.
  • Dokumentatsioon on hea tava mis tahes tarkvaraarendusprojektides. Seega vajab diagrammi mis tahes aspekti määratlemine teiste dokumentide mõistmiseks nõuetekohast dokumentatsiooni või märkusi. Tarkvaraarendusmeeskond peaks lõpus aru saama, mis on diagrammil konfigureeritud.
  • Enne lõpliku versiooni loomist on vaja joonistada tahvlile või tavalisele paberile. Siiski tuleb tagada, et edastatakse ainult valmis diagramm, mis võib sisaldada mitut ümberehitust.

Kuidas see tehnoloogia aitab teid karjääri kasvamisel?

Tarkvaratööstuses töötamiseks on hea toote loomiseks hädavajalik, et te eelnevalt määratleksite oma probleemi struktuuri. Klasside diagramm aitab mõista projekti elutsükli erinevaid aspekte ja aitab mõista suhet koodi elementide sees.

Järeldus

Tarkvara süsteemi artefaktide kavandamiseks ja visuaalseks muutmiseks kasutatakse UML-i standardkeelt. Erinevate objektide suhteid kirjeldab klassidiagramm, mis tagab rakenduse kavandamise ja analüüsi ning vaatab seda staatilisel kujul. Olles kõige olulisem UML-diagramm, koosneb klassidiagramm klassist, atribuutidest ja suhetest, mis on selle olulised elemendid. Rakenduse ülesehituse kohta idee saamiseks kasutatakse klassiskeemi, mis aitab hooldusaega lühendada.

Soovitatavad artiklid

See artikkel on juhend teemale Mis on klassiskeem. Siin arutati põhimõisteid suhetega ja erinevat tüüpi klassiskeemi. Lisateavet leiate ka meie muudest soovitatud artiklitest -

  1. Mis on andmeanalüütik?
  2. Mis on SQL Server?
  3. Mis on taru?
  4. Mis on Apache Spark?
  5. Pöördtehnika

Kategooria:

Tarkvaraarendus