V současné době existuje jen málo lidí, kteří budou argumentovat tvrzením, že náš svět je stále více závislá na softwaru (softwaru). A to není divné. Používá se v mobilních telefonech, integrovaných řídících systémech řízení letového provozu, osobních počítačích, automobilové elektronice a mnoha dalších. Mnoho inovací, které jsme vnímáni jako fakt, stejně jako celá řada organizací, jako je „Yandex“, Amazon nebo Google prostě nemožné bez softwaru. Ale i v tradičním obchodním, veřejném a finančním odvětví je velmi obtížné bez softwaru.

General

Člověk má jen dotknout ponětí o architektuře, jakmile je zřejmé, jedna věc - nedostatek definice neexistuje. Z tohoto důvodu není svrhnout zmatené čtenáře, článek použil IEEE 1471 a IEEE Std 1,472,000 jako příklady za úplatu. A teď se podívejme, jaká architektura představuje. Tento termín se vztahuje na organizaci systému vtěleného do jeho složek, vztah mezi nimi a životního prostředí, a zásad, jimiž se řídí její design a vývoj. Nejprve si však pamatujeme ty, kteří významně přispěli k rozvoji teorie a koncepce softwaru.


Nejdříve je třeba zmínit Lance Bass. "Architektura softwaru v praxi - spíše stará práce tohoto autora (ruský překlad byl vydán v roce 2006), ale přesto vám umožňuje získatvysoce kvalitní pochopení procesu vývoje softwaru. Dalším zajímavým autorem je Robert Martin a jeho tvorba "Pure Architecture". Umění vývoje softwaru ". Překlad a publikaci knihy do ruštiny byly provedeny na počátku roku 2018. Proto je bezpečné říci, že je to doslova novinka, ve které je mnoho čerstvých a relevantních informací. Kniha "Čistá architektura. Umění vývoje softwaru "říká, jak dosáhnout výšky profesionality. Popisuje, co a jak dělat a proč bude řešení rozhodující pro úspěch.

Trochu terminologie

Zvažte některé pojmy, které nám pomohou porozumět tématu:

Systém - určitá sada komponent, která byla spojena k provedení určité funkce nebo nastavení.

Poslání - žádost (opatření), kterou se chystá jedna nebo více zainteresovaných stran v souladu s nezbytnými podmínkami.

Komponent je logický, fyzický, technologicky příbuzný (nezávislý), jemný nebo hrubozrnný modulární systém, který zapouzdřuje jeho obsah.

A některé další interpretace týkající se hlavního tématu:

Architektura - soubor smysluplných rozhodnutí, která ovlivňují organizaci systému C. Soubor konstrukčních prvků, jakož i jejich rozhraní, kterými je uspořádání.

Architektura programu (počítačový systém) - struktura, která zahrnuje určité prvky viditelné zvenčí jejich vlastností, jakož i propojení mezi nimi. Skládá se ze všech důležitýchpřijatá rozhodnutí o návrhu. Poskytuje požadovanou sadu vlastností, které jsou nezbytné pro úspěšné podnikání.

Architektura je struktura organizace, stejně jako související systémové chování. Může být rekurzivně rozebrána do částí, komunikace a podmínek montáže.

I když tyto definice mají zlomek rozdílů, není obtížné si všimnout jisté podobnosti. Takže pozornost je zaměřena na strukturu, chování a smysluplná rozhodnutí. A to není zbytečné.

Vliv architektury na strukturu

Zde je jeden zajímavý moment. Stojí za to požádat o to, aby bylo popsáno slovo "architektura", protože většina lidí zde odkazuje na strukturu. A to není divné. Koneckonců, architektura softwaru v praxi je často založena na schématu, který popisuje strukturální aspekty systému. Kromě toho nezáleží na tom, o čem je jazyk - o úrovních, součástech nebo distribuovaných uzlech. Struktura je nejdůležitějším rysem architektury. Jeho aspekty a rysy se projevují mnoha způsoby. Strukturním prvkem může být databáze, knihovna, proces, subsystém, výpočetní uzel a podobně. Kromě toho je třeba věnovat pozornost nejen jejich samostatnosti, ale také jejich skladbám, zavedeným vazbám, rozhraním a oddílům. Je třeba vzít v úvahu, že každý z těchto prvků může být zastoupen různými způsoby. Jako příklad lze najít propojení. Může být: a /synchronní, zásuvka, spojená s určitým protokolem atd.

Vliv architektury na chování

