Softwarová architektura - Software architecture

Vývoj softwaru
Hlavní činnosti
softwarového inženýrství
Paradigmata a modely
Metodiky a rámce
Podpůrné disciplíny
Cvičení
Nástroje
Standardy a orgány znalostí
Glosáře
Obrysy

Softwarová architektura se týká základních struktur softwarového systému a disciplíny vytváření takových struktur a systémů. Každá struktura obsahuje softwarové prvky, vztahy mezi nimi a vlastnosti obou prvků a vztahů. Architektura softwarového systému je metafora, analogická s architekturou budovy. Funguje jako plán systému a vyvíjejícího se projektu a stanoví úkoly nezbytné k provedení konstrukčními týmy.

Softwarová architektura je o zásadních strukturálních volbách, jejichž změna po implementaci je nákladná. Možnosti softwarové architektury zahrnují konkrétní strukturální možnosti z možností při návrhu softwaru . Například systémy, které ovládaly nosnou raketu raketoplánu, měly požadavek být velmi rychlé a velmi spolehlivé. Proto je třeba zvolit vhodný výpočetní jazyk v reálném čase . Navíc, aby byla uspokojena potřeba spolehlivosti, bylo možné zvolit vícečetné nadbytečné a nezávisle vyrobené kopie programu a spouštět tyto kopie na nezávislém hardwaru při křížové kontrole výsledků.

Architektura dokumentačního softwaru usnadňuje komunikaci mezi zúčastněnými stranami , zachycuje včasná rozhodnutí o návrhu na vysoké úrovni a umožňuje opětovné použití součástí návrhu mezi projekty.

Software_Architecture_Activities

Rozsah

Názory na rozsah softwarových architektur se různí:

  • Struktura makroskopického systému : toto odkazuje na architekturu jako abstrakci vyšší úrovně softwarového systému, který se skládá ze sbírky výpočetních komponent spolu s konektory, které popisují interakci mezi těmito komponentami.
  • Důležité věci - ať už to je cokoli : toto odkazuje na skutečnost, že softwaroví architekti by se měli zabývat těmi rozhodnutími, která mají velký dopad na systém a jeho zúčastněné strany.
  • To je zásadní pro pochopení systému v jeho prostředí
  • Věci, které lidé vnímají jako těžko měnitelné : vzhledem k tomu, že navrhování architektury probíhá na začátku životního cyklu softwarového systému, měl by se architekt zaměřit na rozhodnutí, která „musí“ být poprvé správná. V návaznosti na tuto myšlenkovou linii se problémy architektonického designu mohou stát nearchitektonními, jakmile lze překonat jejich nevratnost.
  • Soubor rozhodnutí o architektonickém návrhu : softwarová architektura by neměla být považována pouze za soubor modelů nebo struktur, ale měla by zahrnovat rozhodnutí, která vedou k těmto konkrétním strukturám, a zdůvodnění za nimi. Tento pohled vedl k rozsáhlému výzkumu správy znalostí softwarové architektury .

Neexistuje žádný ostrý rozdíl mezi architekturou softwaru a návrhem a inženýrstvím požadavků (viz Související pole níže). Všechny jsou součástí „řetězce záměrnosti“ od záměrů na vysoké úrovni po detaily na nízké úrovni.

Charakteristika

Softwarová architektura vykazuje následující:

Mnoho zúčastněných stran: softwarové systémy se musí starat o různé zúčastněné strany, jako jsou obchodní manažeři, majitelé, uživatelé a operátoři. Všechny tyto zúčastněné strany mají své vlastní obavy ohledně systému. Součástí návrhu systému je vyvážení těchto starostí a demonstrace, že jsou řešeny. To znamená, že architektura zahrnuje řešení široké škály problémů a zúčastněných stran a má multidisciplinární povahu.

