Objektorienteeritud modelleerimine. Objektmudel: Klassid, Objektid ja nende seosed Esmärk: Ülevaade objektmodelleerimise põhimõistetest Klassidiagrammides kasutatavate põhikonstruktsioonide tutvustamine Sisu Objektid ja klassid Klassidiagramm Kuidas leida klasse ? Atribuudid Operatsioonid Seosed Piirangud Mudeli kvaliteet Objektorienteeritud modelleerimises on põhilisteks elementideks klassid, objektid ning nendevahelised seosed . Kui modelleerimise eesmärgiks on tarkvarasüsteemide ehitamine, minnakse objektorienteeritud mudelitelt sujuvalt üle objektorienteeritud programmeerimise mõistetele / konstruktsioonidele, kus klassid ja seosed on teisendatud tegelikuks programmikoodiks. Objektid ja klassid Objekt on element, nähtus, asi, millest me räägime ja/või millega tegutseme. Objekt eksisteerib reaalses maailmas, täpsemalt, meie ettekujutuses sellest maailmast. Modelleeritavat osa maailmast nimeta...
1. Küsimused a) Zachmani tugiraamistik Zachmani tugiraamistik – 1990 John A. Zachman. Kirjeldab valdkonna infosüsteemi üldist ülesehitust ja arhitektuuri. Mudel infosüsteemile endale. Saab rakendada igale ärivaldkonnale sõltumata suurusest, „Puhtale valdkonnale“ ja (IT) infrastruktuurile. Veerud vastavad põhiküsimustele: Mis? Kuidas? Kus? Kes? Millal? Miks? Read vastavad süsteemitöö põhilistele osapooltele-huvigruppidele: juhtkond, tippjuhid, planeerijad, ärimõistete omanikud, arhitekt-disainerid, ehitaja-tehnoloogid, tehnikud, ülalhoidjad. „Puhas valdkond“ - 2 ülemist rida. IT infrastruktuur alates kolmandast allapoole. MDA (Model Driven Architecture) mudelitüübid: CIM (Computing Independent Model) – teine rida PIM (Platform Independent Model) – kolmas rida ...
inimene, võib seda pidada ärivald(konnaks). Raamistik rakendub igale ettevõttele, ükskõik kui keerukas see ka poleks. Puhas valdkond – Ülemised kaks rida. Kõik muu on IT infrastruktuur. Just in case kui ta küsib – CIM – Computing Indepedent Model – ülalt teine rida PIM – Platform independent Model – kolmas rida PSM – Platform Specific Model – neljas rida Kood – Viies rida 2. Objektide modelleerimine ja klassidiagrammid Objektorienteeritud progemises on põhilisteks elementideks klassid, objektid ja nendevahelised seosed. Klasse ja seoseid saab tõlgendada programmikoodiks. Objekt – Element, nähtus, asi, millest me räägime ja/või tegutseme nt tellimus, toode, arve, su ema Objektsüsteem – Modelleeritab osa maailmast, ka probleemvaldkond(nagu tuharad), domeen. Selleks võib olla suvaline süsteem, ka masin, organisatsioon, ärisüsteem jne. Klass vs Objekt
seotud? Millist tüüpi olemite kohta peaks süsteem informatsiooni esitama ja kuidas need olemid on omavahel seotud? kontekstidiagramm – näitab mis osadest süsteem koosneb ja kuidas see suhtestub teiste süsteemidega klassidiagramm - esitab struktureeritud kujul informatsiooni, mida saab töödelda aggregatsioon – näitab, kuidas klassidiagrammi elemendid sisaldavad teineteist 1…1* assotsiatsioonid – terve suur süsteem klassidiagrammideast, mis näitab, kuidas klassidiagrammid seotud on Interaktsioonide disain –Milliseid teateid süsteem vahetab enda ja kasutajaga? jadadiagramm - minu definitsioon – näitab ajateljel, kuidas süsteemi osasd omavahel suhtlevad Struktuuri disain – millist informatsiooni tuleb süsteemis esitada? detailne klassidiagramm – klassid koos väljade ja meetoditega käitumise disain – olekudiagrammid – algus ja lõpp-punktiga olekud, vahepeal aga on kommentaarid seisundi kohta Vaatepunkti aspekt
Üldised diagrammid 6 7 Diagramm 2 Valige üks neljast allolevast diagrammist oma matrikli viimase (a) ja eelviimase (b) numbri summa viimase numbri (c = RIGHT( a + b)) järgi: c 0 1 2 3 4 5 6 7 8 9 skeem 2 3 4 3 2 4 1 3 2 1 Exceli klassidiagrammid 8 9
ning toimima koos äri tegemiseks. Väljendatakse erinevat tüüpi diagrammidega, kaasa arvatud käitumislikud diagrammid. Domeenimudel on mittetäielik BOM, mis keskendub domeeni olulistele "asjadele". Dünaamikavaadet ei sisalda. 6. Kasutajaliideste eskiisid kui vaated domeenimudelisse Kasutajaliideste eskiisid, mida võidakse joonistada kasutusjuhtude mudeli tegemisel, on "vaated" Domeeni mudelisse (e kontseptuaalsed klassidiagrammid), st kasutajaliidese andmeväljade sisu peab olema defineeritav kontseptuaalse klassidiagrammi "keeles": Kasutajaliidese ja domeenimudeli elementide seosed Eskiis on tehtud EA diagrammina, mille tüübiks on user interface. Kasutajaliides on vaade domeenimudelisse, st enamus kasutajaliidese andmeelementidest (väljadest) suhestatakse otseselt kontseptuaalse klassidiagrammi vastavate elementidega (atribuutidega). 7. Mustrid kui näidismudelid
The fuck do those diagrams even mean? Esimeses tegevusdiagrammis on äriprotsessi (järelanalüüsi) töövoog ja peamised ressursivood (infovood ja objektivood) joonistatud ühele ja samale diagrammile, teisel tegevusdiagrammil on näidatud kõik ressursivood ilma töövoo elementideta. Preanalüütiline protsess 14. Registrite vaade Täpsustab Visiooni kontseptuaalsel klassidiagrammil (visuaalne Ärisõnastik) näidatud põhiobjekte (ehk ressursse) Struktuuri osas - registrite klassidiagrammid Käitumise osas (elutsüklid) - registrite põhiobjektide olekudiagrammid Tellimuste registri kontseptuaalne klassidiagramm Lol mida whitespacei?? Igatahes see on tellimuse olekudiagramm. Nooltel on kirjas ärisündmused, mis viivad kliendi tellimuse ühest olekust teise. Need sündmused peavad sisendite-väljundite poolest kokku sobima Funktsionaalse vaate tegevusdiagrammis olevate tegevuste kirjeldustega. Vist suht kõik. U did well human. Ok hakkame siis kolmandat tegema
• Struktuuri disain : o Millist informatsiooni tuleb süsteemis esitada? • Käitumise disain : o Kuidas süsteemi olemid käituvad? Olekudiagrammid Horisontaalses – Vaatepunkti aspekt (Interaktsioonid, Struktuur, Käitumine). Vertikaalses – Abstraktsiooni tase (Analüüs, Disain, Platvormist sõltuv disain). Ridade kaupa: Kasutusjuhtude diagrammid, klassidiagrammid, tegevusdiagrammid, Jadadiagrammid, Detailsed klassidiagrammid, Olekudiagrammid, interaktsioonide spefikastsioonid, objektimudelid, Detailsed olekudiagrammid. Versioonihaldus Draiverid - Versioonihaldus. Muudab arenduse paindlikumaks. Hajusad vahendid (Git, Mercurial, TeamWare), Tsentraliseeritud vahendid (SVN, CVS, Perforce, Microsoft TFS). Harud (branch) - luuakse repositooriumi peaharust eraldi haru. Projektid arendatakse harus ja mergetakse peaharru. Harus arendatakse
põhiomadusele. Tihti on raske vahet teha funktsionaalsete ja mittefunktsionaalsete (kvaliteedi) nõuete vahel, see teeb selle raskesti aru saadavaks. o Struktureeritud loomulik keel, nt kasutaja lood, kasutusjuhud, tsenaariumid. o Mudelid, mis illustreerivad nõudeid, ehk graafilised notatsioonid. Nt iteratsioonidiagrammid, klassidiagrammid, süsteemi käitumis diagrammid jne. o Formaalsed ehk matemaatilised spetsifikatsioonid, nt Z keel. Kaks olulist nõuete esitamise viisi o Kasutajalood (user stories) Üldkuju: Kui kasutaja mängib üht teatud rolli, siis mina pean olema võimeline tegema mingeid tegevusi, et tellimus saavutaks eesmärgi. Nt. ÕIS-i puhul, võttes õppejõu siis tema peab sisestama mingi hinde õpilasele.
Analüüs vs. Disain. Strateegiline analüüs vs. detailanalüüs. Klassikaline (struktuurne) vs. objektorienteeritud analüüs, agent-orienteeritud analüüs, nende ühtsus ja erinevus. Ärimodelleerimine vs nõuete (ning kasutajaliideste) analüüs. Objektide, protsesside, sündmuste, organisatsiooni (tegutsejate/agentide), eesmärkide ja suhtluste analüüs ning modelleerimine. Tekstiline vs. graafiline modelleerimine analüüsitöös. UML: klassidiagrammid, kasutusjuhtude diagrammid, tegevusdiagrammid, olekudiagrammid, jadadiagrammid analüüsimudelite kontekstis. Süsteemi nõuded ja kasutusjuhud, kasutuslood ning kasutajaliidesed. Üleminek ärimudelilt kasutusjuhtude mudelile. Kasutusjuhtude kirjeldamise formaadid. Domeenimudel (staatilise valdkonnamudeli tähenduses). Nõuded ja kasutajaliidesed kui vaated (päringud) domeenimudelisse. Süsteemi sündmused ja operatsioonid. Süsteemi jadadiagrammid. Süsteemi operatsioonide lepingud.
annaabi.ee 
