Ühtne protsess– see on tarkvara loomise protsessi üldistatud raamistik, mis võib olla on spetsialiseerunud paljudele tarkvarasüsteemidele. Ühtne protsess kasutab ühtset modelleerimiskeelt tarkvarasüsteemi mudeli väljatöötamiseks.

hakake ründama peamisi riske, tehke seda pidevalt, muidu ründavad riskid teid.

tagage kliendi nõuete täitmine: dokumenteerige nõuded kliendile arusaadaval viisil ning järgige neid nõudeid projekteerimisel ja rakendamisel rangelt

keskenduge käivitatavale programmile: töötav tarkvaratoode, mis läbib teste paremini kui kõikehõlmav dokumentatsioon

kohaneda muutustega juba projekti algusest peale: kaasaegsed rakendused on piisavalt keerulised, et saaksime spetsiifilisi nõudeid esitada juba arenduse alguses. Seetõttu on vaja tarkvara arhitektuur kujundada selliselt, et see oleks vastuvõtlik muutumisele.

panna käivitatavale arhitektuurile alus võimalikult varakult. Käivitatav arhitektuur – peamised kasutusjuhud. VI võti on süsteemi funktsionaalsus, ilma milleta pole tarkvaral mõtet. Võti. VI-d moodustavad 7-10% kõigist valikutest

ehitada komponentidest süsteem. Komponendipõhised rakendused on ehitatud kiiremini, on muudatuste osas paindlikumad ja suhteliselt madalad.

töötada 1 meeskonnana

muuta kvaliteet eluviisiks, mitte järelmõtlemiseks

6 Ühtse protsessi elutsükkel. Iga etapi eesmärgid.

Ühtset protsessi korratakse tsükliliselt. See ühtse protsessi iteratsioonide jada esindab süsteemi elutsüklit. Iga tsükkel lõpeb toote väljalaskega klientidele.

Iga tsükkel koosneb neljast etapist – nõuete analüüs ja planeerimine, projekteerimine, ehitamine ja teostus. Iga faas, nagu allpool kirjeldatud, on jaotatud edasi iteratsioonideks.

ajal analüüsi ja planeerimise etapid nõuded hea mõte muutub valmistoote kontseptsiooniks ja koostatakse äriplaan selle toote arendamiseks. Eelkõige tuleks selles etapis vastata järgmistele küsimustele:

Mida peaks süsteem esmalt oma peamiste kasutajate jaoks tegema?

Milline peaks välja nägema süsteemi arhitektuur?

Mis on plaan ja kui palju toote arendamine maksma läheb?

Selles etapis luuakse arhitektuuri prooviversioon. Tavaliselt on see ülevaade, mis sisaldab kõige olulisemaid alamsüsteeme. Selles etapis tehakse kindlaks ja seatakse prioriteediks kõige olulisemad riskid, kavandatakse üksikasjalikult projekteerimisfaas ning hinnatakse ligikaudselt kogu projekt.

ajal projekteerimise etapid enamik kasutusjuhtumeid on üksikasjalikult kirjeldatud ja süsteemi arhitektuur on välja töötatud.

Projekteerimisfaasi lõpus tegeleb projektijuht tegevuste planeerimisega ja projekti lõpuleviimiseks vajalike ressursside arvutamisega. Siinkohal on võtmeküsimus: kas kasutusjuhud, arhitektuur ja disain on piisavalt küpsed ning kas riskid on piisavalt kontrolli all, et õigustada lepingulist kohustust arendustöö lõpule viia?

ajal ehitusfaasid luuakse toode - luustikule (arhitektuurile) lisatakse lihased (lõpetatud programmid). Selles faasis kasvab arhitektuuri põhitase terviklikuks küpseks süsteemiks. Kontseptsioonid töötatakse välja tooteks, mis on valmis kasutajatele üle andma. Etapi jooksul suureneb vajalike ressursside hulk. Selle etapi lõpus sisaldab toode kõiki kasutusjuhtumeid, mille juhtkond ja klient nõustusid praegusesse väljalaskesse lisama. Tõsi, need võivad sisaldada vigu. Enamik defekte avastatakse ja parandatakse rakendamisetapis. Etapi lõpu põhiküsimus on järgmine: kas toode vastab kasutaja nõudmistele niivõrd, et mõnele kliendile saab ette tarnida?

Rakendusfaas hõlmab perioodi, mille jooksul toode eksisteerib beetaversiooni või beetaversioonina. Väike arv kvalifitseeritud kasutajaid, kes töötavad toote beetaversiooniga, teatavad defektidest ja puudustest. Seejärel parandavad arendajad leitud vead ja lisavad mõned soovitatud täiustused suurele väljalasele, mis on valmis laialdaseks levitamiseks. Rakendusfaas hõlmab selliseid tegevusi nagu koopiate valmistamine, klienditöötajate koolitamine, vihjeliini toe korraldamine ja pärast tarnimist avastatud defektide parandamine.

Rational Unified Process (RUP) on üks parimaid arendusmetoodikaid tarkvara, mille on loonud Rational Software. Tuginedes paljude edukate tarkvaraprojektide kogemusele, võimaldab Unified Process luua keerukaid tarkvarasüsteeme, mis põhinevad tööstuslikul arendusmeetodil. Üks peamisi tugisambaid, millele RUP tugineb, on mudelite loomise protsess UML (Unified Modeling Language) abil. See artikkel räägib UML-diagrammide kasutamisest tarkvarasüsteemide arendamise töövoos, kasutades Rational Software metoodikat.

Pole saladus, et tarkvara loomine on keeruline protsess, millel on ühest küljest palju ühist loovusega, ja teisest küljest, kuigi see on väga tulus, on see ka kõrge kuluga äri. Tugev konkurents turul sunnib arendajaid rohkem otsima tõhusad meetodid tööd. Võimalusi tarkvarasüsteemide loomiseks veelgi enam lühike aeg, väiksemate kuludega ja parim kvaliteet. Programmide keerukus kasvab pidevalt. Kuni viimase ajani said tarkvaratooteid ettenähtava aja jooksul luua üksikisikud või näiteks automatiseeritud ettevõtte IT-osakonnas.

Tänapäeval on inimestele, kes loovad programme põlvili, jäetud väikeste utiliitide ja erinevate laiendusmoodulite ala "raskete" tarkvaratoodete jaoks. Tulevik kuulub tarkvara loomise tööstuslikule lähenemisele. 1913. aastal käivitas Henry Ford esimese autode koosteliini ja 90ndatel hakati sarnast koosteliini kasutama IT-tehnoloogiate valdkonnas. Meeskonna arendamine nõuab hoopis teistsugust lähenemist ja teistsugust metoodikat, mis varem või hiljem tuli luua.