Oddělení obav : zavedený způsob, jak architekti omezit složitost, je oddělit starosti, které jsou hybnou silou návrhu. Dokumentace architektury ukazuje, že všechny obavy zúčastněných stran jsou řešeny modelováním a popisem architektury ze samostatných hledisek spojených s různými obavami zainteresovaných stran. Tyto samostatné popisy se nazývají architektonické pohledy (viz například model architektonického zobrazení 4+1 ).

Řízení podle kvality: Klasické přístupy k navrhování softwaru (např. Jackson Structured Programming ) byly řízeny požadovanou funkčností a tokem dat systémem, ale současný pohled je, že architektura softwarového systému je v těsnějším vztahu k jeho kvalitativním atributům , jako je odolnost proti chybám , zpětná kompatibilita , rozšiřitelnost , spolehlivost , udržovatelnost , dostupnost , bezpečnost, použitelnost a další podobné - ilities . Obavy zúčastněných stran se často promítají do požadavků na tyto atributy kvality, kterým se různě říká nefunkční požadavky , nefunkční požadavky, požadavky na chování nebo požadavky na atributy kvality.

Opakující se styly: jako architektura budov, disciplína softwarové architektury vyvinula standardní způsoby řešení opakujících se problémů. Tyto „standardní způsoby“ se nazývají různými názvy na různých úrovních abstrakce. Běžnými termíny pro opakující se řešení jsou architektonický styl, taktika, referenční architektura a architektonický vzor .

Konceptuální integrita: termín zavedený Fredem Brooksem v The Mythical Man-Month k označení myšlenky, že architektura softwarového systému představuje celkovou vizi toho, co by měl dělat a jak by to měl dělat. Tuto vizi je třeba oddělit od její implementace. Architekt přebírá roli „strážce vize“, přičemž dbá na to, aby dodatky do systému byly v souladu s architekturou, a proto byla zachována koncepční integrita .

Kognitivní omezení: pozorování poprvé provedené v článku z roku 1967 počítačovým programátorem Melvinem Conwayem, že organizace, které navrhují systémy, jsou nuceny vytvářet návrhy, které jsou kopiemi komunikačních struktur těchto organizací. Stejně jako u konceptuální integrity to byl Fred Brooks, kdo to představil širšímu publiku, když citoval papír a myšlenku ve své elegantní klasice The Mythical Man-Month , nazývané „Conwayův zákon“.

Motivace

Softwarová architektura je „intelektuálně uchopitelnou“ abstrakcí komplexního systému. Tato abstrakce poskytuje řadu výhod:

  • Poskytuje základ pro analýzu chování softwarových systémů před vytvořením systému. Schopnost ověřit, že budoucí softwarový systém splňuje potřeby jeho zúčastněných stran, aniž by jej musel ve skutečnosti stavět, představuje značnou úsporu nákladů a snižování rizik. K provádění takových analýz byla vyvinuta řada technik, například ATAM nebo vytvořením vizuální reprezentace softwarového systému.
  • Poskytuje základ pro opětovné použití prvků a rozhodnutí. Kompletní softwarovou architekturu nebo její části, jako jsou individuální architektonické strategie a rozhodnutí, lze znovu použít ve více systémech, jejichž zúčastněné strany vyžadují podobné atributy kvality nebo funkce, což šetří náklady na návrh a snižuje riziko chyb v návrhu.
  • Podporuje počáteční návrhová rozhodnutí, která ovlivňují vývoj, nasazení a životnost systému. Správná včasná rozhodnutí s velkým dopadem jsou důležitá, aby se předešlo překročení plánu a rozpočtu .
  • Usnadňuje komunikaci se zúčastněnými stranami a přispívá k systému, který lépe naplňuje jejich potřeby. Komunikace o komplexních systémech z pohledu zainteresovaných stran jim pomáhá porozumět důsledkům jejich uvedených požadavků a návrhových rozhodnutí na jejich základě. Architektura dává možnost komunikovat o návrzích návrhu ještě před implementací systému, kdy je lze ještě relativně snadno přizpůsobit.
  • Pomáhá při řízení rizik. Softwarová architektura pomáhá snižovat rizika a pravděpodobnost selhání.
  • Umožňuje snížení nákladů . Softwarová architektura je prostředkem k řízení rizik a nákladů v komplexních IT projektech.