Je prostě nemožné ji podceňovat.Navrhování architektury softwaru má velký vliv na jeho implementaci a další výkon. Chování, možná visí, problémy atd. Velmi závisí na tom, jak se všechno vyvinulo od samého počátku. Architektura ovlivňuje interakci mezi konstrukčními prvky, musí poskytovat přenos dat přesně tam, kde je nutné nakonec získat požadovaný výsledek. Jak se to stalo s našimi standardy? Vidíte malý plán činnosti. Předpokládejme, že máme podnik. Je třeba se ujistit, že zaměstnanec vzal příkaz pomocí instance třídy "Form". Obsahuje všechny potřebné informace o klientovi. Pokud je objednávka poprvé provedena, informace se zadá do řídícího systému "prázdné". Pak se používá instance třídy "Spuštění objednávky", která spouští všechny nezbytné procesy v podniku. Celkem je celkem pět prvků. Současně existuje určitá závislost. Například objednání není možné bez zaměstnance. A pokud není Blank vyplněn, nebude přijato.

Koncentrace architektury na základní prvky

Takže jsme již zvažovali dopad na strukturu a chování. Zde je však třeba poznamenat jeden důležitý bod. Konkrétně architektura nedefinuje celou strukturu a ne všechna chování. Ovlivňuje ty prvky, které jsou považovány za významné. Co je pod nimi? Významné jsou ty prvky, které mají dlouhý a trvalý účinek. Například,hlavní konstrukční Nebo ty, které závisí na spolehlivosti a škálovatelnosti softwaru. V takovém případě architektura zpravidla nemá vztah k detailním detailům všech těchto prvků. Hlavní atribut, pro který jsou některé hodnoceny více než jiné, jsou náklady na tvorbu a úpravu. Architektura se zaměřuje na smysluplné prvky. Proto by měla nabídnout konkrétní perspektivu, což je nejdůležitější. Dá se říci, že architektura je definitivní zobecnění celého softwarového systému, který umožňuje vývojáři spravovat stávající složitost. Zde je důležité si uvědomit. Namísto toho soubor smysluplných prvků není statickým seznamem něčeho a může se časem měnit. V jakých případech se to děje? Jako příklad lze uvést situaci, kdy vyplývá výsledek požadavků, identifikace rizik a další podobné momenty. Je třeba poznamenat, že relativní stabilita architektury, navzdory provedeným změnám, je známkou dobře provedené práce a dobře zavedeného procesu rozvoje, stejně jako zkušeností a kvalifikace pracovníků.

Vyrovnání potřeb zúčastněných stran

V praxi by softwarová architektura měla být vhodná jak pro uživatele, tak i pro administrativní pracovníky. Je třeba poznamenat, že často splnění všech vyjádřených přání není možné. Jako příklad lze uvést situaci, kdy dotyčná osoba požaduje určitou funkci, která má být provedena na určitou dobumezera Ale tyto dvě potřeby se navzájem vylučují. To znamená, že můžete buď omezit hranice funkce, která má být provedena, aby splňovala požadovaný plán, nebo ponechat vše v plném rozsahu, ale pak to bude trvat příliš dlouho. Stejně tak například mohou mít zúčastněné strany požadavky různého stupně rozporu. V takových případech je nutné dosáhnout určité rovnováhy. Kompromisní řešení je prakticky nenahraditelným aspektem procesu vývoje architektury. A zde, bohužel, nebudete dělat nic - musíte překonat potíže. Chcete-li získat představu o skutečné situaci, simulujte situaci, když potřebujete splnit potřeby několika zúčastněných stran:

Konečný uživatel. Má zájem o to, aby software byl intuitivní, produktivní, spolehlivý, uživatelsky přívětivý, bezpečný a cenově dostupný, a měl také správné chování.

Správce systému. Zajímá se o přítomnost intuitivního řízení, monitorovacích nástrojů a chování celého komplexu.

Specialista na reklamu a propagaci. Zajímá se o přítomnost jedinečných vlastností, které činí software konkurenceschopným, orientačním časem před uvolněním vývoje na trhu, náklady na produkt a jeho postavení mezi analogy.

Vývojář. Má zájem o pochopení požadavků a nekonfliktních principů vnitřního systému.

Vedoucí projektu. Zajímá se o to, že průběh návrhu, plánování a provádění byl předvídatelný.Je také třeba se starat o racionální využití dostupného rozpočtu a finančních prostředků.

Architektura je založena na logickém zdůvodnění

