Trenutno je malo ljudi, ki bodo zagovarjali trditev, da je naš svet vse bolj odvisen od programske opreme (programske opreme). In to ni čudno. Uporablja se v mobilnih telefonih, integriranih sistemih kontrole zračnega prometa, osebnih računalnikih, avtomobilski elektroniki in še veliko več. Veliko inovacij, ki jih dojemamo kot dano, in veliko število različnih organizacij, kot so Yandex, Amazon ali Google, so preprosto nemogoče brez programske opreme. Toda tudi v tradicionalnem trgovinskem, javnem in finančnem sektorju je zelo težko brez programske opreme.

Splošne informacije

Pomembno je omeniti samo pojem arhitekture, zato je nekaj takoj jasno - pomanjkanje definicij ne obstaja. Zato, da ne bi zmedli bralcev, bodo standardi protokolov IEEE 1471 in IEEE Std 1472000 uporabljeni kot prototipi za obravnavo v članku. Zdaj pa poglejmo, kaj arhitektura predstavlja. Ta izraz se nanaša na organiziranost sistema, ki ga sestavljajo njegovi sestavni deli, na odnos med njimi in okoljem ter na načela, ki opredeljujejo njeno zasnovo in razvoj. Najprej pa se spomnimo tistih, ki so pomembno prispevali k razvoju teorije in koncepta programske opreme.


Najprej je treba omeniti Lance Bass. "Arhitektura programske opreme v praksi - precej staro delo tega avtorja (ruski prevod je bil izdan leta 2006), vendar pa vam omogoča, da dobitekakovostno razumevanje procesa razvoja programske opreme. Naslednji zanimiv avtor je Robert Martin in njegovo ustvarjanje "Čista arhitektura." Umetnost razvoja programske opreme. Prevod in objava knjige v ruščini sta nastali že na samem začetku leta 2018. Zato lahko rečemo, da je to dobesedno novost, v kateri je veliko svežih in relevantnih informacij. Knjiga "Čista arhitektura. Umetnost razvoja programske opreme »pove, kako doseči višino profesionalnosti. Opisuje, kaj in kako narediti in zakaj bo rešitev za uspeh ključna.

Nekaj ​​terminologije

Razmislite o nekaterih pojmih, ki nam bodo pomagali razumeti temo:

Sistem - določen sklop komponent, ki so bile združene za opravljanje določene funkcije ali niza.

Poslanstvo - vloga (ukrep), ki jo bo pripravila ena ali več zainteresiranih strani v skladu s potrebnimi pogoji.

Komponenta je logični, fizični, tehnološko soroden (neodvisen), fino ali grobo modularni sistem, ki vsebuje njegovo vsebino.

In nekatere druge interpretacije na glavno temo:

Arhitektura - niz pomembnih odločitev, ki vplivajo na organizacijo sistema C. Niz strukturnih elementov, kot tudi njihovi vmesniki, skozi katere je postavitev.

Arhitektura programa (računalniški sistem) - struktura, ki vključuje nekatere elemente, vidne z zunanje strani njihovih lastnosti, kakor tudi povezave med njimi. Vsebuje vse pomembnesprejete projektne odločitve. Zagotavlja želeno vrsto lastnosti, ki so potrebne za uspešno poslovanje.

Arhitektura je struktura organizacije, kot tudi vedenje sistema, povezano z njo. Lahko se rekurzivno razstavi v dele, komunikacijo in pogoje montaže.

Čeprav imajo te opredelitve le del razlik, ni težko opaziti določene podobnosti. Zato je pozornost usmerjena na strukturo, vedenje in smiselne odločitve. In to ni zapravljeno.

Vpliv arhitekture na strukturo

Tu je še en zanimiv trenutek. Vredno je, da se opiše beseda "arhitektura", saj se večina ljudi nanaša na strukturo. In to ni čudno. Navsezadnje je arhitektura programske opreme v praksi pogosto zgrajena na shemi, ki prikazuje strukturne vidike sistema. Poleg tega ni pomembno, kaj je jezik - o ravneh, komponentah ali distribuiranih vozliščih. Struktura je najpomembnejša značilnost arhitekture. Njeni vidiki in značilnosti se kažejo na več načinov. Strukturni element je lahko baza podatkov, knjižnica, proces, podsistem, računalniško vozlišče in tako naprej. Poleg tega je treba pozornost nameniti ne le ločeno, temveč tudi njihove sestave, vzpostavljene vezi, vmesnike in razdelke. Upoštevati je treba, da je vsak od teh elementov lahko predstavljen na različne načine. Kot primer lahko najdete povezovalno povezavo. Lahko je: a /synchronous, socket, povezan z določenim protokolom in tako naprej.

Vpliv arhitekture na vedenje