Dějiny

Srovnání mezi softwarovým designem a (civilní) architekturou bylo poprvé vypracováno na konci šedesátých let, ale termín „softwarová architektura“ se rozšířeného používání dočkal až v 90. letech minulého století. Oblast informatiky se od svého vzniku setkala s problémy spojenými se složitostí. Dřívější problémy složitosti řešili vývojáři výběrem správných datových struktur , vývojem algoritmů a aplikací konceptu oddělení obav . Přestože je termín „softwarová architektura“ v oboru relativně nový, průkopníci softwarového inženýrství od poloviny 80. let 20. století sporadicky uplatňovali základní principy oboru . Počáteční pokusy zachytit a vysvětlit softwarovou architekturu systému byly nepřesné a neorganizované, často charakterizované sadou diagramů typu box-and-line .

Softwarová architektura jako koncept má svůj původ ve výzkumu Edsgera Dijkstra v roce 1968 a Davida Parnase na začátku 70. let. Tito vědci zdůraznili, že na struktuře softwarového systému záleží a správná struktura je zásadní. V průběhu roku 1990 došlo ke společné úsilí definovat a kodifikovat základní aspekty disciplíny, se výzkumná činnost soustředí na architektonických stylů ( vzory ), popis architektury jazyků , architektury dokumentace a formální metody .

Výzkumné instituce hrály významnou roli při podpoře softwarové architektury jako disciplíny. Mary Shaw a David Garlan z Carnegie Mellon napsali v roce 1996 knihu s názvem Software Architecture: Perspectives on an Emerging Discipline , která propagovala koncepty softwarové architektury, jako jsou komponenty , konektory a styly. University of California, Irvine ústavu je pro výzkum softwaru snahy v softwarové architektury výzkum je zaměřen především v architektonických stylů, popis architektury jazycích a dynamických architekturách.

IEEE 1471 -2000, „Doporučená praxe pro popis architektury systémů náročných na software“, byl prvním formálním standardem v oblasti softwarové architektury. Byla přijata v roce 2007 ISO jako ISO/IEC 42010: 2007 . V listopadu 2011 byl IEEE 1471–2000 nahrazen normou ISO/IEC/IEEE 42010: 2011 „Systémové a softwarové inženýrství - popis architektury“ (společně vydané IEEE a ISO).

Zatímco v IEEE 1471 byla softwarová architektura o architektuře „softwarově náročných systémů“, definovaných jako „jakýkoli systém, kde software přispívá zásadními vlivy na návrh, konstrukci, nasazení a vývoj systému jako celku“, vydání 2011 jde ještě o krok dále zahrnutím definic systému podle ISO/IEC 15288 a ISO/IEC 12207 , které zahrnují nejen hardware a software, ale také „lidi, procesy, postupy, zařízení, materiály a přirozeně se vyskytující entity“. To odráží vztah mezi softwarovou architekturou, podnikovou architekturou a architekturou řešení .

Architektonické činnosti

Softwarový architekt provádí mnoho činností. Softwarový architekt obvykle pracuje s projektovými manažery, diskutuje se zúčastněnými stranami o architektonicky významných požadavcích , navrhuje softwarovou architekturu, hodnotí návrh, komunikuje s designéry a zúčastněnými stranami, dokumentuje architektonický návrh a další. Při navrhování softwarové architektury existují čtyři hlavní činnosti. Tyto základní činnosti architektury se provádějí iterativně a v různých fázích počátečního životního cyklu vývoje softwaru a také během vývoje systému.

