Vastavalt standardile GOST 34.601-90 “AS. Loomise etapid" kehtestab järgmised AIS-i loomise etapid, mille saab omakorda jagada etappideks:

· nõuete kujundamine AISile;

· AISi kontseptsiooni väljatöötamine;

· tehniline ülesanne;

· eelprojekt;

· tehniline projekt;

· töödokumentatsioon;

· kasutuselevõtt.

Igal etapil on oma projekteerimisdokumentatsioon ning süsteemi tehniliste ja tarkvaramoodulite juurutamine. Praktika näitab, et süsteemi loomise protsess on iteratiivne ja inkrementaalne. UML-i autorid rõhutavad seda mõistet määratledes ühtne tarkvara arendusprotsess ja teabe tugi . Kuigi esimeses etapis moodustatakse AS-ile kui tervikule esitatav nõuete kogum, on see tegelikult alguses alati puudulik ja selgitatakse järgmistes etappides. ma pean tegema iteratsioonid st korrake üksikuid samme ja etappe kas täielikult või osaliselt. Lisaks on reaalne süsteem multifunktsionaalne ja keeruline, seetõttu jagatakse see tavaliselt alamsüsteemideks ja eraldi ülesannete kogumiteks, eristades esimese, teise jne alamsüsteeme ja ülesandeid. Süsteem on loomisel järk-järgult, funktsionaalsuse järkjärgulise suurendamise kaudu, asendades esialgsed disainilahendused rohkem arenenud lahendustega, mis vastavad paremini kasutajate nõudmistele. See vähendab finantsriskid ning säästab aega ja ressursikulu loomise lõppfaasis.

UML-i metoodika kasutamisel AIS-i tarkvara ja teabetoe loomiseks tehakse ettepanek luua omavahel ühendatud mudelite komplekt, mis kajastaks tulevase süsteemi staatilisi ja dünaamilisi omadusi:

· kasutusjuhtumi mudel;

· analüüsimudel;

· disainimudel;

· kasutuselevõtu mudel;

· teostusmudel;

· mudeli testimine.

Kasutage juhtumimudelit sisaldab kasutusjuhtude diagramme ja vastavaid stsenaariume, kirjeldab süsteemi funktsionaalseid nõudeid ja selle käitumist kasutajatega suhtlemisel.

Analüüsi mudel sisaldab üldisi klassiskeeme loogilise taseme kasutusjuhtude, seotud jadaskeemide ja/või koostöödiagrammide rakendamiseks ning on visand selle kohta, kuidas loogilisel tasemel kasutusjuhtumeid rakendatakse.

Disaini mudel on analüüsimudeli füüsilise teostuse detailne esitus ja sisaldab pakett- (allsüsteemi) diagramme, üksikasjalikke klassiskeeme, järjestusskeeme ja/või koostööskeeme, olekuskeeme, erineva detailsusastmega tegevusskeeme.

Kasutuselevõtu mudel sisaldab esialgseid juurutusskeeme, mis määratlevad kõik võrgukonfiguratsioonid, milles süsteem võib töötada. Juurutusskeemid näitavad võrgusõlmi, ühenduse tüüpe ja aktiivsete süsteemiklasside jaotust sõlmede vahel.

Rakendusmudel kirjeldab, kuidas disainiklasse komponentidena realiseeritakse. Sellest tulenevalt sisaldab see komponentide diagramme, klassi (rakenduse) jälgi, üksikasjalikke juurutusskeeme ja süsteemi arhitektuuri kirjeldust.

Testimudel sisaldab testjuhtumite komplekti, testimisprotseduure ja testikomponentide kirjeldusi. See määrab käivitatavate süsteemikomponentide testimise meetodid.

Võrdleme mudelite ehitamise protsesse AS-i loomise standardiseeritud etappidega. Kasutusjuhtumi mudel on üles ehitatud AS-i nõuete kujundamise etapis; analüüsimudel on AS-i kontseptsiooni väljatöötamise staadiumis. Laval lähteülesanne ja eelprojekteerimine, ehitatakse kujundusmudel. Seda täiustatakse tehnilise projekteerimise etapis ja seda täiendatakse kasutuselevõtumudeliga. Töödokumentatsiooni etapis luuakse juurutus- ja testimismudelid. Lõpuks, kasutuselevõtu etapis, testimismudel viimistletakse ja sellest saab töötamise ajal etalonmudel, mis on ette nähtud süsteemi õige toimimise ja diagnostika perioodiliseks kontrollimiseks.

1.5 UML keele komponendid