Rational Software Corporation (http://www.rational.com) on välja andnud struktureeritud teadmistebaasi nimega Rational Unified Process (RUP), mis sisaldab põhjalikke soovitusi peaaegu iga tarkvaratoote loomiseks. Parimate arenduste kogemuse ammutanud RUP räägib üksikasjalikult, millal, kes ja mida peaks projektis tegema, et tulemust saada tarkvarasüsteem kindlaksmääratud tähtaegadega, teatud funktsionaalsusega ja eraldatud eelarve piires.

Ühtset protsessi saab esitada summana erinevat tüüpi arendusettevõtte tegevus, mis on vajalik kliendi nõuete tõlkimiseks tarkvarasüsteemi. Süsteem, mis annaks kasutajatele "tähenduslikke tulemusi" ja teeks täpselt seda, mida nad süsteemilt ootavad. Seetõttu juhivad protsessi süsteemi kasutusjuhtumid või muidu pretsedendid.

Kliendi nõuete õigeaegseks rakendamiseks on ühtne protsess jagatud faasideks, mis koosnevad iteratsioonidest, mistõttu protsessi nimetatakse ka iteratiivseks ja inkrementaalseks. Iga iteratsioon läbib põhitöö tsükli ja viib arendajad lõppeesmärgini: tarkvarasüsteemi loomiseni. Iteratsioonide käigus luuakse vahepealsed artefaktid, mis on vajalikud projekti edukaks lõpuleviimiseks ja tarkvarasüsteemi versioon, mis realiseerib teatud funktsioonide komplekti, mis iteratsioonist iteratsioonini suureneb. Protsessi etapid ja peamised töövood on näidatud joonisel fig. 1 on seal toodud ka tööde orienteeruvad tööjõukulud faaside kaupa.

riis. 1 RUP faasid ja töövood

Tuleb märkida, et joonisel fig. 1 näitab ainult ühtse protsessi põhitööd. Näiteks ei kuvata siin tegevuste juhtimise tegevusi, et vältida diagrammi segadust.

Kogu tarkvaraarendust käsitletakse RUP-is artefaktide loomise protsessina. Projekti mis tahes tulemus, olgu selleks siis lähtetekstid, objektimoodulid, kasutajale edastatud dokumendid, mudelid – need on kõigi projekti artefaktide alamklassid. Iga projektimeeskonna liige loob ise oma artefakte ja vastutab nende eest. Programmeerija koostab programmi, juht projektiplaani ja analüütik süsteemimudeli. RUP võimaldab teil määrata, millal, kes ja millist artefakti tuleb luua, muuta või kasutada.

Üks huvitavamaid projektiartefaktide klasse on mudelid, mis võimaldavad arendajatel tarkvarasüsteemi artefakte määratleda, visualiseerida, konstrueerida ja dokumenteerida. Iga mudel kujutab endast eraldiseisvat vaadet arendatavale süsteemile ja on mõeldud nii probleemide visandamiseks kui ka lahenduste väljapakkumiseks. Mudelite iseseisvus tähendab seda, et analüütik või arendaja saab kogu vajaliku informatsiooni konkreetsest mudelist ilma muude allikate poole pöördumata.

Mudelid võimaldavad teil mõelda tulevasele süsteemile, selle objektidele ja nende koostoimele juba enne märkimisväärsete rahaliste vahendite investeerimist arendusse; need võimaldavad teil näha seda tulevaste kasutajate silmade läbi väljastpoolt ja arendajate silmadega seestpoolt, isegi enne esimest allika rida kood luuakse. Enamik mudeleid on esindatud UML-diagrammidega, UML-i kohta saate rohkem lugeda näiteks aadressilt.

Ühtne modelleerimiskeel ilmus 80ndate lõpus ja 90ndate alguses, peamiselt tänu "kolme sõbra" Gradi Bucha, Jim Rambo ja Ivar Jacobsoni pingutustele. Nüüd on OMG konsortsium selle kasutusele võtnud standardse modelleerimiskeelena, mis pakub arendajatele selget märge, mis võimaldab kuvada mudeleid graafilistes elementides, mis on üldiselt aktsepteeritud ja kõigile projektis osalejatele arusaadavad.

Siiski ei tasu unustada, et modelleerimiskeel pakub ainult tähistust – süsteemi kirjeldamise ja modelleerimise vahendit ning ühtne protsess määrab selle tööriista kasutamise metoodika, aga ka teised Rationali metoodikat toetavad tööriistad. UML-i saab kasutada ilma kindla metoodikata, kuna see on protsessist sõltumatu ja olenemata sellest, millist protsessi valikut kasutatakse, saate diagrammide abil dokumenteerida arenduse käigus tehtud otsuseid ja kuvada loodud mudeleid.

Tarkvarasüsteem luuakse konkreetsete kasutajaprobleemide lahendamiseks, mitte programmeerijatele, kes testivad uusi tehnoloogiaid ja omandavad kogemusi projektijuhile. Üldjoontes ei huvita kasutajat, kas kasutate arendusprotsessis objektorienteeritud lähenemist, UML-i, RUP-i või loote süsteemi XP (äärmuslik programmeerimine) meetodil. Teatud meetodite, tehnoloogiate kasutamine ja projekti optimaalse sisemise struktuuri loomine jääb arendajate südametunnistusele, kes langetavad otsuseid varasemast kogemusest ja oma eelistustest lähtuvalt. Siiski ei andesta kasutaja teile tema nõuete eiramist. Isegi kui tarkvarasüsteemi arendatakse ultramoodsate meetodite ja tehnoloogiate abil vähemalt kümme korda, kui kasutaja ei saa sellest nn "tähenduslikku tulemust", siis teie tarkvara projekt kukub haledalt läbi.

Siit järeldub, et UML-i mõtlematu rakendamine pelgalt moes olemise tõttu mitte ainult ei vii arengut eduni, vaid võib tekitada rahulolematust töötajates, kellel on vaja palju lisakirjandust uurida, ja projektijuhtides, kui selgub, et projekti tööjõukulud suurenevad ja tulu ei suurene. Peate selgelt mõistma, mida soovite selle tehnoloogia rakendamisega saada, ja järgima seda eesmärki. UML-i kasutamine säästab arendusressursse, sest võimaldab süsteemist kiiremini aimu saada kui makettide ja prototüüpide loomisel, kulutades võrreldamatult vähem ressursse.

Diagrammid hõlbustavad projektiliikmetel omavahelist suhtlemist ja, mis on eriti väärtuslik, kaasavad protsessi lõppkasutajaid. Modelleerimine võimaldab teil projekti riske vähendada, kuna programmeerijatel on alati lihtsam teha seda, mis on selge ja arusaadav, kui minna ebakindla tulemuseni. Diagrammide koostamine sarnaneb projekti loomisega ehituses - saate ilma selleta hakkama näiteks suvilale kuuri ehitamisel, kuid mida suurem on hoone (meie puhul tarkvaratoode), seda keerulisem on see teha ja seda ebakindlam on lõpptulemus.

Õpetasin kunagi RUP-teemalist seminari ühes tarkvarafirmas, mis oli kümme aastat turul üsna edukas olnud, kuid ei kasutanud oma töövoos üldse modelleerimist, vaid põhines prototüüpidel. Saali kogunes paarkümmend noort ja kogenud programmeerijat, kes kuulasid hoolega kõike, mida ma neile RUP-i ja UML-i kohta rääkisin. Ja üks neist, vaadates näidisskeemidega kaetud tahvlit, märkis: "See kõik on huvitav ja ilmselt sobib ka teistele projektidele," ütles ta, "aga me oleme ilma selle kõigeta töötanud üsna pikka aega, kuna oleme ikkagi saime ilma UML-ita hakkama, ilmselt pole meil seda vaja.

See küsimus pani mind mõtlema, et äriprotsesside muutus, mis tarkvaraarendusettevõttes RUP-i ja UML-i juurutamisel paratamatult toimuma peab, võib olla sama raske kui infosüsteemi juurutamine tööstusettevõttes.Igasugune juurutamine on stereotüüpide murdmine. Kuna tarkvaraarendusettevõtte töötajate kvalifikatsioon on üsna kõrge, on sellistel inimestel raskem oma seisukohtadest loobuda kui "lihtsurelikel" ning tekkivaid raskusi ja tagasilükkamist võib võrrelda üleminekuga protseduuriliselt objektilt. orienteeritud mõtlemine.

1.Nõuete määratlemine

Ühtne protsess on protsess, mida juhivad kasutusjuhtumid, mis kajastavad kasutaja interaktsiooni stsenaariume. Tegelikult on see kasutajate vaade tarkvarasüsteemile väljastpoolt. Seega saab RUP-i hinnangul üheks olulisemaks arendusetapiks nõuete määramise etapp, mis seisneb kõigi võimalike süsteemi toimimise soovide kogumises, mis võivad vaid kasutajatele ja analüütikutele pähe tulla. Hiljem tuleb need andmed süstematiseerida ja struktureerida, kuid praeguses etapis peavad analüütikud kasutajatega küsitledes ja dokumente uurides koguma tulevasele süsteemile võimalikult palju nõudeid, mis polegi nii lihtne, kui esmapilgul tundub. Kasutajatel pole sageli aimugi, mida nad lõpuks saama peaksid. Selle protsessi hõlbustamiseks kasutavad analüütikud kasutusjuhtude diagramme (joonis 2).

Joonis 2. Kasutusjuhtumi diagrammi näide

Diagramm peegeldab osalejaid (aktante), kes süsteemiga suhtlevad, ja tarkvaraobjektide reaktsiooni nende tegevusele. Tegutsejad võivad olla nii kasutajad kui ka välisagendid, kes peavad infot edastama või vastu võtma. Kasutusjuhtumi ikoon peegeldab süsteemi reaktsiooni välisele sisendile ja näitab, mida tuleb aktandi heaks teha.

Konkreetse kasutusjuhu täpsustamiseks kasutatakse tegevusskeemi, mille näide on toodud joonisel 3.

riis. 3 Tegevusdiagrammi näide

Kasutusjuhtumite diagrammi lihtsus võimaldab analüütikutel nõuete määratlemise protsessi ajal klientidega hõlpsasti suhelda, tuvastades süsteemile ja individuaalsete nõuete rakendamisele seatud piirangud, nagu süsteemi reageerimisaeg, mis hiljem langevad mittefunktsionaalsete osasse. nõuded.

Kasutusjuhtumi diagrammi saab kasutada ka katsestsenaariumide loomiseks, kuna kõik kasutajate ja süsteemi vahelised suhtlused on juba määratletud.

Nõuete õigeks kindlaksmääramiseks peavad arendajad mõistma konteksti (osa ainevaldkonnast), milles tulevane süsteem töötab. Selleks luuakse domeenimudel ja ärimudel, mis on erinevad lähenemised samale probleemile. Sageli luuakse üks asi: domeenimudel või ärimudel.

Nende mudelite erinevus seisneb selles, et domeenimudel kirjeldab olulisi mõisteid, millega süsteem töötab, ja nende omavahelisi seoseid. Kusjuures ärimudel kirjeldab äriprotsesse (olemasolevaid või tulevasi), mida süsteem peaks toetama. Seetõttu määratleb see mudel lisaks protsessi kaasatud äriobjektide määratlemisele töötajad, nende kohustused ja toimingud, mida nad peavad tegema.

Domeenimudeli koostamiseks kasutatakse tavalist klassidiagrammi (joonis 6), kuid ärimudeli koostamiseks sellest selgelt ei piisa. Sel juhul kasutatakse kasutusjuhtude diagrammi, kasutades täiendavaid ikoone, mis kajastavad äriprotsesside olemust – need on äriaktant, ärikasutusjuht, äriüksus ja ärijuhtimine. See mudel on palju lähemal järgmisele arendusprotsessis loodud mudelile – analüüsimudelile.

2.Analüüs

Pärast nõuete ja süsteemi toimimise konteksti kindlaksmääramist on aeg analüüsida saadud andmeid. Analüüsiprotsessi käigus luuakse analüütiline mudel, mis juhatab arendajad tulevase süsteemi arhitektuuri juurde. Analüütiline mudel on vaade süsteemile seestpoolt, erinevalt kasutusjuhtumi mudelist, mis näitab, kuidas süsteem väljastpoolt välja näeb.

See mudel võimaldab teil mõista, kuidas süsteem peaks olema kavandatud, millised klassid sellel peaksid olema ja kuidas need peaksid üksteisega suhtlema. Selle põhieesmärk on määrata kindlaks nõuete kogumise etapis tuvastatud funktsionaalsuse rakendamise suund ja visandada süsteemi arhitektuur.

Erinevalt hiljem loodavast disainimudelist on analüüsimudel pigem kontseptuaalne mudel ja toob arendajaid juurutusklassidele vaid lähemale. Sellel mudelil ei tohiks olla võimalikke vastuolusid, mis võivad esineda pretsedendimudelis.

Analüüsimudeli kuvamiseks UML-i abil kasutatakse klassidiagrammi stereotüüpidega (käitumismustritega) “piirklass”, “üksus”, “kontroll” ning detailiseerimiseks kasutatakse koostööskeeme (joonis 4). "Piiriklassi" stereotüüp kujutab klassi, mis suhtleb väliste aktantidega, "olemi" stereotüüp kujutab klasse, mis on andmehoidlad, ja "kontroll" stereotüüp kujutab klasse, mis haldavad olemitele päringuid.

Joonis 4. Koostööskeemi näide

Sõnumite nummerdamine näitab nende järjekorda, kuid diagrammi eesmärk ei ole mitte arvestada vahetatavate sõnumite järjekorda, vaid selgelt näidata klasside omavahelisi seoseid.

Kui keskenduda interaktsiooni järjekorrale, siis teiseks esituseks oleks järjestusskeem (Sequence), mis on näidatud joonisel 5. See diagramm võimaldab vaadelda sõnumite vahetamist ajas, kuvades visuaalselt protsessi jada. Kui kasutate mudeli loomise tööriista nagu Rational Rose, saab neid kahte tüüpi diagramme üksteisest automaatselt luua (Rational Rose'i kohta saate näiteks lugeda lähemalt).

Riis. 5 Jada diagrammi näide

Otsus, kumb kahest diagrammist esimesena luua, sõltub konkreetse arendaja eelistustest. Kuna need diagrammid kujutavad endast sama protsessi, võimaldavad need mõlemad kajastada objektide vahelist koostoimet.

3.Disain

Süsteemi loomise protsessi järgmine etapp on projekteerimine, mille käigus luuakse varem loodud mudelite põhjal disainimudel. See mudel kajastab süsteemi füüsilist teostust ja kirjeldab loodud toodet klassi ja komponendi tasemel. Erinevalt analüüsimudelist on disainimudelil selge sõltuvus rakendustingimustest, programmeerimiskeeltest ja kasutatud komponentidest. Süsteemi arhitektuuri võimalikult täpseks mõistmiseks peaks see mudel olema võimalikult formaliseeritud ja ajakohastatud kogu süsteemi arenduse elutsükli vältel.

Disainimudeli koostamiseks kasutatakse tervet komplekti UML diagramme: klassiskeeme (joon. 5), koostöödiagramme, interaktsiooniskeeme, tegevusskeeme.

Joonis 6. Klassiskeemi näide

Lisaks saab selle töövooga luua juurutusmudeli, mida rakendatakse juurutusskeemi alusel. See on lihtsaim diagrammitüüp, mis on loodud seadmete võrgus levitamise modelleerimiseks. Kuvamiseks kasutatakse protsessori ja seadme ikoonide jaoks ainult kahte valikut ning nendevahelisi ühendusi.

4.Rakendamine

Rakendusprotsessi peamine ülesanne on luua süsteem komponentide kujul - lähtetekstid programmid, skriptid, binaarfailid, käivitatavad failid jne. Selles etapis luuakse rakendusmudel, mis kirjeldab, kuidas kujundusmudeli elemente realiseeritakse, millised klassid konkreetsetesse komponentidesse kaasatakse. See mudel kirjeldab nende komponentide organiseerimise viisi vastavalt valitud programmeerimiskeskkonnas kasutusele võetud struktureerimis- ja modulariseerimismehhanismidele ning on kujutatud komponentide diagrammil (joonis 7).

riis. 7 Näidiskomponentide diagramm

5.Testimine

Testimisprotsessi käigus kontrollitakse juurutamise tulemusi. Selle protsessi jaoks luuakse testimismudel, mis koosneb testjuhtumitest, testimisprotseduuridest, testikomponentidest, kuid millel puudub UML diagrammi esitus, seega me sellel pikemalt ei peatu.

6.Järeldus

Siin käsitleti ainult ratsionaalse metoodika põhiprotsesse. RUP on üsna mahukas ja sisaldab soovitusi erinevate tarkvaraprojektide käitamiseks, alates programmide loomisest mitmest inimesest koosneva arendajate rühma poolt kuni hajutatud tarkvaraprojektideni, mis ühendavad tuhandeid inimesi erinevatel kontinentidel. Kuid vaatamata nende tohututele erinevustele on UML-i abil loodud mudelite kasutamise meetodid samad. Erinevatel arendusetappidel loodud UML-diagrammid on tarkvaraprojekti ülejäänud artefaktidest lahutamatud ja on sageli lüliks üksikute RUP-protsesside vahel.

Konkreetsete diagrammide kasutamise otsus sõltub ettevõttes üles seatud arendusprotsessist, mis, kuigi nimetatakse ühtseks, ei ole midagi tardunud. Rational pakub mitte ainult selle täiustamist ja viimistlemist, vaid pakub ka spetsiaalseid tööriistu RUP-i andmebaasis muudatuste tegemiseks.

Kuid igal juhul võimaldab UML-i kasutamine koos ühtse protsessiga saavutada prognoositava tulemuse, täita ettenähtud eelarve, tõsta projektis osalejate mõju ja loodud tarkvaratoote kvaliteeti.

Kratchen. F. Sissejuhatus Ratsionaalne ühtne protsess . Ed. 2. - M.: Williams Publishing House, 2002. - 240 lk.: ill.

Jacobson A., Buch G., Rambo J. Ühtne tarkvaraarenduse protsess - Peterburi: Peter, 2002. - 496 lk.: ill.

Fowler M., Scott K. UML lühidalt. Standardse objektide modelleerimiskeele rakendamine: Transl. inglise keelest – M.:Mir, 1999. – 191 lk, ill.

Beck. E. Ekstreemne programmeerimine. – Peterburi: Peeter, 2002. – 224 lk.: ill.

TrofimovS. CASE tehnoloogiad: Praktiline töö raamatus Rational Rose.
Ed. 2. - M.: Binom-Press, 2002 - 288 lk.

Ühtne protsess poolt välja töötatud Rational (Rational Unified Process, RUP) on erinevate tegevuste summa, mis on vajalik kasutaja nõuete muutmiseks tarkvarasüsteemiks. Selle abstraktne ja üksikasjalik esitus on näidatud joonisel fig. 7.2.

RUP-i peamised mõisted on artefakt ja pretsedent. Artefaktid- need on mõned projekti tooted, mis on loodud või kasutatud finaali kallal töötades tarkvaratoode. Pretsedendid või kasutusjuhtumeid(kasutusjuhtum) ‑ Need on tegevuste jadad, mida tarkvarasüsteem jälgitava tulemuse saamiseks teostab.

Kogu tarkvarasüsteemi arendamise protsessi käsitletakse RUP-is kui artefakti loomise protsess. Veelgi enam, see, mis satub lõppkasutaja kätte, olgu selleks tarkvaramoodul või tarkvaradokumentatsioon, on üks kõigi projektiartefaktide alamklasse.

Iga projektimeeskonna liige loob ise oma artefakte ja vastutab nende eest. Programmeerija töötab välja programmi, juht töötab välja projektiplaani ja analüütik töötab välja süsteemimudeli. RUP võimaldab teil määrata, millal, kelle poolt ja millist artefakti tuleb luua.

(A)

Riis. 7.2.Ühtne tarkvara arendusprotsess ( A- abstraktne esitus, b– põhiliste RUP-protsesside üksikasjalik esitus)

RUP on aga rohkem kui üks protsess; see on üldistatud protsessiraamistik, mida saab spetsialiseerida paljudele tarkvarasüsteemidele, rakendusvaldkondadele, oskuste tasemetele ja projekti suurustele. RUP - komponentidele orienteeritud. See tähendab, et loodav tarkvarasüsteem on üles ehitatud täpselt määratletud liidestega ühendatud tarkvarakomponentide baasil.

Tarkvarasüsteemi graafiliste esituste (mudelite) väljatöötamiseks kasutab RUP Ühtne modelleerimiskeel(UML) . Tegelikult on UML RUP-i lahutamatu osa – need töötati välja koos.

RUP-protsessi tõeliselt spetsiifilised aspektid seisnevad aga kolmes fraasis - kasutusjuhtumiga juhitud, arhitektuurile orienteeritud, iteratiivne ja inkrementaalne. See teebki ühtse protsessi ainulaadseks.

Tarkvarasüsteemi täielik esitus RUP-is sisaldab üheksat mudelit, mis koos hõlmavad kõiki kriitilisi otsuseid seoses tarkvarasüsteemi visualiseerimise, spetsifikatsiooni, disaini ja dokumenteerimisega (joonis 7.3):

1. äriprotsessi mudel, mis vormistab organisatsiooni abstraktsiooni (koos kõigi juhtimissüsteemi kasutamise võimalustega ja nende seostega kasutajatega);

2. kasutusjuhtumi mudel- vormistab funktsionaalsed nõuded süsteemile;

3. domeeni mudel või ärimudel, mis kirjeldab süsteemi konteksti.

4. analüüsimudel, millel on kaks eesmärki – selgitada kasutusjuhtude üksikasju ja luua süsteemi käitumise esmane jaotus objektide komplekti vahel, mis pakuvad erinevaid valikuid käitumine;

5. protsessi mudel(valikuline) - formaliseerib paralleelsuse ja sünkroniseerimise mehhanismid süsteemis;

6. disaini mudel, mis määratleb: ( A) – süsteemi staatiline struktuur, nagu alamsüsteemid, klassid ja liidesed, ja ( b) - vormil realiseeritud kasutusjuhud koostööd alamsüsteemide, klasside ja liideste vahel;

7. rakendusmudel, mis sisaldab komponente (esindatud lähtekoodiga) ja klasside paigutust komponentide lõikes;

8. kasutuselevõtu mudel, mis määratleb füüsilised arvutid – võrgusõlmed ja komponentide paigutuse nendes sõlmedes;

9. testimise mudel, mis kirjeldab testjuhtumeid kasutusjuhtude kinnitamiseks;

Riis. 7.3. RUP mudelid (vastavate UML diagrammide kujul)
ja nende seosed,

Kõik need mudelid on ühendatud. Koos kirjeldavad nad täielikult tarkvarasüsteemi. Ühe mudeli elementidel on päri- ja tagasijälgimise sõltuvused, mis on organiseeritud ühenduste kaudu teiste mudelitega (vt joonis 7.3). Näiteks kasutusjuhtumi (kasutusjuhtumi mudelis) saab jälgida vastava kasutusjuhtumi teostuseni (disainimudelis) ja testjuhtumini (testmudelis). Jälgimine muudab mõistmise ja muudatuste tegemise lihtsamaks. RUP-i arendusprotsessi käigus loodud UML-diagrammid annavad tarkvaratootest tervikliku pildi).

RUP-is ei ole põhirõhk mitte dokumentide kui sellisel vormistamisel, vaid sellel modelleerimine arendatav süsteem. Mudelid aitavad visandada nii probleemi kui ka selle lahendamise viise ning nende loomisel kasutatakse UML-i keelt, millest on pikka aega saanud keerukate süsteemide kirjeldamise de facto standard ja mis võimaldab arendajatel määratleda, visualiseerida, konstrueerida ja dokumenteerida mis tahes tarkvarasüsteemide artefakte. keerukus.

Unified Process (UP) on üldistatud protsess raami protsess, mida saab spetsialiseeruda paljudele tarkvarasüsteemidele, erinevatele rakendusvaldkondadele, oskuste tasemetele ja projekti suurustele.

Ühtne protsess komponendile orienteeritud. See tähendab, et loodud tarkvarasüsteem on üles ehitatud tarkvara baasil komponendid, ühendatud hästi määratletud liidestega.

UP spetsiifilised aspektid seisnevad selle kolmes omaduses:

● juhitud kasutusjuhtudest;

● on arhitektuurile orienteeritud;

● on iteratiivne ja inkrementaalne .

Ühtne protsessi elutsükkel

UP elutsükkel on jaotatud tsükliteks, millest igaüks kulmineerub toote vabastamisega. Iga arendustsükkel koosneb neljast etapist – nõuete analüüs ja planeerimine, projekteerimine, ehitamine, teostus. Iga faas on jagatud iteratsioonideks.

UP sisaldab kaheksat töövoogu: viis peamist- nõuete määratlemine, analüüs, projekteerimine, juurutamine, testimine ja kolm abi (peamiste toetamiseks) - nõuete konfigureerimine ja muudatuste juhtimine, projektijuhtimine, keskkonnajuhtimine.

Töövoo struktuuri määratlemiseks peate esmalt kindlaks määrama, mis esinejate tüübid protsessis osaleda. Siis otsustati artefaktid, mille peavad looma igat tüüpi töötajad antud töövoo käigus.

18. XP on protsess.

Ekstreemne programmeerimine(inglise keeles: Extreme Programming, XP) on üks paindlikke tarkvaraarenduse metoodikaid. Metoodika autorid on Kent Beck, Ward Cunningham, Martin Fowler jt.

Ekstreemse programmeerimise kaksteist põhitehnikat (vastavalt raamatu Extreme programming selgitatud esimesele väljaandele) saab ühendada nelja rühma:

1. Lühike tsükkel tagasisidet(Peen skaala tagasiside)

a. Testipõhine arendus

b. Planeerimismäng

c. Klient on alati läheduses (terve meeskond, kohapealne klient)

d. Paari programmeerimine

2. Pigem pidev kui partiiprotsess

a. Pidev integreerimine

b. Refactoring (disaini täiustamine, ümberehitamine)

c. Sagedased väikesed väljaanded

3. Arusaam, mida jagavad kõik

a. Lihtsus (lihtne disain)

b. Suhtlemine

c. Respekt

d. Kollektiivne koodi omandiõigus või valitud kujundusmustrid (kollektiivsete mustrite omandiõigus)

e. Kodeerimisstandard või kodeerimise kokkulepped

4. Programmeerija heaolu:

a. 40 tundi töönädal(Jätkusuutlik tempo, neljakümnetunnine nädal)

XP-s jaguneb protsess ajastatud protsessidega võrreldes väga väikesteks sammudeks. Selle tulemuseks on see, et esimestel sammudel kulub jugamudeli iga etapi jaoks kuude või isegi aastate asemel päevi või nädalaid. Esiteks kirjutatakse arenduseesmärkide kirjeldamiseks automatiseeritud testid. Seejärel tuleb kodeerimine, mis lõpeb hetkel, kui kõik testid läbivad ja programmeerijad ei saa uusi teste välja mõelda. Disaini teevad samad inimesed, kes koodi kirjutavad. (ainult viimane samm – disaini ja koodi ühendamine – on ühine kõikidele agiilsetele protsessidele). Lõpetamata, kuid toimivat süsteemi näidatakse kitsale kasutajate ringile (enamasti on need arendajad ise). Sel hetkel hakkavad nad kirjutama teste süsteemi järgmise olulise osa jaoks.

19. ICONIX on protsess.

ICONIXi töötas välja Doug Rosenberg kell ICONIX tarkvara ICONIX-protsess põhineb kasutusjuhtumitel, kuid sellel pole palju puudusi. See protsess kasutab ka UML-i modelleerimiskeelt, kuid kasutatakse ainult UML-i põhimärke - see on 20% keelest. ICONIX protsess põhineb neljal peamisel kasutusjuhtumipõhisel tarkvaraarenduse etapil:

● domeeni modelleerimine;

● pretsedentide modelleerimine;

● nõuete sobivuse analüüs (kõigi funktsionaalsete nõuete täitmise kontrollimine);

● järjestusskeemide koostamine.

Protsessi peamised etapid on järgmised:

● Nõuete analüüs

● Eelprojekt

● Disain

● Rakendamine

Protsess põhineb minimaalse arvu mudelite loomisel, mis kajastavad tulevast süsteemi. Analüüsi etapis luuakse kasutusjuhtude mudelid, kasutajaliidese mudel ja domeeni olemi mudel. Eelprojekteerimise etapis koostatakse vastupidavuse diagramm. Täiendatakse ka pretsedendimudelit ja domeeni olemi mudelit. Detailse projekteerimise etapis koostatakse järjestusskeem (SequenceDiagram) ja klassiskeem. Rakendusfaasis luuakse lähtekood. Samuti saate luua juurutusskeemi ja komponentide diagrammi. iga etapp kulmineerub ülevaate verstapostiga, kus genereeritud diagramme tuleb kolleegidega arutada.

20. SCRUM on protsess.

Scrum on põhimõtete kogum, millele arendusprotsess on üles ehitatud, võimaldades rangelt fikseeritud lühikesi ajaperioode ( sprintid 2 kuni 4 nädalat) pakkuda lõppkasutajale töötavat tarkvara uute funktsioonidega, millel on kõrgeim prioriteet. Tarkvara võimalused järgmise sprindi rakendamiseks määratakse sprindi alguses planeerimisetapis ja ei saa kogu selle kestuse jooksul muutuda. Samas annab sprindi rangelt fikseeritud lühike kestvus arendusprotsessile etteaimatavuse ja paindlikkuse.

Peamised rollid Scrumis: ScrumMaster- see, kes juhib Scrum koguneb ja tagab kõigi põhimõtete järgimise Scrum(roll ei tähenda midagi muud kui õiget käitumist Scrum-ah, projektijuht pigem viitab Toote omanik ja ei tohiks olla ScrumMaster);Toote omanik (Toote omanik) - isik, kes esindab lõppkasutajate ja teiste tootest huvitatud isikute huve; ja ristfunktsionaalne Meeskond (Scrum meeskond), mis koosneb nii arendajatest kui testijatest, arhitektidest, analüütikutest jne (ideaalse meeskonna suuruseks on 7±2 inimest). Meeskond on ainuke täielikult arendusse kaasatud osaleja ning vastutab tulemuse eest ühtse tervikuna. Mitte keegi teine ​​peale meeskonna ei saa sprindi ajal arendusprotsessi segada.

Iga sprindi käigus luuakse tarkvara funktsionaalne kasv. Igal sprindil tarnitavad funktsioonid pärinevad etapist nimega toodete mahajäämus(töösoovide dokumenteerimine), millel on sooritatavate tööde nõuete taseme osas kõrgeim prioriteet. Töösoovid ( mahajäänud esemed), määratud läbivalt sprindi planeerimisnõukogu (sprindi planeerimise koosolek), viiakse sprindi etappi. Selle koosoleku käigus teavitab tooteomanik ülesandeid, mis tuleb täita. Seejärel määrab meeskond kindlaks, kui palju sellest, mida nad soovivad järgmise sprindi jooksul vajalike osade täitmiseks teha. Sprindi ajal täidab meeskond kindla kindla ülesannete nimekirja (nn. sprindi mahajäämus). Selle aja jooksul ei ole kellelgi õigust muuta töönõuete loetelu, mida tuleks mõista külmutamisnõuetena ( nõuded) sprindi ajal.

Artefaktid

Toodete mahajäämus on dokument, mis sisaldab funktsionaalsusnõuete loendit, mis on järjestatud tähtsuse järgi. Toodete mahajäämus on nimekiri sellest, mida tuleb tarnida. Selle loendi üksusi nimetatakse "lugudeks" ( kasutaja lugu) või mahajäänud elemente ( mahajäänud esemed). Toodete mahajäämus on redigeerimiseks avatud kõigile Scrumi protsessis osalejatele.

Sissejuhatus

Rational Unified Process (RUP) on üks spiraalseid tarkvaraarenduse metoodikaid. Metoodikat toetab Rational Software ning toodet uuendatakse ligikaudu kaks korda aastas. Modelleerimiskeelena sisse ühine alus teadmisi, kasutatakse ühtset modelleerimiskeelt (UML).

Iteratiivne tarkvaraarendus RUP-is hõlmab projekti jagamist mitmeks väikeseks projektiks, mis viiakse läbi järjestikku, ja iga arendusiteratsioon on selgelt määratletud eesmärkide kogumiga, mis tuleb iteratsiooni lõpus saavutada. Lõplik iteratsioon eeldab, et iteratsioonieesmärkide kogum peab täpselt ühtima tootekliendi määratud eesmärkide kogumiga, st kõik nõuded peavad olema täidetud.

RUP on üsna hästi vormistatud ning suurimat tähelepanu pööratakse projekti arendamise algfaasidele – analüüsile ja modelleerimisele. Seega on antud metoodika suunatud äririskide vähendamisele (riskide maandamisele), tuvastades vigu arengu varases staadiumis. Tehnilisi riske hinnatakse ja seatakse prioriteediks arendustsükli varajases staadiumis ning aja jooksul ja projekti arenedes läbi järgnevate iteratsioonide vaadatakse need seejärel üle. Sõltuvalt nende riskide prioriteetidest ilmnevad uued eesmärgid. Versioonide väljalaseid levitatakse nii, et esmajärjekorras käsitletakse kõrgeima prioriteediga riske.

Protsess hõlmab mudelite evolutsiooni; arendustsükli iteratsioon vastab ainulaadselt tarkvaramudeli konkreetsele versioonile. Iga iteratsioon (töövoog) sisaldab tarkvara elutsükli juhtimise elemente: analüüs ja projekteerimine (modelleerimine), juurutamine, integreerimine, testimine, juurutamine. Selles mõttes on RUP spiraalmudeli teostus, kuigi seda kujutatakse sageli tabeligraafikuna. Allpool tutvustame protsessi põhikomponente.

Sest edukas protsess Arenduseks on vaja kolme komponenti (joonis 1): protsess, tähistus ja utiliitide komplekt. Protsess kirjeldab, mida me teeme, mis järjekorras ja mil viisil; märkimine on suhtlusvahend; utiliitide komplekt aitab protsessi automatiseerida ja hallata.

Riis. 1. Edu kolmnurk

RUP sisaldab kõiki kolme komponenti. Kõigepealt vaatame tähistusfunktsioone, mis teevad järgmist.

"Liimib" protsessi ühtseks tervikuks;

on keelepõhine vahend selliste otsuste tegemiseks, mis lähtekoodist ei ilmne;

Annab semantika oluliste strateegiliste ja taktikaliste otsuste esindamiseks;

Pakub vormi, mis on piisav kajastamiseks ja seejärel otsuste tegemiseks ning vahendid protsessi automatiseerimiseks, et manipuleerida formaliseeritud andmetega.

Tegelikult hõlmab tähistus tarkvaraarendust analüüsist toote juurutamiseni. Märkimine RUP–UML-i puhul on formaalne keeleline vahend protsessi kirjeldamiseks (UML-i käsitletakse allpool). Järgmisena kaalume protsessi ülesehitust ja pakume ka utiliitide komplekti, mida kasutatakse projekti arendamise juhtimise protsessis vastavalt RUP-ile.

RUP struktuur

UP pakub struktureeritud lähenemist iteratiivsele tarkvaraarendusele, jagades protsessi aja jooksul neljaks verstapostiks: algus, väljatöötamine, ehitamine ja üleminek. Kahjuks puudub vene keeles väljakujunenud terminoloogia, mistõttu kasutame edaspidi ingliskeelseid termineid koos nende tõlkega vene keelde. Joonisel fig. Joonisel 2 on laialt kasutatav RUP-faaside kujutis. Kõigi nende etappide eesmärgid on:

Algus mõistmine, mida me loome. Teabe kogumise ja nõuete analüüsimise etapp, projekti kui terviku kuvandi määratlemine;

Viimistletud arusaam, kuidas me seda loome. Nõuete analüüsi ja süsteemi projekteerimise faas, vajalike tegevuste ja ressursside planeerimine, funktsioonide ja disainifunktsioonide täpsustamine;

Toote beetaversiooni ehitusloomine. Arenduse ja kodeerimise põhifaas, toote ülesehitamine iteratsioonide tõusva jadana (koodiversioonid);

Toote lõpliku versiooni ülemineku loomine. Toote tutvustamise faas, toote tarnimine konkreetsele kasutajale.

Riis. 2. RUP faasid

Need on toote evolutsiooni juhtimise etapid – elutsükli iteratsioonid. RUP hõlmab lõpp-eesmärgile lähenemist, kuid erinevalt klassikalisest ISO standardist (juga metoodika), kus üleminek on lõppfaas, saab iga faasi korrata mitu korda, peegeldades muutusi kliendi nõuetes tootele.

RUP metoodika põhineb üheksal peamisel töövool, mis on tarkvara elutsükli iteratsiooni elemendid:

Äri modelleerimine (ärianalüüs) - hõlmab nõuete analüüsimist elutsükli antud iteratsioonil, soovitud süsteemi parameetrite ja kasutajate vajaduste määramist;

Nõuded süsteemipildi vormistamine. Hõlmab nõuete kogumist ja haldamist, nõuete muutmist funktsionaalseteks spetsifikatsioonideks. Siit algab pretsedentide analüüs ja kasutusjuhtude (kasutajalugude) konstrueerimine kasutajanõuete formaalne kaardistamine UML-is. Tulemuseks on juhtimistasandi dokumendid;

Analüüs ja projekteerimine (analüüs ja modelleerimine) – hõlmab kogutud nõuete tõlkimist formaliseeritud tarkvaramudeliks. Tulemuseks on süsteemi kirjeldus juurutamisetapis ( tehniline projekt) on süsteemiarendajate tasandi dokumendid. Formaaliseerimiskeel on ühtne modelleerimiskeel (UML), mida käsitletakse allpool. Iteratiivse arenduse käigus areneb selle konkreetse voo toode – projektimudel. Kõik muudatused RUP-is on otseselt seotud mudelitega ning automatiseerimistööriistad ja üsna paindlik modelleerimiskeel võimaldavad seda protsessi ajaliselt ja ressursse arvestades enam-vähem valutult juhtida. See viitab asjaolule, et arenduse tulemuseks ei ole mudel, vaid käivitatav kood, mistõttu kliendile ei meeldi tavaliselt modelleerimise eest tegelikult maksta, kuna mudelid pole see toode, mida ta vajab);