Architektonická analýza je proces porozumění prostředí, ve kterém bude navrhovaný systém fungovat, a stanovení požadavků na systém. Vstup nebo požadavky na analytickou činnost mohou pocházet od libovolného počtu zúčastněných stran a mohou zahrnovat položky jako:

  • co bude systém dělat za provozu (funkční požadavky)
  • jak dobře bude systém plnit za běhu nefunkční požadavky jako spolehlivost, provozuschopnost, výkonnost, bezpečnost, kompatibilita definovaná v normě ISO/IEC 25010 : 2011
  • doba vývoje nefunkčních požadavků, jako je udržovatelnost a přenositelnost, definovaných v normě ISO 25010: 2011
  • obchodní požadavky a environmentální souvislosti systému, které se mohou v průběhu času měnit, například právní, sociální, finanční, konkurenční a technologické problémy

Výstupy analytické činnosti jsou požadavky, které mají měřitelný dopad na architekturu softwarového systému, nazývané architektonicky významné požadavky.

Architektonická syntéza nebo design je proces vytváření architektury. Vzhledem k architektonicky významným požadavkům stanoveným analýzou, současnému stavu návrhu a výsledkům všech hodnotících činností je návrh vytvořen a vylepšen.

Hodnocení architektury je proces určování, jak dobře současný design nebo jeho část splňuje požadavky odvozené během analýzy. Hodnocení může nastat kdykoli, když architekt zvažuje rozhodnutí o návrhu, může k němu dojít po dokončení určité části návrhu, může k němu dojít po dokončení konečného návrhu nebo k němu může dojít po konstrukci systému. Mezi některé z dostupných technik hodnocení architektury softwaru patří Architecture Tradeoff Analysis Method (ATAM) a TARA. Rámce pro porovnávání technik jsou diskutovány v rámcích, jako jsou SARA Report a Architecture Reviews: Practice and Experience .

Evoluce architektury je proces udržování a přizpůsobování stávající softwarové architektury tak, aby vyhovoval změnám požadavků a prostředí. Jelikož softwarová architektura poskytuje základní strukturu softwarového systému, její vývoj a údržba by nutně ovlivnily její základní strukturu. Evoluce architektury se jako taková zabývá přidáváním nových funkcí a udržováním stávajících funkcí a chování systému.

Architektura vyžaduje kritické podpůrné činnosti. Tyto podpůrné činnosti probíhají v celém procesu základní architektury softwaru. Zahrnují správu znalostí a komunikaci, návrhové úvahy a rozhodování a dokumentaci.

Činnosti podporující architekturu