Při práci musí být věnována pozornost nejen výslednému výsledku. Samozřejmě, architektura si zaslouží pozornost. Stejné jako logické odůvodnění použité jako jeho základ. Proto je nutné poskytnout dokumentaci o rozhodnutích, kterými se vytvořila stávající architektura. Je také nezbytné poskytnout jim logické zdůvodnění. Navzdory jednoduchosti a jednoduchosti úkolu je tato informace důležitá pro zúčastněné strany, zejména pro ty, kteří systém obsluhují. Také dokumentace je cenná pro vývojáře v případě potřeby revidovat důvody pro rozhodování, aby se zabránilo zbytečnému opakování činností, které již spáchal. Například při prohlížení architektury. Koneckonců, v takových případech je nutné vysvětlit, proč taková rozhodnutí byla učiněna.

O architektonickém stylu

Co a jak v tomto případě? Pokud se podíváte na architekturu softwaru pro mnoho produktů, uvidíte, že jsou postaveny na systémech, které používají podobné skupiny zájmů. Řada podobností může být provedena v určitém stylu. On, na druhou stranu, může být považován za zvláštní druh šablony, velmi složitou a konstitutivní. Jedná se o kodér zkušeností a je to dost dobré pro vývojáře, aby ji znovu použili. Koneckonců vám to umožní rychle a rychle provést tuto práci. Jaké jsou hlavní architektury?stylový software outsourcing? Příklady zahrnují:

Distribuované.

Kanály a filtry.

Při centralizovaném zpracování údajů.

Postaven na pravidlech.

Je třeba poznamenat, že jednotlivé systémy mohou prokázat přítomnost více než jednoho stylu. Jaká je potvrzení těchto slov? Za prvé můžeme zmínit architektonický styl výstavy a Garlan. Jak se to projevuje? Architektonický styl je v podstatě nomenklatura součástí, stejně jako typy propojovacích vazeb a souborem podmínek, pomocí kterých je lze kombinovat. Opětovné využití zkušeností v podobě aplikace architektonického stylu pomáhá ulehčit život díky skutečnosti, že již dobře zdokumentoval a zdůvodnil racionální využití něčeho obilí.

O vlivu životního prostředí. A naopak

Jinými slovy, o architektuře v rámci sémantického obsahu. Je třeba určit limity, v nichž bude fungovat softwarový systém. Zaměřuje se především na životní prostředí. Architektura softwarového systému by měla v takových případech zohledňovat faktory vlivu. Konkrétněji je nutné zaměřit se na zúčastněné subjekty v rámci misí, na interní a externí technické omezení. Architektura softwaru může navíc ovlivnit jeho prostředí. Kromě toho nejen z technologického hlediska, ale také umožňuje opětovné využití majetku a pracovního prostředí. O jakých standardech mluvíme? Pokud hovoříme o převážně softwarových systémech, pak byste měli vzít v úvahuurčitých aspektů životního prostředí. Takže, aby byl program užitečný, měl by fungovat. Chcete-li to provést, musíte jej spustit na určitém hardwaru. Architektura počítače je zde velmi důležitá. Počítačový software vytvořený pro systém Windows nebude pracovat s technologií, na které je nainstalován program MacOS. Přestože můžete samozřejmě vytvořit emulátor, spustit virtuální počítač nebo použít jiného prostředníka a spustit software. Účinnost práce bude však mnohem nižší než v případě práce s cílovými systémy. Proto by architektura počítače a softwaru měla odpovídat správnému fungování. Koneckonců, stejný systém MacOS může fungovat pouze za určité konfigurace. Takže Windows má určitá omezení, i když je méně spojena se železem.

O rozmanitosti druhů

Jaké modely můžete vytvořit? Stručně uvádíme typy softwarové architektury, které jsou široce používány:

Model klient-server.

Monolitická aplikace.

Příležitostná architektura.

Strukturovaný.

Tři úrovně.

Architektura orientovaná na služby.

Implicitní výzvy.

Vyhledávací architektura.

Toto je jen malá část velkého množství různých přístupů a šablon. A zdaleka to není jediný. Je třeba poznamenat, že vývoj softwarové architektury není něco složitého a nemožného, ​​mnoho z nich vytváří samostatně (velmi často kopíruje to, co již existuje, ale co nevědělo). Samozřejmě, i když existují malé rozdíly v detailech, alejsou výsledkem přizpůsobení šablony specifickým požadavkům týmů programátora. Možná je možné zastavit. Je třeba poznamenat, že v článku byl kladen důraz především na charakteristiky softwarové architektury. Řada důležitých otázek, poněkud mimo rozsah hlavního tématu, nebyla zvažována. Mezi nimi - role developera, které základní činnosti musí vykonávat, a některé další.