Rakendamine ( juurutamine, kodeerimine ) – hõlmab tegelikult koodi kirjutamist. RUP-i koodielemendid luuakse juba analüüsi- ja projekteerimisfaasis, kuna UML-i juurutamise tööriist - Rational Rose - võimaldab luua koodielemente mitmes programmeerimiskeeles. Metoodika – objektorienteeritud programmeerimine;

Test hõlmab toote testimist antud iteratsiooniga. Eraldi väärib märkimist, et regressioonitestid (tagastustestid, toote "mitteriknemise" testimine) peaksid sel juhul sisaldama kõiki eelmise iteratsiooni praeguseid teste ja eelmise üleminekufaasi vastuvõtuteste;

Kasutuselevõtt (juurutamine) hõlmab toote paigaldamist kliendi asukohas, personali koolitamist, süsteemi käivitamist pluss vastuvõtutestid, toote pakendamise ja levitamise standardite koostamist, materjalide edastamist müügiosakonda (toimingud on valikulised olenevalt toote spetsiifikast ).

Ülaltoodud elemendid ei ole tarkvaraarenduse elutsükli seisukohalt uued, kuna need esinevad peaaegu igas metoodikas - võib-olla välja arvatud XP (kus need on siiski esitatud väga originaalsel kujul). RUP-i rakendamise tunnuseks on ajaline rõhuasetus, nimelt teatud lõimede iteratsioonide domineerimine, samuti universaalse keele ja utiliitide komplekti olemasolu, mis võimaldab kirjeldada arendusprotsessi. Nagu näeme joonisel fig. 2, toote arendamise algfaasis pööratakse põhitähelepanu projekti vormistamisele (analüüs, modelleerimine), mille eesmärk on vähendada ärilisi riske ja vähendada projekteerimisvigade maksumust. Kui pilt on enam-vähem selge, algab toote tegelik arendus, testimine ja lõpuks ka juurutamine.

