Proces unificat de dezvoltare software. Proces de dezvoltare unificat și programare extremă

În conformitate cu GOST 34.601-90 „AS. Etapele creației” stabilește următoarele etape de creare a unui AIS, care, la rândul său, poate fi împărțit în etape:

· formarea cerințelor pentru AIS;

· dezvoltarea conceptului AIS;

· sarcină tehnică;

· proiectare preliminară;

· proiect tehnic;

· documentație de lucru;

· punere in functiune.

Fiecare etapă are propriul set de documentație de proiectare și implementare a modulelor tehnice și software ale sistemului. Practica arată că procesul de creare a unui sistem este iterativ și incremental. Autorii UML subliniază acest lucru atunci când definesc conceptul proces unificat de dezvoltare a software-ului și a informațiilor. Deși în prima etapă se formează un set de cerințe pentru AS în ansamblu, de fapt acesta este întotdeauna incomplet la început și este clarificat în etapele ulterioare. Eu trebuie să fac iterații, adică repetați pașii și etapele individuale, fie în întregime, fie în parte. În plus, un sistem real este multifuncțional și complex, deci este de obicei împărțit în subsisteme și seturi separate de sarcini, distingând subsistemele și sarcinile primei etape, celei de-a doua etc. Sistemul este creat treptat, prin creșteri treptate de funcționalitate cu înlocuirea soluțiilor preliminare de proiectare cu altele mai dezvoltate, care răspund mai bine cerințelor utilizatorilor. Acest lucru reduce riscurile financiare și economisește timp și consumul de resurse în etapele finale ale creării.

Când se utilizează metodologia UML pentru a crea software AIS și suport pentru informații, se propune construirea unui set de modele interconectate care să reflecte proprietățile statice și dinamice ale viitorului sistem:

· model de caz de utilizare;

· model de analiză;

· model de proiectare;

· model de implementare;

· model de implementare;

· model de testare.

Model de caz de utilizare include diagrame de cazuri de utilizare și scenarii corespunzătoare, descrie cerințele funcționale ale sistemului și comportamentul acestuia atunci când interacționează cu utilizatorii.

Model de analiză include diagrame de clasă generice pentru implementarea cazurilor de utilizare la nivel logic, diagrame de secvență asociate și/sau diagrame de colaborare și este o schiță a modului în care vor fi implementate cazurile de utilizare la nivel logic.

Model de design este o reprezentare detaliată a implementării fizice a modelului de analiză și include diagrame de pachet (subsistem), diagrame de clasă detaliate, diagrame de secvență și/sau diagrame de cooperare, diagrame de stare, diagrame de activitate cu diferite grade de detaliu.

Model de implementare include diagrame preliminare de implementare care definesc toate configurațiile de rețea pe care poate rula sistemul. Diagramele de implementare indică nodurile de rețea, tipurile de conexiune și distribuția claselor de sistem active între noduri.

Model de implementare descrie modul în care clasele de proiectare sunt implementate ca componente. În consecință, include diagrame ale componentelor, urme de clasă (implementare), diagrame detaliate de implementare și o descriere a arhitecturii sistemului.

Model de testare conține un set de cazuri de testare, proceduri de testare și descrieri ale componentelor de testare. Specifică metode de testare a componentelor sistemului executabil.

Să comparăm procesele de construire a modelelor cu etapele standardizate ale creării unui AS. Modelul de caz de utilizare este construit în etapa de formare a cerințelor pentru AS; modelul de analiză se află în stadiul dezvoltării conceptului AS. La etapa de specificații tehnice și proiectare preliminară se construiește un model de proiectare. Este rafinat în etapa de proiectare tehnică și completat de un model de implementare. În etapa de documentare de lucru, sunt create modele de implementare și testare. In final, in faza de punere in functiune, modelul de testare este rafinat si devine model de referinta in timpul functionarii, destinat verificarilor periodice ale functionarii corecte si diagnosticarii sistemului.

1.5 Componentele limbajului UML

Limbajul de modelare unificat UML(Unified Modeling Language) este un limbaj de modelare vizuală utilizat pentru specificarea, vizualizarea, configurarea și documentarea sistemelor complexe (inclusiv software) folosind tehnologia orientată pe obiecte.

La crearea unui AS în metodologia UML, sunt utilizate principiile analizei sistemului structural cunoscute din metodologiile Hein/Sarson și SADT:

· dezvoltare de sus în jos etapă cu etapă;

· tehnica diagramării;

· ierarhia descrierilor;

· formalizarea strictă a descrierii soluțiilor de proiectare;

· dezvoltarea inițială a proiectului la nivel logic fără detalii de implementare tehnică;

· modelare conceptuală din punct de vedere al domeniului subiectului pentru ca clientul să înțeleagă proiectarea sistemului;

· suport tehnologic cu instrumente (sisteme CASE).

Un model al unui sistem complex în UML poate fi studiat pentru a obține caracteristici estimate ale eficienței proceselor din sistem.

Modelele pentru implementarea, implementarea și testarea software-ului AS și a suportului de informații în UML pot fi utilizate ca proiect de aplicație cu generarea automată ulterioară a codului aplicației într-unul dintre mediile de programare selectate.

Un model destul de complet al unui sistem complex ar trebui să reflecte două aspecte:

-static(structural) – compoziția, structura componentelor și relațiile acestora;

-dinamic(comportamental) – descrierea logicii proceselor care au loc în sistem sau care urmează să fie implementate.

Principala metodă de reprezentare a modelelor adoptate în UML sunt diagramele furnizate cu informații textuale, inclusiv expresii în limbajul de constrângere încorporat OCL, precum și în limbajele de programare și interogare de informații utilizate pentru implementarea sistemului.

Principiul de bază al modelării: un sistem este modelat ca un grup de obiecte discrete care interacționează între ele în așa fel încât să satisfacă cerințele utilizatorului.

Un model static specifică structura, tipurile de obiecte și relațiile dintre obiecte. Modelul dinamic determină comportamentul obiectelor în timp (istoria obiectelor) și interacțiunea lor.