Činnosti podporující architekturu softwaru se provádějí během hlavních činností softwarové architektury. Tyto podpůrné činnosti pomáhají softwarovému architektovi provádět analýzu, syntézu, hodnocení a evoluci. Například architekt musí během fáze analýzy sbírat znalosti, rozhodovat se a dokumentovat.

  • Správa znalostí a komunikace je akt zkoumání a správy znalostí, které jsou zásadní pro návrh softwarové architektury. Softwarový architekt nepracuje izolovaně. Získávají vstupy, funkční i nefunkční požadavky a kontext návrhu od různých zúčastněných stran; a poskytuje výstupy zúčastněným stranám. Znalost softwarové architektury je často tichá a uchovává se v hlavách zúčastněných stran. Činnost správy znalostí softwarové architektury je o hledání, komunikaci a udržování znalostí. Protože problémy s návrhem softwarové architektury jsou složité a vzájemně závislé, může mezera ve znalostech v úvahách o návrhu vést k nesprávnému návrhu softwarové architektury. Mezi příklady aktivit správy znalostí a komunikace patří hledání návrhových vzorů, prototypování, dotazování zkušených vývojářů a architektů, hodnocení návrhů podobných systémů, sdílení znalostí s dalšími designéry a zúčastněnými stranami a dokumentování zkušeností na wiki stránce.
  • Úvaha a rozhodování o návrhu je činnost hodnocení návrhových rozhodnutí. Tato aktivita je zásadní pro všechny tři základní činnosti architektury softwaru. To zahrnuje shromažďování a sdružování rozhodovacích kontextů, formulování problémů při rozhodování o návrhu, hledání možností řešení a vyhodnocování kompromisů před rozhodnutím. Tento proces probíhá na různých úrovních granularity rozhodování při vyhodnocování významných architektonických požadavků a rozhodnutí o softwarové architektuře a analýze, syntéze a hodnocení softwarové architektury. Mezi příklady činností spojených s uvažováním patří porozumění dopadům požadavku nebo návrhu na atributy kvality, zpochybňování problémů, které by návrh mohl způsobit, posouzení možných možností řešení a vyhodnocení kompromisů mezi řešeními.
  • Dokumentace je akt zaznamenávání návrhu generovaného během procesu softwarové architektury. Návrh systému je popsán pomocí několika pohledů, které často zahrnují statický pohled ukazující strukturu kódu systému, dynamický pohled zobrazující akce systému během provádění a zobrazení nasazení ukazující, jak je systém umístěn na hardware pro provádění. Pohled Kruchten 4+1 navrhuje popis běžně používaných pohledů pro dokumentaci softwarové architektury; Documenting Software Architectures: Views and Beyond má popisy druhů notací, které by mohly být použity v popisu pohledu. Příklady aktivit v oblasti dokumentace jsou psaní specifikace, zaznamenávání modelu návrhu systému, dokumentace odůvodnění návrhu, vývoj pohledu, dokumentace pohledů.

Témata softwarové architektury

Popis softwarové architektury

Hlavní článek: Popis architektury softwaru

Popis softwarové architektury zahrnuje principy a postupy modelování a reprezentace architektur pomocí mechanismů, jako jsou jazyky popisu architektury, hlediska architektury a rámce architektury.

Jazyky popisu architektury

Hlavní článek: Jazyk popisu architektury