Esialgne interna on tegelikult dokumendid, mille on välja andnud ettevõtete juhtide tehniline nõukogu. Algetappide põhieesmärk on lepingu või kavatsuste protokolli sõlmimine. Edasised iteratsioonid on arendusmeeskonna töö tegelik algus, kellel on aega ja ressursse formaalsete mudelite koostamiseks. UML-il on sel juhul tööriistad, mis võimaldavad teil mudeli koodielementidele vastendada. Näiteks kuvatakse otse objektide puud, variatsioonid sõltuvad arendajate valitud programmeerimiskeele realiseerimisvõimsusest, samuti G. Butchi ja selle keele arendajate seisukohtade kokkulangemisest objektimudeli suhtes. . Sama kehtib ka meetodite kohta.

Vaatame nüüd tootetoega seotud elemente – põhilisi toetavaid töövooge:

Konfiguratsioonihaldus (konfiguratsiooni- ja muudatuste haldamine) on võimas tooteversioonide haldamiseks mõeldud haldustoimingute kiht, mis hõlmab lähtekoodi (mudel, käivitatavad moodulid, testid, dokumentatsioon), tooteversiooni juhtimist, ettevõtte koodiarenduse ja dokumentatsiooni standardeid, muudatuste ja vigade jälgimine (vigade jälgimine); tihedalt seotud testimise ja klienditoega;

