V súčasnosti je málo ľudí, ktorí budú argumentovať s tvrdením, že náš svet je čoraz viac závislý od softvéru (softvéru). A nie je to zvláštne. Používa sa v mobilných telefónoch, integrovaných systémoch riadenia letovej prevádzky, osobných počítačoch, automobilovej elektronike a mnohým ďalším. Mnoho inovácií, ktoré vnímame ako dané, ako aj veľké množstvo rôznych organizácií, ako napríklad Yandex, Amazon alebo Google, sú bez softvéru jednoducho nemožné. Ale aj v tradičnom obchodnom, verejnom a finančnom sektore je veľmi ťažké robiť bez softvéru.

Všeobecné informácie

Stojí za zmienku len pojem architektúra, takže jedna vec je jasná naraz - nedostatok definícií neexistuje. Preto aby sa zamenili čitatelia, štandardy IEEE 1471 a IEEE Std 1472000 sa budú používať ako prototypy na posúdenie v článku. A teraz sa pozrime na to, čo predstavuje architektúra. Tento pojem sa týka organizácie systému obsiahnutého v jeho zložkách, vzťahu medzi nimi a životného prostredia, ako aj princípov, ktoré vymedzujú jeho návrh a vývoj. Po prvé, spomeňme si tých, ktorí významne prispeli k rozvoju teórie a koncepcie softvéru.


Predovšetkým je potrebné spomenúť Lance Bass. "Architektúra softvéru v praxi - dosť stará práca tohto autora (ruský preklad bol prepustený v roku 2006), ale napriek tomu vám umožňuje získaťvysoko kvalitné pochopenie procesu vývoja softvéru. Ďalším zaujímavým autorom je Robert Martin a jeho tvorba "Pure Architecture". Umenie vývoja softvéru ". Preklad a publikácia knihy do ruštiny sa uskutočnili už na začiatku roka 2018. Preto je bezpečné povedať, že je to doslova novinka, v ktorej je veľa čerstvých a relevantných informácií. Kniha "Čistá architektúra. The Art of Software Development "hovorí o tom, ako dosiahnuť výšky profesionality. Opisuje, čo a ako urobiť a prečo bude riešenie kľúčové pre úspech.

Trochu terminológie

Zvážte niektoré pojmy, ktoré nám pomôžu pochopiť tému:

Systém - určitá sada komponentov, ktoré boli kombinované na vykonávanie konkrétnej funkcie alebo množiny.

Poslanie - žiadosť (akcia), ktorú má jedna alebo viacero zainteresovaných strán pripraviť v súlade s potrebnými podmienkami.

Komponent je logický, fyzikálny, technologicky príbuzný (nezávislý), jemný alebo hrubozrnný modulárny systém, ktorý zapuzdruje jeho obsah.

a niekoľko výkladov k hlavnej téme:

Architektúra - súbor dôležité rozhodnutia ovplyvňujúce organizáciu Z. sadu konštrukčných prvkov a ich rozhranie, cez ktoré rozvrhnutie.

Architektúra programu (počítačový systém) - štruktúra, ktorá zahŕňa určité prvky viditeľné zvonka ich vlastností, ako aj spojenia medzi nimi. Skladá sa zo všetkých dôležitýchprijaté rozhodnutia o návrhu. Poskytuje požadovanú sadu vlastností, ktoré sú potrebné pre úspešné podnikanie.

Architektúra je štruktúra organizácie, ako aj systémové správanie s ňou spojené. Môže byť rekurzívne rozložený na časti, komunikáciu a podmienky montáže.

Hoci tieto definície majú zlomok rozdielov, nie je ťažké si všimnúť určitú podobnosť. Takže pozornosť je zameraná na štruktúru, správanie a zmysluplné rozhodnutia. A to nie je zbytočné.

Vplyv architektúry na štruktúru

Tu je jeden zaujímavý moment. Stojí za to žiadať, aby bolo popísané slovo "architektúra", ako sa tu väčšina ľudí odvoláva na štruktúru. A nie je to zvláštne. Koneckonců, architektúra softvéru v praxi je často postavená na schéme, ktorá zobrazuje štrukturálne aspekty systému. Navyše nezáleží na tom, čo je o jazyku - o úrovniach, súčastiach alebo distribuovaných uzloch. Štruktúra je najdôležitejším prvkom architektúry. Jeho aspekty a črty sa prejavujú mnohými spôsobmi. Štrukturálnym prvkom môže byť databáza, knižnica, proces, subsystém, výpočtový uzol atď. Okrem toho by sa mala pozornosť venovať nielen samostatne, ale aj ich kompozíciám, zavedeným zväzom, rozhraniam a oddeleniam. Musí sa vziať do úvahy, že každý z týchto prvkov môže byť zastúpený rôznymi spôsobmi. Ako príklad možno nájsť spojenie. Môže to byť: a /synchrónny, zásuvka, spojená s konkrétnym protokolom atď.

Vplyv architektúry na správanie

