Trenutno ima malo ljudi koji će raspravljati s tvrdnjom da naš svijet sve više ovisi o softveru (softveru). I to nije čudno. Koristi se u mobilnim telefonima, integriranim sustavima kontrole zračnog prometa, osobnim računalima, automobilskoj elektroniki i još mnogo toga. Mnoge inovacije koje doživljavamo kao danu, kao i veliki broj različitih organizacija kao što su Yandex, Amazon ili Google, jednostavno su nemoguće bez softvera. Ali čak iu tradicionalnom trgovinskom, javnom i financijskom sektoru vrlo je teško bez softvera.

Opće informacije

Vrijedi spomenuti samo pojam arhitekture, pa je jedno jasno - nedostatak definicija ne postoji. Stoga, kako ne bi brkali čitatelje, IEEE 1471 i IEEE Std 1472000 standardi će se koristiti kao prototipovi za razmatranje u članku. A sada pogledajmo što arhitektura predstavlja. Ovaj se pojam odnosi na organizaciju sustava utjelovljenu u njegovim sastavnicama, na odnos između njih i okoliša, kao i na načela koja definiraju njezin dizajn i razvoj. No, najprije se prisjetimo onih koji su dali značajan doprinos razvoju teorije i koncepta softvera.


Prije svega, potrebno je spomenuti Lance Bassa. "Arhitektura softvera u praksi - prilično stari rad ovog autora (ruski prijevod objavljen je 2006.), ali vam ipak omogućuje da dobijetekvalitetno razumijevanje procesa razvoja softvera. Sljedeći zanimljivi autor je Robert Martin i njegovo stvaranje "Čista arhitektura". Umjetnost razvoja softvera ". Prijevod i objavljivanje knjige na ruskom jeziku napravljeni su već na početku 2018. godine. Stoga je sigurno reći da je to doslovno novina u kojoj ima mnogo svježih i relevantnih informacija. Knjiga "Čista arhitektura. Umjetnost razvoja softvera "govori kako doći do vrhunca profesionalnosti. On opisuje što i kako treba raditi i zašto će rješenje biti presudno za uspjeh.

Malo terminologije

Razmotrimo neke pojmove koji će nam pomoći razumjeti temu:

Sustav - određeni skup komponenti koje su kombinirane za obavljanje određene funkcije ili skupa.

Misija - zahtjev (radnja) koji će jedna ili više zainteresiranih strana učiniti u skladu s potrebnim skupom uvjeta.

Komponenta je logičan, fizički, tehnološki srodan (neovisan), fino ili grubo modularni sustav koji sadržava njegov sadržaj.

I neke druge interpretacije na glavnoj temi:

Arhitektura - skup značajnih odluka koje utječu na organizaciju sustava C. Skup strukturnih elemenata, kao i njihova sučelja, kroz koje se postavlja.

Arhitektura programa (računalni sustav) - struktura koja uključuje određene elemente, vidljive s vanjske strane njihovih svojstava, kao i veze između njih. Sastoji se od svih važnihprihvaćene projektne odluke. Ona pruža željeni skup svojstava potrebnih za uspješno poslovanje.

Arhitektura je struktura organizacije, kao i ponašanje sustava povezano s njom. Može se rekurzivno rastaviti na dijelove, komunikaciju i uvjete montaže.

Iako ove definicije imaju samo dio razlika, nije teško uočiti određenu sličnost. Dakle, pažnja je usmjerena na strukturu, ponašanje i smislene odluke. A to se ne gubi.

Utjecaj arhitekture na strukturu

Ovdje postoji jedan zanimljiv trenutak. Vrijedi tražiti da se riječ "arhitektura" opisuje, jer se većina ljudi ovdje odnosi na strukturu. I to nije čudno. Uostalom, arhitektura softvera u praksi često se temelji na shemi, koja opisuje strukturalne aspekte sustava. Štoviše, nije bitno o čemu se radi - o razinama, komponentama ili distribuiranim čvorovima. Struktura je najvažnija značajka arhitekture. Njegovi aspekti i obilježja manifestiraju se na mnogo načina. Strukturni element može biti baza podataka, knjižnica, proces, podsustav, računalni čvor i tako dalje. Štoviše, pozornost treba posvetiti ne samo njima zasebno, nego i njihovim sastavima, uspostavljenim vezama, sučeljima i particijama. Mora se uzeti u obzir da svaki od ovih elemenata može biti predstavljen na različite načine. Kao primjer, može se pronaći povezna veza. Može biti: a /synchronous, socket, biti povezan s određenim protokolom i tako dalje.

Utjecaj arhitekture na ponašanje

