Razvoj softverskih proizvoda poznaje mnoge vrijedne metodologije - drugim riječima, dobro uspostavljene najbolje prakse. Izbor ovisi o specifičnostima projekta, proračunskom sustavu, subjektivnim preferencijama, pa čak i temperamentu upravitelja. U članku su opisane metodologije s kojima se redovito susrećemo u Edisonu.
Model vodopada je proširenje testiranja. . U ovom modelu, osim faze testiranja, dodan je i element koji se može smatrati jednom od faza - plan testiranja. Slika 5 - vlastiti razvoj temeljen na radu. Također je uveden kaskadni model s iteracijama. Ovaj model pretpostavlja da rezultati bilo koje faze nisu potpuni i moraju se promijeniti. Model vam omogućuje promjenu zahtjeva, troškova i vremena implementacije. Primjena je pronađena u složenim višestranim situacijama koje su dovele do složenog sustava.
Ovisno o izvoru, pretpostavlja se da model nema testiranje i samo provjeru valjanosti. Također možete otkriti da je testiranje druga generacija softver u ovom modelu. Slika 6 - vlastiti razvoj temeljen na radu.
1. "Model vodopada" (kaskadni model ili "vodopad")
Jedan od najstarijih, uključuje uzastopni prolazak faza, od kojih svaka mora biti u potpunosti dovršena prije početka sljedeće. Lako je upravljati projektom u modelu Vodopad. Zbog svoje krutosti, razvoj je brz, cijena i vrijeme su unaprijed određeni. Ali ovo je dvosjekli mač. Model vodopada dobro će funkcionirati samo za projekte s jasno definiranim zahtjevima i načinom na koji će se oni provoditi. Ne postoji način da se napravi korak unatrag, testiranje počinje tek nakon što je razvoj dovršen ili gotovo dovršen. Proizvodi razvijeni prema ovom modelu bez opravdanog izbora mogu imati nedostatke (popis zahtjeva se ne može prilagoditi u bilo kojem trenutku), koji postaju poznati tek na kraju zbog strogog slijeda radnji. Trošak unošenja izmjena je visok jer morate čekati da cijeli projekt završi da biste ga pokrenuli. Međutim, fiksni trošak često nadmašuje nedostatke pristupa. Ispravak nedostataka uočenih tijekom izrade je moguć, a prema našem iskustvu zahtijeva jedan do tri dodatna dogovora uz ugovor s malom tehničkom specifikacijom.
Model - programiranje pretraživanja. . Model prikazan u dokumentu koristi se u sustavima s teško definiranim zahtjevima, sustav se gradi u ciklusima, svaki ciklus završava provjerom klijenta. Ovaj model se može koristiti kao amaterski način za izradu softvera. Profesionalno se koristi u izradi prototipova. Početno testiranje sustava događa se nakon njegovog cjelokupnog dizajna.
Slika 7 - vlastiti razvoj temeljen na radu. Model se koristi u složenim sustavima s dvosmislenim ili višeznačnim zahtjevima – sustav se ciklički implementira kroz prototipove koje provjerava kupac. Prototipovi tzv. Šminkanje se može napraviti po niskoj cijeni i vrlo brzo. Korištena metodologija omogućuje provjeru zahtjeva. Testiranje se odvija nakon faze implementacije sustava.
Uz pomoć modela vodopada stvorili smo mnoge projekte od nule, uključujući razvoj samo tehničkih specifikacija. Projekti o kojima piše na Habréu: srednji - , mali - .
Kada koristiti metodologiju vodopada?
- Tek kada su zahtjevi poznati, shvaćeni i fiksni. Nema proturječnih zahtjeva.
- Nema problema s dostupnošću programera potrebnih kvalifikacija.
- Za relativno male projekte.
2. "V-model"
Naslijedio strukturu korak po korak od modela vodopada. Model u obliku slova V primjenjiv je za sustave koji su posebno važni za nesmetan rad. Na primjer, aplikacijski programi u klinikama za praćenje pacijenata, integrirani softver za upravljačke mehanizme zračnih jastuka za hitne slučajeve u vozilima i tako dalje. Značajkom modela može se smatrati da je usmjeren na temeljitu provjeru i testiranje proizvoda, koji je već u početnim fazama dizajna. Faza testiranja provodi se istodobno s odgovarajućom razvojnom fazom, na primjer jedinični testovi se pišu tijekom kodiranja.
Slika 8 - vlastiti razvoj temeljen na radu. Četiri glavne faze životnog ciklusa softvera su cikličke: analiza rizika, dizajn, provjera valjanosti, planiranje. Slika 9 - vlastiti razvoj temeljen na radu.
Što je testiranje softvera? . Prije nego što odgovorimo na pitanje što je testiranje softvera, vrijedi spomenuti definiciju pojmova kao što su validacija i validacija. Autorov pregled rada potvrđuje ispitivanjem i jasnim dokazima da su određeni zahtjevi ispunjeni. U projektiranju i proizvodnji, provjera se odnosi na proces testiranja rezultata aktivnosti kako bi se utvrdilo ispunjava li zahtjeve za tu aktivnost.
Primjer našeg rada po V-metodologiji - mobilna aplikacija za europski mobilni operater, što štedi troškove roaminga tijekom putovanja. Projekt se provodi prema jasnom TOR-u, ali uključuje značajnu fazu testiranja: praktičnost sučelja, funkcionalnost, opterećenje, uključujući integraciju, koja bi trebala potvrditi da nekoliko komponenti različitih proizvođača radi zajedno stabilno, krađu novca i zajmovi su nemogući.
Validacija, koja se odnosi na istog autora, je potvrda, ispitivanjem, i daje jasan dokaz da su specifični zahtjevi za određenu, namjeravanu upotrebu ispunjeni. U dizajnu i proizvodnji, validacija se odnosi na proces testiranja proizvoda kako bi se utvrdilo zadovoljava li potrebe korisnika. Validacija se obično provodi na konačnom proizvodu. Testiranje uključuje provjeru i provjeru softvera. Testiranje softvera prema ovoj definiciji je izvršavanje koda za kombinaciju ulaza i stanja za otkrivanje pogrešaka.
Kada koristiti V-model?
- Ako je potrebno temeljito testiranje proizvoda, tada će V-model opravdati temeljnu ideju: validaciju i provjeru.
- Za male i srednje projekte gdje su zahtjevi jasno definirani i fiksni.
- S obzirom na dostupnost inženjera s potrebnim kvalifikacijama, posebno ispitivača.
3. "Inkrementalni model" (inkrementalni model)
U inkrementalnom modelu, kompletni zahtjevi sustava podijeljeni su u različite sklopove. Terminologija se često koristi za opisivanje postupne izgradnje softvera. Postoji više razvojnih ciklusa, a zajedno čine životni ciklus s više vodopada. Ciklus je podijeljen na manje lako kreirane module. Svaki modul prolazi kroz faze definiranja zahtjeva, dizajna, kodiranja, implementacije i testiranja. Razvojni postupak prema inkrementalnom modelu uključuje puštanje proizvoda u prvu veću fazu osnovne funkcionalnosti, a zatim dosljedno dodavanje novih značajki, tzv. "inkremenata". Proces se nastavlja sve dok se ne stvori kompletan sustav.
Svrha testova je otkrivanje grešaka. Testiranje je dinamička analiza jer se testirani kod izvršava. Verifikacija softvera - testiranje u pet koraka. . Radna faza procesa testiranja prikazana je na sljedeći način.
U prvom koraku komponente se testiraju kako bi se osigurao ispravan rad komponenti. Modul je skup neovisnih komponenti kao što su klase objekata, apstraktni tipovi podataka ili skup funkcija i procedura. Budući da modul zatvara povezane komponente, može se testirati bez uključivanja drugih modula sustava. Ispitivanje podsustava. U ovoj fazi testira se sklop modula koji je integriran u podsustav. Nekompatibilnost sučelja jedan je od problema s kojima se susreću veliki sustavi. Testiranje ove faze trebalo bi dovesti do sučelja za otkrivanje pogrešaka. Testiranje sustava. Podsustavi su već integrirani u sustav. U ovom trenutku testiranje bi trebalo otkriti pogreške uzrokovane neželjenim interakcijama između podsustava i probleme sa sučeljima podsustava. Funkcionalna i nefunkcionalna provjera također ovisi o funkcionalnim i nefunkcionalnim zahtjevima cijelog sustava. Provođenje testiranja. Završna faza procesa testiranja prije predaje sustava korisniku. Sustav se testira korištenjem skupa podataka primljenih od korisnika. Ova faza testiranja može otkriti pogreške i propuste u definiranju zahtjeva sustava. Osim toga, mogu se pojaviti problemi da alati sustava ne zadovoljavaju u potpunosti zahtjeve korisnika ili da je izvedba sustava neprihvatljiva.
- Svaka se komponenta testira neovisno bez sudjelovanja drugih komponenti sustava.
- Testiranje modula.
Inkrementalni modeli se koriste tamo gdje su pojedinačni zahtjevi za promjenama jasni i mogu se lako formalizirati i implementirati. U našim smo projektima njime izradili čitač DefView, a potom i mrežu digitalnih knjižnica Vivaldi.
Kao primjer, opišimo bit jednog inkrementa. zamijenio DefView. DefView se prije povezivao s jednim poslužiteljem dokumenata, ali sada se može povezati s mnogima. Na stranici institucije koja svoj sadržaj želi emitirati određenoj publici, instaliran je poslužitelj za pohranu podataka koji izravno pristupa dokumentima i pretvara ih u željeni format. Pojavio se korijenski element arhitekture - središnji Vivaldi poslužitelj, koji djeluje kao jedan pretraživač na svim poslužiteljima za pohranu instaliranim u raznim institucijama.
Obično su programeri i programeri komponenti odgovorni za testiranje modula i modula koje razvijaju. To je opravdano jer programer koji stvara komponentu najbolje poznaje komponentu. Kasnije faze testiranja uključuju integraciju rada mnogih programera. Ove aktivnosti treba planirati prije testiranja. Preporuča se da ispitivač izvede neovisnu testnu grupu na temelju specifikacija i pripremljenih testnih slučajeva. Slika pokazuje kako su planovi testiranja poveznica između aktivnosti stvaranja i testiranja.
Kada koristiti inkrementalni model?
- Kada su osnovni zahtjevi za sustav jasno definirani i razumljivi. Istodobno, neki se detalji s vremenom mogu poboljšati.
- Zahtijeva rano lansiranje na tržište.
- Postoji nekoliko rizičnih značajki ili ciljeva.
4. "RAD Model" (model brzog razvoja aplikacija ili brzi razvoj aplikacija)
RAD model je varijacija inkrementalnog modela. U RAD modelu, komponente ili funkcije razvija nekoliko visoko kvalificiranih timova paralelno, poput nekoliko mini-projekata. Vremenski okvir jednog ciklusa je strogo ograničen. Stvoreni moduli se zatim integriraju u jedan radni prototip. Sinergija vam omogućuje da klijentu brzo predstavite nešto što radi na pregled kako biste dobili povratnu informaciju i napravili promjene.
Ovdje vrijedi spomenuti alfa testove i beta testove. Alfa testiranje je inače poznato kao testiranje prihvaćanja. U slučaju beta testiranja, radi se o skupini proizvoda koja je izložena određenoj skupini korisnika. Korisnici prijavljuju probleme proizvođačima koji se javljaju tijekom korištenja. Ovo rješenje čini proizvod zaista korisnim i omogućuje otkrivanje grešaka koje programeri i operateri sustava ne očekuju. Nakon što se primi povratna informacija, sustav se modificira i stavlja na raspolaganje za daljnje beta testiranje ili opću upotrebu.
Model brzog razvoja aplikacije uključuje sljedeće faze:
- Poslovno modeliranje: definiranje popisa protoka informacija između različitih odjela.
- Modeliranje podataka: Informacije prikupljene u prethodnom koraku koriste se za definiranje objekata i drugih entiteta potrebnih za kruženje informacija.
- Modeliranje procesa: Tokovi informacija povezuju objekte radi postizanja ciljeva dizajna.
- Aplikacija za izradu: koristi alate za automatsku izradu za pretvaranje CAD modela u kod.
- Testiranje: testiraju se nove komponente i sučelja.
Može se koristiti samo s visoko kvalificiranim i visoko specijaliziranim arhitektima. Proračun projekta dovoljno je velik da plati ove stručnjake, zajedno s cijenom gotovih automatiziranih alata za montažu. RAD model možete odabrati ako pouzdano poznajete ciljni posao i trebate hitno proizvesti sustav u roku od 2-3 mjeseca.
Zaključno, iz modela prikazanih u ovom članku može se vidjeti da je važnost testiranja u proizvodnji softvera sve veća. Gornji tekst je dio doktorske pripreme. Definiranje razvojnog ciklusa softvera odavno je tradicija. Jedan od prvih pokušaja bio je izrada makete vodopada. Iako je vrlo jednostavan, u potpunosti se odrazio na prve projekte u kojima je softver nastao. Jedini nedostatak mu je jednostavnost, koja ne uzima u obzir, primjerice, optimizaciju vremena.
5. "Agilni model" (metodologija agilnog razvoja)
U "agilnoj" metodologiji razvoja, nakon svake iteracije kupac može promatrati rezultat i shvatiti zadovoljava li ga ili ne. Ovo je jedna od prednosti fleksibilnog modela. Njegovi nedostaci uključuju činjenicu da je, zbog nedostatka specifičnih formulacija rezultata, teško procijeniti troškove rada i troškove potrebne za razvoj. Ekstremno programiranje (XP) jedna je od najpoznatijih primjena agilnog modela u praksi.
Model ćemo analizirati pomoću programa Reminder. Njegova glavna premisa će, kao što pretpostavljate, podsjećati na događaje. Moramo početi sa zahtjevima: na što nas ovo podsjeća? Koji se parametri mogu postaviti u njemu? Zahtjevi zahtjevi osnova su za početak definiranja testa.
Znajući što želimo postići, možemo odrediti kako želimo da bude i hoće li uspjeti. Prvi i osnovni završni test - ako se program pokrene, podsjeća li vas podsjetnik na podsjetnik? Zahtjevi se analiziraju kada timovi arhitekata, programera, testera itd. odlučiti je li Ideja moguća. Je li moguće provesti sve početne pretpostavke? Važno je, međutim, da se rijetko koristi za analizu testera, koja može biti okosnica testiranja sustava na razini verifikacije.
Ovaj tip se temelji na kratkim dnevnim sastancima - "Scrum" i redovito ponavljajućim sastancima (jednom tjedno, jednom svaka dva tjedna ili jednom mjesečno) pod nazivom "Sprint". Na dnevnim sastancima članovi tima raspravljaju o:
- izvješće o obavljenom poslu od posljednjeg Scruma;
- popis zadataka koje zaposlenik mora obaviti prije sljedećeg sastanka;
- poteškoće koje su se pojavile u toku rada.
Kada koristiti Agile?
Projektni arhitekti podijeljeni su u pojedinačne komponente. Oni stvaraju specifikaciju koju unose programeri i testeri. Svaki projekt ima vlastita sučelja koja mu omogućuju rad operacijski sustav, na primjer. Zauzvrat, svaka se komponenta može testirati zasebno prije integracije. Ovdje su koncepti testiranja sučelja i komponenti. Provedba - teorijski kraj lijeve ruke. Desna ruka ili validacija je jednostavno provjeriti jesu li izvorne pretpostavke ispunjene; Počevši od najmanjih komponenti u cijelom integriranom sustavu, obično se pozivaju End-of-line testovi.
- Kada se potrebe korisnika neprestano mijenjaju u dinamičnom poslovanju.
- Agilne promjene provode se po nižoj cijeni zbog čestih povećanja.
- Za razliku od modela vodopada, agilni model treba samo malo planiranja za početak projekta.
6. "Iterativni model" (iterativni ili iterativni model)
Iterativni model životnog ciklusa ne zahtijeva potpunu specifikaciju zahtjeva za početak. Umjesto toga, izrada počinje implementacijom dijela funkcionalnosti, koji postaje temelj za određivanje daljnjih zahtjeva. Ovaj proces se ponavlja. Verzija možda nije savršena, glavna stvar je da radi. Razumijevajući krajnji cilj, težimo mu tako da svaki korak bude učinkovit, a svaka verzija izvediva.
Ispitivanja prihvatljivosti koja odgovaraju na pitanje zadovoljava li proizvod zahtjeve kupca. Svaka faza projektiranja završava unosom za sljedeću fazu i odgovarajuću fazu verifikacije. Potiče rani početak procesa izrade planova testiranja, specifikacija testiranja i testiranja.
Analizom grafikona lako možemo identificirati područja u kojima treba provjeriti dokumentaciju. Iako nije vrlo detaljan i neučinkovit, pruža primjer idealnog svijeta suradnje između arhitekata, programera, testera i klijenata. Ovo je nenadmašan model koji treba poznavati svaka osoba koja se želi baviti softverom. Razvoj softvera usmjeren je prvenstveno na profesionalnost i visoku kvalitetu isporučenih proizvoda, što naši kupci svaki put uočavaju.
Dijagram prikazuje iterativni "razvoj" Mona Lise. Kao što vidite, u prvoj iteraciji postoji samo skica Mona Lise, u drugoj se pojavljuju boje, a treća iteracija dodaje detalje, zasićenost i dovršava proces. U inkrementalnom modelu, funkcionalnost proizvoda se gradi malo po malo, proizvod se sastoji od dijelova. Za razliku od iterativnog modela, svaki komad je integralni element.
Zbog toga cijenimo tržište specijaliziranog softvera. Informacijski sustavi koje je pripremila naša tvrtka mogu se pronaći na internetu, na adresi Mobiteli i na televiziji. Naše razvojne usluge ne završavaju razvojem softvera po narudžbi - naši stručnjaci nadziru naš rad, brinu se o našim sustavima i grade ih za naše potrebe.
Projekti koje provodimo su fleksibilni i u njima možemo sudjelovati u bilo kojoj fazi rada. Metodologija suradnje i provedbe projekta uvijek uvažava očekivanja naručitelja. Tehnologije korištene u projektu moraju biti što učinkovitije i brže, a pritom zadržati sigurnost i performanse sustava.
Primjer iterativnog razvoja je prepoznavanje glasa. Prva istraživanja i priprema znanstvenog aparata započela je davno, u početku - u mislima, zatim - na papiru. Sa svakom novom iteracijom, kvaliteta prepoznavanja se poboljšavala. Međutim, savršeno prepoznavanje još nije postignuto, stoga problem još nije u potpunosti riješen.
Sveobuhvatna usluga za IT projekte
Analiza potreba i zahtjeva naručitelja ispunjenje tehničkih specifikacija Razvoj informatičkih sustava razvoj softvera aplikativnog softvera implementacija sistemskog softvera hosting administracija hostinga, održavanje, praćenje razvoja aplikacija.
Razvoj, optimizacija, migracija postojećih sustava
Izrada softvera za razvoj baze podataka za proširenje funkcionalnosti potpunim ili djelomičnim restrukturiranjem postojeće podatkovne infrastrukture. Uzorni IT projekti. Dizajn i implementacija softvera prilagođenog klijentu, razvoj i administracija internetskog softvera i instalacija na računalne analize, dizajn i implementacija poslovnog softvera, razvoj i implementacija desktop i klijent-poslužitelj aplikacija; razvoj i implementacija korisničkih sučelja; integracija baze podataka; reorganizacija informacijski sustavi migracija izvorni kod; sustava i lokalizacija softverskih podataka i izrada tehničke dokumentacije. U proteklih nekoliko godina realizirali smo niz IT projekata.Kada je najbolje vrijeme za korištenje iterativnog modela?
- Zahtjevi za konačni sustav jasno su definirani i unaprijed razumljivi.
- Projekt je velik ili vrlo velik.
- Glavni zadatak mora biti definiran, ali detalji implementacije mogu se razvijati tijekom vremena.
7. "Spiralni model" (spiralni model)
„Spiralni model“ sličan je inkrementalnom modelu, ali s naglaskom na analizi rizika. Dobro radi za kritične poslovne izazove gdje je neuspjeh nekompatibilan s poslovanjem tvrtke, novim linijama proizvoda, istraživanjem i terenskim ispitivanjima.
Spiralni model pretpostavlja 4 stupnja za svaki zavoj:
- planiranje;
- analiza rizika;
- građenje;
- evaluacija rezultata i, ako je kvaliteta zadovoljavajuća, prijelaz u novi krug.
Sažmimo
Slajd pokazuje razlike između dvije najčešće metodologije.
U suvremenoj praksi modeli razvoja softvera su multivarijantni. Ne postoji isti za sve projekte, početne uvjete i modele plaćanja. Čak ni svima nama toliko dragi Agile ne može se primijeniti svugdje zbog nepripremljenosti pojedinih kupaca ili nemogućnosti fleksibilnog financiranja. Metodologije se djelomično preklapaju u sredstvima i donekle su slične jedna drugoj. Neki drugi koncepti korišteni su samo za promicanje vlastitih prevoditelja i nisu donijeli ništa novo u praksu.
O razvojnim tehnologijama:
.
.
.
.
Koje metodologije koristite?
Danas se proces stvaranja složenih softverskih aplikacija ne može zamisliti bez podjele na faze životnog ciklusa. Pod životnim ciklusom programa podrazumijevamo niz faza:
- Analiza predmetnog područja i izrada tehničke specifikacije (interakcija s kupcem)
- Dizajn strukture programa
- Kodiranje (skup programskog koda prema projektnoj dokumentaciji)
- Testiranje i otklanjanje pogrešaka
- Provedba programa
- Programska podrška
- Raspolaganje
UML je grafički jezik za vizualizaciju, opis parametara, dizajn i dokumentaciju raznih sustava (posebno programa). Dijagrami se izrađuju pomoću posebnih CASE alata kao što su Rational Rose (http://www-01.ibm.com/software/rational/) i Enterprise Architect (http://www.sparxsystems.com.au/). Temeljen na UML tehnologiji, jedinstveni informacijski model. Gornji CASE alati sposobni su generirati kod u raznim objektno orijentiranim jezicima, a također imaju vrlo korisna značajka obrnuti inženjering. (Obrnuti inženjering vam omogućuje stvaranje grafičkog modela iz postojećeg programskog koda i komentara na njega.)
Razmotrite vrste dijagrama za vizualizaciju modela (ovi su obavezni, iako postoji mnogo više vrsta):
Dijagram slučaja uporabe
Dizajnirani sustav je predstavljen kao skup entiteta ili aktera koji su u interakciji sa sustavom koristeći takozvane presedane. U ovom slučaju, akter (glumac) ili akter je bilo koji entitet koji izvana komunicira sa sustavom. Drugim riječima, svaki slučaj upotrebe definira određeni skup radnji koje sustav izvodi kada razgovara s glumcem. Pritom se ništa ne govori o tome kako će se provoditi interakcija aktera sa sustavom.Dijagram klasa (dijagram klasa)
Dijagram klasa služi za predstavljanje statičke strukture modela sustava u terminologiji klasa objektno orijentiranog programiranja. Dijagram klasa može posebno odražavati različite odnose između pojedinačnih entiteta predmetnog područja, kao što su objekti i podsustavi, a također opisuje njihovu unutarnju strukturu (polja, metode ...) i vrste odnosa (nasljeđivanje, implementacija sučelja . ..). Ovaj dijagram ne pruža informacije o vremenskim aspektima rada sustava. S ove točke gledišta, dijagram klasa je daljnji razvoj konceptualnog modela projektiranog sustava. U ovoj fazi neophodno je poznavanje OOP pristupa i obrazaca dizajna.
Dijagram stanja (dijagram stanja)
Glavna svrha ovog dijagrama je opisati moguće nizove stanja i prijelaza koji zajedno karakteriziraju ponašanje elementa modela tijekom njegovog životnog ciklusa. Dijagram stanja predstavlja dinamičko ponašanje entiteta, temeljeno na specifikaciji njihovog odgovora na percepciju nekih specifičnih događaja.
Dijagram slijeda
Za modeliranje interakcije objekata u UML jeziku koriste se odgovarajući dijagrami interakcije. Interakcije objekata mogu se razmatrati u vremenu, a zatim se dijagram sekvence koristi za predstavljanje vremena prijenosa i primanja poruka između objekata. Objekti u interakciji međusobno razmjenjuju neke informacije. U tom slučaju informacije imaju oblik cjelovitih poruka. Drugim riječima, iako poruka ima informacijski sadržaj, ona dobiva dodatno svojstvo usmjerenog utjecaja na primatelja.
Dijagram suradnje
U dijagramu suradnje objekti koji sudjeluju u interakciji prikazani su u obliku pravokutnika koji sadrže naziv objekta, njegovu klasu i, eventualno, vrijednosti atributa. Kao iu dijagramu klasa, asocijacije između objekata naznačene su u obliku različitih povezujućih linija. U ovom slučaju možete eksplicitno odrediti nazive pridruživanja i uloge koje objekti igraju u ovom pridruživanju.Za razliku od dijagrama sekvenci, dijagram suradnje prikazuje samo odnose između objekata koji igraju određene uloge u interakciji.
Dijagram komponenti
Dijagram komponenti, za razliku od prethodno razmatranih dijagrama, opisuje značajke fizičkog prikaza sustava. Dijagram komponenti vam omogućuje da odredite arhitekturu sustava koji se razvija uspostavljanjem ovisnosti između softverskih komponenti, koje mogu biti izvorni, binarni i izvršni kod. U mnogim razvojnim okruženjima, modul ili komponenta odgovaraju datoteci. Točkaste strelice koje povezuju module pokazuju odnose ovisnosti slične onima koji se javljaju prilikom prevođenja izvornog koda programa. Glavni grafički elementi dijagrama komponenti su komponente, sučelja i ovisnosti između njih.
Dijagram postavljanja
Dijagram implementacije dizajniran je za vizualizaciju elemenata i komponenti programa koji postoje samo u fazi njegovog izvođenja (runtime). U ovom slučaju prikazane su samo komponente instance programa koje su izvršne datoteke ili dinamičke biblioteke. One komponente koje se ne koriste tijekom izvođenja nisu prikazane u dijagramu postavljanja.Dijagram postavljanja sadrži grafičke slike procesore, uređaje, procese i veze između njih. Za razliku od logičkih dijagrama prikaza, dijagram implementacije je isti za sustav kao cjelinu, jer mora u potpunosti odražavati značajke njegove implementacije. Ovaj dijagram u biti dovršava OOAP proces za određeni programski sustav a njegov razvoj obično je posljednji korak u specifikaciji modela.
Ovo zaključuje naš pregled dijagrama posebno i dizajna općenito. Vrijedno je napomenuti da je proces dizajna odavno postao standard razvoja softvera, ali često se morate nositi s lijepo napisanim programom, koji zbog nedostatka odgovarajuće dokumentacije dobiva nepotrebne sporedne funkcionalnosti, štake, postaje glomazan i gubi svoju prijašnja kvaliteta. =(
Uvjeren sam da je programer prije svega koder - on NE treba komunicirati s kupcem, NE treba razmišljati o arhitekturi sustava, ne treba izmišljati sučelje programa, on treba samo kodirati - implementirati algoritme, funkcionalnost, izgled, upotrebljivost, ali ne više…. Projektant, počevši od apstraktnih dijagrama (koji opisuju predmetno područje) do dijagrama koji predstavljaju strukturu podataka, klase i procese njihove interakcije, mora sve detaljno opisati korak po korak. Odnosno, složenost posla i plaća dizajnera trebala bi biti red veličine veća od one programera == kodera. Oprostite na laprdanju....