Vienotā modelēšanas valoda (UML) ir vispārējas nozīmes modelēšanas valoda. UML galvenais mērķis ir definēt standarta veidu, kā vizualizēt veids, kā sistēma ir izstrādāta. Tas ir diezgan līdzīgs rasējumiem, ko izmanto citās inženierzinātņu jomās. UML ir nav programmēšanas valoda , tā drīzāk ir vizuāla valoda.

Svarīgas tēmas vienotās modelēšanas valodas (UML) diagrammām

sarakstu kārtot java

• Kas ir UML?
• Kāpēc mums ir nepieciešams UML?
• Dažādi UML diagrammu veidi
• Strukturālās UML diagrammas
• Uzvedības UML diagrammas
• UML diagrammās izmantotie objektorientētie jēdzieni
• Rīki UML diagrammu izveidei
• Darbības, lai izveidotu UML diagrammas
• UML diagrammu paraugprakse
• UML un Agile attīstība
• Biežākie izaicinājumi UML modelēšanā
• UML diagrammu izmantošanas priekšrocības

1. Kas ir UML?

Unified Modeling Language (UML) ir standartizēta vizuālās modelēšanas valoda, ko izmanto programmatūras inženierijas jomā, lai nodrošinātu vispārēju, attīstošu un intuitīvu veidu, kā vizualizēt sistēmas dizainu. UML palīdz precizēt, vizualizēt, konstruēt un dokumentēt programmatūras sistēmu artefaktus.

• Mēs izmantojam UML diagrammas, lai attēlotu uzvedība un struktūra sistēmas.
• UML palīdz programmatūras inženieriem, uzņēmējiem un sistēmu arhitektiem veikt modelēšanu, projektēšanu un analīzi.
• Objektu pārvaldības grupa (OMG) 1997. gadā pieņēma vienoto modelēšanas valodu kā standartu. Kopš tā laika to pārvalda OMG.
• Starptautiskā standartizācijas organizācija (ISO) publicēja UML kā apstiprinātu standartu 2005. gadā. UML gadu gaitā ir pārskatīts un tiek periodiski pārskatīts.

2. Kāpēc mums ir nepieciešams UML?

• Sarežģītām lietojumprogrammām ir nepieciešama sadarbība un plānošana no vairākām komandām, un tāpēc tām ir nepieciešams skaidrs un kodolīgs saziņas veids.
• Uzņēmēji nesaprot kodu. Tāpēc UML kļūst par būtisku, lai sazinātos ar neprogrammētājiem par sistēmas būtiskām prasībām, funkcijām un procesiem.
• Daudz laika tiek ietaupīts, kad komandas var vizualizēt procesus, lietotāju mijiedarbību un sistēmas statisko struktūru.

3. Dažādi UML diagrammu veidi

UML ir saistīts ar objektorientētu projektēšana un analīze. UML izmanto elementus un veido asociācijas starp tiem, lai veidotu diagrammas. Diagrammas UML var plaši klasificēt kā:

4. Strukturālās UML diagrammas

4.1. Klases diagramma

Visplašāk izmantotā UML diagramma ir klašu diagramma. Tas ir visu objektu orientēto programmatūras sistēmu pamatelements. Mēs izmantojam klašu diagrammas, lai attēlotu sistēmas statisko struktūru, parādot sistēmas klases, to metodes un atribūtus. Klašu diagrammas arī palīdz mums noteikt attiecības starp dažādām klasēm vai objektiem.

4.2. Saliktās struktūras diagramma

Mēs izmantojam saliktās struktūras diagrammas, lai attēlotu klases iekšējo struktūru un tās mijiedarbības punktus ar citām sistēmas daļām.

• Saliktā struktūras diagramma attēlo attiecības starp daļām un to konfigurāciju, kas nosaka, kā darbojas klasifikators (klase, komponents vai izvietošanas mezgls).
• Tie atspoguļo strukturēta klasifikatora iekšējo struktūru, izmantojot daļas, portus un savienotājus.
• Mēs varam arī modelēt sadarbību, izmantojot saliktas struktūras diagrammas.
• Tās ir līdzīgas klašu diagrammām, izņemot to, ka tās detalizēti attēlo atsevišķas daļas, salīdzinot ar visu klasi.

4.3. Objekta diagramma