Je jednoducho nemožné ho podceňovať.Navrhovanie architektúry softvéru má veľký vplyv na jeho implementáciu a ďalší výkon. Správanie, možné závesy, problémy atď. Veľmi závisí od toho, ako sa všetko vyvinulo od samého začiatku. Architektúra ovplyvňuje interakciu medzi konštrukčnými prvkami, musí poskytnúť prenos dát presne tam, kde je potrebné nakoniec získať požadovaný výsledok. Ako sa to stalo s našimi normami? Môžete vidieť malý plán činnosti. Predpokladajme, že máme podnik. Je potrebné zabezpečiť, aby zamestnanec prijal objednávku pomocou inštancie triedy "Form". Obsahuje všetky potrebné informácie o klientovi. Ak sa objednávka vykoná prvýkrát, informácie sa zadajú do riadku "Blank" pomocou riadiaceho systému. Potom sa použije inštancia triedy "Začať spracovanie objednávky", ktorá spúšťa všetky potrebné procesy v podniku. Celkovo je päť prvkov. Súčasne existuje určitá závislosť. Napríklad objednávanie je bez zamestnanca nemožné. A ak Blank nie je naplnený, nebude prijatý.

Koncentrácia architektúry na základné prvky

Takže sme už zvážili vplyv na štruktúru a správanie. Tu je však potrebné poznamenať jeden dôležitý bod. Konkrétne architektúra nedefinuje celú štruktúru a nie celé správanie. Ovplyvňuje tie prvky, ktoré sú považované za významné. Čo je pod nimi? Významné sú tie prvky, ktoré majú dlhý a dlhotrvajúci účinok. Napríklad,hlavné štrukturálne Alebo tie, ktoré závisia od spoľahlivosti a škálovateľnosti softvéru. V tomto prípade architektúra spravidla nemá žiadnu súvislosť s podrobnými detailmi všetkých týchto prvkov. Hlavným atribútom, pre ktorý sú niektoré hodnotené viac ako iné, sú náklady na tvorbu a úpravu. Architektúra sa zameriava na zmysluplné prvky. Preto by mala ponúknuť konkrétny pohľad, čo je najdôležitejšie. Dá sa povedať, že architektúra je definitívne zovšeobecnenie celého softvérového systému, ktorý umožňuje vývojárovi zvládnuť existujúcu zložitosť. Tu je dôležité si všimnúť. Zozname zmysluplných prvkov nie je statickým zoznamom niečoho a môže sa časom meniť. V akých prípadoch sa to deje? Ako príklad možno uviesť situáciu, v ktorej príde výsledok požiadaviek, identifikácia rizík a iné podobné momenty. Treba poznamenať, že relatívna stabilita architektúry napriek vykonaným zmenám je znakom dobre vykonanej práce a dobre zavedeného procesu rozvoja, ako aj skúseností a kvalifikácie zamestnancov.

Vyrovnávanie potrieb zainteresovaných strán

V praxi by softvérová architektúra mala byť užitočná pre užívateľov, ako aj pre administratívnych pracovníkov. Treba poznamenať, že často nie je možné splniť všetky vyjadrené želania. Ako príklad možno uviesť situáciu, keď daná osoba požaduje, aby sa určitá funkcia vykonávala na určitý časobdobie. Ale tieto dve potreby sa navzájom vylučujú. To znamená, že môžete buď obmedziť hranice funkcie, ktorá sa má vykonať, aby spĺňala požadovaný plán, alebo ponechať všetko v plnom rozsahu, ale potom to bude trvať príliš veľa času. Podobne môžu napríklad zainteresované strany mať požiadavky rôzneho stupňa rozporu. V takýchto prípadoch je potrebné dosiahnuť určitú rovnováhu. Kompromisné riešenie je prakticky nenahraditeľným aspektom procesu vývoja architektúry. A tu, bohužiaľ, neurobíte nič - musíte prekonať ťažkosti. Ak chcete získať predstavu o skutočnej situácii, simulujte situáciu, keď potrebujete splniť potreby viacerých zainteresovaných strán:

Koncový používateľ. Má záujem zabezpečiť, aby bol softvér intuitívny, produktívny, spoľahlivý, užívateľsky prívetivý, bezpečný a cenovo dostupný, a tiež má správne správanie.

Správca systému. Zaujíma sa o prítomnosť intuitívneho manažmentu, monitorovacích nástrojov a správania celého komplexu.

Špecialista na reklamu a propagáciu. Zaujíma sa o prítomnosť jedinečných funkcií, ktoré robia softvér konkurencieschopným, orientačným časom pred uvoľnením vývoja na trhu, cenou produktu a jeho pozíciami medzi analógmi.

Vývojár. Má záujem o pochopenie požiadaviek a nezlučiteľných princípov vnútorného systému.

Projektový manažér. Zaujíma sa o tom, že priebeh návrhu, plánovania a realizácie bol predvídateľný.Je tiež potrebné dbať na racionálne využitie dostupného rozpočtu a finančných prostriedkov.

Architektúra je založená na logickom odôvodnení.