În mod fundamental, UML este un limbaj de modelare discret, adică conține conceptul de evenimente discrete și schimbări de stare. Procesele continue sunt modelate aproximativ prin discretizare.

Modelul are două aspecte: informația semantică (semantică) și reprezentarea vizuală (notația).

Compoziția completă a reprezentărilor modelului în limbajul UML este dată în Tabelul 1

Tabelul 1 – Reprezentarea modelelor de sistem în UML.

Cel mai comun model conceptual al unui sistem este diagrama de caz de utilizare este punctul de plecare pentru construirea altor diagrame.

Toate diagramele de limbaj sunt grafice de tip special, care conțin vârfuri (figuri geometrice) conectate prin muchii (arce). De obicei, scara imaginii și locația vârfurilor nu sunt deosebit de importante, totuși, în diagrama de secvență este introdusă axa timpului și acolo este semnificativă.

Conexiunile sunt indicate prin diferite linii pe plan, textul este scris în interiorul figurilor și unele simboluri grafice pot fi reprezentate lângă vârfuri și conexiuni. Extensiile UML permit diagrame spațiale.

Limbajul are 4 tipuri de structuri grafice:

· icoane (pictograme);

· simboluri grafice pe un plan;

· poteci (linii);

· linii de text.

1.6 Nivel conceptual. Model de caz de utilizare

În general, procesul de proiectare orientată pe obiect are loc în conformitate cu principiile de bază ale analizei sistemelor structurale: proiectare de sus în jos cu construirea unei ierarhii de diagrame care ne mută treptat de la nivel la nivel: conceptual – logic – fizic (implementare)

Diagrama de nivel superior este considerată a fi cea propusă de A. Jacobson în OOSE diagrama cazului de utilizare sisteme ca un întreg. Aceasta este reprezentarea conceptuală inițială a sistemului și este construită cu scopul de a:

· determina granițele generale și contextul domeniului subiectului modelat;

· formula cerințe generale pentru comportamentul funcțional și interfața sistemului;

· pregătirea documentației inițiale pentru interacțiunea dintre dezvoltatori și clienți - utilizatorii sistemului.

Punctul de vedere al modelului: utilizator extern al sistemului. O diagramă de caz de utilizare include actori, cazuri de utilizare și asocieri.

Actant(actor, entitate externă, actor) - o descriere abstractă a unei clase de surse/receptoare de mesaje care interacționează direct cu un sistem, subsistem sau clasă. Aceasta este descrierea roluri jucat de utilizator (persoană sau alt sistem, subsistem, clasă) în timpul interacțiunii cu sistemul. În esență, aceasta este o generalizare a solicitărilor de informații similare la sistem care necesită o anumită serviciu(Servicii).

Actantul nu trebuie neapărat să fie identificat cu un anumit individ sau dispozitiv, deși, uneori, acest lucru este posibil, în principiu, dacă au un singur rol. Cel mai adesea - fizic - acestea sunt persoane și dispozitive diferite care accesează sistemul pentru a primi același serviciu. La cel mai înalt nivel, de exemplu, actanții pot fi un operator, un administrator de sistem, un administrator de baze de date, un utilizator obișnuit sau o anumită clasă de dispozitive.

Toți actanții posibili epuizează toate căile posibile de interacțiune a utilizatorului cu sistemul (subsistem, clasă). La implementarea unui sistem, actanții sunt întruchipați în oameni și obiecte fizice. O persoană sau obiect fizic, în funcție de modul de interacțiune, poate reprezenta mai mulți actanți (roluri diferite). De exemplu, aceeași persoană poate fi un operator și un administrator de baze de date, un vânzător și un cumpărător etc.

În multe AS nu există alți actanți cu excepția oamenilor. Cu toate acestea, actanții pot fi un sistem extern, un dispozitiv I/O sau un cronometru (se găsesc în mod obișnuit în sistemele încorporate în timp real). Dintre actanții din cazul de utilizare, unul iese în evidență actant principal(actor primar), care inițiază lucrul cu sistemul. Restul sunt secundare, participă și la cazul de utilizare, primind rezultate și introducând câteva date intermediare.

La nivel logic și fizic, actanții sunt reprezentați de clase și obiecte care sunt instanțe ale claselor. Este posibil să se construiască o ierarhie de actanți cu moștenirea tuturor rolurilor și relațiilor, atributelor și operațiilor pe care le are actantul strămoș. O instanță a unui actant copil poate fi întotdeauna folosită în locul din sistem în care este declarată utilizarea actantului strămoș (principiul substituției).

Un actant poate fi reprezentat pe diagrame în două moduri:

3. Simbolul clasei (dreptunghi) cu indicarea internă a stereotipului

4. Mai standard: „om” cu o inscripție (simbol al unei persoane)

Actantul se află în afara sistemului și structura sa internă nu este determinată. Este sursa/receptorul mesajelor.

Client

Utilizare caz(precedent, caz de utilizare) – o descriere abstractă a clasei de serviciu (funcții de serviciu) furnizată actantului ca răspuns la solicitările acestuia.

Serviciul poate fi furnizat de sistem ca întreg, un subsistem sau o clasă. Astfel, un caz de utilizare înseamnă modelarea unei părți din funcționalitatea sau comportamentul unui sistem. Un caz de utilizare are un nume și înseamnă o anumită secvență de acțiuni vizibile pentru o sursă/receptor extern (actant). Modul intern de implementare a opțiunii este ascuns și dezvăluit la niveluri inferioare de detaliu. diagrama de cooperare. Ca orice clasă, un caz de utilizare are atribute și operații, a căror implementare este expusă la nivelul fizic.

Cazul de utilizare include întreaga secvență de mesaje pe care actantul începe și se termină cu sistemul (subsistem, clasă). Prin urmare, orice instanță a implementării unui caz de utilizare are întotdeauna un început în timp și un sfârșit atunci când niciun actant nu trimite mesaje pentru această opțiune. Aceasta include și mesaje de eroare, opțiuni pentru efectuarea funcției de întreținere cu diverse setări (alternative).