Unified Modeling Language UML(Unified Modeling Language) on visuaalne modelleerimiskeel, mida kasutatakse keerukate süsteemide (sh. tarkvara), kasutades objektorienteeritud tehnoloogiat.

UML-i metoodikas AS-i loomisel kasutatakse Hein/Sarsoni ja SADT metoodikast tuntud struktuurisüsteemi analüüsi põhimõtteid:

· ülalt-alla järkjärguline arendus;

· diagrammitehnika;

· kirjelduste hierarhia;

· projektlahenduste kirjelduse range vormistamine;

· projekti esialgne arendamine loogilisel tasemel ilma tehnilise teostuse üksikasjadeta;

· kontseptuaalne modelleerimine ainevaldkonnas, et klient mõistaks süsteemi ülesehitust;

· tehnoloogiline tugi tööriistadega (CASE süsteemid).

UML-i keeruka süsteemi mudelit saab uurida, et saada süsteemi protsesside efektiivsuse hinnangulisi omadusi.

AS-i tarkvara juurutamise, juurutamise ja testimise ning UML-i teabetoe mudeleid saab kasutada rakendusprojektina koos järgneva rakenduskoodi automaatse genereerimisega ühes valitud programmeerimiskeskkonnas.

Kompleksse süsteemi üsna täielik mudel peaks kajastama kahte aspekti:

-staatiline(struktuurne) – koostis, komponentide struktuur ja nende seosed;

-dünaamiline(käitumuslik) – süsteemis toimuvate või rakendatavate protsesside loogika kirjeldus.

UML-is kasutusele võetud mudelite esitusmeetodiks on põhilised diagrammid, mis on varustatud tekstilise teabega, sealhulgas sisseehitatud piirangukeeles OCL, aga ka süsteemi juurutamiseks kasutatavates programmeerimis- ja teabepäringukeeltes.

Modelleerimise põhiprintsiip: süsteem modelleeritakse diskreetsete objektide rühmana, mis suhtlevad üksteisega nii, et rahuldatakse kasutaja nõudmisi.

Staatiline mudel määrab struktuuri, objektide tüübid ja objektidevahelised seosed. Dünaamiline mudel määrab objektide käitumise ajas (objektide ajaloo) ja nende vastasmõju.

Põhimõtteliselt on UML diskreetne modelleerimiskeel, see tähendab, et see sisaldab diskreetsete sündmuste ja olekumuutuste kontseptsiooni. Pidevaid protsesse modelleeritakse ligikaudu diskretiseerimise teel.

Mudelil on kaks aspekti: semantiline informatsioon (semantika) ja visuaalne esitus (notatsioon).

UML-keele mudeliesitluste täielik koosseis on toodud tabelis 1

Tabel 1 – Süsteemimudelite esitus UML-is.

Süsteemi kõige levinum kontseptuaalne mudel on kasutusjuhtude diagramm, see on lähtepunkt muude diagrammide koostamisel.

Kõik keelediagrammid on eritüüpi graafikud, mis sisaldavad servadega (kaaredega) ühendatud tippe (geomeetrilisi kujundeid). Tavaliselt ei ole pildi mastaap ja tippude asukoht eriti oluline, samas jadadiagrammis tuuakse ajatelg sisse ja seal on see oluline.

Seoseid tähistavad tasapinnal erinevad jooned, jooniste sisse on kirjutatud tekst, tippude ja ühenduste läheduses saab kujutada mõningaid graafilisi sümboleid. UML-i laiendused võimaldavad ruumidiagramme.

Keelel on 4 tüüpi graafilisi struktuure:

· ikoonid (piktogrammid);

· graafilised sümbolid tasapinnal;

· teed (jooned);

· tekstiread.

1.6 Kontseptuaalne tase. Kasutage juhtumimudelit

Üldiselt toimub objektorienteeritud projekteerimisprotsess vastavalt struktuurisüsteemide analüüsi aluspõhimõtetele: ülalt-alla projekteerimine koos diagrammide hierarhia ehitamisega, mis viib meid järk-järgult tasemelt tasemele: kontseptuaalne – loogiline – füüsiline (rakendamine)

Tipptaseme diagrammi peetakse A. Jacobsoni poolt OOSE-s välja pakutud diagrammiks kasutusjuhtude diagramm süsteemid tervikuna. See on süsteemi esialgne kontseptuaalne esitus ja see on üles ehitatud eesmärgiga:

· määrata modelleeritava ainevaldkonna üldised piirid ja kontekst;

· vorm Üldnõuded süsteemi funktsionaalsele käitumisele ja liidesele;

