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

· AIS-i nõuete kujundamine;

· AIS-i kontseptsiooni väljatöötamine;

· Tehniline ülesanne;

· eelprojekt;

· Tehniline projekt;

· Töödokumentatsioon;

· Kasutusele võtmine.

Igal etapil on oma projektdokumentatsiooni komplekt ning süsteemi tehniliste ja tarkvaramoodulite juurutamine. Praktika näitab, et süsteemi loomise protsess on korduv ja inkrementaalne. UMLi autorid rõhutavad sama, määratledes selle mõiste ühtne tarkvaraarendusprotsess ja teabetugi ... Ehkki esimeses etapis moodustatakse Aafrika Liidu nõuete kogum tervikuna, on see tegelikult alguses alati puudulik ja täpsustatakse järgmistel etappidel. Peab tegema kordused, see tähendab üksikute etappide ja etappide kordamist kas täielikult või osaliselt. Lisaks on reaalne süsteem multifunktsionaalne ja keeruline, seetõttu jaguneb see tavaliselt alamsüsteemideks ja eraldi ülesandekompleksideks, tuues neis esile esimese, teise jne etapi alamsüsteeme ja ülesandeid. Süsteem on loomisel järk-järgult, järk-järgult suurendades funktsionaalsust, asendades esialgsed disainilahendused täpsemate ja paremini kasutajate vajaduste rahuldamiseks. See vähendab finantsriske ja säästab loomise lõppjärgus aega ja ressursse.

Kui UIS-i metoodikat kasutatakse AIS-i tarkvara- ja teabetoe loomiseks, tehakse ettepanek ehitada omavahel ühendatud mudelite komplekt, mis kajastaks tulevase süsteemi staatilisi ja dünaamilisi omadusi:

· Kasuta juhtumimudelit;

· Analüüsimudel;

· Kujundusmudel;

· Kasutuselevõtu mudel;

· Rakendamise mudel;

· Mudeli testimine.

Kasuta juhtumimudelit sisaldab kasutusjuhtude skeeme ja seotud stsenaariume, kirjeldab süsteemi funktsionaalseid nõudeid ja selle käitumist kasutajatega suhtlemisel.

Analüüsimudel sisaldab üldistatud klassiskeeme kasutusjuhtumite rakendamiseks loogilisel tasemel, vastavaid järjestusdiagramme ja / või koostööskeeme ning on visand selle kohta, kuidas kasutusjuhtumeid loogilisel tasandil rakendatakse.

Kujundusmudel on üksikasjalik esitus analüüsimudeli füüsilisest teostusest ja sisaldab paketi (alamsüsteemi) skeeme, üksikasjalikke klasside skeeme, järjestusdiagramme ja / või koostööskeeme, olekudiagramme ja erineva detailsusastmega tegevusskeeme.

Kasutuselevõtu mudel sisaldab esialgseid juurutusskeeme, mis määratlevad kõik võrgu konfiguratsioonid, millel süsteem saab töötada. Juurutusdiagrammid näitavad võrgusõlmi, ühenduste tüüpe, süsteemi aktiivsete klasside jaotust sõlmede kaupa.

Rakendusmudelkirjeldab, kuidas disainiklassid rakendatakse komponentidena. Vastavalt sellele sisaldab see komponentide skeeme, klassijälgi (juurutusi), üksikasjalikke juurutusskeeme ja süsteemi arhitektuuri kirjeldust.

Testimismudelsisaldab testjuhtumite komplekti, katseprotseduure ja testikomponentide kirjeldusi. See täpsustab, kuidas käivitatavaid süsteemikomponente testida.

Võrrelgem mudelite ehitamise protsesse AS-i loomise standardiseeritud etappidega. Kasutusjuhtumi mudel on üles ehitatud Aafrika Liidu nõuete kujundamise etapis; analüüsimudel - Aafrika Liidu kontseptsiooni väljatöötamise etapis Tehniliste spetsifikatsioonide ja eskiisprojekti koostamise etapis ehitatakse kujundusmudel. See viimistletakse tehnilise projekteerimise etapis ja seda täiendab juurutusmudel. Töödokumentatsiooni etapis luuakse rakendus- ja testimismudelid. Lõpuks, kasutuselevõtu etapis täpsustatakse testimudelit ja see muutub töö käigus võrdluseks, mis on ette nähtud süsteemi korrektse toimimise ja diagnostika perioodiliseks kontrollimiseks.

1,5 UML-i komponendid

Ühtse modelleerimise keele UML (Unified Modeling Language) on visuaalne modelleerimiskeel, mida kasutatakse keerukate süsteemide (sh tarkvara) objektorienteeritud tehnoloogia abil.

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

· Ülalt-alla etapiviisiline arendus;

· Skemaatiline tehnika;

· Kirjelduste hierarhia;

· Disainilahenduste kirjelduse range vormistamine;

· Projekti esmane uurimine loogilisel tasemel ilma tehnilise teostuse üksikasjadeta;

· Kontseptuaalne modelleerimine ainevaldkonnas, et klient saaks süsteemi kujundusest aru;

· Tehnoloogiline tugi instrumentaalsete vahenditega (CASE-süsteemid).

UML-is saab uurida keeruka süsteemi mudelit, et saada hinnanguid protsesside efektiivsusele süsteemis.

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

Keerulise süsteemi piisavalt täielik mudel peaks kajastama kahte aspekti:

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

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

