Rational Unified Process

Teema esitlus: "Rational Unified Process"— Esitluse väljavõte:

1 Rational Unified Process
Tarkvara arendusprotsess (Software Engineering Process). RUP2

2 Vaatleme järgnevalt Põhiliste töövoogude kirjeldused
Nende käigus loodavad artefaktid Töövooga seotud töörollid ja nende vastutusalas olevad toimingud RUP2

3 Ärivajaduste modelleerimine
Iga projekti korral on tegelik lähtepunkt erinev. Alguseks võib olla: Äri- ehk tegevusmudeli loomine Mingi teise organisatsiooni poolt loodud ärimudel Kliendi poolt ette valmistatud kirjeldused/nägemus loodavast süsteemist Juhtkond tunnetab vajadust lahendada mingeid organisatsiooni ees seisvaid vajadusi IT vahenditega Töövoog sisaldab üldjuhul järgnevaid samme: Võimalike vajaduste nimekirja koostamine, nende hindamine (nende päritolu, tähtsuse, eeldatava maksumuse järgi) Süsteemi konteksti selgitamine süsteemi loojatele Süsteemi funktsionaalsete vajaduste selgitamine Süsteemi mittefunktsionaalsete vajaduste selgitamine Valdkonna mudel (Domain model) - Kirjeldab tegevusvaldkonda iseloomustavate olemite vahelisi staatilisi suhteid Äri- ehk tegevusmudel (Business model) – kirjeldab organisatsiooni tegevusprotsesse ja organisatsiooni töötajaid (business actors), kes nendes osalevad RUP2

4 Nõuete analüüs Eesmärk: Luua loodava süsteemi mudel, kirjeldus. Seda tehakse kasutuslugude baasil Artefaktid – vastutavad töörollid Kasutuslugude mudel (Use Case Model) – Süsteemianalüütik (System Analyst) Aktorid Kasutuslood koos sündmuste kulgemise kirjeldusetegas – sündmuste jada, mida võib koondada ühise nimetaja alla, mida saab koos vaadelda,disainida, luua, testida ja kirjeldada kasutajajuhendis. Erinõudmiste nimekiri iga kasutajaloo jaoks (näiteks nõuded süsteemi jõudlusele, turvalisusele, kasutajaliidese lihtsusele jne. ) Valdkonna sõnastik (Domain Glossary) – Süsteemianalüütik Luuakse äri- või valdkonnamudelis alusel. Abiks kasutuslugude kirjeldamisel. Kasutajaliidese prototüüp. – Kasutajaliidese disainer (User-Interface Designer) Arhitektuuri kirjeldus - Süsteemi arhitekt (Architect) RUP2

5 Nõuete analüüs Nõuete analüüsi töövoog on kirjeldatud toimingute ja neid teostavate töörollide abil RUP2

6 Nõuete analüüs Toimingul on konkreetne teostaja, lähteandmed (artefaktid) ja tulemus(ed). RUP2

7 Analüüs ja Disain Analüüs annab üldise ülevaate loodava süsteemi arhitektuurist. Kirjeldused ei pea olema arusaadavad lõppkasutajatele. Peab andma ülevaate loodava süsteemi sisemisest ülesehitusest Analüüsi artefaktid: Analüüsimudel. Koosneb analüüsiklassidest. Neid on kolme tüüpi: Liidesklassid (Boundary) – kirjeldab süsteemi ja tegutsejate vahelisi suhteid Olemklassid (Entity Class) – kirjeldab süsteemi andmeklasse Kontrollklassid (Control) – tegevuste juhtijad, koordinaatorid RUP2

8 Analüüs ja Disain Kasutuslugude realisatsioon - Analüüs (Use Case Realization – Analysis) – Analüüsimudeli klassid realiseerivad kasutuslugude mudelis kirjeldatud kasutajavajadusi. Seda tehakse klassi, järgnevus- ja koostöödiagrammide ja sündmusi kirjeldava teksti abil. Analüüsipaketid – Eelmiste artefaktide jaotus hallatavateks alamosadeks RUP2

9 Analüüs ja Disain Disaini eesmärgid:
Leida lahendused kõigile mittefunktsionaalsetele piirangutele, mis tulenevad kasutatavast programmeerimiskeskkonnast, op.süsteemist, komponentide kasutamisest, jne Luua ammendav stardiplatvorm süsteemi kodeerimiseks. Selleks peavad olema põhjalikult kirjeldatud iseseisvad alamsüsteemid, liidesed ja klassid Luua eeldused selleks, et teostamine kujuneks väiksemate alamülesannete lahendamiseks, mis paljudel juhtudel saab toimuda paralleelselt. Disaini artefaktid: Disaini mudel (Design model) – kirjeldab, kuidas kasutuslugude kirjelduste füüsiline realisatsioon antud vahenditega toimuma hakkab. Disainimudel kirjeldatakse järgenvate artefaktide abil Disainiklassid (Design Class) – Süsteemi loomise käigus kasutatavate klasside kirjeldused. Disainiklassi meetodite, atribuutide, tüüpide kirjeldamisel kasutatakse valitud arendusvahendi süntaksi. Kasutatakse stereotüüppe, mis on vaste arendusvahendi mingile klassitüübile. Näiteks: Visual Basicu korral <<form>>, <<user control>> jne RUP2

10 Analüüs ja Disain Kasutuslugude realisatsioon – Disain (Use Case Realization – Design) – Konkreetsete kasutuslugude realiseerimise kirjeldused. Kirjeldamisel kasutatakse disainiklasse, UML-i suhtlusdiagramme, tekstilisi sündmuste kulgemise kirjeldusi, kasutuslugudega kaasnevate mittefunkt-sionaalsete vajaduste lahenduste kirjeldusi Disaini alamsüsteemid ehk moodulid (Design subsystems)– Disaini artefaktide jaotus hallatavateks alamüksusteks. Liidesed (Interface) – Liideste kirjeldused, mille abil klassid ja alamsüsteemid omavahel suhtelvad. Arhitektuuri kirjeldus (Architecture Description) Juurutusmudel (Deployment Model) – Kirjeldab, kuidas süsteemi funktsionaalsed osad jagunevad erinevate arvutite vahel. RUP2

11 Disain - Töövoog RUP2

12 Teostus Teostuse eesmärk on realiseerida eelenvatel etappidel kirjeldatud süsteemi arhitektuur. Täpsemalt: Planeerida tüsklid ja nende tulemused Planeerida vastavalt juurutusmudelile erinevates arvutites töötavad komponendid Kodeerida disainiklassid ja –alamsüsteemid Klasside ja alamsüsteemide testimine enne kui need lisatakse süsteemi kui terviku testimisse RUP2

13 Teostus Artefaktid Teostuse mudel (Implementation model)
Komponent (Component) – Mõned komponentide stereotüübid: programm, fail, teek, andmetabel, dokument Alamsüsteem Liides Arhitektuuri kirjeldus – Teostus – Dekompositsioon alamsüsteemideks,võtmekompo- nendid, jne Arendusplaan (Build Plan) RUP2

14 Teostus RUP2

15 Testimine Eesmärk : Tulemuste kontroll iga iteratsiooni lõpetamisel
iga iteratsiooni testide planeerimine Testistsenaariumite disainimine ja koostamine Testide läbiviimine Artefaktid Testistsenaariumid Testiprotseduuride kirjeldused – kuidas testistsenaariumeid läbi viia RUP2

16 Arendusmetoodika Select Perspective
RUP2

17 Arendusmetoodika Select Perspective
RUP2

18 Arendusmetoodika Select Perspective
RUP2