· koostada esmane dokumentatsioon suhtlemiseks arendajate ja klientide – süsteemi kasutajate vahel.

Modelli vaatenurk: süsteemi väliskasutaja. Kasutusjuhtude diagramm sisaldab osalejaid, kasutusjuhtumeid ja seoseid.

Aktant(toimija, väline üksus, tegutseja) – süsteemi, alamsüsteemi või klassiga vahetult suhtlevate sõnumiallikate/vastuvõtjate klassi abstraktne kirjeldus. See on kirjeldus rollid mida mängib kasutaja (isik või muu süsteem, alamsüsteem, klass) süsteemiga suhtlemise ajal. Põhimõtteliselt on see sarnaste teabepäringute üldistamine süsteemile, mis nõuavad teatud teavet teenust(teenused).

Aktant ei pea tingimata olema samastatud konkreetsega indiviid või seade, kuigi see on mõnikord põhimõtteliselt võimalik, kui nad täidavad ainult ühte rolli. Kõige sagedamini - füüsiliselt - see on erinevad inimesed ja seadmed, mis pääsevad sama teenuse saamiseks süsteemile juurde. Kõrgeimal tasemel võivad aktandid olla näiteks operaator, süsteemiadministraator, andmebaasi administraator, tavakasutaja või mõni seadmete klass.

Kõik võimalikud aktandid ammendavad kõik võimalikud viisid kasutaja suhtlemiseks süsteemiga (alamsüsteem, klass). Süsteemi juurutamisel kehastuvad aktandid inimestes ja füüsilistes objektides. Üks inimene või füüsiline objekt võib olenevalt interaktsiooni viisist esindada mitut aktanti (erinevaid rolle). Näiteks võib sama isik olla operaator ja andmebaasi administraator, müüja ja ostja jne.

Paljudes AS-is pole peale inimeste teisi näitlejaid. Kuid aktandid võivad olla väline süsteem, I/O-seade või taimer (seda leidub tavaliselt manustatud reaalajasüsteemides). Kasutusjuhtumi aktantide hulgast torkab silma üks põhiaktant(esmane tegutseja), mis käivitab töö süsteemiga. Ülejäänud on teisejärgulised, nemadki osalevad kasutusjuhtumis, saades tulemusi ja sisestades mingeid vaheandmeid.

Loogilisel ja füüsilisel tasandil esindavad aktante klassid ja objektid, mis on klasside eksemplarid. On võimalik üles ehitada aktantide hierarhia, mis pärib kõik rollid ja suhted, atribuudid ja operatsioonid, mis esivanemal on. Alam-aktandi eksemplari saab alati kasutada süsteemis, kus on deklareeritud esivanema aktandi kasutamine (asenduspõhimõte).

Aktanti saab diagrammidel kujutada kahel viisil:

3. Klassi sümbol (ristkülik) stereotüübi sisemise tähisega

4. Standardsem: “mees” koos pealdisega (isiku sümbol)

Aktant asub süsteemist väljas ja selle sisemine struktuur pole määratud. See on sõnumite allikas/vastuvõtja.

Klient

Kasutusjuhtum(pretsedent, kasutusjuhtum) – teenuseklassi (teenindusfunktsioonide) abstraktne kirjeldus, mis antakse aktandile vastuseks tema taotlustele.

Teenust võib pakkuda süsteem tervikuna, alamsüsteem või klass. Seega tähendab kasutusjuhtum süsteemi funktsionaalsuse või käitumise mingi osa modelleerimist. Kasutusjuhtumil on nimi ja see tähendab teatud toimingute jada, mis on nähtav välisele allikale/vastuvõtjale (aktant). Võimaluse sisemine viis on peidetud ja paljastatud madalamal detailsusastmel. koostöö diagramm. Nagu igal klassil, on ka kasutusjuhul atribuudid ja toimingud, mille rakendamine avaldatakse füüsilisel kihil.

Kasutusjuhtum hõlmab kogu sõnumite jada, mida aktant alustab ja lõpetab süsteemiga (alamsüsteem, klass). Seetõttu on igal kasutusjuhu juurutuse eksemplaril alati algus ajas ja lõpp, kui ükski toimija selle valiku jaoks sõnumeid ei saada. Siia kuuluvad ka veateated, hooldusfunktsiooni teostamise võimalused erinevate seadistustega (alternatiividega).