Jazyk popisu architektury (ADL) je jakýkoli výrazový prostředek používaný k popisu softwarové architektury ( ISO/IEC/IEEE 42010 ). Od 90. let bylo vyvinuto mnoho ADL pro zvláštní účely, včetně AADL (standard SAE), Wright (vyvinutý Carnegie Mellon), Acme (vyvinutý Carnegie Mellon), xADL (vyvinutý UCI), Darwin (vyvinutý Imperial College London ) , DAOP-ADL (vyvinutý University of Málaga), SBC-ADL (vyvinutý National Sun Yat-Sen University ) a ByADL (University of L'Aquila, Itálie).

Pohledy na architekturu

Hlavní článek: Zobrazit model
4+1 model architektonického pohledu .

Popisy softwarové architektury jsou běžně organizovány do pohledů , které jsou analogické různým typům plánů vytvořených v architektuře budov . Každý pohled řeší soubor obav systému v souladu s konvencemi jeho hlediska , kde hledisko je specifikací, která popisuje notace, modelování a analytické techniky, které se mají použít v pohledu, který vyjadřuje danou architekturu z pohledu dané sady zúčastněných stran a jejich obav ( ISO/IEC/IEEE 42010 ). Hledisko specifikuje nejen rámcované obavy (tj. Které je třeba řešit), ale také prezentaci, použité typy modelů, použité konvence a jakákoli pravidla konzistence (korespondence), aby byl pohled konzistentní s jinými pohledy.

Architektonické rámce

Hlavní článek: Framework architektury

Rámec architektury zachycuje „konvence, zásady a postupy pro popis architektur zavedených v konkrétní oblasti aplikace a/nebo komunity zúčastněných stran“ ( ISO/IEC/IEEE 42010 ). Rámec je obvykle implementován z hlediska jednoho nebo více hledisek nebo ADL.

Architektonické styly a vzory

Hlavní článek: Architektonický vzor

Architektonický model je obecný, opakovaně použitelné řešení pro běžně se vyskytující problém v architektuře softwaru v daném kontextu. Architektonické vzory jsou často dokumentovány jako vzory pro návrh softwaru .

V návaznosti na tradiční stavební architekturu je „softwarový architektonický styl“ specifickou metodou stavby, která se vyznačuje vlastnostmi, které jej činí pozoruhodným “( architektonický styl ).

Architektonický styl definuje: rodinu systémů z hlediska struktury strukturální organizace; slovník komponent a konektorů s omezeními, jak je lze kombinovat.

Architektonické styly jsou opakovaně použitelnými „balíčky“ návrhových rozhodnutí a omezení, která jsou v architektuře aplikována k vyvolání zvolených požadovaných vlastností.

Existuje mnoho uznávaných architektonických vzorů a stylů, mezi nimi:

Někteří považují architektonické vzory a architektonické styly za stejné, někteří považují styly za specializace vzorů. Společné je to, že vzory a styly jsou idiomy, které architekti používají, „poskytují společný jazyk“ nebo „slovník“, pomocí něhož lze popisovat třídy systémů.

Softwarová architektura a agilní vývoj

Hlavní článek: Agilní vývoj

Existují také obavy, že softwarová architektura vede k příliš velkému návrhu vepředu , zejména mezi zastánci agilního vývoje softwaru . Byla vyvinuta řada metod k vyvážení kompromisů up-front designu a agility, včetně agilní metody DSDM, která nařizuje fázi „Foundations“, během níž je položeno „jen tolik“ architektonických základů. Software IEEE věnoval zvláštní problém interakci mezi agilitou a architekturou.

Eroze softwarové architektury

Softwarová eroze architektury (neboli „rozpad“) označuje mezeru pozorovanou mezi plánovanou a skutečnou architekturou softwarového systému, jak byla realizována při jeho implementaci. K erozi softwarové architektury dochází, když implementační rozhodnutí buď plně nedosáhnou architektury podle plánu, nebo jinak porušují omezení nebo zásady této architektury.

Jako příklad zvažte přísně vrstvený systém, kde každá vrstva může používat pouze služby poskytované vrstvou bezprostředně pod ní. Jakákoli součást zdrojového kódu, která toto omezení nedodržuje, představuje porušení architektury. Pokud nebudou napravena, mohou taková porušení transformovat architekturu na monolitický blok s nepříznivými dopady na srozumitelnost, udržovatelnost a vyvíjitelnost.

Byly navrženy různé přístupy k řešení eroze. "Tyto přístupy, které zahrnují nástroje, techniky a procesy, jsou primárně rozděleny do tří obecných kategorií, které se pokoušejí minimalizovat, předcházet a napravovat erozi architektury. V těchto širokých kategoriích je každý přístup dále rozčleněn tak, aby odrážel strategie na vysoké úrovni přijaté k řešit erozi. Jedná se o procesně orientovanou shodu architektury, řízení evoluce architektury, vynucování návrhu architektury, propojení architektury s implementací, vlastní adaptace a techniky obnovy architektury sestávající z obnovy, objevování a usmíření. “

Existují dvě hlavní techniky detekce porušení architektury: reflexní modely a jazyky specifické pro doménu. Techniky modelu reflexe (RM) porovnávají model na vysoké úrovni poskytovaný architekty systému s implementací zdrojového kódu. Existují také jazyky specifické pro doménu se zaměřením na zadávání a kontrolu architektonických omezení.

Obnova softwarové architektury

Hlavní článek: Obnova architektury softwaru

Obnova architektury softwaru (nebo rekonstrukce nebo reverzní inženýrství ) zahrnuje metody, techniky a procesy k odhalení architektury softwarového systému z dostupných informací, včetně jeho implementace a dokumentace. Obnova architektury je často nutná k informovanému rozhodování tváří v tvář zastaralé nebo zastaralé dokumentaci a erozi architektury : rozhodnutí o implementaci a údržbě se liší od předpokládané architektury. Existují postupy pro obnovu architektury softwaru jako statické analýzy programu . Toto je část předmětů, na které se vztahuje praxe softwarové inteligence .

Související pole

Design

Hlavní článek: Softwarový design

Architektura je design, ale ne celý design je architektonický. V praxi je architekt tím, kdo určuje hranici mezi softwarovou architekturou (architektonický návrh) a podrobným návrhem (nearchitektonický návrh). Neexistují žádná pravidla ani pokyny, které by vyhovovaly všem případům, i když se vyskytly pokusy formalizovat rozdíl. Podle hypotézy Intension/Locality je rozdíl mezi architektonickým a detailním designem definován kritériem Locality Criterion , podle kterého prohlášení o softwarovém designu není lokální (architektonické) právě tehdy, když lze program, který jej splňuje, rozšířit do program, který nemá. Například styl klient-server je architektonický (strategický), protože program, který je postaven na tomto principu, lze rozšířit do programu, který není klient-server-například přidáním uzlů peer-to-peer .

Požadavky inženýrství

Hlavní článek: Požadavky inženýrství

Inženýrství požadavků a architekturu softwaru lze považovat za komplementární přístupy: zatímco architektura softwaru se zaměřuje na „ prostor řešení “ nebo „jak“, inženýrství požadavků řeší „ problémový prostor “ nebo „co“. Požadavky inženýrství má za následek elicitace , vyjednávání , specifikace , ověřování , dokumentaci a správu všech požadavků . Technická i softwarová architektura požadavků se točí kolem zájmů, potřeb a přání zúčastněných stran .

Existuje značné překrývání mezi inženýrstvím požadavků a architekturou softwaru, což dokazuje například studie pěti metod architektury průmyslového softwaru, která dospěla k závěru, že „vstupy (cíle, omezení atd.) Jsou obvykle špatně definovány a jsou objeveny nebo lépe chápán tak, že se začíná objevovat architektura “ a že „ zatímco většina architektonických starostí je vyjádřena jako požadavky na systém, mohou zahrnovat i nařízená rozhodnutí o návrhu “ . Stručně řečeno, požadované chování ovlivňuje architekturu řešení, což zase může zavádět nové požadavky. Přístupy, jako je model Twin Peaks, mají za cíl využít synergický vztah mezi požadavky a architekturou.

Jiné typy „architektury“

Hlavní články: Počítačová architektura , Systémová architektura a Podniková architektura
Počítačová architektura
Počítačová architektura se zaměřuje na vnitřní strukturu počítačového systému, pokud jde o spolupracující hardwarové komponenty, jako je CPU - nebo procesor - sběrnice a paměť .
Architektura systémů
Pojem systémová architektura byl původně aplikován na architekturu systémů, která se skládá jak z hardwaru, tak ze softwaru . Hlavní starostí řešenou architekturou systémů je pak integrace softwaru a hardwaru do kompletního, správně fungujícího zařízení. V dalším běžném - mnohem širším - smyslu se tento termín vztahuje na architekturu jakéhokoli komplexního systému, který může mít technickou, sociotechnickou nebo sociální povahu.
Podniková architektura
Cílem podnikové architektury je „převést obchodní vizi a strategii na efektivní podnikání“. Rámce podnikové architektury , jako jsou TOGAF a Zachman Framework , obvykle rozlišují různé vrstvy podnikové architektury. Přestože se terminologie liší rámec od rámce, mnoho z nich obsahuje alespoň rozlišení mezi obchodní vrstvou , aplikační (nebo informační ) vrstvou a technologickou vrstvou . Podniková architektura mimo jiné řeší zarovnání mezi těmito vrstvami, obvykle přístupem shora dolů.

Viz také

Reference

Další čtení

externí odkazy