Objekta diagrammu var saukt par sistēmas gadījumu ekrānuzņēmumu un starp tiem pastāvošajām attiecībām. Tā kā objektu diagrammas attēlo uzvedību, kad objekti ir instantierēti, mēs varam izpētīt sistēmas uzvedību noteiktā brīdī.

• Objekta diagramma ir līdzīga klašu diagrammai, izņemot to, ka tajā ir parādīti sistēmas klašu gadījumi.
• Mēs attēlojam faktiskos klasifikatorus un to attiecības, izmantojot klašu diagrammas.
• No otras puses, objektu diagramma attēlo konkrētus klašu gadījumus un attiecības starp tām noteiktā laika posmā.

4.4. Komponentu diagramma

Komponentu diagrammas tiek izmantotas, lai attēlotu, kā sistēmas fiziskās sastāvdaļas ir sakārtotas. Mēs tos izmantojam, lai modelētu ieviešanas detaļas.

• Komponentu diagrammas attēlo strukturālās attiecības starp programmatūras sistēmas elementiem un palīdz mums saprast, vai funkcionālās prasības ir ietvertas plānotajā attīstībā.
• Komponentu diagrammas kļūst par būtiskām, lai tās izmantotu, izstrādājot un veidojot sarežģītas sistēmas.
• Sistēmas komponenti izmanto saskarnes, lai sazinātos savā starpā.

4.5. Izvietošanas diagramma

Izvietošanas diagrammas tiek izmantotas, lai attēlotu sistēmas aparatūru un tās programmatūru. Tajā ir norādīts, kādi aparatūras komponenti pastāv un kādi programmatūras komponenti tajos darbojas.

atrast manu iphone android

• Mēs ilustrējam sistēmas arhitektūru kā programmatūras artefaktu sadali pa izplatītiem mērķiem.
• Artefakts ir informācija, ko ģenerē sistēmas programmatūra.
• Tos galvenokārt izmanto, ja programmatūra tiek izmantota, izplatīta vai izvietota vairākās iekārtās ar atšķirīgu konfigurāciju.

4.6. Iepakojuma diagramma

Mēs izmantojam pakešu diagrammas, lai attēlotu, kā ir sakārtotas paketes un to elementi. Pakešu diagramma vienkārši parāda atkarības starp dažādām pakotnēm un pakešu iekšējo sastāvu.

• Paketes palīdz mums sakārtot UML diagrammas jēgpilnās grupās un padara diagrammu viegli saprotamu.
• Tos galvenokārt izmanto, lai sakārtotu klases un lietošanas gadījumu diagrammas.

5. Uzvedības UML diagrammas

5.1. Stāvokļa mašīnu diagrammas

Stāvokļa diagramma tiek izmantota, lai attēlotu sistēmas vai sistēmas daļas stāvokli ierobežotos laika gadījumos. Tā ir uzvedības diagramma, un tā attēlo uzvedību, izmantojot ierobežotas stāvokļa pārejas.

• Stāvokļa diagrammas tiek sauktas arī par Valsts mašīnas un Stāvokļa diagrammas diagrammas
• Šie termini bieži tiek lietoti kā sinonīmi. Tātad vienkārši stāvokļa diagramma tiek izmantota, lai modelētu klases dinamisko uzvedību, reaģējot uz laiku un mainīgiem ārējiem stimuliem.

5.2. Aktivitāšu diagrammas

Mēs izmantojam aktivitāšu diagrammas, lai ilustrētu vadības plūsmu sistēmā. Mēs varam arī izmantot darbības diagrammu, lai norādītu uz lietošanas gadījuma izpildes darbībām.

• Mēs modelējam secīgas un vienlaicīgas darbības, izmantojot aktivitāšu diagrammas. Tātad, mēs pamatā attēlojam darbplūsmas vizuāli, izmantojot darbības diagrammu.
• Darbības diagramma koncentrējas uz plūsmas stāvokli un secību, kādā tas notiek.
• Mēs aprakstām vai attēlojam, kas izraisa konkrētu notikumu, izmantojot darbības diagrammu.

5.3. Izmantojiet gadījumu diagrammas

Lietošanas gadījumu diagrammas tiek izmantotas, lai attēlotu sistēmas vai sistēmas daļas funkcionalitāti. Tos plaši izmanto, lai ilustrētu sistēmas funkcionālās prasības un tās mijiedarbību ar ārējiem aģentiem (aktieriem).

