Toto je objekt systému MBI.

MBI (Management Byznys Informatiky) je portál obsahující zobecněná řešení v řízení provozu a rozvoje IT, resp. podnikové informatiky.

Pokud máte zájem získat více informací o tomto objektu (vazby na další objekty, přílohy, apod.), ale i získat mnoho dalších užitečných materiálů, můžete tak učinit ZDE / (registrace je bezplatná).

Faktor : Softwarová architektura
Softwarová architektura
Kód faktoru

Standardní kód faktoru v MBI.

:
F155
Autor

Jméno a příjmení autora

:
Voříšek, J. (KIT, VŠE)
Podstatné charakteristik faktoru

Obsahové vymezení faktoru

1. Softwarová architektura - obsahové vymezení
  • V případě softwarové architektury je systémem, na kterém architekturu definujeme, jeden softwarový produkt, tj. jedna softwarová aplikace.
  • Hlavními komponentami , jejichž strukturu a vztahy architektura definuje, jsou programové moduly aplikace .
1.1. Jednouživatelská a víceuživatelská aplikace (single-tenant, multi-tenant architecture)
  • Architektura jednouživatelské aplikace je navržena pro situaci , kdy aplikace je provozována zvlášť pro každého uživatele . Tzn., že jestliže aplikaci využívá v podniku „n“ uživatelů současně, je daná aplikace zavedena do operační paměti a spuštěna n-krát . Taková situace např. nastává, když textový editor má každý uživatel nainstalovaný na svém notebooku.
  • Jednouživatelská aplikace má obvykle nižší náklady tvorby (je jednodušší ji napsat, odladit, otestovat a customizovat), ale vyšší náklady provozu (má vyšší celkové nároky na počítačové zdroje. Pro některé aplikace je ale jednouživatelská aplikace nepoužitelná , a to zejména v případech, kdy má více uživatelů pracovat se stejnými daty (společná tvorba dokumentu, rezervace letenek apod.).
  • Architektura víceuživatelské aplikace je navržena tak, aby tutéž aplikaci ve stejné době mohly využívat stovky a tisíce uživatelů z jedné nebo dokonce z mnoha organizací (viz např. e-shop, rezervace letenek, Google Apps, nebo CRM od SalesForce). U těchto aplikací je často typické, že všichni uživatelé sdílejí tutéž datovou základnu. Víceuživatelské aplikace se široce využívají zejména pro realizaci SaaS (Software jako služba) - (F106 ) .
1.2. Klient/server architektura
  • V klient/server architektuře je aplikace rozdělena na dva nebo více kooperujících programů . Klientem je ten program, který vyžaduje provedení určité služby (funkcionality), zatímco serverem je ten, který danou službu na požádání poskytuje.
  • Jeden a tentýž program přitom jednou může vystupovat jako klient, jindy jako server. Klient i server mohou být umístěny buď na tomtéž počítači , nebo mohou pracovat na různých počítačích počítačové sítě .
  • Mezi výhody klient/server architektury , která využívá více počítačů patří:
    • nižší nároky na server oproti centralizovanému zpracování (část zátěže nese klient),
    • snadnější inkrementální růst kapacit , které jsou pro zpracování aplikace zapotřebí. Tato výhoda se využívá zejména u víceuživatelských aplikací, kde klient řeší zpracování uživatelského rozhraní . S růstem počtu uživatelů takových aplikací roste počet koncových stanic, na kterých je zpracovávána klientská část aplikace, ale nároky na server rostou jen minimálně,
    • lze volit zvlášť vhodnou provozní platformu (hardware a základní software) pro jednotlivé části aplikace,
    • snadnější zabezpečení ochrany dat pomocí specializovaného datového serveru.
  • Mezi nevýhody klient/server architektury lze zařadit:
    • vyšší počáteční investice nutné pro zprovoznění aplikací (komunikační infrastruktura, výkonnější stanice používané v roli klientů),
    • problémy s integrací různých platforem,
    • vyšší nároky na kvalifikaci řešitelů.
  • Klient/server architektura se aplikuje v dvou a třívrstvé softwarové architektuře.
1.3. Monolitická, dvouvrstvá a třívrstvá architektura
  • Obvyklá aplikace obsahuje tři základní skupiny funkcí:
    • datové funkce (ukládání dat, výběry dat, aktualizace dat, ochrana dat),
    • věcně orientované funkce, které zajišťují vlastní byznys logiku aplikace, tj. zajišťují požadovanou transformaci vstupních dat na data výstupní (např. výpočet mzdy zaměstnance, vytvoření faktury apod.),
    • komunikační funkce (zobrazování výsledků na obrazovce koncové stanice, komunikace s uživatelem ve zvolené formě, navigace po funkcích aplikace, nápověda uživateli atd.).
  • Základní rozdíl mezi monolitickou, dvouvrstvou a třívrstvou architekturou je v tom, zda jsou tyto skupiny funkcí odděleny do samostatných programů, či nikoli:
    • jsou-li všechny skupiny funkcí realizovány jedním programem , jedná se o jednovrstvou monolitickou architekturu,
    • je-li jedna ze skupin funkcí oddělena od dvou zbývajících, jedná se o dvouvrstvou architekturu,
    • jsou-li všechny tři skupiny odděleny do samostatných programů, jde o třívrstvou architekturu (vznikají datová vrstva, aplikační vrstva a prezentační vrstva aplikace).
  • Jednotlivé vrstvy přitom mezi sebou komunikují jako klient se serverem , tzn., že dvouvrstvá a třívrstvá architektura aplikuje současně klient/server architekturu .
  • Monolitická architektura je typická pro centralizované zpracování . V monolitické architektuře jsou tři skupiny funkcí v programu vzájemně propleteny a samotný program běží na jednom počítači . Výhodou tohoto řešení je snadné zajišťování ochrany funkcí a dat aplikace před neautorizovaným použitím a snadné zajišťování aplikace proti výpadkům.
  • Monolitická architektura ale s sebou přináší i řadu problémů :
    • obtížná údržba . Tím, že jednotlivé skupiny funkcí nejsou v aplikaci separovány, znamená například přechod na jinou formu komunikace nebo přechod na jiný systém řízení báze dat zásah do mnoha míst programu, což zvyšuje jak časové nároky na údržbu, tak riziko chybných nebo neúplných oprav,
    • obtížná přenositelnost aplikace mezi různými platformami. Velmi často jsou aplikace s monolitickou architekturou spojeny s jednou platformou jako pupeční šňůrou. Když se na trhu objeví lacinější a výkonnější hardware a/nebo základní software, je velmi nesnadné přenést aplikaci do tohoto nového prostředí.
1.4. Dvouvrstvá architektura
  • U dvouvrstvé architektury jsou možné dvě varianty řešení aplikace - tzv. lehký nebo těžký klient . Obě varianty sledují hlavní cíl - oddělit komunikační a datové funkce aplikace .
  • Oddělením těchto dvou skupin funkcí se získává řada výhod :
    • v aplikaci se s nadněji zajišťují různé formy komunikace s různými koncovými stanicemi a s různými uživateli tím, že pro každou formu komunikace se vytvoří samostatný program realizující prezentační vrstvu pro daný účel. Tím r oste uživatelský komfort aplikace a usnadňuje se údržba aplikace,
    • zvyšuje se přenositelnost aplikace (např. aplikaci mohou používat různé typy chytrých telefonů s různým ovládáním),
    • u dvouvrstvé architektury však přetrvává problém přílišného propojení věcně orientovaných funkcí s jednou z dalších skupin funkcí.
1.5. Třívrstvá architektura
  • Třívrstvá architektura odstraňuje i poslední nevýhodu. Každou ze skupin funkcí lze tudíž udržovat a rozvíjet zcela samostatně , pro každou z nich je také možné zvolit nejvýhodnější vývojové a provozní prostředí.
  • třívrstvá architektura je proto ideální architekturou pro tvorbu otevřených, distribuovaných a flexibilních informačních systémů, které lze pružně přizpůsobovat:
    • změnám na trhu s hardwarem a základním softwarem - pro jednotlivé části aplikací je možné vybrat tu platformu, která má nejvýhodnější poměr cena/výkon,
    • změnám v uživatelských požadavcích na funkce a uživatelské rozhraní aplikací,
    • změnám v počtu uživatelů a změnám v intenzitě práce uživatelů.
1.6. Lineární, hierarchická, vrstvená a síťová architektura
  • Větší aplikace (např. ERP, CRM) jsou tvořeny desítkami až stovkami programových modulů. Znamená to, že např. byznys logika aplikace nebo prezentační funkce nejsou tvořeny pouze jedním programovým modulem, ale mnoha moduly .
  • Cílem této dekompozice aplikace na malé programové celky je snadnější vývoj a údržba aplikace a také realizace téže funkcionality pouze jedenkrát (sdílení téže funkcionality více moduly). Dekomponujeme-li aplikaci na mnoho modulů, musí být též navrženo, jaké budou platit principy pro jejich vzájemnou komunikaci .
  • V lineární architektuře je požadovaná funkcionalita systému dosažena sekvenčním uspořádáním elementárních modulů . Příkladem lineární architektury je uspořádání základních komponent klasického textového systému , který obsahuje tři základní funkční komponenty: editor (tvorba a údržba dokumentu), reeditor (doplnění variabilních částí dokumentu jako jsou křížové odkazy, obsah, rejstřík atd.) a formátor (sestavení výstupní podoby dokumentu na obrazovce či tiskárně).
  • Výhodou systému s lineární architekturou je, že nevyžaduje komplikovanou organizaci pracovních týmů a že se snadno testuje. Nevýhodou pak je, že nepodporuje strukturovaný přístup k řešení problému a že změna v jedné funkci/modulu může vyvolat řetěz úprav navazujících funkcí/modulů.
  • Je-li lineární architektura použita při řešení vhodného typu problému, pak má aplikace oproti následujícím architekturám nejnižší náklady vývoje. V praxi se však systémy z čistě lineární architekturou vyskytují zřídka , protože podstata problému obvykle vyžaduje strukturovaný přístup k jeho řešení. I když má systém na nejvyšší úrovni abstrakce architekturu lineární, pak obvykle na nižších úrovních má funkce/moduly uspořádány podle některé z následujících architektur (to platí i o uvedeném příkladu textového systému).
  • V hierarchické architektuře jsou jednotlivé funkce/moduly systému uspořádány tak, že jejich vazby jsou reprezentovány stromovým grafem. Znamená to, že každá elementární funkce je využita vždy právě v jedné funkci vyšší úrovně .
  • Hierarchická architektura se dá s úspěchem použít pouze tehdy , jsou-li na systém kladeny takové požadavky, které lze splnit množinou vzájemně disjunktních funkcí .
  • Tyto funkce musí být na nižší úrovni abstrakce opět dělitelné na vzájemně disjunkcí množiny elementárních funkcí. Tento předpoklad bývá v praxi málokdy splněn, takže striktní dodržení hierarchické architektury obvykle vede k duplicitním pracím, a tím k nárůstu nákladů tvorby a údržby . Velkým problémem je též dodávání nových funkcí , kterým nevyhovuje stávající struktura systému. Na druhé straně výhodou hierarchické architektury je přehledná struktura systému , která vede k poměrně snadnému testování a snadné údržbě systému.
  • Hlavní nevýhodu hierarchické architektury překonává vrstvená architektura . Její grafickou reprezentací je acyklický graf .
  • Funkce softwarového systému jsou uspořádány do několika vrstev s tím, že funkce vyšší vrstvy mohou využívat jen funkce vrstev podřízených.
  • Posledním typem architektury používané v praxi je síťová architektura, která je reprezentovaná obecným orientovaným grafem , to znamená, že zde neplatí závazná pravidla podřízenosti a nadřízenosti jednotlivých modulů.
  • Síťová architektura je typická pro řadu současných rozsáhlých softwarových systémů . Je to de facto jediná použitelná architektura pro systémy budované „za pochodu“, protože její hlavní předností je otevřenost pro přidávání nových funkcí .
  • Předcházející tři architektury tak pružné nejsou, protože neočekávaný požadavek na přidání určité funkce může být v rozporu s dosavadní strukturou funkcí. Další výhodou síťové architektury je, že v porovnání s hierarchickou a vrstvenou architekturou má obvykle nižší náklady provozu . Na druhé straně má z uvedených architektur obvykle nejvyšší náklady užití , protože její zvládnutí uživatelem je nejnáročnější.
  • Náklady tvorby a údržby mohou být nízké , ale jenom za předpokladu vysoké zkušenosti tvůrců a jejích dokonalé organizace, protože síťová architektura vede k vysoké vzájemné závislosti jednotlivých funkcí (změna jedné funkce může vynutit úpravy velkého počtu jiných funkcí).
  • V okamžiku, kdy se tyto závislosti vymknou přísné kontrole, má to za důsledek velmi těžko zjistitelné šíření chyb po celém systému a rapidní narůstání nákladů údržby. Pravděpodobnost vzniku takové situace je u rozsáhlých systémů značně vysoká. Zkušenosti se síťovou strukturou ukazují, že opravení jedné chyby často vede ke vzniku předem těžko odhadnutelného počtu chyb jiných.
  • Z přehledu architektur softwarových systémů je zřejmé, že pro tvorbu rozsáhlého softwarového systému připadají v úvahu v podstatě dvě ze čtyř výše popsaných architektur – vrstvená a síťová. Vzhledem k uvedeným faktům je použití síťové architektury ospravedlnitelné pouze tehdy, musíme-li preferovat nízké náklady provozu, před nízkými náklady tvorby a údržby a před nízkými náklady užití (např. systémy pro řízení technologických procesů s dobou odezvy hluboko pod hranicí 1 sekundy, jádro operačního systému). Ve všech ostatních případech je pak vhodnější vrstvená architektura.