UML-is kasutusele võetud mudelite esitamise peamine viis on skeemid, mis on varustatud tekstiteabe, sealhulgas avaldustega piirangute sisseehitatud keeles OCL, samuti süsteemi juurutamiseks kasutatavates programmeerimiskeeltes ja infopäringutes.

Modelleerimise põhiprintsiip: süsteem on modelleeritud diskreetsete objektide rühmana, mis suhtlevad üksteisega viisil, mis vastab kasutaja nõuetele.

Staatiline mudel määratleb objektide struktuuri, tüübid ja objektidevahelised suhted. Dünaamiline mudel määratleb objektide käitumise ajas (objektide ajalugu) ja nende vastastikuse mõju.

Põhimõtteliselt on UML diskreetne modelleerimiskeel, see tähendab, et see sisaldab diskreetsete sündmuste ja olekumuutuste mõistet. Pidevaid protsesse modelleeritakse ligikaudu valimite abil.

Mudelil on kaks aspekti: semantiline teave (semantika) ja visuaalne esitlus (tähistamine).

UML-keeles esitatavate mudelite täielik komplekt on toodud tabelis 1

Tabel 1 - süsteemimudelite esitamine UML-keeles.

Süsteemi kõige tavalisem kontseptuaalne mudel on kasutusjuhtumite skeem, mis on ülejäänud skeemide lähtepunkt.

Kõik keele diagrammid on eritüüpi graafikud, need sisaldavad tippe (geomeetrilisi kujundeid), mis on ühendatud servadega (kaared). Tavaliselt pole pildi skaalal ja tippude asukohal tegelikult mingit tähtsust, aga järjestusdiagrammile lisatakse ajatelg ja seal on see oluline.

Lingid on tähistatud tasapinnal erinevate joontega, jooniste sisse on kirjutatud tekst, tippude ja linkide lähedal saab kuvada mõnda graafilist sümbolit. UML-laiendites on ruumidiagrammid lubatud.

Keeles on 4 tüüpi graafilisi struktuure:

· Ikoonid (piktogrammid);

· Graafilised sümbolid tasapinnal;

· Teed (jooned);

· Tekstiread.

1.6 Kontseptuaalne tasand. Kasuta juhtumimudelit

Üldiselt toimub objektorienteeritud disainiprotsess vastavalt struktuursete süsteemide analüüsi põhiprintsiipidele: ülalt-alla disain koos diagrammide hierarhia ülesehitamisega, viies meid järk-järgult tasandilt tasandile: kontseptuaalne - loogiline - füüsiline (teostus)

Tipptasemel skeemi peab välja pakkunuks A. Jacobson OOSE-s kasutage juhtumiskeemi süsteem tervikuna. See on tema, kes on süsteemi esialgne kontseptuaalne esitus ja mille eesmärk on:

· Määratleda simuleeritud domeeni üldised piirid ja kontekst;

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

· Koostage esialgne dokumentatsioon arendajate ja klientide - süsteemi kasutajate suhtlemiseks.

Mudeli vaatenurk: süsteemi väline kasutaja.Kasutusjuhtumite skeem sisaldab osalejaid, kasutusjuhtumeid ja seoseid.

Näitleja (näitleja, väline üksus, näitleja) - abstraktne kirjeldus sõnumite allikate / vastuvõtjate klassist, mis vahetult suhtleb süsteemi, alamsüsteemi või klassiga. See on kirjeldus rollmängib kasutaja (isik või muu süsteem, alamsüsteem, klass) süsteemiga suheldes. Sisuliselt on see süsteemile sarnaste teabenõuete üldistamine, mis nõuavad teatud teenus (teenus).

Aktanti ei pea samastama konkreetsega füüsiline isik või seade, kuigi põhimõtteliselt on see mõnikord võimalik, kui nad täidavad ainult ühte rolli. Kõige sagedamini - füüsiliselt - on erinevad inimesed ja seadmed, mis pääsevad süsteemi juurde sama teenuse saamiseks. Kõrgemal tasemel võivad aktandid olla näiteks operaator, süsteemiadministraator, andmebaasiadministraator, tavakasutaja või mis tahes klassi seadmed.

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

Paljudes esinejates pole peale inimeste teisi aktante. Aktandid võivad olla aga väline süsteem, sisend- / väljundseade või taimer (tavaliselt leidub manustatud reaalajasüsteemides). Kasutusjuhu aktantide hulgas paistab silma peaaktant(esmane näitleja), mis algatab töö süsteemiga. Ülejäänud on teisejärgulised, nad osalevad ka kasutusjuhtumis, saades tulemusi ja sisestades mõned vaheandmed.

Loogilisel ja füüsilisel tasandil esindavad aktante klassid ja klasside objekt-eksemplarid. Aktantide hierarhiat on võimalik üles ehitada, pärides kõik rollid ja suhted, atribuudid ja toimingud, mis esivanemal on. Järeltuleva aktandi eksemplari saab alati kasutada selles kohas süsteemis, kus deklareeritakse eellasaktandi kasutamist (asenduspõhimõte).

Aktanti saab skeemidel kujutada kahel viisil:

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

4. Standardlikum: “isik” koos kirjutisega (inimese sümbol)

Aktant on väljaspool süsteemi ja selle sisemist struktuuri ei määrata. Ta on sõnumite allikas / sihtkoht.

Klient

Kasutusjuht(kasutusjuhtum) - abstraktne kirjeldus teenistusklassi (teenusefunktsioonide) kohta, mida pakutavatele pakutakse vastuseks tema taotlustele.