• Lietošanas gadījums būtībā ir diagramma, kas attēlo dažādus scenārijus, kuros sistēmu var izmantot.
• Lietošanas gadījumu diagramma sniedz mums augsta līmeņa priekšstatu par to, ko sistēma vai sistēmas daļa dara, neiedziļinoties ieviešanas detaļās.

5.4. Secības diagramma

Secības diagramma vienkārši attēlo mijiedarbību starp objektiem secīgā secībā, t.i., secībā, kādā notiek šīs mijiedarbības.

• Mēs varam arī izmantot terminus notikumu diagrammas vai notikumu scenāriji, lai atsauktos uz secības diagrammu.
• Secību diagrammas apraksta, kā un kādā secībā darbojas objekti sistēmā.
• Šīs diagrammas plaši izmanto uzņēmēji un programmatūras izstrādātāji, lai dokumentētu un izprastu prasības jaunām un esošajām sistēmām.

5.5. Komunikācijas diagramma

Komunikācijas diagramma (pazīstama kā sadarbības diagramma UML 1.x) tiek izmantota, lai parādītu secīgus ziņojumus, ar kuriem apmainās starp objektiem.

• Komunikācijas diagramma galvenokārt koncentrējas uz objektiem un to attiecībām.
• Līdzīgu informāciju varam attēlot, izmantojot secību diagrammas, taču komunikācijas diagrammas attēlo objektus un saites brīvā formā.

5.6. Laika diagramma

Laika diagramma ir īpaša secību diagrammu forma, ko izmanto, lai attēlotu objektu uzvedību laika posmā. Mēs tos izmantojam, lai parādītu laika un ilguma ierobežojumus, kas regulē izmaiņas objektu stāvokļos un uzvedībā.

5.7. Mijiedarbības pārskata diagramma

Mijiedarbības pārskata diagramma modelē darbību secību un palīdz mums vienkāršot sarežģītas mijiedarbības vienkāršākos gadījumos. Tas ir aktivitāšu un secību diagrammu sajaukums.

nejaušu skaitļu ģenerators c

6. UML diagrammās izmantotie objektorientētie jēdzieni

1. Klase: Klase nosaka zilo druku, t.i., objekta struktūru un funkcijas.
2. Objekti : Objekti palīdz mums sadalīt lielas sistēmas un palīdz mums modularizēt mūsu sistēmu. Modularitāte palīdz sadalīt mūsu sistēmu saprotamās komponentēs, lai mēs varētu veidot savu sistēmu pa gabalu.
3. Mantojums: Mantojums ir mehānisms, ar kura palīdzību pakārtotās klases pārmanto vecāku klašu īpašības.
4. Abstrakcija: Abstrakcija UML attiecas uz procesu, kurā tiek uzsvērti sistēmas vai objekta būtiski aspekti, vienlaikus neņemot vērā nebūtiskas detaļas. Abstrahējot nevajadzīgas sarežģītības, abstrakcija veicina skaidrāku izpratni un saziņu starp ieinteresētajām personām.
5. Iekapsulēšana: Datu saistīšanu kopā un to aizsargāšanu no ārējās pasaules sauc par iekapsulēšanu.
6. Polimorfisms: Mehānisms, ar kura palīdzību funkcijas vai entītijas var pastāvēt dažādās formās.

6.1. UML 2.0 papildinājumi

• Ir iekļautas programmatūras izstrādes metodoloģijas, piemēram, Agile, un ir paplašināts oriģinālās UML specifikācijas apjoms.
• Sākotnēji UML noteica 9 diagrammas. UML 2.x ir palielinājis diagrammu skaitu no 9 līdz 13. Četras pievienotās diagrammas ir: laika diagramma, sakaru diagramma, mijiedarbības pārskata diagramma un saliktās struktūras diagramma. UML 2.x pārdēvēja stāvokļa diagrammas diagrammas par stāvokļa mašīnu diagrammām.
• UML 2.x pievienoja iespēju sadalīt programmatūras sistēmu komponentos un apakškomponentos.

7. Rīki UML diagrammu izveidei

Ir pieejami vairāki rīki, lai izveidotu vienotās modelēšanas valodas (UML) diagrammas, kuras parasti izmanto programmatūras izstrādē, lai vizuāli attēlotu sistēmas arhitektūru, dizainu un ieviešanu. Šeit ir daži populāri UML diagrammu izveides rīki:

