.............................................................................................................23 5.1 BUSSIJUHI TÖÖLEVÕTMISE OLEKUDIAGRAMM.............................................................................23 5.2 PILETI TRÜKKIMISE OLEKUDIAGRAMM........................................................................................24 5.3 PILETI BRONEERIMISE OLEKUDIAGRAMM....................................................................................25 6. KLASSIDIAGRAMM.......................................................................................................................26 7.KOLMEKIHILISE ARHITEKTUURI KLASSIDIAGRAMM.....................................................27 8. OBJEKTIDE JA ATRIBUUTIDE SEMANTIKA........................................................................28 9. SÜSTEEMI ARENDAMISKAVA JA STRATEEGIA................................................................30 9.1 STRATEEGIAETAPP...............................
......10 2.2.2.5 Kliendi pädevusala sündmused..................................................................11 2.2.2.6 Kliendi pädevusalaga seotud subjektid......................................................11 2.2.2.7 Business Use Case diagrammid.................................................................11 2.2.2.8 Business Use Case-de kirjeldused..............................................................14 2.2.2.9 Kontseptuaalne klassidiagramm.................................................................17 2.2.2.10 Klasside definitsioonid.............................................................................18 2.2.3 Laenutaja pädevusala spetsifikatsioon.....................................................................18 2.2.3.1 Laenutaja pädevusala eesmärgid................................................................18 2.2.3.2 Laenutaja pädevusala vastutused......................
......... 11 3. Funktsionaalne vaade............................................................................................... 12 3.1. Infosüsteemide põhifunktsioonid...................................................................... 12 3.2. Kasutuslugude mudel ja kirjeldus .................................................................... 13 4. Infosüsteemide andmevaade.....................................................................................15 4.1Kontseptuaalne klassidiagramm..........................................................................15 ..................................................................................................................................15 4.2. Andmemudel..................................................................................................... 17 4.3. Andmeobjektide ja atribuutide semantika.........................................................18 4.4. CRUD maatriks.....................................
................................................................... 10 1.2.3 Äriprotsesside struktuur........................................................................................... 10 1.2.4 Põhiprotsesside lausendid........................................................................................ 11 1.2.5 Põhiliste töövoogude tegevusdiagrammid............................................................... 11 1.2.6 Esialgne kontseptuaalne klassidiagramm.................................................................12 1.3 Nõuete analüüs................................................................................................................12 1.3.1 Funktsionaalsed nõudmised..................................................................................... 12 1.3.2 Mittefunktsionaalsed nõudmised............................................................................. 13 1.3
............................14 1.1.1.7Pädevusalaga seotud subjektid (business actorid)...............................15 1.1.1.8Pädevusala mudelid..............................................................................15 1.1.1.8.1Business Use Case diagrammid.................................................... 15 1.1.1.8.2Business Use Case `ide kirjeldused .............................................. 18 1.1.1.8.3Kontseptuaalne klassidiagramm.....................................................20 1.1.1.8.4Klasside definitsioonid ...................................................................21 1.1.1.8.5Olulisemad püsipäringud, väljundid (nimekiri)................................22 2.2.3 Meelelahutusjuhi pädevusala spetsifikatsioon............................................22 1.1.1.9Pädevusala eesmärgid..........................................................................22
...................................................................10 1.3.3 Äriprotsesside struktuur...........................................................................................10 1.3.4 Põhiprotsesside lausendid........................................................................................11 1.3.5 Põhiliste töövoogude tegevusdiagrammid...............................................................11 1.3.6 Esialgne kontseptuaalne klassidiagramm.................................................................12 1.4 Nõuete analüüs................................................................................................................13 1.4.1 Funktsionaalsed nõudmised.....................................................................................13 1.4.2 Mittefunktsionaalsed nõudmised.............................................................................13 1.4.2
................................................ 12 5.1. Kasutuslugude diagramm......................................................................................................... 12 5.2. Kasutuslugude kirjeldused....................................................................................................... 12 6. Andmevaade.................................................................................................................................. 15 6.1. Kontseptuaalne klassidiagramm.............................................................................................. 15 6.2. Andmemudel............................................................................................................................ 16 6.3. Objektide ja atribuutide semantika........................................................................................... 16 6.4. CRUD maatriks...................................................................................................
diagrammide joonistamisest Kasutusjuhtude mudeli koostamisel on diagrammide joonistamine tähtsam kui teksti kirjutamine 2. Kas äriprotsess on samal ajal ka tarkvara kasutusjuhtum (use case)? Joonige alla õige vastus. Võib olla küll, kuid kindlate tingimuste täidetuse korral Ei, kindlasti mitte Jah, kindlasti on 3. Millist loetletud diagrammitehnikatest ei kasutata põhimõtteliselt Eriksson-Penkeri ärimodelleerimise notatsioonis? klassidiagramm + ärikasutusjuhtude diagramm olekudiagramm tegevusdiagramm 4. Milliseid kasutusjuhtude mudelis identifitseeritud tegutsejaid (actors) ei ole vaja kasutusjuhtude diagrammis näidata? Valige pakutud vastusevariantide hulgast parim (s.t. täpne) vastus: toetavad tegutsejad vaadeldava süsteemi suhtes huvisid omavad tegutsejad +kõrvalseisvad (offstage) tegutsejad arvutisüsteemid inimtegutsejad primaarsed tegutsejad 5. Isikute haldamine on tavaline nn
diagrammide joonistamisest Kasutusjuhtude mudeli koostamisel on diagrammide joonistamine tähtsam kui teksti kirjutamine 2. Kas äriprotsess on samal ajal ka tarkvara kasutusjuhtum (use case)? Joonige alla õige vastus. Võib olla küll, kuid kindlate tingimuste täidetuse korral Ei, kindlasti mitte Jah, kindlasti on 3. Millist loetletud diagrammitehnikatest ei kasutata põhimõtteliselt Eriksson-Penkeri ärimodelleerimise notatsioonis? klassidiagramm + ärikasutusjuhtude diagramm olekudiagramm tegevusdiagramm 4. Milliseid kasutusjuhtude mudelis identifitseeritud tegutsejaid (actors) ei ole vaja kasutusjuhtude diagrammis näidata? Valige pakutud vastusevariantide hulgast parim (s.t. täpne) vastus: toetavad tegutsejad vaadeldava süsteemi suhtes huvisid omavad tegutsejad +kõrvalseisvad (offstage) tegutsejad arvutisüsteemid inimtegutsejad primaarsed tegutsejad 5. Isikute haldamine on tavaline nn
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.
Põhistsenaarium: 1. Andmesisestaja avab filmi lisamise vormi. 2. Andmesisestaja määrab filimile sobivaid seansse kõike seansside nimekirjast. 3. Andmesisestaja salvestab lisatud objekti. 5. Uus film on süsteemisse lisatud. TTÜ IS strateegiline analüüs 6 © TTÜ Informaatikainstituut 2.2.2.9.3 Kontseptuaalne klassidiagramm SeansiTüüp 1 1..* Seans 0..* Film Staatus (from Kl assi fi kaatorite register) (from Fi lmide regi ster) 0..* (from Fi lmide regi ster) (from Kl assi fi kaatorite register)
...............................................................18 loodud_RE_arv.................................................................................................................18 loodud_TREV_arv............................................................................................................19 ...........................................................................................................................................19 Ülevaatlik disaini klassidiagramm............................................................................................20 Üldvaade Siin kasutatakse C. Larmani Applying UML and Patterns toodud kuju (samad osad on nõutud ka ametlikus RUP-is). Oma iseseisvas töös võib kasutada üldvaadet eelmistest projektidest. Visioon Sissejuhatus Antud dokumentatsioonis esitatakse nägemus loodavast TTÜ õppekohtade haldussüsteemist, mis võimaldaks eraldatud õppekohtade elektroonilist arvestust ja veebipõhist
............................................................................................19 Kasutusjuhu Väljuva kõne alustamine realisatsioon.................................................................20 Jadadiagramm.......................................................................................................................20 Interaktsioonidiagramm........................................................................................................21 Ülevaatlik disaini klassidiagramm............................................................................................21 Jooniste sisukord Joonis 1. Tugiteenuste allsüsteem...............................................................................................6 Joonis 2. Sõnumite allsüsteem....................................................................................................7 Joonis 3. Telefoniraamatu allsüsteem......................................................................................
Kontseptuaalne süsteemianalüüs KT küsimused ja vastused 1. Milline järgnevalt nimetatud analüüsitulemustest on objektorienteeritud analüüsis kõige tähtsam? (Objektorienteeritud analüüsi all on siin mõeldud mitte kogu analüüsitegevust UP nimelises protsessis, vaid objektorienteeritud mõtteviisi selles tegevuses) kasutusjuhtude mudel protsessi mudel eesmärkmudel domeenimudel 2. Kas äriprotsess on samal ajal ka tarkvara kasutusjuhtum (use case)? Joonige alla õige vastus. Jah, kindlasti on Võib olla küll, kuid kindlate tingimuste täidetuse korral Ei, kindlasti mitte 3. Kas RUP Äri Objektmudel (Business Object Model) võib sisaldada dünaamikavaadet? Valige täpselt üks õige vastus: Ei või Jah, võib küll Oleneb asjaoludest 4. Millise allpool nimetatutest võiks olla (ainekonspekti ning C. Larmani raamatu õpetuse järgi) korrektse ning kasuliku skoobiga tarkvara kasutuslugu (use case)? Ainult üks vastusevariantidest vastab korrektse kasutuslo...
..okei ma väga ei taju seda oot. Aaa okei. Slaidide näide - konverentsi külastaja ja korraldaja on osapooled, UC on ‘konverentsi külastamine (täisteenus), registreerumine,tellimine,maksmine ja artikli/ettekande saatmine. Nooltel on soovib, teeb, võimaldab Kontekstidiagramm - Slaidinäide - samad osapooled, UC konverentsi külastamise täisteenus ja sellega ühendatud klassid, kus on kvaliteedieesmärgid mis on seotud selle UC’ga Kvaliteedieesmärgid - Klassidiagramm kus on hunnik väärtuseid/omadussõnu Funktsionaalsed eesmärgid - UC diagramm mille keskmes on see põhiline usecase ja on toodud include/extend seostega mini-UC’d Visuaalne sõnastik - Klassidiagramm millel on põhimõisted seostega. Põhiprotsessi lihtsustatud töövoog - action diagramm, see kus on need swimline’id mis näitavad kuidas üks transaktsioon peaks toimuma erinevate osapooltega.Tegevusdiagramm on vist see nimi :D THE END, sa oled väga tubli, loodan, et omandasid ka midagi
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 Klass kirjeldab objekti tüüpi. Kirjeldab ühe objektitüübi omadusi ning käitumist. Moodustub ühesuguste omaduste ja käitumisega objektid. Objekt on konkreetse klassi liige e eksemplar. Zachmani raamistikus paiknevad objektid esimeses veerus (mis). Nende kirjeldamiseks sobib kõige paremini klassidiagramm ja objektidiagramm. Nt Klassi „Kinnisvara“ objektideks võivad olla majad ja korterid Analood – Muutuja seos tüübiga (programmeerimiskeeles) 3. Mis aastal ja kelle poolt leiutati Zachmani raamistik (dis aint important) John Zachman, 1980ndatel IBM-is. 4. Kas Zachmani raamistik on mudel? Raamistiku read pigem on seotud mudelitega. (Vt iga rea kirjeldused) 5. Millisest kahest osast koosneb infosüsteem?
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 Abstraktsioonit Interaktsioonid Struktuur Käitumine ase Analüüs Kasutusjuhtude Kontekstidiagramm Eesmärgimudeli diagrammid, id, d, kasutusjuhtude klassidiagrammid tegevusdiagramm
M. Roost , TTÜ Informaatikainstituut, Loengukonspektid aines Süsteemianalüüs, 2014 o Kontseptuaalse süsteemianalüüsi aine (valdkonna, metoodika) arhitektuur (Zachmani pluss UP raamistiku eeskujul) o Ainetöö (projekti) ülesande käsitlemine selles raamistikus Valdkonna visiooni esitamiseks kasutatavad mudelid ja notatsioonid o Aine deklareerimise (teenuse) näide: eesmärkmudel o Kontseptuaalne klassidiagramm (visuaalne ärisõnastik) o Kontekstidiagrammid o Äriprotsessi töövoo kirjeldamine (UML, BPMN) o M. Roost , TTÜ Informaatikainstituut, Loengukonspektid aines Süsteemianalüüs, 2014 Süsteemianalüüs erinevates arendusmetoodikates Eelmises loengus rääkisime valdkonnapõhisest süsteemianalüüsist, mis toetub Zachmani arhitektuuriraamistikule ning katab selle kaks ülemist rida, millised kirjeldavad nn. „puhast valdkonda“
Nõuete analüüs Kasutusjuhtude mudel UC kirjeldused UC diagrammid Süsteemi jadadiagrammid Süsteemi operatsioonid/lepingud Mittefunktsionaalsed nõuded 8. Organisatsiooni struktuuride modelleerimine a) Ilmutatud kuju - iga `osa' tüüp modelleeritud eraldi klassina Võtta seda kui sugupuu tüüpi struktuuri. Kõige kõrgemal on nt firma, 1 firma alla kuulub mitu osakonda, 1 osakond koosneb mitmest isikust. Klassidiagramm, nool on valge otsaga, valge pool läheb kõrgema klassi poole. Cons - Ei tööta hästi, kui on palju ühist (struktuuri või käitumist) organisatsiooni/osade tüüpide vahel. Kannavad olemasolevaid organisatsioonilisi kategooriaid (tarkvara) disaini - kui otsustatakse lisada regioonid osakondade ja divisjonide vahele, on vaja muuta mudelit. b) Organisatsiooni hierarhia - probleemide lahenduseks on supertüübile Organisatsioon
Lepingud süsteemi operatsioonidele Lepingud aitavad defineerida süsteemi käitumist, kirjeldades operatsioonide mõju süsteemile (kuidas muutub süsteemi seisund iga operatsiooni täitumise tulemusena). UMLis saab seda teha operatsioonide eel- ja järeltingimuste defineerimise teel. Süsteemi operatsioonide lepingute loomine toimub detailimisfaas (elaboration) iteratsioonides, nõuete analüüsi distsipliinis, kasutusjuhu mudeli osana. Eelnevalt peavad olemas olema kontseptuaalne klassidiagramm (domeeni mudel), süsteemi jadadiagramm ning identifitseeritud süsteemi operatsioonid. Lepingu osad Operatsioon: Operatsiooni nimi ja parameetrid Viited (cross references): kasutusjuhud, milles antud operatsioon võib toimuda Eeltingimused: Olulised eeldused süsteemi või domeeni mudeli objektide seisundi kohta enne operatsiooni täitmist. Neid ei testita selle operatsiooni loogika sees, vaid eeldatakse, et need kehtivad
(relationship) Näide: http://www-106.ibm.com/developerworks/rational/library/769.html Mõisted kordamiseks 15 Sissejuhatus infosüsteemidesse IDU3530 © Karin Rava 65. KLASS Klass(class) on omavahel sarnaste omadustega ilmingute hulga kirjeldus. (ntx:tarkvarasüsteem-fail;programmid;ikoon;aken) Klassidiagramm (Class Diagram)kirjeldab süsteemi staatilise vaate klasside (class) ja nendevaheliste seostena (relationship). Klassi omadused klassil on nimi (ainsuses) ja see peab olema pärit probleemvaldkonnast klassil on atribuudid, mis objekte iseloomustavad ja omavad iga konkreetse ilmingu puhul konkreetseid väärtusi klassil on operatsioonid (funktsioonid), mis kirjeldavad, mida klassiga on
alusel). Kui kliendil on arve eest tasutud, saadab süsteem raamatupidajale vastava teate. Samuti saadab süsteem arve kullerile. 16 Nimi 3.10: Arve allkirjastamine Tegutsejad: Klient Kirjeldus: Kliendil tuleb arve allkirjastada elektroonselt kulleri i-padis. 17 4 Infosüsteemi andmevaade Järgnevalt esitatakse Fototellimuse kontseptuaalne klassidiagramm (konseptuaalmudel) ning andmemudel. 4.1 KONTSEPTUAALMUDEL Joonis 5. Konseptuaalne klassidiagramm 18 4.2 ANDMEMUDEL Organisatsiooni Fototellimus andmemudel on järgmine: Joonis 6. Andmemudel Muudatused võrreldes kontseptuaalmudeliga: On kadunud seos “klient suhtleb pildistamise korraldajaga“, sest selle kohta pole infosüsteemis vaja andmeid salvestada.
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
Lähenemine, kus peamise tähelepanu all on Objekt orienteeritud lähenemine infosüsteemiga seotud ärimaailma obejktid ja nendevaheline koostöö nimetakse Vastus 3 Lähenemine, kus peamise tähelepanu all Protsessile orienteeritud lähenemine andmeid töötlevad protsessid nimetakse Küsimus 8 UML toetab järgmised diagrammid Vali üks või enam: a. ERD b. Andmevoo diagramm c. Use-Case d. Klassidiagramm e. Activity Küsimus 9 Objekt – Orienteeritud lähenemise põhimõtted Vali üks või enam: a. Iga objektiga on seotud teadmised ja käitumine b. Protsessid ja objektid ei ole omavahel seotud c. Äriobjekt on reaalse maailma objekt d. Süsteem koosneb objektidest e. Iga objrekti saab modelleerida eraldi Küsimus 10 Objektide omavalelise koostöö teatud ajaperiooni jooksul saab näidata Vali üks: a. Class diagram b. Use Case diagran c. Sequence diagram d. Activity diagram Küsimus 11
TARKVARATEHNIKA KORDAMISKÜSIMUSED 1. Mis on tarkvaratehnika? Software engineering ! “Engineers Australia” definitsioon: Tarkvaratehnika on tiimide poolt rakendatav distsipliin tootmaks kõrgekvaliteedilist, suuremastaabilist ja hinnaefektiivset tarkvara mis rahuldab kasutajate nõudmisi ja mida saab hooldada teatud ajaperioodi vältel. IEEE definitsioon: Tarkvaratehnika on süstemaatilise, distsiplineeritud ja mõõdetava lähehemisviisi rakendamine tarkvara arendamisele, käitamisele ja hooldamisele, see tähendab, inseneriteaduste rakendamine tarkvarale. Tarkvaraarendus on nõrgem termin, kus tingimata ei kasutata protsesse, tööriistu, standardeid, jne. Tarkvaraarendus on progemine + konfigursatsiooni haldus. Tarkvaratehnika ei ole ainult programmi kirjutamine, vaid teemad hõlmavad ka kvaliteeti, ajakavasid, tasuvust ning põhimõtete ja korra tundmist ja rakendamist. Tar...
• Constraints • Essential use case models • Essential user interface prototypes • Persistence/data models • Technical requirements • UML activity diagrams • UML class models • UML collaboration diagrams • UML component diagrams • UML deployment diagrams • UML sequence diagrams • UML state chart diagrams • UML use case models • User interface flow diagrams • User interface prototypes UML põhidiagrammid : • Staatika diagrammid • Klassidiagramm • Use Case diagramm • Dünaamika diagrammid – Suhtlusdiagrammid • Jadadiagramm (sequence diagram) • Koostöödiagramm (collaboration diagram) – Elutsükli dikagrammid • Seisundidiagramm (state diagram) • Tegevusdiagramm (activity diagram) • Realisatsiooni diagrammid • Komponendidiagramm (component diagram) • Rakendusdiagramm (deployment diagram) UML Concepts • The UML may be used to:
annaabi.ee 
Sisene Facebook'ga
Sisene Google'ga
Sisene LinkedIn'ga
