ärimudeli definitsiooni). Fuck me, kui palju on võimalik sõna “äri” kirjutada? Mu ä täht läheb katki varsti Väärtusmodelleerimine - (value modeling) - on äri(HAHA my point)modelleerimise alamdistsiblinn, mis toetab pigem seda definitsiooni, mille fookus on väärtuste loomisel ja raha teenimisel. Siin aines sellega eriti ei tegele, aga võtame aluseks e3-value meetodi ja notatsiooni lihtsustatud/vähendatud ver mida annab UMLi panna. Sellised lingid oli toppinud sinna, kel huvi vaadaku https://www.google.ee/?gws_rd=ssl#q=e3-value+diagram http://www.palgrave-journals.com/ejis/journal/v19/n3/fig_tab/ejis201013f1.html http://e3value.few.vu.nl/ Ahja, kuuenda loengu ajal ma photoshoppisin Rogeri näole kivi-paber-kääre peale seega ma väga ei kuulanud. Sorry! 6. e3 - Value notatsioonist Mõeldud ärivõrgustike (business networks) modelleerimiseks. Põhifookus:
Pomme saab teele saata kasutades u "Tuld" ja mängu saab iga hetk lõpetada vajutades "Katkesta mäng". Max_pommid 4 Tulistatud pommid Tabatud Aeg Max _aeg Muutujad on aeg, pommide arv ja tabamused. 3 1 20,1 20 Kasutatavad objektid on laev, allveelaev, plahvatus, vesi ja pomm. abamused. laev, plahvatus, vesi ja pomm. Protseduuri Liigu algoritmi UMLi tegevusskeem laev.IncrementLeft dx allveelaev.IncrementLeft dx_a laev.Left <= vp laev.Left + lae peegeldab laeva pilti, dx=dx
kohandamist. Arendamine organiseeritakse lühikesteks, fikseeritud pikkusega miniprojektideks (uusarenduse puhul soovitatakse ühe iteratsiooni pikkuseks 2-6 nädalat, pikem oleks halb motivatsiooni aspekti tõttu ja tagasisisde saamine veniks liiga pikaks, tähtaegasid ei nihutata). Pidev kvaliteedikontroll - testitakse varakult, tihti. Rakendatakse use case-e, kasutatakse UMLi Üks projekt = iteratsioon, tulemuseks on testitud, integreeritud ja täidetav süsteem (aga mittetäielik PS tulemus ei ole prototüüp, tulemus on tootmiskvaliteediga alamhulk lõppsüsteemist EHK iteratsiooni tulemus on tükike lõpp-produktist). Tavaliselt iga iteratsioon võtab ette uued nõuded ja laiendab süsteemi, samas saab ka olemasolevat tarkvara täiustada. Iga iteratsioon sisaldab oma nõuete analüüsi, disaini ja testimist. Asi on jagatud 4
4.Valdkonna ja interpretatsiooni seos? Interpretatsioon seob elemendid valdkonnaga. 5. Mudeli ja konteksti seos? Tähtkuju suur vanker vs ostukäru näide. 6. UML trivia!!!! Loodi 90ndatel (1800) Booch, Jackobson, Rumbaugh poolt (valged mehed?), Rational Software firmast 97ndal Object Management Group (OMG) poolt standardiks võetud keel Praegune ver. 2.5 (Märts 2015) Iseennast kirjeldav e standard on kirjutatud UMLi enda vahendeid kasutades (klassidiagramme) 7. Mudel vs diagramm Mudel analoogia andmebaasiga, sisu mõttes on nagu tekstidokument (kasutusjuhtude puhul) Diagramm nagu vaade mudelisse (analoogia ekraanivormidega), illustreeriv, kokkuvõttev tähendus (kasutusjuhtude puhul) 8. Tuum (standard) vs laiendused (profiilid) Valdkonnaspetsiifilised modelleerimiskeeled nt Business, Real-time systems, database, web jne jaoks Mitte UML BPMN, ArchiMate, Entity-Relationship 9. UML diagrammid
automatiseeritud maksete autoriseerimise teenus. Sageli arvutisüsteem, kuid võib olla ka inimene või organisatsioon. Miks identifitseeritakse? Er selgitada välja välised liideseid ja protokolle. 3. Kõrvalseisev, lavatagune/offstage tegutseja - omab huvi kasutusjuhu käitumise suhtes, kuid pole primaarne ega toetav, nt riiklik maksuamet. Milleks? Et kindlustada kõigi vajalike huvide identifitseerimine ja rahuldamine. 14. Kasutusjuhtude mudel vs kasutusjuhtude diagramm Diagrammid on UMLi tehnika kasutusjuhtude illustreerimiseks. Diagrammid ja seosed ei ole põhi fookus, pigem peaks keskenduma mudelile ehk see pikk kaunis tekstidokument, kus on kogu asi detailselt, laialt ja mõistlikult lahti kirjutatud, ehk eelda, et su lugeja on primitiiv ja sa tõesti pead iga sammu eriti üksikasjalikult välja kirjutama. Rõhk tekstile, mitte diagrammile! AGA - kuna diagrammid pole ikkagi täiesti kasutud, siis Mardi pro tips on how to make the best use case diagrams evaaaa 1
17. Valige QIGE vaide. Juhtimist toetava susteemi naiteks on :: P: 2.3 aruandlussusteemid, otsustamise toetussusteemid elektrisusteemid, kuttesusteemid, kanalisatsioonisusteemid transaktsioonide tootlussusteemid, protsesside juhtimissusteemid, kontori automatiseerimissusteemid 18. Valige QIGE vaide. Andmebaas on: :: P: 3.6 infosusteemi "veaparandusmasin", milles salvestatakse susteemi too kaigus tekkinud vead infosusteemi "generaator", mis genereerib sisendandmete kujul antud UMLi mudelite baasist programmkoodi, automatiseerides nqnda susteemitood infosusteemi "mootor", milles organiseeritakse infosusteemi sundmused infosusteemi "piir", milles organiseeritakse infosusteemi protsessid infosusteemi "tuum", milles organiseeritakse infosusteemi andmed 19. Valige QIGE vaide. Juhtimist toetavad susteemid: :: P: 1.4 teenindavad operatiivse juhtimise taset, vqimaldades korduvalt ja rutiinselt salvestada nii organisatsioonis endas kui valjaspool seda toimuvaid sundmusi
kasutatakse (kasutusjuhtude mudel, kontseptuaalne andmemudel, seisundidiagramm, tegevusdiagramm, andmebaasioperatsioonide lepingud, CRUD maatriks) ning milline mudel on aluseks millise teise mudeli loomisele (naiteks pohiobjektide jargi leian funktsionaalsed allsusteemid ja registrid; seisundidiagrammi jargi leian paljud ̈ kasutusjuhud ja paljude andmebaasioperatsioonide nimed). • Millist UMLi diagrammi tuupi saab kasutada olemisuhte diagrammi ja ̈ andmebaasi diagrammi koostamiseks? (klassidiagrammi) • Olemisuhte diagramm ja temaga seotud moisted. • Milline on aine projektile moeldes kasutusjuhtude ja seisundidiagrammi seos? Iga seisundiüleminek juhtub mingi kasutusjuhu käigus. • Milline on aine projektile moeldes operatsiooni lepingute ja seisundidiagrammi seos
2. Saab aru analüüsi ning disaini erinevusest ning ühtsusest. 3. Oskab süsteemselt (struktuurselt) mõelda ning arutleda. 4.Teab ning oskab kasutada ja siduda traditsioonilise (struktuurse), objektorienteeritud ning agent-orienteeritud süsteemianalüüsi tuntumaid meetodeid, tehnikaid ning vahendeid. 5.On võimeline rakendama kontseptuaalset süsteemianalüüsi ümbritseva elu erinevatele nähtustele ja probleemidele nende mõistmiseks, kirjeldamiseks ja selgitamiseks. 6.Oskab kasutada UMLi põhilisi diagrammitehnikaid (UP - Unified Process-i) ärimodelleerimise ja (kasutusjuhtude ning/või kasutuslugude keskse) nõuete analüüsi kontekstis 7.Oskab kirjeldada, analüüsida, hallata ning selgitada infosüsteemi/arenduse osapoolte nõudeid ja eesmärke, mõisteid, kasutuslugusid ja kasutajaliideseid. 8.Oskab ühendada tekstilist ning graafilist (sealhulgas UML) modelleerimist, ning päringute (vaadete) koostamist (valdkonnamudeli alusel nõuete modelleerimiseks). 9
annaabi.ee 