Jednostavno ga je nemoguće podcijeniti.Projektiranje arhitekture softvera ima velik utjecaj na njegovu implementaciju i daljnje performanse. Ponašanje, eventualni zastoji, problemi itd. Jako ovise o tome kako se sve razvijalo od samog početka. Arhitektura utječe na interakciju između strukturnih elemenata, mora osigurati prijenos podataka točno tamo gdje je potrebno da bi se na kraju postigao željeni rezultat. Kako se to događa našim standardima? Možete vidjeti malu shemu aktivnosti. Pretpostavimo da imamo poduzeće. Potrebno je provjeriti je li zaposlenik naručio narudžbu primjenom razreda "Form". Sadrži sve potrebne informacije o klijentu. Ako je narudžba napravljena prvi put, tada se podaci unose u "Prazno" pomoću kontrolnog sustava. Zatim se koristi instanca klase "Start Order Processing", koja pokreće sve potrebne procese u poduzeću. Ukupno ima pet elemenata. U isto vrijeme postoji određena ovisnost. Na primjer, naručivanje je nemoguće bez zaposlenika. A ako Blank nije popunjen, neće biti prihvaćen.

Koncentracija arhitekture na bitne elemente

Dakle, već smo razmotrili utjecaj na strukturu i ponašanje. No ovdje se mora istaknuti jedna važna točka. Naime, arhitektura ne definira cijelu strukturu, a ne svako ponašanje. Utječe na one elemente koji se smatraju značajnima. Što je pod njima? Značajni su oni elementi koji imaju dugotrajan i trajan učinak. Na primjer,glavni strukturni Ili one koji ovise o pouzdanosti i skalabilnosti softvera. U ovom slučaju, arhitektura, u pravilu, nema veze s detaljima svih tih elemenata. Glavni atribut, za koji se neki vrednuju više od drugih, je trošak stvaranja i modificiranja. Arhitektura se fokusira na smislene elemente. Stoga treba ponuditi konkretnu perspektivu, nešto što je najznačajnije. Može se reći da je arhitektura definitivna generalizacija cjelokupnog softverskog sustava, što omogućuje programeru da upravlja postojećom složenošću. Ovdje valja istaknuti jednu važnu točku. Naime, skup značajnih elemenata nije statična lista nečega i može se mijenjati tijekom vremena. U kojim slučajevima se to događa? Kao primjer može se navesti situacija u kojoj rezultat zahtjeva, identifikacija rizika i drugih sličnih trenutaka dolazi. Treba napomenuti da je relativna stabilnost arhitekture, unatoč promjenama, znak dobro izvedenog rada i dobro uspostavljenog procesa razvoja, kao i iskustva i kvalifikacija osoblja.

Usklađivanje potreba dionika

U praksi, arhitektura softvera trebala bi biti prikladna i za korisnike i za administrativno osoblje. Treba napomenuti da često ispunjavanje svih izraženih želja nije moguće. Na primjer, može se navesti situacija u kojoj dotična osoba traži određenu funkcionalnost koja će se obavljati za određeno vrijemerazdoblje. No ove se dvije potrebe međusobno isključuju. To jest, možete ili smanjiti granice funkcije koja se izvodi tako da zadovoljava traženi raspored, ili zadržati sve u cijelosti, ali onda će to potrajati previše vremena. Slično tome, na primjer, zainteresirane strane mogu imati zahtjeve različitih stupnjeva proturječnosti. U takvim slučajevima potrebno je postići određenu ravnotežu. Kompromisno rješenje je praktički nezamjenjiv aspekt procesa razvoja arhitekture. I ovdje, nažalost, nećete učiniti ništa - morate prevladati poteškoće. Da bismo dobili ideju o stvarnoj situaciji, simuliramo situaciju kada trebate zadovoljiti potrebe nekoliko dionika:

Krajnji korisnik. Zainteresiran je za osiguravanje da je softver intuitivan, produktivan, pouzdan, user-friendly, siguran i pristupačan, te također ima ispravno ponašanje.

Administrator sustava. Zanima ga prisutnost intuitivnog upravljanja, alata za praćenje i ponašanja cijelog kompleksa.

Stručnjak za oglašavanje i promociju. On je zainteresiran za prisutnost jedinstvenih značajki koje čine softver konkurentnim, indikativno vrijeme prije objavljivanja razvoja na tržištu, trošak proizvoda i njegove pozicije među analozima.

Razvijač. Zainteresiran je za razumijevanje zahtjeva i neusklađenih načela unutarnjeg sustava.

Voditelj projekta. Zanima ga činjenica da je tijek projektiranja, planiranja i izvođenja bio predvidljiv.Također je potrebno voditi računa o racionalnom korištenju raspoloživog proračuna i sredstava.

Arhitektura se temelji na logičkom opravdanju