Kasutusjuhtumi eksemplar on kasutusjuhtumi täitmine, mis algab pärast seda, kui on esimest korda saadetud teade aktiivselt eksemplarilt. Vastuseks antud sõnumile teostab kasutusjuht teatud toimingute jada, näiteks saadab sõnumi aktandi teistele eksemplaridele (mitte ainult algatajale). Need aktandid saadavad omakorda sõnumeid sellele kasutusjuhtumi eksemplarile ja suhtlus jätkub seni, kuni selliseid sõnumeid enam vastu ei võeta. See tähistab kasutusjuhtumi lõppu.

Näidatakse aktandi ja kasutusjuhtumi suhet assotsiatsioon.

Diagramm kujutab kasutusjuhtu kahel viisil:

1) ellips, selle sisse pannakse nimi

2) ristkülik - nagu iga klass

Klient

Andur

Aktantide ja kasutusjuhtude vahel on seos ainsaks ühenduse tüübiks. Lisaks on sellel semantika side vahetamine, st sõnumi edastamist, tavaliselt ei märgistata, kuna kontekst on aktandi ja kasutusjuhtude tähistusest selge. Kuid saate selle märkida ja näidata ka ühenduse paljusust:

Panga klient

Paljusus(multiplicity) iseloomustab antud ühenduses osaleva klassi konkreetsete esinemisjuhtude arvu (üks klient võib väljastada piiramatul arvul laene).

Üldiselt assotsiatsioon on seos kahe või enama mudelikomponendi vahel. Kuna enamikul juhtudel on komponendid mingid objektide klassid, on seose eksemplar lihtsalt järjestatud loend konkreetsetele eksemplaridele viidetest, mis võib olla varustatud seose atribuutidega (omadustega).

Ühenduse nimi, kui see on olemas, peab olema kordumatu. See moodustub vastavalt ühenduses osalevate klasside vaheliste suhete tähendusele. Näiteks "Töötaja töötab sisse Osakond“, „Juhataja lõpetab Arvuti” jne.

Ühendused on ise klassid ( ühingu klass, assotsiatsiooniklass), sellel on nii klassi kui ka assotsiatsiooni omadused. Selle klassi eksemplarid on ühendused, millel pole mitte ainult linke objektidele, vaid ka atribuutide (omaduste) väärtusi.

Ühingu liikmeid nimetatakse selleks poolused. Kõik poolused on ühendusega seotud klasside rollid, need on erinevad ja neid saab loetleda mõnes järjestatud loendis. Enamasti on seosed binaarsed (kaks rolli teatud semantikaga ühenduses), kuid võib esineda ka n -ary. Üks ja sama klass võib tegutseda erinevates rollides ehk olla samaaegselt ühenduse kahes pooluses.

Ühenduste paljusus on näidatud pooluste juures.

Ühendused võivad süsteemi töötamise ajal tekkida ja kaduda, ühenduse poolustel saab määrata piiranguid ja vastavaid predikaate.

Mõnikord muutub ühendus ainult ühel poolusel. Kui lingil on atribuute, saab neid operatsioonidega muuta, kuid lingid lingis osalejatele ei muutu.

Ühendus on kujutatud pideva joonena, mis ühendab 2 klassi piire n-ary, siis joonistatakse romb (liitumise märk):

		Paljud ühendused - liitmine
	Binaarne assotsiatsioon

Kasutusjuhtumid ei vaheta üksteisega sõnumeid ja võivad olla ainult suhetes (ühendustes) laiendused(pikendama) kaasamine(kaasa arvatud) ja üldistused(üldistamine).

IN laienemise osas kasutusjuhtum – klient tutvustab täiendavat tegevuste jada, alustades mõnest põhijärjestuse punktist ja selliseid “sisestusi” võib olla mitu. Kõiki neid punkte nimetatakse laienduspunktid.

Ühtne protsess mille on välja töötanud Rational (Rational Unified Process, RUP) - see on summa erinevat tüüpi tegevused, mis on vajalikud 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 luuakse või kasutatakse projektis lõpliku tarkvaratootega töötades. 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– peamise detailne esitlus RUP protsessid)

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 loodud 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.

Rational Unified Process (RUP) on üks parimaid tarkvaraarenduse metoodikaid, 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 õigeaegselt, teatud funktsionaalsusega ja ette nähtud eelarve piires tarkvarasüsteem valmis saaks.