Teenust võib pakkuda süsteem tervikuna, alamsüsteem või klass. Seega tähendab kasutusjuhtum süsteemi mõne funktsionaalsuse või käitumise modelleerimist. Kasutusjuhul on nimi ja see tähendab mõnda toimimisjärjestust, mis on nähtav välisele allikale / vastuvõtjale (aktant). Sel juhul on varjatud sisemine viis varjatud ja paljastatakse madalamatel detailitasemetel. koostööskeem... Nagu igal klassil, on ka kasutusjuhtudel atribuudid ja toimingud, mille rakendamine on paljastatud füüsilises kihis.

Kasutusjuhtum hõlmab kogu sõnumijada, mille aktant alustab ja süsteem (alamsüsteem, klass) lõpeb. Seetõttu on igal kasutusjuhtumi rakendamise igal juhtumil alati algus ajas ja lõpp, kui ükski tegutseja selle kasutuse kohta juba teateid ei saada. See hõlmab ka veateateid, valikuid hooldustoimingu teostamiseks erinevate seadistustega (alternatiivid).

Kasutusjuhtumi eksemplar on kasutusjuhtumi käivitamine, mis algab pärast seda, kui aktant-eksemplarilt on esimene sõnum kätte saadud. Vastusena antud sõnumile teostab kasutusjuht konkreetse toimingute jada, näiteks saadab sõnumi aktandi teistele eksemplaridele (mitte ainult algatajale). Omakorda saadavad need aktandid sõnumeid sellesse kasutusjuhtumi eksemplari ja suhtlemine jätkub seni, kuni enam sõnumeid pole saabunud. See tähendab kasutusjuhtumi lõppu.

Näidatakse aktiendi ja kasutamise juhtumi suhet ühing.

Diagramm kujutab kasutusjuhtumit kahel viisil:

1) ellips nime sees

2) ristkülik - nagu iga klass

Klient

Andur

Aktantide ja kasutusjuhtumite vahel on ainus seos seos. Pealegi on sellel semantika kommutatiivne suhtlus, see tähendab sõnumi edastamine, nii et seda tavaliselt ei märgistata, kuna kontekst selgub aktandi märkimisest ja kasutusjuhtumist. Kuid saate selle märkida ja näidata ka ühenduse sagedust:

Panga klient

Paljusus (paljusus) iseloomustab selles ühenduses osalevate klassi konkreetsete eksemplaride arvu (üks klient võib väljastada piiramatu arvu krediite).

Üldiselt ühing Kas suhe kahe või enama mudeli komponendi vahel. Kuna enamikul juhtudel on komponendid mõned objektiklassid, on assotsiatsiooni eksemplar lihtsalt järjestatud loetelu viidetest konkreetsetele eksemplaridele, mis võib olla varustatud assotsiatsiooniatribuutidega (atribuutidega).

Ühenduse nimi, kui see on olemas, peab olema kordumatu. See moodustatakse vastavalt klasside - ühingu liikmete vahelise suhte tähendusele. Näiteks: "Töötaja töötab aastal Osakond "," juhataja lõpetab Arvuti "jne.

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

Ühingu liikmeid nimetatakse selleks postid... Kõik poolused on suhtes osalevate klasside rollid, need erinevad ja neid saab loetleda mõnes järjestatud loendis. Enamasti on assotsiatsioonid binaarsed (kaks rolli koos teatud semantikaga), kuid neid võib ka olla n -arne. Üks ja sama klass võib tegutseda erinevates rollides, see tähendab olla samaaegselt assotsiatsiooni kahes pooluses.

Ühenduste arv on kinnitatud postidele.

Ühendused võivad süsteemi toimimise ajal ilmneda ja kaduda, piiranguid ja vastavaid predikaate saab näidata assotsiatsiooni poolustel.

Mõnikord muutub ühendus ainult ühes pooluses. Kui lingil on atribuudid, saab neid toimingutega muuta, kuid lingid liikmetele ei muutu.

Ühendust on kujutatud pideva joonega, mis ühendab 2 klassi piire, kui ühendus n- siis joonistatakse romb (liitmise märk):

		Paljud ühendused - liitmine
	Binaarühistu

Kasutusjuhud ei vaheta omavahel sõnumeid ja võivad olla ainult suhetes (ühendustes) laienemine (pikendada), kaasamine(lisada) ja üldistused (üldistus).

IN seoses laienemisega kasutuse juhtum - klient sisestab täiendava toimingute jada, alustades põhijärjestuse mõnest punktist, ja selliseid “sisestusi” võib olla mitu. Kõiki neid punkte nimetatakse laienemispunktid.

Ühtne protsess Ratsionaalne arendus (Rational Unified Process, RUP) on erinevate tegevuste summa, mis on vajalik kasutajate vajaduste muutmiseks tarkvarasüsteemiks. Selle abstraktne ja laiendatud kujutis on näidatud joonisel fig. 7.2.

RUP-i põhimõisted on artefakt ja pretsedent. Artefaktid on osa projekti toodetest, mis on selles loodud või kasutatud tarkvara lõpptoote kallal töötamisel. Pretsedendid või kasutamise juhtumid(kasutamise juhtum) ‑ need on toimingute jadad, mida tarkvarasüsteem teeb vaadeldava tulemuse saamiseks.