O instanță de caz de utilizare este execuția unui caz de utilizare care începe după prima primire a unui mesaj de la o instanță actant. Ca răspuns la un mesaj dat, cazul de utilizare realizează o secvență specifică de acțiuni, cum ar fi trimiterea unui mesaj către alte instanțe ale actantului (nu doar inițiatorul). La rândul lor, acești actanți trimit mesaje către această instanță de caz de utilizare, iar interacțiunea continuă până când nu mai sunt primite astfel de mesaje. Aceasta marchează sfârșitul cazului de utilizare.

Este prezentată relația dintre actant și cazul de utilizare asociere.

Diagrama descrie cazul de utilizare în două moduri:

1) o elipsă, un nume este plasat în interior

2) un dreptunghi - ca orice clasă

Client

Senzor

Între actanți și cazuri de utilizare, asocierea este singurul tip de conexiune. Mai mult, are semantică comutarea comunicării, adică transmiterea mesajului, de obicei nu este semnalată, deoarece contextul este clar din actant și notația cazului de utilizare. Dar îl puteți marca și, de asemenea, să indicați multiplicitatea conexiunii:

Client bancar

Multiplicitate(multiplicitatea) caracterizează numărul de instanțe specifice ale unei clase care participă la o anumită conexiune (un client poate emite un număr nelimitat de împrumuturi).

În general asociere este o relație între două sau mai multe componente ale modelului. Deoarece în majoritatea cazurilor componentele sunt niște clase de obiecte, o instanță de asociere este pur și simplu o listă ordonată de referințe la instanțe specifice, poate echipată cu atribute de asociere (proprietăți).

Numele asociației, dacă există unul, trebuie să fie unic. Se formează în funcție de sensul relațiilor dintre clasele care participă la asociație. De exemplu, „Angajat lucrează în Manager de departament completează Computer”, etc.

Asociațiile sunt ele însele clase ( clasa de asociere, clasa de asociere), are atât proprietăți de clasă, cât și proprietăți de asociere. Instanțele acestei clase sunt conexiuni care au nu numai legături către obiecte, ci și valori de atribut (proprietăți).

Membrii asociației se numesc ei stâlpi. Toți polii sunt rolurile claselor implicate în conexiune, sunt distincti și pot fi enumerați într-o listă ordonată. În cele mai multe cazuri, asocierile sunt binare (două roluri într-o asociere cu o anumită semantică), dar pot exista și n -ary. Una și aceeași clasă poate acționa în roluri diferite, adică să fie simultan în doi poli ai asociației.

La poli este indicată multiplicitatea conexiunilor.

Conexiunile pot apărea și dispărea în timpul funcționării sistemului, pot fi specificate restricții și predicate corespunzătoare la polii asociației.

Uneori conexiunea se schimbă doar la unul dintre poli. Dacă un link are atribute, atunci acestea pot fi modificate prin operații, totuși, legăturile către participanții la link nu se modifică.

O asociere este reprezentată ca o linie continuă care leagă limitele a 2 clase dacă asocierea n-ary, apoi se desenează un romb (semn de agregare):

		Multe asociații - agregare
	Asociere binară

Cazurile de utilizare nu fac schimb de mesaje între ele și pot fi doar în relații (conexiuni) extensii(extinde) includere(include) și generalizări(generalizare).

ÎN referitor la extindere caz de utilizare – clientul introduce o secvență suplimentară de acțiuni, începând de la un punct din secvența principală și pot exista mai multe astfel de „inserții”. Toate aceste puncte sunt numite puncte de expansiune.

Rational Unified Process (RUP) este una dintre cele mai bune metodologii de dezvoltare software, creată de Rational Software. Bazat pe experiența multor proiecte software de succes, Procesul Unificat vă permite să creați sisteme software complexe bazate pe metode de dezvoltare industrială. Unul dintre principalii piloni pe care se bazează RUP este procesul de creare a modelelor folosind Unified Modeling Language (UML). Acest articol este despre utilizarea diagramelor UML în fluxul de lucru de dezvoltare a sistemelor software folosind metodologia Rational Software.

Nu este un secret pentru nimeni că crearea de software este un proces complex, care, pe de o parte, are multe în comun cu creativitatea, iar pe de altă parte, deși este o afacere foarte profitabilă, este și o afacere cu costuri ridicate. Concurența acerbă pe piață îi obligă pe dezvoltatori să caute metode de lucru mai eficiente. Modalități de a crea sisteme software într-un timp și mai rapid, la costuri mai mici și cu o calitate mai bună. Complexitatea programelor este în continuă creștere. Până de curând, produsele software puteau fi create într-un interval de timp previzibil de către persoane fizice sau, de exemplu, în departamentul IT al unei întreprinderi automatizate.

În zilele noastre, persoanele care creează programe în genunchi rămân cu zona de utilități mici și diverse module de extensie pentru produse software „grele”. Viitorul aparține abordării industriale a creării de software. În 1913, Henry Ford a lansat prima linie de asamblare de automobile, iar în anii 90 a început să fie utilizată o linie de asamblare similară în domeniul tehnologiilor IT. Dezvoltarea echipei necesită o abordare complet diferită și o metodologie diferită, care mai devreme sau mai târziu trebuia creată.