Juhtimine (projektijuhtimine) - hõlmab projektijuhtimiseks vajalike haldustoimingute kogumit vastavalt RUP-i ideoloogiale, kasutatakse projektijuhtimise tööriistu (vt allpool ratsionaalsete toodete loendit);

Keskkond hõlmab loomist ja hooldamist analüüsivahendid, projekteerimine, arendus, testimine (nii tarkvara kui riistvara).

Iteratiivne arendus;

Nõuete haldamine;

Modulaarsete arhitektuuride kasutamine;

Visuaalne modelleerimine;

Kvaliteedikontroll;

Jälgi muudatusi.

Praktika ei ole otseselt osa RUP protsess, kuid neid on väga soovitatav kasutada. Mõned tavad tulenevad otseselt RUP-ideoloogiast. Seega on iteratiivne arendus RUP-i struktuuri sisse ehitatud, kuna see protsess on üks "spiraali" rakendusi. RUP-i nõuete haldamine ilmub analüüsi kõige varasemates etappides. Teoreetiliselt võimaldab modulaarne arhitektuur koodi uuesti kasutada, muutes süsteemi paindlikumaks. Tänu sellele, et UML on objektkeel, on võimalik modulaarsust ignoreerida, aga... see on mõnevõrra keeruline. Visuaalne modelleerimine võimaldab tõhusalt toime tulla süsteemide kasvava keerukusega. Lisaks on mudelid arendajatevahelise suhtluse vahendid, kuid selleks peavad arendajad rääkima UML-i keeles, mis nõuab teatud koolitust. Visuaalset modelleerimist kasutatakse sageli Rational Rose'i tööriista abil, mis võimaldab hankida juhtidele, süsteemiadministraatoritele, arendajatele, testijatele väga kasulikke dokumente ja luua koodielemente. See tööriist ei ole ainus UML-i rakendus – saadaval on nii kaubanduslikud alternatiivid (näiteks Microsoft Visio) kui ka tasuta. Tuleb märkida, et modelleerimisvahendites rakendatud UML-i murded ei ole alati samad: ratsionaalsel murdel on mõned suured erinevused, mida on kirjeldatud nii dokumentatsioonis kui ka UML-i raamatutes.