• Skaidrības diagramma: Lucidchart ir tīmekļa diagrammu veidošanas rīks, kas atbalsta UML diagrammas. Tas ir lietotājam draudzīgs un sadarbīgs, ļaujot vairākiem lietotājiem strādāt pie diagrammām reāllaikā.
• Draw.io: Draw.io ir bezmaksas tīmekļa diagrammu veidošanas rīks, kas atbalsta dažādus diagrammu veidus, tostarp UML. Tas integrējas ar dažādiem mākoņa krātuves pakalpojumiem, un to var izmantot bezsaistē.
• Vizuālā paradigma: Visual Paradigm nodrošina visaptverošu rīku komplektu programmatūras izstrādei, tostarp UML diagrammu veidošanai. Tā piedāvā gan tiešsaistes, gan darbvirsmas versijas un atbalsta plašu UML diagrammu klāstu.
• StarUML: StarUML ir atvērtā koda UML modelēšanas rīks ar lietotājam draudzīgu saskarni. Tā atbalsta standarta UML 2.x diagrammas un ļauj lietotājiem pielāgot un paplašināt tā funkcionalitāti, izmantojot spraudņus.
• Papiruss: Papyrus ir atvērtā koda UML modelēšanas rīks, kas ir daļa no Eclipse Modeling Project. Tā nodrošina pielāgojamu vidi UML diagrammu izveidei, rediģēšanai un vizualizēšanai.
• PlantUML: PlantUML ir uz tekstu balstīts rīks, kas ļauj izveidot UML diagrammas, izmantojot vienkāršu un cilvēkiem lasāmu sintaksi. To bieži izmanto kopā ar citiem rīkiem un atbalsta dažādus diagrammu veidus.

8. Darbības, lai izveidotu UML diagrammas

Vienotās modelēšanas valodas (UML) diagrammu izveide ietver sistemātisku procesu, kas parasti ietver šādas darbības:

atšķirība starp programmu un skriptu

• 1. darbība: nosakiet mērķi:
  • Nosakiet UML diagrammas izveides mērķi. Dažādu veidu UML diagrammas kalpo dažādiem mērķiem, piemēram, prasību tveršanai, sistēmas arhitektūras projektēšanai vai klašu attiecību dokumentēšanai.
• 2. darbība: nosakiet elementus un attiecības.
  • Nosakiet galvenos elementus (klases, objektus, lietošanas gadījumus utt.) un to attiecības, kas jāattēlo diagrammā. Šis solis ietver modelējamās sistēmas struktūras un uzvedības izpratni.
• 3. darbība: atlasiet atbilstošo UML diagrammas veidu:
  • Izvēlieties UML diagrammas veidu, kas vislabāk atbilst jūsu modelēšanas vajadzībām. Izplatītākie veidi ir klašu diagrammas, lietošanas gadījumu diagrammas, secību diagrammas, darbību diagrammas un citas.
• 4. darbība: izveidojiet aptuvenu skici:
  • Pirms UML modelēšanas rīka izmantošanas var būt noderīgi izveidot aptuvenu skici uz papīra vai tāfeles. Tas var palīdzēt vizualizēt izkārtojumu un savienojumus starp elementiem.
• 5. darbība. Izvēlieties UML modelēšanas rīku:
  • Izvēlieties UML modelēšanas rīku, kas atbilst jūsu vēlmēm un prasībām. Ir pieejami dažādi rīki gan tiešsaistē, gan bezsaistē, kas piedāvā līdzekļus UML diagrammu izveidei un rediģēšanai.
• 6. darbība: izveidojiet diagrammu:
  • Atveriet atlasīto UML modelēšanas rīku un izveidojiet jaunu projektu vai diagrammu. Sāciet diagrammai pievienot elementus (piemēram, klases, lietošanas gadījumus, dalībniekus) un savienojiet tos ar atbilstošām attiecībām (piemēram, asociācijām, atkarībām).
• 7. darbība: definējiet elementa rekvizītus.
  • Katram diagrammas elementam norādiet atbilstošos rekvizītus un atribūtus. Tas var ietvert klases atribūtus un metodes, lietošanas gadījumu informāciju vai jebkuru citu informāciju, kas raksturīga diagrammas veidam.