Rational Software Corporation (http://www.rational.com) a lansat o bază de cunoștințe structurată numită Rational Unified Process (RUP), care este un set de recomandări cuprinzătoare pentru a crea aproape orice produs software. După ce a absorbit experiența celor mai bune dezvoltări, RUP spune în detaliu când, cine și ce trebuie făcut în proiect pentru a ajunge la un sistem software la timp, cu o anumită funcționalitate și în bugetul alocat.

Procesul unificat poate fi gândit ca suma diferitelor activități ale companiei de dezvoltare necesare pentru a traduce cerințele clienților într-un sistem software. Un sistem care ar oferi „rezultate semnificative” utilizatorilor și ar face exact ceea ce se așteaptă de la sistem. Prin urmare, procesul este controlat de cazurile de utilizare ale sistemului, sau altfel - precedente.

Pentru a implementa cerințele clienților la timp, Procesul Unificat este împărțit în faze care constau în iterații, motiv pentru care procesul este numit și iterativ și incremental. Fiecare iterație trece printr-un ciclu de lucru de bază și îi aduce pe dezvoltatori la obiectivul final: crearea unui sistem software. În timpul iterațiilor, sunt create artefacte intermediare care sunt necesare pentru finalizarea cu succes a proiectului și o versiune a sistemului software care implementează un anumit set de funcții, care crește de la iterație la iterație. Fazele și fluxurile principale de lucru ale procesului sunt prezentate în Fig. 1, acolo sunt date și costurile aproximative cu forța de muncă ale lucrării pe fază.

orez. 1 fazele RUP și fluxurile de lucru

Trebuie remarcat faptul că în fig. 1 arată doar activitatea principală a Procesului Unificat. De exemplu, activitățile de management al activității nu sunt afișate aici pentru a evita aglomerarea diagramei.

Toată dezvoltarea software-ului este considerată în RUP ca un proces de creare a artefactelor. Orice rezultat al proiectului, fie că este vorba de coduri sursă, module obiect, documente transferate utilizatorului, modele - acestea sunt subclase ale tuturor artefactelor proiectului. Fiecare membru al echipei de proiect își creează propriile artefacte și este responsabil pentru ele. Programatorul creează programul, managerul creează planul de proiect, iar analistul creează modelele de sistem. RUP vă permite să determinați când, de către cine și ce artefact trebuie creat, modificat sau utilizat.

Una dintre cele mai interesante clase de artefacte de proiect sunt modelele, care permit dezvoltatorilor să definească, să vizualizeze, să construiască și să documenteze artefactele sistemului software. Fiecare model este o vedere de sine stătătoare a sistemului în curs de dezvoltare și are scopul atât de a contura problemele, cât și de a propune soluții. Autosuficiența modelelor înseamnă că un analist sau dezvoltator poate obține toate informațiile de care are nevoie dintr-un anumit model fără a apela la alte surse.

Modelele vă permit să luați în considerare viitorul sistem, obiectele sale și interacțiunea lor chiar înainte de a investi fonduri semnificative în dezvoltare, vă permit să-l vedeți prin ochii viitorilor utilizatori din exterior și dezvoltatorilor din interior chiar înainte de prima linie de cod sursă; este creat. Majoritatea modelelor sunt reprezentate prin diagrame UML, puteți citi mai multe despre UML, de exemplu, în.

Unified Modeling Language a apărut la sfârșitul anilor 80 și începutul anilor 90, în principal datorită eforturilor celor „trei prieteni” Gradi Bucha, Jim Rambo și Ivar Jacobson. Acum a fost adoptat de consorțiul OMG ca un limbaj de modelare standard care oferă dezvoltatorilor o notație clară care permite ca modelele să fie afișate în elemente grafice care sunt în general acceptate și înțelese de toată lumea din proiect.

Cu toate acestea, nu trebuie să uităm că limbajul de modelare oferă doar o notație - un instrument pentru descrierea și modelarea unui sistem, iar un proces unificat determină metodologia de utilizare a acestui instrument, precum și alte instrumente de suport metodologic de la Rational. UML poate fi folosit fără o metodologie specifică, deoarece este independent de proces și indiferent de opțiunea de proces utilizată, puteți utiliza diagrame pentru a documenta deciziile luate în timpul dezvoltării și pentru a afișa modelele create.

Un sistem software este creat pentru a rezolva probleme specifice ale utilizatorilor, și nu pentru ca programatorii să testeze noi tehnologii și să câștige experiență pentru managerul de proiect. În general, utilizatorului nu îi pasă dacă utilizați o abordare orientată pe obiecte, UML, RUP sau dacă creați un sistem folosind metoda XP (programare extremă) în procesul de dezvoltare. Utilizarea anumitor metode, tehnologii și crearea structurii interne optime a proiectului rămâne la conștiința dezvoltatorilor, care iau decizii pe baza experienței anterioare și a propriilor preferințe. Cu toate acestea, utilizatorul nu vă va ierta pentru ignorarea cerințelor sale. Chiar dacă un sistem software este dezvoltat de zece ori folosind metode și tehnologii de ultimă generație, dacă utilizatorul nu obține ceea ce se numește un „rezultat semnificativ” din acesta, proiectul tău software va eșua lamentabil.

De aici rezultă că aplicarea necugetă a UML, pur și simplu pentru că este la modă, nu numai că nu va duce la succes, ci poate provoca și nemulțumiri în rândul angajaților care au nevoie să studieze o cantitate mare de literatură suplimentară și manageri de proiect atunci când se dovedește că costurile cu forța de muncă la proiect cresc, iar profiturile nu cresc. Trebuie să înțelegeți clar ce doriți să obțineți din implementarea acestei tehnologii și să urmați acest obiectiv. Utilizarea UML economisește resurse de dezvoltare, deoarece vă permite să vă faceți o idee despre sistem mai rapid decât atunci când creați machete și prototipuri, cheltuind resurse incomparabil mai puține.

Diagramele facilitează comunicarea membrilor proiectului între ei și, ceea ce este deosebit de valoros, implică utilizatorii finali ai sistemului în proces. Modelarea vă permite să reduceți riscurile proiectului, deoarece este întotdeauna mai ușor pentru programatori să facă ceea ce este clar și de înțeles decât să meargă la un rezultat incert. Crearea de diagrame este similară cu crearea unui proiect în construcție - puteți face fără el, de exemplu, atunci când construiți un șopron pe o cabană de vară, cu toate acestea, cu cât clădirea este mai mare (în cazul nostru, un produs software), cu atât este mai dificil. de făcut și cu atât mai incert rezultatul final.

Am ținut odată un seminar despre RUP la o companie de software care avea un succes destul de mare pe piață timp de zece ani, dar nu folosea deloc modelarea în fluxul său de lucru, ci se baza pe prototipuri. În sală s-au adunat vreo douăzeci de programatori tineri și experimentați, care au ascultat cu atenție tot ce le-am spus despre RUP și UML. Și unul dintre ei, uitându-se la tabla acoperită cu exemple de diagrame, a remarcat: „Totul acesta este interesant și probabil bun pentru alte proiecte”, a spus el, „dar lucrăm de destul de mult timp fără toate acestea, de când suntem totuși ne-am descurcat fără UML, probabil că nu avem nevoie de el.”

Această întrebare m-a făcut să mă gândesc că schimbarea proceselor de afaceri care trebuie să apară în mod inevitabil într-o companie de dezvoltare de software atunci când implementează RUP și UML poate fi la fel de dificilă ca și implementarea unui sistem informațional la o întreprindere industrială. Orice implementare este o rupere a stereotipurilor. Deoarece calificările angajaților dintr-o companie de dezvoltare de software sunt destul de înalte, este mai dificil pentru astfel de oameni să-și abandoneze opiniile decât pentru „simplii muritori”, iar dificultățile și respingerea care apar pot fi comparate cu trecerea de la procedural la obiect. gândire orientată.

1.Definirea cerințelor

Un proces unificat este un proces condus de cazuri de utilizare care reflectă scenarii de interacțiune cu utilizatorul. De fapt, este punctul de vedere al utilizatorilor asupra sistemului software din exterior. Astfel, una dintre cele mai importante etape de dezvoltare, potrivit RUP, va fi etapa de determinare a cerințelor, care constă în colectarea tuturor dorințelor posibile pentru funcționarea sistemului care pot veni doar în minte utilizatorilor și analiștilor. Ulterior, aceste date vor trebui sistematizate și structurate, dar în această etapă, prin interviuri cu utilizatorii și studierea documentelor, analiștii trebuie să colecteze cât mai multe cerințe pentru viitorul sistem, ceea ce nu este atât de simplu pe cât pare la prima vedere. Utilizatorii de multe ori nu au idee ce ar trebui să obțină în cele din urmă. Pentru a facilita acest proces, analiștii folosesc diagrame de cazuri de utilizare (Fig. 2)

Fig 2. Exemplu de diagramă de caz de utilizare

Diagrama este o reflectare a actorilor (actanților) care interacționează cu sistemul și a reacției obiectelor software la acțiunile lor. Actanții pot fi atât utilizatori, cât și agenți externi care au nevoie să transmită sau să primească informații. Pictograma cazului de utilizare reflectă răspunsul sistemului la intrarea externă și arată ce trebuie făcut pentru actant.

Pentru a detalia un caz de utilizare specific, este utilizată o Diagramă de activitate, un exemplu al căruia este dat în Figura 3.

orez. 3 Exemplu de diagramă de activitate

Simplitatea diagramei de caz de utilizare permite analiștilor să comunice cu ușurință cu clienții în timpul procesului de definire a cerințelor, identificând constrângerile impuse sistemului și implementării cerințelor individuale, cum ar fi timpul de răspuns al sistemului, care ulterior se încadrează în secțiunea nefuncțională. cerințe.

O diagramă de caz de utilizare poate fi folosită și pentru a crea scenarii de testare, deoarece toate interacțiunile dintre utilizatori și sistem au fost deja definite.

Pentru a determina corect cerințele, dezvoltatorii trebuie să înțeleagă contextul (parte a domeniului subiectului) în care va funcționa viitorul sistem. Pentru a face acest lucru, se creează un model de domeniu și un model de afaceri, care sunt abordări diferite ale aceleiași probleme. Adesea se creează un singur lucru: un model de domeniu sau un model de afaceri.

Diferența dintre aceste modele este că modelul de domeniu descrie conceptele importante cu care va funcționa sistemul și conexiunile dintre ele. În timp ce un model de afaceri descrie procesele de afaceri (existente sau viitoare) pe care sistemul ar trebui să le suporte. Prin urmare, pe lângă definirea obiectelor de business implicate în proces, acest model definește lucrătorii, responsabilitățile acestora și acțiunile pe care trebuie să le realizeze.

Pentru a crea un model de domeniu, este utilizată o diagramă de clasă obișnuită (Figura 6), dar în mod clar nu este suficientă pentru a crea un model de afaceri. În acest caz, o diagramă de caz de utilizare este utilizată folosind pictograme suplimentare care reflectă esența proceselor de afaceri - acestea sunt actant de afaceri, caz de utilizare de afaceri, entitate de afaceri și managementul afacerii. Acest model este mult mai aproape de următorul model creat în procesul de dezvoltare - modelul de analiză.

2.Analiză

După stabilirea cerințelor și a contextului în care sistemul va funcționa, este momentul să analizăm datele obținute. În timpul procesului de analiză, este creat un model analitic care ghidează dezvoltatorii către arhitectura viitorului sistem. Un model analitic este o vedere a unui sistem din interior, spre deosebire de un model de caz de utilizare, care arată cum va arăta sistemul din exterior.

Acest model vă permite să înțelegeți cum ar trebui proiectat sistemul, ce clase ar trebui să aibă și cum ar trebui să interacționeze între ele. Scopul său principal este de a determina direcția de implementare a funcționalității identificate în etapa de colectare a cerințelor și de a schița arhitectura sistemului.

Spre deosebire de modelul de proiectare care este creat ulterior, modelul de analiză este mai mult un model conceptual și îi apropie doar pe dezvoltatori de clasele de implementare. Acest model nu ar trebui să aibă posibile contradicții care pot apărea în modelul precedent.

Pentru a afișa modelul de analiză folosind UML, se folosește o diagramă de clasă cu stereotipuri (modele de comportament) „clasa limită”, „entitate”, „control”, iar diagramele de colaborare sunt folosite pentru detaliere (Figura 4). Stereotipul „clasă limită” descrie o clasă care interacționează cu actanți externi, stereotipul „entitate” descrie clase care sunt depozite de date, iar stereotipul „control” descrie clase care gestionează interogări către entități.

Figura 4. Exemplu de diagramă de colaborare

Numerotarea mesajelor arată ordinea acestora, dar scopul diagramei nu este de a lua în considerare ordinea mesajelor schimbate, ci de a arăta în mod clar relațiile claselor între ele.

Dacă ne concentrăm pe ordinea interacțiunii, atunci o altă reprezentare ar fi o diagramă de secvență (Sequence), prezentată în Figura 5. Această diagramă vă permite să priviți schimbul de mesaje în timp, afișând vizual secvența procesului. Când utilizați un instrument de creare a modelelor precum Rational Rose, aceste două tipuri de diagrame pot fi create automat unul de celălalt (puteți citi mai multe despre Rational Rose, de exemplu, în).

Orez. 5 Exemplu de diagramă de secvență

Decizia careia dintre cele două diagrame să creeze prima depinde de preferințele dezvoltatorului individual. Deoarece aceste diagrame sunt o reprezentare a aceluiași proces, ambele vă permit să reflectați interacțiunea dintre obiecte.

3.Design

Următoarea etapă a procesului de creare a unui sistem este proiectarea, în timpul căreia se creează un model de proiectare pe baza modelelor create anterior. Acest model reflectă implementarea fizică a sistemului și descrie produsul creat la nivel de clasă și de componentă. Spre deosebire de modelul de analiză, modelul de proiectare are o dependență clară de condițiile de implementare, limbajele de programare și componentele utilizate. Pentru o înțelegere cât mai precisă a arhitecturii sistemului, acest model ar trebui să fie cât mai formalizat posibil și menținut la zi pe parcursul întregului ciclu de viață al dezvoltării sistemului.

Pentru a crea un model de proiectare se folosește un întreg set de diagrame UML: diagrame de clasă (Fig. 5), diagrame de cooperare, diagrame de interacțiune, diagrame de activități.

Fig 6. Exemplu de diagramă de clase

În plus, acest flux de lucru poate crea un model de implementare care este implementat pe baza unei diagrame de implementare. Acesta este cel mai simplu tip de diagramă conceput pentru a modela distribuția dispozitivelor într-o rețea. Pentru afișare sunt utilizate doar două opțiuni pentru pictogramele procesorului și dispozitivului, împreună cu conexiunile dintre ele.

4.Implementare

Sarcina principală a procesului de implementare este crearea unui sistem sub formă de componente - coduri sursă de program, scripturi, fișiere binare, module executabile etc. În această etapă, este creat un model de implementare care descrie modul în care sunt implementate elementele modelului de proiectare, care clase vor fi incluse în componente specifice. Acest model descrie modul de organizare a acestor componente în conformitate cu mecanismele de structurare și modularizare adoptate în mediul de programare selectat și este reprezentat printr-o diagramă de componente (Fig. 7).

orez. 7 Exemplu de diagramă de componente

5. Testare

În timpul procesului de testare, rezultatele implementării sunt verificate. Pentru acest proces se creează un model de testare, care constă din cazuri de testare, proceduri de testare, componente de testare, dar nu are o reprezentare diagramă UML, așa că nu ne vom opri asupra lui.

6. Concluzie

Aici au fost luate în considerare doar procesele principale ale metodologiei raționale. RUP este destul de extins, și conține recomandări pentru rularea diferitelor proiecte software, de la crearea de programe de către un grup de dezvoltatori de mai multe persoane, până la proiecte software distribuite care unesc mii de oameni de pe diferite continente. Cu toate acestea, în ciuda diferențelor lor enorme, metodele de utilizare a modelelor create folosind UML vor fi aceleași. Diagramele UML, create în diferite stadii de dezvoltare, sunt inseparabile de restul artefactelor unui proiect software și sunt adesea legătura dintre procesele RUP individuale.

Decizia de a folosi diagrame specifice depinde de procesul de dezvoltare pus la punct în companie, care, deși numit unificat, nu este ceva înghețat. Rational nu oferă doar îmbunătățirea și rafinarea acestuia, dar oferă și instrumente speciale pentru a face modificări în baza de date RUP.

Dar, în orice caz, utilizarea UML împreună cu un proces unificat vă va permite să obțineți un rezultat previzibil, să îndepliniți bugetul alocat, să creșteți impactul participanților la proiect și calitatea produsului software creat.

Kratchen. F. Introducere Proces rațional unificat . Ed. a 2-a - M.: Editura Williams, 2002. - 240 p.: ill.

Jacobson A., Buch G., Rambo J. Proces unificat de dezvoltare software - Sankt Petersburg: Peter, 2002. - 496 p.: ill.

Fowler M., Scott K. UML pe scurt. Aplicarea unui limbaj standard de modelare a obiectelor: Transl. din engleza – M.:Mir, 1999. – 191 p., ill.

Beck. E. Programare extremă. – Sankt Petersburg: Peter, 2002. – 224 p.: ill.

TrofimovS. Tehnologii CASE: Lucrări practice în Rational Rose.
Ed. 2 - M.: Binom-Press, 2002 - 288 p.

Procesul unificat utilizează în mod activ limbajul de modelare unificat ( UML). În miez UML constă un model care permite echipei de dezvoltare să înțeleagă într-un mod simplificat varietatea de procese complexe necesare dezvoltării software. Diverse modele utilizate în Proces unificat, vă permit să vizualizați sistemul, să descrieți structura și comportamentul acestuia și să documentați deciziile luate în timpul procesului de dezvoltare.

Istoria originii

Originile cadrului se află în munca unui angajat Ericsson Ivar Jacobson, publicat la sfârșitul anilor 1960. Jacobson și colegii săi au modelat sisteme uriașe de telecomunicații folosind straturi de „blocuri” (ceea ce mai târziu a devenit cunoscut sub numele de „componente”): straturile inferioare au servit ca bază pentru subsistemele din straturile superioare. Echipa a construit blocurile inferioare luând în considerare „cazurile de trafic” care s-ar putea întâmpla utilizatorilor sistemului. Aceste „incidente” au devenit prototipul cazurilor de utilizare, care au fost ulterior incluse UML. Lucrarea lui Jacobson a inspirat, de asemenea, crearea de diagrame utilizate în UML, inclusiv diagrame de activitate și secvențe .

În 1987, Jacobson și-a fondat propria companie Obiectiv ABși împreună cu partenerii au petrecut câțiva ani dezvoltând un proiect și un produs numit Obiecție. În 1995, Jacobson a publicat cartea „ Inginerie software orientată pe obiecte”, descriind un proces de dezvoltare condus de cerințele clienților care sunt traduse într-un produs final prin cazuri de utilizare. Lansarea cărții a coincis cu prima publicare a versiunii online a nucleului Proces unificat.

În 1995 compania Obiectiv AB absorbit de corporație Raţional. Cu ajutorul unui număr semnificativ crescut de colegi, Jacobson începe să extindă procesul Obiecție, completând-o cu instrumente pentru managementul și dezvoltarea proiectelor. Alături de Grady Booch și James Rumbaugh, care au lucrat în Raţional mai devreme, Jacobson a devenit membru al grupului de „trei prieteni”, care a condus munca pentru a crea un proces numit Procesul obiectiei raționale (ROP), precum și distribuția Proces unificat, care a devenit baza pentru Limbajul de modelare unificat.

În procesul de lucru la ROPȘi UML, corporație Raţional fuziuni și achiziții în continuare de companii implicate în crearea de instrumente de dezvoltare software. Aceste instrumente au oferit capabilități pentru gestionarea cerințelor („RequisitePro”), testare generală („SQA”), testarea performanței, gestionarea configurației și managementul schimbărilor. În 1998 Raţional schimbă numele produsului în RUP, al cărui miez conceptual rămâne Proces unificat.

Caracteristici

Proces unificat bazat pe cazuri de utilizare, descriind unul sau mai mulți actori care interacționează cu sistemul și obținând rezultate care sunt valoroase pentru participanții la proces. Cazurile de utilizare sunt principala forță motrice care conduce întregul proces de dezvoltare, începând cu colectarea și discutarea cerințelor și terminând cu analiză, proiectare și implementare. Cazurile de utilizare sunt descrise într-un limbaj simplu și ușor de înțeles, astfel încât să fie ușor de înțeles pentru un cititor extern.

Conform Proces unificat, în centrul procesului de dezvoltare se află arhitectură- organizarea fundamentală a întregului sistem. Poate include elemente statice și dinamice, interacțiunea lor și vă permite să rezolvați problemele de eficiență a produsului, extensibilitate, capacitatea de a reutiliza elemente și ajuta la depășirea limitărilor economice și tehnice. Echipa de proiect începe să lucreze la descrierea arhitecturii cât mai devreme posibil și o extinde și o îmbunătățește constant în timpul procesului de dezvoltare. Arhitectura este considerată un aspect important Proces unificat din mai multe motive, a căror cheie este capacitatea de a vedea imaginea completă a ceea ce se întâmplă, aplicarea corectă a eforturilor dezvoltatorului, facilitarea oportunităților de reutilizare a componentelor, dezvoltarea sistemului și selectarea corectă a cazurilor de utilizare.

Al treilea principiu fundamental Proces unificat este folosirea abordare iterativă și incrementală. Iterațiile sunt proiecte în miniatură care vă permit să lansați o versiune mai nouă a sistemului. Rezultatul iterației, modificările aduse sistemului, se numește increment. În special, abordarea iterativă vă permite să îmbunătățiți în mod constant arhitectura sistemului, să gestionați schimbările constante ale cerințelor și să ajustați în mod flexibil planul întregului proiect. Angajamentul față de principiul integrării continue vă permite să identificați posibilele probleme într-un stadiu incipient. În plus, iterația ajută la minimizarea riscurilor asociate cu constrângerile tehnice, arhitectura și cerințele în schimbare.

Fazele de dezvoltare

Dimensiunea relativă a fazelor de dezvoltare pentru un proiect tipic

Fiecare ciclu de dezvoltare, conform Proces unificat, constă din patru faze, care reprezintă perioada de timp dintre etapele importante ale proiectului, permițând managerilor să ia decizii importante privind continuarea procesului de dezvoltare, sfera lucrărilor, bugetul și programul.

Varietăți de flux de lucru

Interior Proces unificatÎn fiecare fază de dezvoltare, există cinci tipuri de procese de lucru: cerințe, analiză, proiectare, implementare și testare.

Fiecare proces este un set de activități realizate de diferiți membri ai echipei de proiect. Astfel, scopul proceselor de colectare a cerințelor este de a crea un model de cazuri de utilizare care să permită identificarea cerințelor funcționale de bază pentru sistem. Procesele de analiză și modelul corespunzător permit dezvoltatorilor să structureze cerințele funcționale; Procesul de proiectare descrie implementarea fizică a cazurilor de utilizare și este o abstractizare pentru următorul model. Procesul și modelul de implementare descriu modul în care elementele de proiectare se referă la componentele software, inclusiv codul sursă, bibliotecile dinamice etc. Ultimul model, care descrie testarea, explică ce teste de sistem și teste unitare ar trebui efectuate și cum ar trebui să le efectueze echipa de dezvoltare.

Iterații și creșteri

Fiecare dintre fazele descrise în Procesul Unificat constă în iterații, care sunt subproiecte în miniatură cu durată limitată. De obicei, fiecare iterație include toate cele cinci elemente ale fluxului de lucru în grade diferite. Rezultatul iterației este creştere, o versiune care conține îmbunătățiri în comparație cu versiunea anterioară a produsului.

Proces rațional unificat(RUP) este un cadru tehnologic de dezvoltare software dezvoltat și comercializat de Rational Software. Acesta încorporează cele mai bune practici globale în dezvoltarea de software și oferă o abordare disciplinară pentru atribuirea și gestionarea sarcinilor și responsabilităților în cadrul unei organizații de dezvoltare de software. Prin aplicarea acestui proces, echipele de dezvoltare de software vor putea crea software de înaltă calitate care să răspundă nevoilor utilizatorilor finali și să facă acest lucru într-un program și buget previzibil.

RUP îndrumă profesioniștii în software pentru a aplica în mod eficient cele mai bune practici actuale, cum ar fi dezvoltare iterativă, aplicație abordare centrată pe arhitectură, cazuri de utilizare, reducerea riscului în toate etapele procesului și verificarea continuă a programului.

Procesul Rațional Unificat se bazează pe mai multe principii fundamentale, colectate din multe proiecte de succes:

· Începeți să atacați principalele riscuri mai devreme și să le conduceți continuu, altfel ei înșiși vor trece la ofensivă împotriva dvs.

· Asigurați-vă că cerințele clienților sunt îndeplinite.

· Concentrați-vă asupra programului în curs de execuție.

· Adaptați-vă la schimbare încă de la începutul proiectului.

· Stabiliți arhitectura executabilă din timp.

· Construiți un sistem din componente.

· Lucrați împreună ca o echipă.

· Faceți din calitate un mod de viață, nu un gând ulterior.

RUP folosește abordare iterativă Fiecare iterație face un pic de lucru cu cerințele, analiză, proiectare, implementare și testare. Fiecare iterație se bazează pe rezultatele iterațiilor anterioare și produce un program executabil care se apropie cu un pas de produsul final.

RUP oferă abordare structurată a dezvoltării iterative, împărțind proiectul în patru faze: Inițiere, Proiectare, Construcție și Implementare. Fiecare fază este însoțită de un așa-zis jalon, un punct de control al procesului, la care se verifică atingerea obiectivelor fazei următoare și se ia o decizie privind trecerea (sau nu) la următoarea fază. Fiecare dintre cele patru faze ale RUP are astfel o piatră de hotar și un set de obiective clar definit. Aceste obiective sunt folosite pentru a determina ce sarcini să efectueze și ce artefacte să creeze. Fiecare fază se concentrează strict pe ceea ce este necesar doar pentru atingerea obiectivelor de afaceri ale fazei.

Toate elementele procesului - roluri, sarcini, artefacteși înrudite concepte, ghiduri și șabloane grupate în containere logice numite Discipline(Discipline). Există doar nouă discipline în produsul standard RUP. Acestea includ: modelarea afacerii, managementul cerințelor, managementul proiectelor, managementul schimbărilor și mediul.

Fiecare flux de lucru al procesului: colectarea cerințelor, analiza, proiectarea, implementarea și testarea definește un set de artefacte și activități asociate. Amintiți-vă că un artefact este un document, raport, element executabil etc. Artefact poate fi produs, procesat sau consumat.

Model- cel mai important tip de artefact. Sunt furnizate nouă modele, împreună care acoperă toate soluțiile pentru vizualizarea, specificarea, proiectarea și documentarea sistemelor software:

· model de afaceri. Definește abstractizarea organizației pentru care este creat sistemul;

· model de domeniu. Fixează mediul contextual al sistemului;

· Caz de utilizare a modelului. Definește cerințele funcționale pentru sistem.

· model de analiză. Interpretează cerințele sistemului în ceea ce privește modelul de proiectare;

· model de proiectare. Definește vocabularul de domeniu al problemei și soluția acesteia;

· model de plasare. Definește topologia hardware în care rulează sistemul;

· model de implementare. Definește piesele care sunt folosite pentru asamblarea și implementarea unui sistem fizic;

· model de testare. Definește cazuri de testare pentru a testa sistemul;

· model de proces. Definește paralelismul în sistem și mecanismele de sincronizare.

Artefacte tehnice sunt împărțite în patru seturi principale:

· set de cerințe. Descrie Ce sistemul ar trebui să facă;

· set de design.

· set de implementări. Descrie ansamblul componentelor software dezvoltate;

· set de plasare. Oferă toate informațiile despre configurația furnizată.

Set de cerințe poate include un model de caz de utilizare, un model de cerințe nefuncționale, un model de domeniu, un model de analiză și alte forme de exprimare a nevoilor utilizatorilor.

Set de design poate include un model de proiectare, un model de testare și alte forme de exprimare a esenței sistemului.

Set de implementări grupează toate datele despre elementele software care alcătuiesc sistemul (codul programului, fișierele de configurare, fișierele de date, componentele software, informații despre asamblarea sistemului).

Set de plasare grupează toate informațiile despre ambalare, expediere, instalare și pornire a sistemului.

Fiecare proces tehnologic este însoțit risc. La dezvoltarea unui produs software, un rezultat nesatisfăcător (UN) poate fi: depășirea bugetului, fiabilitatea scăzută, funcționarea incorectă etc. Impactul riscului este calculat folosind expresia

Indicator de risc = Probabilitate (LP) * Pierdere (LP).

Managementul riscului include șase acțiuni:

1. Identificarea riscurilor – identificarea elementelor de risc din proiect.

2. Analiza riscului – evaluarea probabilității și amplitudinii pierderii pentru fiecare element de risc.

3. Clasificarea riscurilor - ordonarea elementelor de risc în funcție de gradul de influență al acestora.

4. Planificarea managementului riscului – pregătirea pentru a face față fiecărui element de risc.

5. Rezolvarea riscurilor – eliminarea sau rezolvarea elementelor de risc.

6. Monitorizarea riscului – urmărirea dinamicii elementelor de risc, luarea de măsuri corective.

Primele trei acțiuni aparțin etapei de evaluare a riscurilor, ultimele trei acțiuni fazei de control al riscului.

Există trei categorii de surse de risc: risc de proiect, risc tehnic și risc comercial. După identificarea elementelor de risc, impactul acestora asupra proiectului software ar trebui cuantificat și întrebările legate de posibilele pierderi trebuie rezolvate. Aceste probleme sunt abordate în timpul etapei de analiză a riscurilor. Și în sfârșit, în planul de ansamblu al proiectului software este integrat un plan de gestionare a fiecărui element de risc, adică un set de funcții pentru gestionarea fiecărui element de risc.