Tooted, mis toetavad RUP-i

Järgmised on kõige tuntumad tooted, mis toetavad ratsionaalset ühtset protsessi:

Rational Rose CASE visuaalse modelleerimise tööriist infosüsteemid, millel on koodielementide genereerimise võimalus. Toote Rational Rose RealTime eriväljaanne võimaldab teil saada väljundina käivitatava mooduli;

Rational Requisite Pro nõuete haldustööriist, mis võimaldab teil luua, struktureerida, prioritiseerida, jälgida ja juhtida nõuete muudatusi, mis tekivad rakenduse komponentide arendamise mis tahes etapis;

Rational ClearQuest toode muudatuste haldamiseks ja defektide jälgimiseks projektis (vigade jälgimine), mis on tihedalt integreeritud testimis- ja nõuetehaldustööriistadega ning pakub ühtset keskkonda kõigi vigade ja dokumentide omavaheliseks sidumiseks;

Ratsionaalne SoDA toode projekti dokumentatsiooni automaatseks genereerimiseks, mis võimaldab teil määrata sisedokumentidele ettevõtte standardi. Samuti on võimalik viia dokumentatsioon olemasolevatele standarditele (ISO, CMM);

Rational Purify, Rational Quantify Rational PureCoverage, - testimis- ja silumistööriistad:

Rational Purify on väga võimas käitusaegne vigade otsimise tööriist rakenduste ja komponentide arendajatele, kes programmeerivad C/C++ keeles,

Rational Visual Quantify jõudluse mõõtmise tööriist rakenduste ja komponentide arendajatele programmeerimiseks C/C++, Visual Basic ja Java keeles; aitab tuvastada ja kõrvaldada tarkvara jõudluse kitsaskohti,

Rational Visual PureCoverage – tuvastab automaatselt koodipiirkonnad, mida ei testita;

Rational ClearCase on tarkvara konfiguratsioonihalduse toode (Rational's Software Configuration Management, SCM), mis võimaldab kõikide projektidokumentide versioonikontrolli. Selle abiga saate toetada korraga mitut projekti versiooni, vahetades nende vahel kiiresti. Rational Requisite Pro toetab uuendusi ja jälgib arendusmeeskonna nõuete muudatusi;

SQA TeamTest testimise automatiseerimise tööriist;

Rational TestManager testihaldussüsteem, mis koondab kõik testiga seotud tööriistad, artefaktid, skriptid ja andmed;

Rational Robot tööriist testide loomiseks, muutmiseks ja automaatseks käivitamiseks;

SiteLoad, SiteChecki tööriistad veebisaitide toimivuse ja katkiste linkide olemasolu testimiseks;

Rational PerformanceStudio – mõõdab ja ennustab süsteemi jõudlusnäitajaid.

Artefaktid ja rollid

RUP-i lahutamatu osa on artefaktid, pretsedendid ja rollid. Artefaktid on mõned projekti tooted, mis luuakse või kasutatakse projektis lõpptoote kallal töötades. Kasutusjuhud on tegevuste jadad, mida süsteem jälgitava tulemuse saavutamiseks teeb. Tegelikult on iga üksikisiku või rühma töö tulemus artefakt, olgu selleks analüüsidokument, mudeli element, koodifail, testskript, vea kirjeldus vms. Teatud spetsialistid vastutavad üht või teist tüüpi artefakti loomise eest. Seega määratleb RUP selgelt iga arendusmeeskonna liikme kohustused ühes või teises etapis ehk millal ja kes peaks selle või teise artefakti looma. Kogu tarkvarasüsteemi arendamise protsessi käsitletakse RUP-is kui artefaktide loomise protsessi - alates esialgsetest analüüsidokumentidest kuni käivitatavate moodulite, kasutusjuhenditeni jne. Allpool on iga voo artefaktide komplekt (mudelid, dokumendid jne).

Äri modelleerimine

Äriprotsessi mudeli ärinõuete määramine arendatavale süsteemile;

Ettevõtte struktuuri mudel – artefakt süsteemi funktsionaalse mudeli väljatöötamiseks;

Dokumentide mudelid, äriüksused, ärifunktsioonide stsenaariumide mudelid, äriüksuste olekute mudelid - kasutajaliidese, andmebaasisüsteemi kujundamiseks; kujutavad endast süsteemi staatiliste ja dünaamiliste olekute kirjeldust erinevatest vaatenurkadest;

Ärireeglite mudelite artefakti kasutatakse reeglite modelleerimiseks tarkvaras.

Dokumentide artefaktid, mida kasutavad RequisitePro, SoDA, tekstitöötlusprogrammid, Microsofti projekt:

Kliendi organisatsiooni, äristruktuuri hindamine;

Ainevaldkonna terminite sõnastik;

Ärireeglite kogum;

Kommertspakkumine;

Ärifunktsioonide spetsifikatsioonid;

Tööplaan äri modelleerimise etapis;

Muudatustaotlused.

Nõuded

Rational Rose'i kasutatud artefaktimudelid:

Süsteemi funktsiooni mudel;

Süsteemi funktsiooni stsenaariumi mudel;

Kasutajaliidese mudel;

Süsteemi kasutaja stsenaariumide mudel;

Väljundvormide mudel;

Süsteemireeglite mudel.

Nõuete haldamise plaan;

Süsteemiterminite sõnastik;

Tarkvarasüsteemi spetsifikatsioon;

Süsteemi funktsioonide spetsifikatsioon;

Süsteemi reeglid;

Huvirühmade päringud;

Tööplaan süsteeminõuete kindlaksmääramise etapis;

Muudatustaotlused.

Analüüs ja disain

Rational Rose'i kasutatud artefaktimudelid:

Loogiline andmemudel;

Füüsiline andmemudel;

Süsteemi komponentide spetsifikatsioonide mudel;

Süsteemikomponente rakendavate klasside interaktsiooni stsenaariumid.

RequisitePro, SoDA, tekstitöötlusprogrammide ja MS Projecti kasutatavad dokumendiartefaktid:

Tarkvara arhitektuur;

Tarkvarakomponentide spetsifikatsioonid;

Tööplaan analüüsi ja projekteerimise etapis;

Muudatustaotlused.

Rakendamine

Rational Rose'i kasutatud artefaktimudelid:

Komponentide rakendusmudel.

Rational Rose'i kasutatud artefaktide kood, programmeerimisvahendid, tekstitöötlusprogrammid:

Koodi genereerimise elemendid pärinevad ettevõttest Rational Rose;

tegelik rakenduse kood;

Dokumentatsioon.

RequisitePro, SoDA, tekstitöötlusprogrammide ja MS Projecti kasutatavad dokumendiartefaktid:

Rakenduse ehitusplaan;

Tööplaan elluviimise etapis.

Test

Rational Rose'i kasutatud artefaktimudelid:

Katsejuhtumi mudel;

Testprogrammi funktsionaalne mudel;

Testiprogrammi komponentide spetsifikatsioonimudel;

Testprogrammi komponentide koostoimet rakendavate klasside interaktsiooni stsenaariumid.

Katsejuhtumite kirjeldus;

katseplaan;

testimisetapi tööplaan;

Muudatustaotlused.

Testimisrakenduse kvantifitseerimine, puhastamine, PureCoverage, Robot, SiteLoad, SiteCheck.

Kasutuselevõtt

Rational Rose'i kasutatud artefaktimudelid:

Komponentide paigutuse mudeli kirjeldus töötlemissõlmedesse.

SoDA, tekstitöötlusprogrammide, MS Projecti kasutatavad dokumendiartefaktid:

Õppematerjalid;

Paigaldusdokumendid;

Süsteemi versioonide kirjeldus;

Rakendusplaan.

Selle seeria järgmine artikkel on pühendatud ühtsele modelleerimiskeelele (UML).