Preprosto ga ni mogoče podcenjevati.Oblikovanje arhitekture programske opreme ima velik vpliv na njegovo izvedbo in nadaljnje delovanje. Vedenje, možna obešanja, težave itd. Je zelo odvisno od tega, kako se je vse razvilo od samega začetka. Arhitektura vpliva na interakcijo med strukturnimi elementi, mora zagotoviti prenos podatkov točno tam, kjer je potrebno sčasoma dobiti želeni rezultat. Kako se to dogaja našim standardom? Vidite lahko majhno shemo dejavnosti. Recimo, da imamo podjetje. Zagotoviti je treba, da je uslužbenec naročil z uporabo primerka razreda "Obrazec". Vsebuje vse potrebne informacije o stranki. Če je naročilo izdano prvič, se informacije vnesejo v "Prazno" z uporabo nadzornega sistema. Nato se uporabi primer razreda "Začetek obdelave naročila", ki izvaja vse potrebne procese v podjetju. Skupaj je pet elementov. Hkrati pa obstaja določena odvisnost. Na primer, naročanje je nemogoče brez zaposlenega. Če Blank ni napolnjen, ga ne bomo sprejeli.

Koncentracija arhitekture na bistvene elemente

Torej smo že upoštevali vpliv na strukturo in vedenje. Toda tukaj je treba omeniti eno pomembno točko. Arhitektura namreč ne opredeljuje celotne strukture in ne vsega vedenja. Vpliva na tiste elemente, ki se štejejo za pomembne. Kaj je pod njimi? Pomembni so tisti elementi, ki imajo dolg in trajen učinek. Na primer,glavni strukturni Ali tiste, ki so odvisne od zanesljivosti in razširljivosti programske opreme. V tem primeru arhitektura praviloma nima nobene zveze s podrobnostmi vseh teh elementov. Glavni atribut, za katerega so nekateri ocenjeni bolj kot drugi, so stroški ustvarjanja in spreminjanja. Arhitektura se osredotoča na pomembne elemente. Zato mora ponuditi konkretno perspektivo, nekaj, kar je najbolj pomembno. Lahko rečemo, da je arhitektura dokončna generalizacija celotnega sistema programske opreme, ki razvijalcu omogoča upravljanje obstoječe kompleksnosti. Pomembno je omeniti tukaj. Nabor smiselnih elementov namreč ni statični seznam nečesa in se lahko sčasoma spremeni. V katerih primerih se to dogaja? Kot primer lahko navedemo situacijo, v kateri pride do rezultatov zahtev, identifikacije tveganj in drugih podobnih trenutkov. Opozoriti je treba, da je relativna stabilnost arhitekture kljub sprejetim spremembam znak dobro opravljenega dela in dobro uveljavljenega razvojnega procesa, pa tudi izkušenj in usposobljenosti osebja.

Usklajevanje potreb zainteresiranih strani

V praksi bi morala biti arhitektura programske opreme primerna tako za uporabnike kot za administrativno osebje. Omeniti je treba, da pogosto ni mogoče izpolniti vseh izraženih želja. Kot primer lahko navedemo situacijo, ko zadevna oseba zahteva določeno funkcijo, ki jo je treba izvesti za določen časvrzel Toda ti dve zahtevi se medsebojno izključujeta. To pomeni, da lahko bodisi zmanjšate meje funkcije, ki jo želite izvesti, tako da ustreza zahtevanemu urniku, ali pa ohranite vse v celoti, potem pa bo trajalo preveč časa. Podobno lahko na primer zainteresirane stranke zahtevajo različne stopnje nasprotja. V takih primerih je treba doseči določeno ravnovesje. Kompromisna rešitev je praktično nenadomestljiv vidik procesa razvoja arhitekture. In tukaj, na žalost, ne boste storili ničesar - premagati morate težave. Da bi dobili idejo o dejanskem stanju, simuliramo situacijo, ko morate zadovoljiti potrebe več deležnikov:

Končni uporabnik. Zanima ga, da je programska oprema intuitivna, produktivna, zanesljiva, uporabniku prijazna, varna in cenovno dostopna, prav tako pa ima ustrezno vedenje.

Sistemski administrator. Zanima ga prisotnost intuitivnega upravljanja, orodij za spremljanje in obnašanja celotnega kompleksa.

Specialist za oglaševanje in promocijo. Zanima ga prisotnost edinstvenih značilnosti, zaradi katerih je programska oprema konkurenčna, indikativni čas pred sprostitvijo razvoja na trgu, stroški izdelka in njegove pozicije med analogi.

Razvijalec. Zanima ga razumevanje zahtev in neskladnih načel notranjega sistema.

Vodja projekta. Zanima ga dejstvo, da je bil potek oblikovanja, načrtovanja in izvedbe predvidljiv.Prav tako je treba skrbeti za racionalno porabo razpoložljivih sredstev in sredstev.

Arhitektura temelji na logični utemeljitvi