Kogu tarkvarasüsteemi arendamise protsessi käsitletakse RUP as artefakti loomise protsess... Veelgi enam, see, mis jääb lõppkasutaja kätte, olgu see tarkvaramoodul või tarkvara dokumentatsioon, on kõigi projekti artefaktide üks alaklass.

Iga projektimeeskonna liige loob oma esemed ja vastutab nende eest. Programmeerija töötab välja programmi, juht projektiplaani ja analüütik süsteemimudelid. RUP võimaldab teil määrata, millal, kellele ja mis artefakt tuleb luua.

(a)

Joonis: 7.2.Ühtne tarkvaraarenduse protsess ( a- abstraktne esitus, b - üksikasjalik ülevaade peamistest RUP-protsessidest)

Kuid RUP on rohkem kui üks protsess, see on üldine protsessiraamistik, mis võib olla spetsialiseerunud väga erinevatele tarkvarasüsteemidele, erinevatele rakendusvaldkondadele, oskuste tasemele ja projekti suurusele. RUP - komponentidele orienteeritud.See tähendab, et loodud tarkvarasüsteem on üles ehitatud tarkvarakomponentide baasil, mis on ühendatud täpselt määratletud liideste abil.

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.

Kuid RUP-protsessi tõeliselt spetsiifilised aspektid on kolmes fraasis - kasutamise juhtum, arhitektuurile orienteeritud, korduv ja inkrementaalne... See muudab Unified Process ainulaadseks.

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

1. äriprotsessi mudel, mis vormistab organisatsiooni abstraktsiooni (koos kõigi võimalustega haldava PS kasutamiseks ja nende sidemetega kasutajatega);

2. kasutage juhtumimudelit - vormistab süsteemi funktsionaalsed nõuded;

3. domeenimudel või ärimudelkirjeldades süsteemi konteksti.

4. analüüsimudel, millel on kaks eesmärki - selgitada kasutusjuhtumite üksikasju ja luua süsteemikäitumise esmane jaotus objektide komplekti suhtes, mis pakuvad erinevaid võimalusi käitumine;

5. protsessimudel (valikuline) - vormistab süsteemi paralleelsuse ja sünkroniseerimise mehhanismid;

6. kujundusmudelmis määratleb: a) - süsteemi staatiline struktuur, nagu alamsüsteemid, klassid ja liidesed, ja b) - kasutamisjuhud rakendatud kujul ühistudalamsüsteemide, klasside ja liideste vahel;

7. rakendamise mudel, mis sisaldab komponente (mida pakub lähtekood) ja klasside paigutust komponentide kaupa;

8. kasutuselevõtu mudelmis määratleb füüsilised arvutid - võrgusõlmed ja nende sõlmede komponentide paigutuse;

9. testimismudelsee kirjeldab testjuhtumeid kasutusjuhtumite kinnitamiseks;

Joonis: 7.3. RUP-mudelid (vastavate UML-diagrammide kujul)
ja nende seosed,

Kõik need mudelid on omavahel seotud. Koos kirjeldavad nad tarkvarasüsteemi täielikult. Ühe mudeli elementidel on edasi ja tagasi suunamispiirangud, mis on korraldatud linkide abil teistele mudelitele (vt joonis 7.3). Näiteks saab kasutusjuhtumi (kasutusjuhtumimudelis) jälgida kasutusjuhtumi (disainimudelis) ja testjuhtumi (testmudelis) vastava teostuseni. Jälgimine hõlbustab mõistmist ja muudatuste tegemist. RUP-i arendusprotsessi käigus loodud UML-diagrammid annavad tarkvaratoote kohta täieliku ülevaate).

Põhirõhk RUP-is ei ole mitte dokumentide kui selliste ettevalmistamisel, vaid sellel modelleerimine arendatav süsteem. Mudelid aitavad välja tuua nii probleemi kui ka selle lahendamise viisid ning nende loomisel kasutatakse UML-keelt, mis on pikka aega muutunud keerukate süsteemide kirjeldamise de facto standardiks ja võimaldab arendajatel määratleda, visualiseerida, kujundada ja dokumenteerida igasuguse keerukusega tarkvarasüsteemide artefakte.

Rational Unified Process (RUP) on üks parimaid tarkvaraarenduse metoodikaid ettevõttelt Rational Software. Tuginedes paljude edukate tarkvaraprojektide kogemustele, võimaldab ühtne protsess luua keerukaid tarkvarasüsteeme, mis põhinevad tööstuse arendusmeetoditel. RUP-i üks põhisambaid on mudelite loomine, kasutades ühtlast modelleerimiskeelt (UML). See artikkel käsitleb UML-diagrammide rakendamist Rational Software Development töövoole.

Pole saladus, et tarkvara loomine on keeruline protsess, millel on ühelt poolt palju pistmist loovusega, ja teiselt poolt, kuigi see on väga kasumlik, on see ka kulukas äri. Tihe konkurents turul sunnib arendajaid rohkem otsima tõhusad meetodid töö. Luues tarkvarasüsteeme veelgi enam lühike aeg, väiksemate kulude ja parema kvaliteediga. Programmide keerukus kasvab pidevalt. Kuni viimase ajani võisid tarkvaratooteid lähitulevikus luua üksikisikud või näiteks automatiseeritud ettevõtte IT-osakonnas.