• 8. darbība. Pievienojiet piezīmes un komentārus:
  • Uzlabojiet diagrammas skaidrību, pievienojot anotācijas, komentārus un paskaidrojošas piezīmes. Tas palīdz ikvienam, kas pārskata diagrammu, izprast dizaina lēmumus un tās loģiku.
• 9. darbība: apstipriniet un pārskatiet:
  • Pārskatiet diagrammu, lai iegūtu precizitāti un pilnīgumu. Pārliecinieties, ka attiecības, ierobežojumi un elementi precīzi atspoguļo paredzēto sistēmu vai procesu. Apstipriniet diagrammu atbilstoši prasībām un veiciet nepieciešamos pielāgojumus.
• 10. darbība. Uzlabojiet un atkārtojiet:
  • Uzlabojiet diagrammu, pamatojoties uz atsauksmēm un papildu ieskatiem. UML diagrammas bieži tiek veidotas iteratīvi, attīstoties izpratnei par sistēmu.
• 11. darbība: ģenerējiet dokumentāciju:
  • Daži UML rīki ļauj ģenerēt dokumentāciju tieši no diagrammām. Tas var ietvert klases dokumentāciju, lietošanas gadījumu aprakstus un citu būtisku informāciju.

Piezīme: Atcerieties, ka konkrētās darbības var atšķirties atkarībā no UML diagrammas veida un izmantotā rīka.

9. UML diagrammu labākās prakses

Vienotā modelēšanas valoda (UML) ir spēcīgs rīks sistēmas dizaina vizualizēšanai un dokumentēšanai. Lai izveidotu efektīvas un jēgpilnas UML diagrammas, ir svarīgi ievērot labāko praksi. Šeit ir daži UML paraugprakses piemēri:

1. Izprotiet auditoriju: Veidojot UML diagrammas, ņemiet vērā savu auditoriju. Pielāgojiet detalizētības līmeni un diagrammu izvēli, lai tie atbilstu jūsu auditorijas izpratnei un vajadzībām neatkarīgi no tā, vai tie ir izstrādātāji, arhitekti vai ieinteresētās personas.
2. Saglabājiet diagrammas vienkāršas un mērķtiecīgas: Diagrammās tiecieties pēc vienkāršības. Katrai diagrammai jākoncentrējas uz konkrētu sistēmas aspektu vai noteiktu attiecību kopumu. Izvairieties no jucekli un nevajadzīgām detaļām, kas var novērst uzmanību no galvenā ziņojuma.
3. Izmantojiet konsekventas nosaukumu piešķiršanas konvencijas: Pieņemiet konsekventus un jēgpilnus nosaukumus klasēm, objektiem, atribūtiem, metodēm un citiem UML elementiem. Skaidras un pārdomātas nosaukumu piešķiršanas metodes uzlabo jūsu diagrammu saprotamību.
4. Ievērojiet standarta UML apzīmējumus: Ievērojiet standarta UML apzīmējumus un simbolus. UML konvenciju izmantošanas konsekvence nodrošina, ka jūsu diagrammas ir viegli saprotamas citiem, kas pārzina UML.
5. Saglabājiet nepārprotamas attiecības: Skaidri definējiet un iezīmējiet attiecības starp elementiem. Izmantojiet atbilstošas ​​bultiņas, daudzkārtības apzīmējumus un asociāciju nosaukumus, lai paziņotu par savienojumu raksturu starp klasēm, objektiem vai lietošanas gadījumiem.

10. UML un Agile Development

Unified Modeling Language (UML) un Agile izstrāde ir divas dažādas pieejas programmatūras izstrādei, un tās var efektīvi integrēt, lai uzlabotu kopējo izstrādes procesu. Šeit ir daži galvenie punkti par saistību starp UML un Agile attīstību:

10.1. UML Agile Development