Pri práci sa musí venovať pozornosť nielen výslednému výsledku. Samozrejme, architektúra si zasluhuje pozornosť. Rovnako ako logické odôvodnenie ako jeho základ. Preto je potrebné poskytnúť dokumentáciu o rozhodnutiach, ktorými sa vytvorili existujúce architektúry. Je tiež potrebné poskytnúť im logické zdôvodnenie. Napriek jednoduchosti a jednoduchosti úlohy je táto informácia dôležitá pre zainteresované strany, najmä pre tých, ktorí túto službu poskytujú. Dokumentácia má tiež hodnotu pre vývojárov v prípadoch, keď je potrebné preskúmať odôvodnenie prijatých rozhodnutí, aby sa zabránilo zbytočnému opakovaniu už vykonaných krokov. Napríklad pri prezeraní architektúry. Napokon je v takýchto prípadoch potrebné vysvetliť, prečo boli takéto rozhodnutia prijaté.

O architektonickom štýle

Čo a ako v tomto prípade? Ak sa pozriete na architektúru softvéru pre mnohé produkty, môžete vidieť, že sú postavené na systémoch, ktoré používajú podobné skupiny záujmov. V určitom štýle sa dá urobiť niekoľko podobností. Na druhej strane môže byť považovaný za špeciálny druh šablóny, veľmi zložitý a základný. Toto je kodér skúseností a je to dosť dobré pre vývojárov, aby ich znova použili. Koniec koncov vám to umožní robiť takú prácu rýchlo a rýchlo. Aké sú hlavné architektúryštýlový softvér outsourcing? Medzi príklady patria:

Distribuované.

Kanály a filtre.

Pri centralizovanom spracovaní údajov.

Vytvorené podľa pravidiel.

Treba poznamenať, že jednotlivé systémy dokážu preukázať prítomnosť viac ako jedného štýlu. Čo je to potvrdenie týchto slov? Po prvé, môžeme spomenúť architektonický štýl výstavy a Garlan. Ako sa to prejavuje? Architektonický štýl je v podstate nomenklatúra komponentov, ako aj typy spojovacích článkov a súbory podmienok, pomocou ktorých sa dajú kombinovať. Opätovné použitie skúseností v podobe aplikácie architektonického štýlu pomáha uľahčiť život vďaka tomu, že už dobre zdokumentoval a zdôvodnil racionálne použitie niečoho obilia.

O vplyve na životné prostredie. A naopak

Alebo inými slovami, o architektúre v rámci sémantického obsahu. Je potrebné určiť limity, v rámci ktorých bude softvérový systém fungovať. Zameriava sa hlavne na životné prostredie. Architektúra softvérového systému by mala zohľadňovať faktory ovplyvňovania. Konkrétnejšie je potrebné zamerať sa na účastníkov misie, interné a externé technické obmedzenia. Navyše architektúra softvéru môže ovplyvniť jeho prostredie. Navyše nielen z technologického hľadiska, ale umožňuje aj opätovné použitie majetku a pracovného prostredia. O čom hovoria štandardy? Ak hovoríme o prevažne softvérových systémoch, mali by ste to vziať do úvahyurčitých aspektov životného prostredia. Takže, aby bol program užitočný, mal by fungovať. Ak to chcete urobiť, musíte ho spustiť na konkrétnom hardvéri. Architektúra počítača má veľký význam. Počítačový softvér, ktorý je vytvorený pre operačný systém Windows, nebude pracovať s technológiou, na ktorej je MacOS nainštalovaný. Aj keď, samozrejme, môžete vytvoriť emulátor, spustiť virtuálny počítač alebo použiť iného mediátora a spustiť softvér. Účinnosť jeho práce bude však omnoho nižšia ako v prípade práce s cieľovými systémami. Preto by architektúra počítača a softvéru mala zodpovedať, aby fungovala správne. Koniec koncov, rovnaký systém MacOS môže pracovať iba v určitej konfigurácii. Systém Windows má určité obmedzenia, aj keď je menej viazaný na železo.

o rozmanitosti druhov

Aké modely môžete vytvoriť? Stručne uvádzame typy architektúry softvéru, ktoré sú široko používané:

Model klient-server.

Monolitická aplikácia.

Príležitostná architektúra.

Štruktúrované.

Tri úrovne.

Architektúra orientovaná na služby.

Implicitné výzvy.

Architektúra orientovaná na vyhľadávanie.

Toto je len malá časť veľkého množstva rôznych prístupov a šablón. A ďaleko od toho, aby bol jediný. Treba poznamenať, že vývoj softvérovej architektúry nie je niečo zložité a nemožné, toľko ich vytvára samostatne (veľmi často kopíruje to, čo už existuje, ale čo nevedelo). Samozrejme, aj keď sú malé rozdiely v detaile, alesú výsledkom prispôsobenia šablóny špecifickým požiadavkám tímov programátora. Možno sa dá zastaviť. Je potrebné poznamenať, že na základe článku bol kladený dôraz na opis architektúry softvéru. Rad dôležitých otázok, ktoré sú trochu mimo hlavných diskutovaných tém nebol. Medzi nimi - úloha developera, že hlavná činnosť by mala vykonávať a ďalšie.