Nüüd jäävad üksikutele, kes loovad programme "põlvili", väikeste utiliitide ja mitmesuguste "raskete" tarkvaratoodete laiendusmoodulite ala. Tulevik kuulub tööstuslikule lähenemisele tarkvaraarenduses. 1913. aastal käivitas Henry Ford esimese autokonveieri ja 90ndatel kasutati sarnast konveierit ka 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 loonud struktureeritud teadmusbaasi nimega Rational Unified Process (RUP), mis on põhjalik juhiste kogum praktiliselt iga tarkvaratoote loomiseks. Parimate arenduste kogemuste põhjal on RUP üksikasjalikult öelnud, millal, keda ja mida tuleks projektis teha, et tarkvarasüsteem õigeaegselt, kindla funktsionaalsusega ja eraldatud eelarve piires saada.

Ühtsest protsessist võib mõelda kui arendusettevõtte erinevate tegevuste summast, mis on vajalik klientide nõuete tarkvarasüsteemi teisendamiseks. Süsteem, mis pakub kasutajatele "sisukaid tulemusi" ja teeb täpselt seda, mida nad süsteemist ootavad. Seetõttu juhivad protsessi süsteemi kasutamise juhtumid või muul viisil - pretsedendid.

Kliendi nõuete õigeaegseks rakendamiseks jagatakse ühtne protsess faasideks, mis koosnevad iteratsioonidest, seetõttu nimetatakse protsessi ka iteratiivseks ja inkrementaalseks. Iga iteratsioon läbib põhitöö tsükli ja viib arendajad lõppeesmärgi juurde: tarkvarasüsteemi loomiseni. Korduste ajal luuakse projekti edukaks lõpuleviimiseks vajalikud vaheartefaktid ja tarkvarasüsteemi versioon, mis rakendab teatud funktsioonide komplekti, mis suureneb iteratsioonist iteratsioonini. Protsessi faasid ja peamised töövood on näidatud joonisel fig. 1 on toodud ka faaside ligikaudsed tööjõukulud.

joon. 1 RUP-faasid ja töövood

Tuleb märkida, et joonisel fig. 1 näitab ainult ühendatud protsessi põhitegevusi. Näiteks ei kuvata siin skeemi risustamise vältimiseks tegevuste haldamise tegevusi.

Kogu tarkvaraarendust vaadeldakse RUP-is kui artefaktide loomise protsessi. Kõik projekti töö tulemused, olgu need siis lähtekoodid, objektimoodulid, kasutajale edastatud dokumendid, mudelid on kõigi projekti artefaktide alaklassid. Iga projektimeeskonna liige loob oma esemed ja vastutab nende eest. Programmeerija loob programmi, juht projektiplaani ja analüütik süsteemimudelid. RUP võimaldab teil määratleda, millal, kelle poolt ja milline artefakt tuleb luua, muuta või kasutada.

Üks projekti artefaktide huvitavamaid klasse on mudelid, mis võimaldavad arendajatel tarkvarasüsteemi artefakte määratleda, visualiseerida, kujundada ja dokumenteerida. Iga mudel on iseseisev vaade arendatavale süsteemile ja on mõeldud nii probleemide piiritlemiseks kui ka lahenduste pakkumiseks. Mudelite iseseisvus tähendab, et analüütik või arendaja saab kogu vajamineva teabe konkreetselt mudelilt ilma muudest allikatest kasutamata.

Mudelid võimaldavad teil arvestada tulevase süsteemi, selle objektide ja nende koostoimega juba enne märkimisväärsete rahaliste vahendite arendusse investeerimist, võimaldavad seda näha juba tulevaste kasutajate väljastpoolt ja arendajate pilgu kaudu juba enne lähtekoodi esimese rea loomist. Enamikku mudeleid esindavad UML-diagrammid, UML-i kohta saate rohkem lugeda näiteks.

Ühtne modelleerimiskeel tekkis 1980. aastate lõpus ja 1990. aastate alguses, peamiselt tänu Grady Boochi, Jim Rambeau ja Ivar Jacobsoni "kolme sõbra" pingutustele. OMG on nüüd selle keele kasutusele võtnud standardse modelleerimiskeelena, mis annab arendajatele selge märke kuvada mudeleid graafilistes elementides, mida kõik projekti liikmed üldiselt aktsepteerivad ja mõistavad.

Siiski ei tohiks unustada, et modelleerimiskeel pakub ainult märke - tööriista süsteemi kirjeldamiseks ja modelleerimiseks ning ühtne protsess määrab selle tööriista kasutamise metoodika, samuti muud tööriistad Rationali metoodika toetamiseks. UML-i saab kasutada ilma konkreetse metoodikata, kuna see on protsessist sõltumatu ja ükskõik millist protsessivarianti rakendatakse, saate diagrammide abil dokumenteerida arenduse käigus tehtud otsuseid ja kuvada loodud mudeleid.

Tarkvarasüsteem on loodud konkreetsete kasutajaprobleemide lahendamiseks, mitte aga programmeerijate uute tehnoloogiate katsetamiseks ja projektijuhi kogemuste saamiseks. Üldiselt pole kasutajal vahet, kas kasutate arendusprotsessis objektorienteeritud lähenemist, UML-i, RUP-i või loote süsteemi XP (extreme programmeerimine) meetodil. Teatud meetodite, tehnoloogiate kasutamine, projekti optimaalse sisestruktuuri loomine jääb arendajate südametunnistusele, kes langetavad otsuseid varasema kogemuse ja oma eelistuste põhjal. Kuid kasutaja ei andesta teile, kui ignoreerite tema nõudeid. Kas tarkvarasüsteem on välja töötatud vähemalt kümme korda, kasutades tipptehnoloogia meetodeid ja tehnoloogiaid, kui kasutaja ei saa sellest nn tähendusrikast tulemust, kukub teie tarkvaraprojekt haledalt läbi.

