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
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 Abstraktsioonit Interaktsioonid Struktuur Käitumine ase Analüüs Kasutusjuhtude Kontekstidiagramm Eesmärgimudeli diagrammid, id, d, kasutusjuhtude klassidiagrammid tegevusdiagramm tabelid id, kasutuslood Disain Jadadiagrammi Detailsed klassi- Olekudiagrammi d diagrammid d Platvormist Kasutajaliidese Andmemudelid Detailsed sõltuv disain ja ja olekudiagrammid interaktsioonid objektimudelid e spetsifikatsioo
Ü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
Duck tape makes even "no no" sound like "mm mm" 1. Domeenimudel Domeen ==Valdkond. UP (ja RUP) kontekstis me nimetame domeeni mudeliks kontseptuaalsete klassidiagrammide vormis staatilist esitust valdkonna objektmudelist. Iteratiivses arendusprotsessis UP Kui muidu tegelesime ärisüsteemide mõistete ja objektide (registrid) äriprotsesside modelleerimisega, siis nüüd modelleerime neid konkreetse iteratsiooni tarkvara nõuete ja kasutusjuhtude kontekstis suurema täpsusega. Domeenimudelid tehakse peamiselt detailimisfaasis (elaboration) iteratiivselt. Algfaasis tehtav domeenimudeli eskiis on kasulik, kuid tõestamata kvaliteediga. PS. Seda saab teha ka siis, kui äriprotsesse pole eelnevalt kirjeldatud. Põhisammud 1. Identifitseerida kontseptuaalsed klassid, mis on seotud jooksva iteratsiooni nõuetega. 2. Luua esialgne domeeni mudel (just selle iteratsiooni fookuses olevate nõuete ja kasutusjuhtude jaoks. 3. Eristad...
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
Tarkvaratehnika konspekt. Tarkvaratehnika Tarkvaratehnika e. tarkvara inseneeria on professionaalsele tarkvaraarendusele suunatud distsipliin, mis tegeleb sellega, kuidas organiseerida tarkvaraarendust, arvestades organisatsiooniliste ja rahaliste piirangutega. Tarkvaratooted koosnevad valjatöötatud programmidest ja nende dokumentatsioonist. Tarkvaratehnika eesmärgiks on kuluefektiivne tarkvaraarendus kogu tarkvara elukaare ulatuses. Tarkvaratehnika on süstemaatilise, distsiplineeritud ja mõõdetava lähehemisviisi rakendamine tarkvara arendamisele, käitamisele ja hooldamisele, see tähendab, inseneriteaduste rakendamine tarkvarale. Tarkvaratehnika „point“: Tarkvaratehnika on suunatud professionaalsele tarkvaraarendusele. Tarkvaratehnika ei tegele tarkvaraarenduse endaga vaid sellega, kuidas organiseerida tarkvaraarendust. Tarkvaratehnika vajadus - kõrgenenud nõudmised: suuremad süsteemid, keerulisemad süsteemid, kiiremini aren...
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 
Sisene Facebook'ga
Sisene Google'ga
Sisene LinkedIn'ga