Ühtset protsessi võib käsitleda kui arendusettevõtte erinevate tegevuste summat, 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üsteemimudelid. 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 kümme korda tipptasemel meetodeid ja tehnoloogiaid kasutades, siis kui kasutaja ei saa sellest nn "tähenduslikku tulemust", kukub teie tarkvaraprojekt 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 tarkvara), seda keerulisem on seda 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ääratlemise etapp, mis seisneb kõigi võimalike süsteemi toimimise soovide kogumises, mida kasutajad ja analüütikud suudavad mõelda. 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 testistsenaariumide 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. UML-diagrammid, mis on loodud arenduse eri etappides, on lahutamatud tarkvaraprojekti ülejäänud artefaktidest 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.

Rational Unified Process (RUP) on Rational Software poolt loodud tarkvaraarenduse metoodika.

Põhimõtted: Suuremate riskide varajane tuvastamine ja pidev (kuni projekti lõpuni) kõrvaldamine. Keskendumine kliendi nõuete täitmisele käivitatava programmi osas (pretsedentide mudeli (kasutusjuhtumite) analüüs ja konstrueerimine). Arendusprotsessi käigus on oodata muutusi nõuetes, disainiotsustes ja teostuses. Projekti alguses rakendatud ja testitud komponentide arhitektuur. Pidev kvaliteedi tagamine projekti (toote) arendamise kõikides etappides.

Projekti kallal töötamine tihedas meeskonnas, milles arhitektidel on võtmeroll.

RUP kasutab iteratiivne arengumudel. Iga iteratsiooni (ideaaljuhul 2–6 nädalat) lõpus peaks projektimeeskond saavutama selle iteratsiooni jaoks kavandatud eesmärgid, looma või viimistlema disainiartefakte ning hankima lõpptoote vahepealse, kuid funktsionaalse versiooni.

Kogu tootearenduse elutsükkel koosneb neli faasi, millest igaüks sisaldab ühte või mitut iteratsiooni: algfaas, selgitamise, kavandamise ja rakendamise faas.

Extreme Programming (XP)

Ekstreemne programmeerimine(Extreme Programming, XP) – üks paindlikke tarkvaraarenduse metoodikaid

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

Lühike tsükkel tagasisidet: (Testipõhine arendus, planeerimismäng, klient on alati olemas, paarisprogrammeerimine

Pidev kui partiiprotsess: Pidev integreerimine, ümbertegemine, sagedased väikesed väljaanded

Kõigile jagatud arusaam: lihtsus, süsteemimetafoor, koodi või valitud kujundusmustrite kollektiivne omamine, kodeerimisstandard

Programmeerija sotsiaalkindlustus: 40 tundi töönädal

Paarprogrammeerimine hõlmab kogu koodi, mille loovad programmeerijapaarid, kes töötavad samas arvutis. Kollektiivne omand tähendab, et iga meeskonnaliige vastutab kogu lähtekoodi eest. XP-s pole "klient" mitte see, kes arveid maksab, vaid see, kes süsteemi reaalselt kasutab.

Dokumentatsiooni standardid

Standardid tagavad projektide ühilduvuse. Standardid parandavad inseneride arusaamist. Insenerid peaksid standardeid tajuma kui midagi neile kasulikku, mitte kui takistuste kogumit. Selged ja mõõdetavad eesmärgid, mis nõuavad distsiplineeritud ja dokumenteeritud lähenemist, on tavaliselt arendajatele heaks motivaatoriks

SVVP- Plaan määrab, kuidas ja millises järjestuses projekti etappe testida. Kinnitamine on protsess, mille käigus kontrollitakse, kas rakendus on õigesti üles ehitatud. Valideerimine kinnitab, et vajalik toode on kokku pandud.

SQAP- Tarkvara kvaliteedikontrolli plaan

SCMP- Majandamiskava tarkvara projekt

SRS- Tarkvaranõuete spetsifikatsioon

SDD- Tarkvara projekteerimisdokumentatsioon

STD- Tarkvara testimise dokumentatsioon

Dokumentatsiooni järjepidevus ja terviklikkus.

Dokumendihaldus nõuab olulisi organiseerimisoskusi. Hea ja paindliku dokumentatsiooni kirjutamine sarnaneb hea ja paindliku koodi kirjutamisega.

Dokumendihaldus tähendab selle säilitamist täielikkus Ja järjepidevus ja sisaldab ka Konfiguratsiooni juhtimine.

Täielikkus – arendus- ja hooldusprotsessi hõlmava dokumentatsiooni komplekti olemasolu.

Järjepidevus tähendab, et dokumentide kogum ei sisalda sisemisi vastuolusid Probleem on selles, et kui see hulk on suur, siis on üsna raske vältida üksteist välistavate väidete ilmnemist selles.

Konfiguratsiooni tugi - see on dokumentatsiooni ja programmikoodi erinevate versioonide ja osade koordineerimine.