Sellest järeldub, et UML-i läbimõtlematu kasutamine lihtsalt sellepärast, et see on moes, ei too mitte ainult kaasa edu arendamisele, vaid võib põhjustada ka rahulolematust töötajate seas, kes peavad uurima suurt hulka täiendavat kirjandust, ja projektijuhte, kui selgub, et projekti tööjõukulud suurenevad. ja tootlus ei suurene. Peate olema selge, mida soovite selle tehnoloogia rakendamisel saada, ja järgige seda eesmärki. UML-i kasutamine säästab arendusressursse, kuna see võimaldab teil süsteemist aimu saada kiiremini kui makettide ja prototüüpide loomisel, kulutades võrreldamatult vähem ressursse.

Diagrammid hõlbustavad projekti liikmete omavahelist suhtlemist ja mis on eriti väärtuslik, kaasavad protsessi süsteemi lõppkasutajad. Modelleerimine võimaldab teil vähendada projekti riske, kuna programmeerijatel on alati lihtsam teha seda, mis on selge ja arusaadav, kui minna määramata tulemuse juurde. Diagrammide koostamine sarnaneb ehituses projekti loomisega - ilma selleta saab hakkama näiteks suvilasse kuuri ehitades, aga seda suurem on hoone (meie puhul tarkvara), seda keerulisem on seda teha ja seda ebakindlam on lõpptulemus.

Õpetasin kunagi tarkvarafirmas RUP-seminari, mis on kümme aastat turul üsna edukalt tegutsenud, kuid ei kasuta oma töövoos üldse modelleerimist, vaid tugineb prototüüpidele. Saali kogunes paarkümmend noort ja kogenud programmeerijat, kes kuulasid tähelepanelikult kõike, mida ma neile RUP-i ja UML-i kohta rääkisin. Ja üks neist, vaadates tahvlit, millel on diagrammide näited, märkis: "See kõik on huvitav ja sobib tõenäoliselt ka teiste projektide jaoks," ütles ta, "kuid ilma selleta oleme töötanud üsna pikka aega, kuna oleme endiselt saime läbi ilma UMLita, ilmselt pole seda lihtsalt vaja. "

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

1. Nõuete määratlemine

Ühtne protsess on kasutusjuhtumipõhine protsess, mis haarab kasutaja interaktsiooni stsenaariume. Tegelikult on see kasutaja vaade tarkvarasüsteemile väljastpoolt. Seega saab RUP-i üheks olulisemaks arenguetapiks nõuete kindlaksmääramise etapp, mis seisneb kõigi võimalike soovide kogumises süsteemi toimimiseks, millele võivad mõelda ainult kasutajad ja analüütikud. Hiljem tuleb need andmed süstematiseerida ja struktureerida, kuid praeguses etapis peavad kasutajate intervjuude ja dokumentide uurimise ajal analüütikud koguma tulevase süsteemi jaoks võimalikult palju nõudeid, mis pole nii lihtne, kui esmapilgul tundub. Kasutajatel pole sageli aimugi, mida nad lõpuks peaksid saama. Selle protsessi hõlbustamiseks kasutavad analüütikud juhtumiskeeme (joonis 2)

joonis 2. Kasutusjuhtumi skeemi näide

Diagramm on süsteemiga suhtlevate osalejate (näitlejate) peegeldus ja tarkvaraobjektide reaktsioon nende tegevusele. Näitlejad võivad olla nii kasutajad kui ka välised agendid, kellel on vaja teavet edastada või vastu võtta. Kasutusjuhtumi ikoon peegeldab süsteemi reageerimist välisele stiimulile ja näitab, mida tuleb aktandi jaoks teha.

Konkreetse kasutusjuhtumi üksikasjalikumaks kirjeldamiseks kasutatakse tegevuste skeemi, mille näide on toodud joonisel 3.

joon. 3 Näide tegevuse diagrammist

Kasutusjuhu skeemi lihtsus võimaldab analüütikutel nõuete määratlemisel klientidega hõlpsalt suhelda, tuvastada süsteemile ja üksikute nõuete täitmisele seatud piirangud, näiteks süsteemi reageerimisaeg, mis hiljem jaguneb mittetoimivate nõuete sektsiooni.

Kasutamisjuhtude skeemi saab kasutada ka teststsenaariumide loomiseks, kuna kogu kasutaja ja süsteemi interaktsioon on juba määratletud.

Nõuete õigeks määratlemiseks peavad arendajad mõistma konteksti (domeeni osa), milles tulevane süsteem töötab. Selleks luuakse domeenimudel ja ärimudel, mis on samale küsimusele erinevad lähenemised. 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 seoseid omavahel. Ärimudel kirjeldab äriprotsesse (olemasolevaid või tulevasi), mida süsteem peab toetama. Seetõttu määratleb see mudel lisaks protsessis osalevate äriobjektide määratlemisele ka töötajad, nende kohustused ja tegevused, mida nad peavad tegema.

Domeenimudeli loomiseks kasutatakse tavapärast klassiskeemi (joonis 6), kuid ärimudeli loomiseks sellest selgelt ei piisa. Sellisel juhul kasutatakse kasutusjuhtude skeemi koos täiendavate ikoonidega, mis kajastavad äriprotsesside olemust - äriaktant, ärikasutusjuhtum, äriüksus ja ärijuhtimine. See mudel on palju lähemal järgmisele arenduse käigus loodud mudelile - analüüsimudelile.