Pri delu je treba pozornost nameniti ne le končnemu rezultatu. Seveda arhitektura zasluži pozornost. Enako kot logična utemeljitev, uporabljena kot osnova. Zato je potrebno zagotoviti dokumentacijo o odločitvah, s katerimi so prišli do oblikovanja obstoječe arhitekture. Prav tako je treba za njih zagotoviti logično utemeljitev. Kljub preprostosti in enostavnosti naloge so te informacije pomembne za zainteresirane strani, zlasti med tistimi, ki servisirajo sistem. Poleg tega je dokumentacija koristna za razvijalce v primerih, ko je treba pregledati utemeljitev sprejetih odločitev, da bi se izognili nepotrebnemu ponavljanju že sprejetih ukrepov. Na primer, ko gledate arhitekturo. Navsezadnje je v takih primerih treba pojasniti, zakaj so bile take odločitve sprejete.

O arhitekturnem slogu

Kaj in kako v tem primeru? Če pogledate arhitekturo programske opreme za mnoge izdelke, lahko vidite, da so zgrajeni na sistemih, ki uporabljajo podobne interese. Številne podobnosti se lahko naredijo v določenem slogu. On je po drugi strani mogoče obravnavati kot posebno vrsto predloge, zelo zapleteno in sestavno. To je kodirnik izkušenj in dovolj je, da ga razvijalci ponovno uporabijo. Konec koncev, to vam bo omogočilo, da to delo opravite hitro in hitro. Katere so glavne arhitektureslog software outsource? Primeri vključujejo:

Distribuirano.

Kanali in filtri.

S centralizirano obdelavo podatkov.

Izdelano po pravilih.

Treba je opozoriti, da lahko posamezni sistemi pokažejo prisotnost več kot enega sloga. Kaj je potrditev teh besed? Na prvem mestu lahko omenimo arhitekturni slog razstave in Garlan. Kako se manifestira? Arhitekturni slog je v bistvu nomenklatura komponent, pa tudi vrste povezovalnih povezav in sklopov pogojev, s katerimi se lahko združijo. Ponovna uporaba izkušenj v obliki uporabe arhitekturnega sloga olajša življenje zaradi dejstva, da je že dobro dokumentiral in utemeljil racionalno rabo nečesa.

O vplivu okolja. In obratno

Ali z drugimi besedami, o arhitekturi znotraj semantične vsebine. Potrebno je določiti meje, v katerih bo sistem programske opreme deloval. V glavnem se ukvarja z okoljem. Arhitektura sistema programske opreme mora v takih primerih upoštevati dejavnike vpliva. Natančneje, treba se je osredotočiti na deležnike misij, notranje in zunanje tehnične omejitve. Poleg tega lahko arhitektura programske opreme vpliva na njeno okolje. Poleg tega, ne samo s tehnološkega vidika, ampak tudi vam omogoča, da ponovno uporabite sredstva in delovno okolje. O čem govorijo standardi? Če govorimo o sistemih s pretežno programsko opremo, morate upoštevatinekaterih vidikov okolja. Torej, da bi bil program koristen, bi moral delovati. To storite tako, da ga zaženete na določeni strojni opremi. Arhitektura računalnika je tukaj zelo pomembna. Računalniška programska oprema, ki je ustvarjena za Windows, ne bo delovala na tehnologiji, na kateri je nameščen MacOS. Čeprav lahko, seveda, naredite emulator, tečete skozi navidezni stroj ali uporabite drugega posrednika in zaženete programsko opremo. Toda učinkovitost svojega dela bo veliko manj kot v primeru dela s ciljnimi sistemi. Zato se mora arhitektura računalnika in programske opreme pravilno ujemati. Konec koncev lahko isti MacOS deluje le pod določeno konfiguracijo. Torej ima Windows določene omejitve, čeprav je manj vezan na železo.

Raznolikost vrst

Katere modele lahko ustvarite? Na kratko opišemo vrste arhitekture programske opreme, ki se pogosto uporabljajo:

model odjemalec-strežnik.

Monolitna uporaba.

Priložnostna arhitektura.

Strukturirano.

Tri ravni.

Arhitektura, usmerjena v storitve.

Implicitni izzivi.

Arhitektura, usmerjena v iskanje.

To je le majhen del velikega števila različnih pristopov in predlog. In daleč od tega, da bi bil edini. Treba je opozoriti, da razvoj arhitekture programske opreme ni nekaj zapletenega in nemogočega, zato jih mnogi ustvarjajo sami (zelo pogosto kopirajo tisto, kar že obstaja, vendar ne ve). Seveda, medtem ko so majhne razlike v podrobnostih, vendarso rezultat prilagajanja predloge posebnim zahtevam skupin programerjev. Morda je mogoče ustaviti. Opozoriti je treba, da je bil v članku glavni poudarek na značilnostih arhitekture programske opreme. Številnih pomembnih vprašanj, ki so precej presegla obseg glavne teme, niso upoštevali. Med njimi - vloga razvijalca, katere osnovne dejavnosti mora izvajati, in nekatere druge.