Prilikom rada, pozornost se mora posvetiti ne samo krajnjem rezultatu. Naravno, arhitektura zaslužuje pozornost. Isto kao i logičko opravdanje koje se koristi kao osnova. Stoga je potrebno osigurati dokumentaciju o odlukama, putem kojih su došli do stvaranja postojeće arhitekture. Također im je potrebno pružiti logično opravdanje. Unatoč jednostavnosti i jednostavnosti zadatka, te su informacije važne za zainteresirane strane, osobito među onima koji servisiraju sustav. Također, dokumentacija je vrijedna za programere u slučajevima kada je potrebno preispitati razloge za odluke koje su donesene kako bi se izbjeglo nepotrebno ponavljanje već poduzetih radnji. Na primjer, pri pregledavanju arhitekture. Uostalom, u takvim je slučajevima potrebno objasniti zašto su takve odluke donesene.

O arhitektonskom stilu

Što i kako u ovom slučaju? Ako pogledate softversku arhitekturu za mnoge proizvode, možete vidjeti da su izgrađeni na sustavima koji koriste slične skupove interesa. Brojne sličnosti mogu se napraviti u određenom stilu. On se, pak, može smatrati posebnom vrstom predloška, ​​vrlo složenim i sastavnim. Ovo je koder iskustva i dovoljno je da ga programeri ponovno koriste. Uostalom, to će vam omogućiti da radite takav posao brzo i brzo. Koje su glavne arhitekturestil softver outsource? Primjeri uključuju:

Distribuirano.

Kanali i filtri.

S centraliziranom obradom podataka.

Izrađeno prema pravilima. Treba napomenuti da pojedini sustavi mogu pokazati prisutnost više od jednog stila. Što je potvrda tih riječi? Na prvom mjestu možemo spomenuti arhitektonski stil izložbe i Garlan. Kako se manifestira? Arhitektonski stil je u suštini nomenklatura sastavnica, kao i vrste poveznih veza i skupova uvjeta kojima se mogu kombinirati. Ponovno korištenje iskustva u obliku primjene arhitektonskog stila pomaže olakšati život zahvaljujući činjenici da je već dobro dokumentirao i potkrijepio racionalno korištenje nečeg zrna.

O utjecaju okoliša. I obrnuto

Ili drugim riječima, o arhitekturi unutar semantičkog sadržaja. Potrebno je odrediti granice unutar kojih će softverski sustav funkcionirati. Uglavnom se bavi okolišem. Arhitektura softverskog sustava u takvim slučajevima treba uzeti u obzir čimbenike utjecaja. Konkretnije, potrebno je usredotočiti se na nositelje misija, unutarnja i vanjska tehnička ograničenja. Osim toga, arhitektura softvera može utjecati na okoliš. Štoviše, ne samo s tehnološke točke gledišta, već vam također omogućuje ponovno korištenje sredstava i radnog okruženja. O čemu govore standardi? Ako govorimo o pretežno softverskim sustavima, onda ih treba uzeti u obzirodređene aspekte okoliša. Dakle, da bi program bio koristan, trebao bi raditi. Da biste to učinili, morate ga pokrenuti na određenom hardveru. Arhitektura računala ovdje je od velike važnosti. Računalni softver koji je stvoren za Windows neće raditi na tehnologiji na kojoj je instaliran MacOS. Iako, naravno, možete napraviti emulator, proći kroz virtualni stroj, ili koristiti drugog posrednika i pokrenuti softver. No, učinkovitost njegova rada bit će mnogo manje nego u slučaju rada s ciljnim sustavima. Stoga bi arhitektura računala i softvera trebala odgovarati pravilnom radu. Uostalom, isti MacOS može raditi samo pod određenom konfiguracijom. Dakle, Windows ima određena ograničenja, iako je manje vezan za željezo.

Raznolikost vrsta

Koje modele možete stvoriti? Ukratko ćemo navesti tipove softverske arhitekture koji se široko koriste:

model klijent-poslužitelj.

Monolitna primjena.

Arhitektura povodom.

Strukturirano.

Tri razine.

Arhitektura orijentirana na usluge.

Implicitni izazovi.

Arhitektura usmjerena na pretraživanje.

Ovo je samo mali dio velikog broja različitih pristupa i predložaka. I daleko od toga da je jedini. Treba napomenuti da razvoj softverske arhitekture nije nešto složeno i nemoguće, pa ih mnogi sami stvaraju (vrlo često kopiraju ono što već postoji, ali ono što ne zna). Naravno, dok su male razlike u detaljima, alioni su rezultat prilagođavanja predloška specifičnim zahtjevima timova programera. Na ovom, možda, moguće je zaustaviti se. Treba napomenuti da je u članku glavni naglasak stavljen na karakteristike softverske arhitekture. Niz važnih pitanja, nešto izvan opsega glavne teme, nisu razmatrana. Među njima - uloga developera, koje osnovne radnje mora obaviti, i neke druge.