2. Analüüs

Pärast nõuete ja süsteemi toimimise konteksti määratlemist on aeg saadud andmeid analüüsida. Analüüsi käigus luuakse analüütiline mudel, mis viib arendajad tulevase süsteemi arhitektuurini. Analüütiline mudel on pilk süsteemile seestpoolt, erinevalt kasutusjuhtumismudelist, 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 selles peaksid olema ja kuidas nad peaksid üksteisega suhtlema. Selle peamine eesmärk on määrata kindlaks nõuete kogumise etapis tuvastatud funktsionaalsuse rakendamise suund ja teha visand süsteemi arhitektuurist.

Erinevalt hiljem loodavast disainimudelist on analüüsimudel pigem kontseptuaalne mudel ja viib arendajad rakendusklassidele lähemale. Sellel mudelil ei tohiks olla võimalikke vastuolusid, mis võivad esineda kasutusjuhtumudelis.

UML-i kasutava analüüsimudeli kuvamiseks kasutatakse klasside skeemi stereotüüpidega (käitumismustrid) "piiriklass", "üksus", "kontroll" ja üksikasjalikumaks kasutamiseks koostööskeeme (koostöö) (joonis 4). Stereotüüp "piiriklass" kuvab klassi, mis suhtleb väliste aktantidega, "olem" - kuvab klassid, mis on andmekogud, ja "haldus" - klassid, mis haldavad üksustele päringuid.

joonis 4. Koostööskeemi näide

Sõnumite numeratsioon näitab nende järjekorda, kuid skeemi eesmärk pole näidata sõnumite vahetamise järjekorda, vaid visuaalselt näidata klasside suhet üksteisega.