• Vizualizācija un komunikācija: UML diagrammas nodrošina vizuālu veidu, kā attēlot sistēmas arhitektūru, dizainu un uzvedību. Agile attīstībā, kur komunikācija ir ļoti svarīga, UML diagrammas var kalpot kā efektīvi saziņas rīki starp komandas locekļiem, ieinteresētajām personām un pat netehniskām auditorijām.
• Lietotāju stāsti un lietošanas gadījumi: UML lietošanas gadījumu diagrammas var izmantot, lai tvertu un modelētu lietotāju stāstus Agile attīstībā. Lietošanas gadījumi palīdz izprast sistēmu no galalietotāja perspektīvas un palīdz veidot lietotāju stāstus.
• Iteratīvā modelēšana: Agile metodoloģijas uzsver iteratīvo attīstību, un UML var pielāgot, lai atbalstītu šo pieeju. UML modeļus var izveidot un pilnveidot pakāpeniski, jo izpratne par sistēmu attīstās katras iterācijas laikā.
• Agile modelēšanas metodes: Agile modelēšanas metodes, piemēram, lietotāju stāstu kartēšana un ietekmes kartēšana, papildina UML, nodrošinot vieglus veidus, kā vizualizēt un paziņot prasības un dizainu. Šīs metodes atbilst Agile principam, ka darba programmatūra tiek vērtēta, nevis visaptveroša dokumentācija.

10.2. Agility un modelēšanas līdzsvarošana

• Adaptīvā modelēšana: Izmantojiet adaptīvās modelēšanas pieeju, kurā UML tiek izmantots tiktāl, cik tas ir nepieciešams efektīvai saziņai un izpratnei. Galvenā uzmanība jāpievērš vērtības nodrošināšanai, izmantojot strādājošu programmatūru, nevis izsmeļošu dokumentāciju.
• Komandas pilnvarošana: Dodiet izstrādes komandai iespēju izvēlēties pareizo modelēšanas līmeni, pamatojoties uz projekta vajadzībām. Komandas locekļiem vajadzētu justies ērti, izmantojot UML kā saziņas rīku, nejūtoties apgrūtinātiem ar pārmērīgām modelēšanas prasībām.

11. Biežākie izaicinājumi UML modelēšanā

1. laikietilpīgs: UML modelēšanu var uztvert kā laikietilpīgu, īpaši ātrā tempā Agile vidēs, kur tiek uzsvērta strauja attīstība. Komandām var būt grūti sekot līdzi nepieciešamībai bieži atjaunināt UML diagrammas.
2. Pārmērīga dokumentācija: Agile principi vērtē darba programmatūru, nevis visaptverošu dokumentāciju. Lietojot UML, pastāv pārmērīgas dokumentācijas risks, jo komandas var tērēt pārāk daudz laika detalizētām diagrammām, kas tieši neveicina vērtības nodrošināšanu.
3. Prasību maiņa: Agile projekti bieži saskaras ar mainīgām prasībām, un UML diagrammas var ātri novecot. Var būt sarežģīti sekot līdzi šīm izmaiņām un nodrošināt, ka UML modeļi atspoguļo pašreizējo sistēmas stāvokli.
4. Sadarbības problēmas: Agile uzsver sadarbību starp komandas locekļiem, un dažreiz UML diagrammas tiek uzskatītas par artefaktiem, kurus saprot tikai daži komandas locekļi. Nodrošināt, ka ikviens var dot ieguldījumu UML modeļos un gūt labumu no tiem, var būt izaicinājums.

12. UML diagrammu izmantošanas priekšrocības

1. Standartizācija: UML nodrošina standartizētu veidu, kā attēlot sistēmas modeļus, nodrošinot, ka izstrādātāji un ieinteresētās personas var sazināties, izmantojot kopīgu vizuālo valodu.
2. Saziņa: UML diagrammas kalpo kā spēcīgs saziņas rīks starp ieinteresētajām personām, tostarp izstrādātājiem, dizaineriem, testētājiem un biznesa lietotājiem. Tie palīdz saprotamākā veidā nodot sarežģītas idejas.
3. Vizualizācija: UML diagrammas atvieglo sistēmas komponentu, attiecību un procesu vizualizāciju. Šis vizuālais attēlojums palīdz izprast un izstrādāt sarežģītas sistēmas.
4. Dokumentācija: UML diagrammas var izmantot kā efektīvus dokumentācijas rīkus. Tie nodrošina strukturētu un organizētu veidu, kā dokumentēt dažādus sistēmas aspektus, piemēram, arhitektūru, dizainu un uzvedību.
5. Analīze un dizains: UML atbalsta gan programmatūras izstrādes analīzes, gan projektēšanas fāzes. Tas palīdz modelēt sistēmas prasības un pēc tam pārveidot tās par dizainu, ko var īstenot.