Kui keskendume interaktsiooni järjekorrale, siis on selle teiseks esituseks järjestusskeem (järjestus), mis on näidatud joonisel 5. See diagramm võimaldab teil vaadata sõnumite vahetust ajas, visuaalselt kuvada protsessi jada. Kui kasutate tööriista selliste mudelite loomiseks nagu Rational Rose, saab neid kahte tüüpi diagramme üksteisest automaatselt luua (Rational Rose'i kohta lisateabe saamiseks võite lugeda näiteks sisse).

Joonis: 5 Näidisjärjestuse skeem

Otsus selle kohta, kumb kahest diagrammist kõigepealt luua, sõltub konkreetse arendaja eelistustest. Kuna need diagrammid peegeldavad sama protsessi, võimaldavad mõlemad kajastada objektide vastastikust mõju.

3. Kujundus

Järgmine samm süsteemi loomise protsessis on disain, mille käigus luuakse varem loodud mudelite põhjal kujundusmudel. See mudel kajastab süsteemi füüsilist rakendamist ja kirjeldab loodud toodet klasside ja komponentide tasandil. Erinevalt analüüsimudelist sõltub disainimudel otsesõnu rakendamistingimustest, kasutatud programmeerimiskeeltest ja komponentidest. Süsteemi arhitektuuri kõige täpsemaks mõistmiseks tuleks see mudel võimalikult palju vormistada ja ajakohastada kogu süsteemi arendamise elutsükli vältel.

Kujundusmudeli loomiseks kasutatakse tervet UML-diagrammide komplekti: klasside skeemid (joonis 5), koostööskeemid, interaktsiooniskeemid ja tegevusdiagrammid.

joonis 6. Klassiskeemi näide

Lisaks võib see töövoog luua juurutusdiagrammil põhineva juurutusmudeli. See on lihtsaim skeemitüüp seadmete jaotuse võrgus simuleerimiseks. Kuvamiseks kasutatakse ainult kahte protsessori ja seadme ikooni versiooni koos nende vaheliste ühendustega.

4. Rakendamine

Rakendusprotsessi peamine ülesanne on luua süsteem komponentide kujul - programmide lähtekoodid, skriptid, binaarkaardid, käivitatavad moodulid jne. Selles etapis luuakse rakendusmudel, mis kirjeldab, kuidas kujundusmudeli elemente rakendatakse, millised klassid lisatakse konkreetsetesse komponentidesse. See mudel kirjeldab nende komponentide korraldamise viisi vastavalt valitud programmeerimiskeskkonnas vastuvõetud struktureerimise ja mooduliteks jaotamise mehhanismidele ning seda esindab komponentide skeem (joonis 7).

joon. 7 Komponentskeemi näide

5. Testimine

Testimisprotsess kontrollib rakendamise tulemusi. Selle protsessi jaoks luuakse testimismudel, mis koosneb testjuhtumitest, testimisprotseduuridest, testikomponentidest, kuid sellel pole UML-diagrammiga vastendamist, nii et me ei peatu sellel.

6. Järeldus

Siin on käsitletud ainult ratsionaalse metoodika põhiprotsesse. RUP on üsna ulatuslik ja annab juhiseid mitmesuguste tarkvaraprojektide haldamiseks alates programmide loomisest mitme inimese arendajate meeskonna poolt kuni hajutatud tarkvaraprojektideni, mis toovad kokku tuhandeid inimesi erinevatel mandritel. Vaatamata nende kolossaalsele erinevusele on UML-iga loodud mudelite rakendamise meetodid samad. Erinevates arenguetappides loodud UML-diagrammid on tarkvara projekti ülejäänud artefaktidest lahutamatud ja on sageli ühenduslüliks üksikute RUP-protsesside vahel.

Konkreetsete skeemide kasutamise otsus sõltub ettevõtte kehtestatud arenguprotsessist, mis, ehkki seda nimetatakse ühtseks, pole siiski midagi külmutatud. Rational pakub mitte ainult selle täiustamist ja täpsustamist, vaid pakub ka spetsiaalseid tööriistu RUP-i andmebaasi muudatuste tegemiseks.

Kuid igal juhul võimaldab UML-i kasutamine koos ühtse protsessiga saada prognoositavat tulemust, hoida ettenähtud eelarve piires, suurendada projektis osalejate tasuvust ja loodud tarkvaratoote kvaliteeti.

Krachten. F. Sissejuhatus Ratsionaalne ühtne protsess . Ed. 2 - e. - M.: Kirjastus "Williams", 2002. - 240 lk: ill.

Yakobson A., Booch G., Rambeau J. ühtne tarkvaraarendusprotsess - Peterburi: Peter, 2002. - 496 lk: ill.

Fowler M., Scott K. UML kokkuvõttes. Objektide modelleerimise standardkeele rakendamine: Per. inglise keelest - M .: Mir, 1999. - 191 lk., Ill.

Beck. E. Äärmuslik programmeerimine. - SPb.: Peter, 2002. - 224 lk: ill.

Trofimov S. CASE tehnoloogiad: Praktiline töö aastal Rational Rose.
Ed. 2. - M.: Binom-Press, 2002 - 288 lk.

Ratsionaalne ühtne protsess (RUP) - tarkvara arendamise metoodika, mille on loonud Rational Software.

Põhimõtted: Peamiste riskide varajane tuvastamine ja pidev (kuni projekti lõpuni) kõrvaldamine. Keskendumine käivitatava programmi klientide nõuete täitmisele (kasutusjuhtumite (kasutusjuhtumite) mudeli analüüs ja konstrueerimine). Ootan nõuete, disainiotsuste ja rakendamise muudatusi arenduse käigus. Projekti alguses rakendatud ja testitud komponendi arhitektuur. Pidev kvaliteedi tagamine kõigis projekti (toote) arendamise etappides.

Töötamine tihedas meeskonnas projekti kallal, milles arhitektidel on võtmeroll.

RUP kasutab iteratiivne arengumudel... Iga iteratsiooni lõpus (ideaalsel juhul kestab see 2 kuni 6 nädalat) peaks projekti meeskond saavutama selle iteratsiooni jaoks kavandatud eesmärgid, looma või viimistlema kujunduse esemeid ja hankima lõpptoote vahepealse, kuid funktsionaalse versiooni.

Tootearenduse täielik elutsükkel koosneb neli faasi, millest igaüks sisaldab ühte või mitut kordust: algfaas, täpsustamis-, kavandamis- ja juurutusetapp.

Äärmuslik programmeerimine (XP)

Äärmuslik programmeerimine (Extreme Programming, XP) on üks vilgas tarkvaraarenduse metoodika

12 põhitehnikat Äärmusliku programmeerimise (vastavalt raamatu esmatrükile Selgitatud äärmuslik programmeerimine) võib jagada nelja rühma:

Lühike tsükkel tagasiside: (Testpõhine arendus, plaanimäng, klient on alati olemas, paari programmeerimine

Pidev, mitte partiiprotsess: Pidev integreerimine, refaktoreerimine, sagedased väikesed väljalasked

Kõigi ühine arusaam: Lihtsus, süsteemimetafoor, koodi või valitud kujundusmustrite ühine omamine, kodeerimisstandard

Programmeerija sotsiaalkindlustus: 40 tundi töönädal

Paaride programmeerimine eeldab, et kogu koodi loovad programmeerijate paarid, kes töötavad samas arvutis. Jagatud omand tähendab seda, et iga meeskonnaliige vastutab kogu lähtekoodi eest. XP klient ei maksa arveid, vaid see, kes süsteemi tegelikult kasutab.

Dokumentatsiooni standardid

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

SVVP -Plaan määratleb, kuidas ja millises järjekorras tuleks projekti etappe kontrollida. Kontrollimine on protsess, mille abil kontrollitakse, kas rakendus on õigesti ehitatud. Valideerimine kontrollib, kas vajalik toode on kokku pandud.

SQAP -Tarkvara kvaliteedikontrolli kava

SCMP -Tarkvara projekti juhtimise kava

SRS -Tarkvaranõuete spetsifikatsioon

SDD -Tarkvara disaini dokumentatsioon

Suguhaigus -Tarkvara testimise dokumentatsioon

Dokumentatsiooni järjepidevus ja terviklikkus.

Dokumendihaldus nõuab märkimisväärseid korraldamisoskusi. Hea paindliku dokumentatsiooni kirjutamine sarnaneb hea paindliku koodi kirjutamisega.

Dokumendihaldus seisneb hoolduses täielikkus ja järjepidevus ja sisaldab ka konfiguratsiooni juhtimine.

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

Järjepidevus tähendab, et dokumentide komplekt ei sisalda sisemisi vastuolusid. Probleem on selles, et kui see komplekt on suur, on selles üsna keeruline vältida üksteist välistavate avalduste esinemist.

Konfiguratsiooni tugi -see on dokumentatsiooni erinevate versioonide ja osade ning programmikoodi kooskõlastamine.