Architektura softwarových systémů

Podobné dokumenty
Analýza a Návrh. Analýza

TÉMATICKÝ OKRUH Softwarové inženýrství

Design systému. Komponentová versus procesní architektura

Smysl metodiky IS/IT. Koncentrovaná zkušenost Checklist na nic nezapomeneme

7 Jazyk UML (Unified Modeling Language)

7 Jazyk UML (Unified Modeling Language)

Návrh softwarových systémů - architektura softwarových systémů

CASE. Jaroslav Žáček

CASE nástroje. Jaroslav Žáček

Návrh softwarových systémů - architektura softwarových systémů

Usage of modular scissors in the implementation of FEM

Programování II. Modularita 2017/18

MVC (Model-View-Controller)

3 Inženýrství systémů založených na počítačích (Computer-based System Engineering)

3 Inženýrství systémů založených na počítačích (Computer-based System Engineering)

TREND POPIS ODPOVĚDNOSTI PRACOVNÍKA MANAŽER VÝVOJE

TÉMATICKÝ OKRUH Softwarové inženýrství

Budování architektury pomocí IAA

8 Přehled OO metodik (metod, metodologií)

Vývoj informačních systémů. Přehled témat a úkolů

Vývoj informačních systémů. Přehled témat a úkolů

EXTRAKT z mezinárodní normy

Novinky v UML 2.5 a agilní modelování

Vývoj řízený testy Test Driven Development

X36SIN: Softwarové inženýrství. Životní cyklus a plánování

Servisně orientovaná architektura a její aplikace v systémech sledování a řízení výroby

Zkušenosti se zaváděním a řízením EA ve veřejné správě Slovenska. září 2015

Metodické postupy tvorby architektury

Uvažujete o změně automatizovaného knihovního systému?

Návod k požadavkům ISO 9001:2015 na dokumentované informace

Principy UML. Clear View Training 2005 v2.2 1

Doc. Ing. Daniel Kaminský, CSc. ELCOM, a.s.

8 Přehled OO metodik (metod, metodologií)

SPECIFICKÁ PRAVIDLA PRO ŽADATELE A PŘÍJEMCE

6 Objektově-orientovaný vývoj programového vybavení

Paralelní programování

ÚVOD DO SOFTWAROVÉHO INŽENÝRSTVÍ

Unifikovaný modelovací jazyk UML

Systémy pro podporu rozhodování. Hlubší pohled 2

Common Object Request Broker Architecture

A7B36SI2 Tematický okruh SI08 Revidoval: Martin Kvetko

Příloha č. 1. Náležitosti nabídky a návrh funkčnosti Interaktivního manažerského modulu (IMM)

Modelování procesů s využitím MS Visio.

SOFTWAROVÉ INŽENÝRSTVÍ 1

Návrh softwarových systémů - úvod, motivace

Obsah. Zpracoval:

12 Zajištění kvality programového vybavení

2. Automatická tvorba seminářů v prostředí Unifor/Asja

12 Zajištění kvality programového vybavení

Architektury Informačních systémů. Jaroslav Žáček

Metodika analýzy. Příloha č. 1

Úvod do softwarového inženýrství a týmového vývoje

Vývoj informačních systémů. Architektura, návrh Vzory: Doménová logika

Archivace Elektronických Dokumentů

Softwarové komponenty a Internet

Zakázka Vnitřní integrace úřadu v rámci PROJEKTU Rozvoj služeb egovernmentu ve správním obvodu ORP Rosice

Vývoj informačních systémů. Obecně o IS

Vývoj informačních systémů. Architektura, návrh Vzory: Doménová logika

Globální strategie, IT strategie, podnikové procesy. Jaroslav Žáček

Obsah. Základní pojmy, zkratky Předpisy a literatura přehled Přístup k validacím počítačových systémů URS Validace Předpisy a literatura

Evropský sociální fond Praha & EU: Investujeme do vaší budoucnosti

IS pro podporu BOZP na FIT ČVUT

Srovnání implementace a využití systému Microsoft Project v rozdílném produkčním prostředí případová studie

Personální audit. Audit informačního systému. Audit SW a HW

Český egovernment 2015+

ADMINISTRACE POČÍTAČOVÝCH SÍTÍ. OPC Server

Informační systémy. Jaroslav Žáček

Katalog služeb a podmínky poskytování provozu

POČÍTAČE A PROGRAMOVÁNÍ

Návrh softwarových systém. Návrh softwarových systémů

Java/QE Akademie - Osnova

10 Balíčky, grafické znázornění tříd, základy zapozdření

1. VYMEZENÍ ODBORNÉ STÁŽE

Reportingová platforma v České spořitelně

Kvalita SW produktů. Jiří Sochor, Jaroslav Ráček 1

Unifikovaný proces vývoje

Úvod do validace počítačových systémů Ing. Miroslav Mík. Obsah

Analytický programový modul pro hodnocení odolnosti v reálném čase z hlediska konvergované bezpečnosti

EXTRAKT z mezinárodní normy

Specializace Návrhář software na základě analýzy vytváří návrh softwarových aplikací ve formě schémat a diagramů.

1. Integrační koncept

Jan Hřídel Regional Sales Manager - Public Administration

Příspěvek k tématu připravenosti. Jan Fibír

Okruhy z odborných předmětů

Modelování informačních systémů s využitím jazyka UML. Jaroslav Šmarda

Objektově orientované technologie Diagram komponent Implementační náhled (Diagram rozmístění) Pavel Děrgel, Daniela Szturcová

Přednáška Principy kvantifikace integrity bezpečnosti železničních zabezpečovacích systémů Autor: Ing. Petr Hloušek, Ph.D

Architektury Informačních systémů. Jaroslav Žáček

2. Systémová analýza SA návrhová část projektu = příručka projektu - systémový přístup k analýze problémů, nejdůležitější etapa projektu - podrobné st

Přístupy k řešení a zavádění spisové služby

Objekty, třídy, vazby 2006 UOMO 30

SRSW4IT Inventarizační SW. Prezentace aplikace. Vedoucí DP: ing. Lukáš Macura Autor: Bc. Petr Mrůzek

1. Webové služby. K čemu slouží? 2. RPC Web Service. 3. SOA Web Service. 4. RESTful Web services

Občani a občanky miniblok ministerstva vnitra o egovernmentu

Úvod. Programovací paradigmata

Simulace a návrh vyvíjejících Nadpis se 1. Nadpis 3. Božetěchova 2, Brno

Obsah přednášky 9. Skrývání informací. Skrývání informací. Zapouzdření. Skrývání informací. Základy programování (IZAPR, IZKPR) Přednáška 9

METODICKÝ RÁMEC IS/ICT

Standardizace kartových systémů ve veřejné dopravě, legislativní podpora

Alternativy k SAP HANA appliance? Představení možnosti TDI a cloudové infrastruktury

Transkript:

Architektura softwarových systémů Definice, Strukturní a Procesní doporučení Ing. Tomáš Černý, MSCS

Pojem softwarové architektury (SA) Obvyklé způsoby vysvětlování pojmu SA komponenty a vazby celková struktura systému diagram struktury systému

Co dělá dobrou architekturu.. Doporučení procesní strukturní

Procesní doporučení Architektura je produktem jednoho architekta malé skupiny architektů s definovaným vedoucím Architekt k dispozici technické požadavky na systém sepsaný prioritní list kvalitativních vlastností Architektura by měla být dobře dokumentovaná používat domluvenou notaci (porozumění)

Procesní doporučení Architektura by se měla opírat o lidské účastníky, ti se aktivně podílí na revizi Architektura by měla být analyzována pro kvantitativní měření (propustnost) formálně revidována pro kvalitativní vlastnosti (modifikovatelnost) Architektura by měla vézt k implementaci přes vytvoření kostry systému naplňuje jen minimum požadavků. kostra je inkrementálně rozšiřována usnadňujíce integraci a testování

Procesní doporučení Architektura by měla vyústit ve specifickou množinu možných částí řešení jsou pak dobře specifikována, cirkulována a udržována Př. Network utilization area Architekt produkuje doporučení pro každý team, tak aby se dosáhlo minimální zahlcení sítě network traffic Př. Výkonnostní zájem Architekt vyprodukuje časové úvahy pro hlavní vlákna

Strukturní doporučení Architekt by měl navrhnout funkční moduly: využívající zapouzdření informaci (information hiding) oddělení zájmů (separation of concerns) každý modul by měl: mít rozhraní vynášející jen důležité metody schovávat měnitelné aspekty (implementační strategie) od ostatního SW využívajícího služeb daného modulu. Př. GRASP Př. Abstrakce a implementace Př. Dependency Injection (DI)

Strukturní doporučení Moduly by měly reflektovat oddělení zájmů (separation of concerns) tak že je umožněno jejich rozdělení do týmů týmy pak pracují nezávisle na dalších Moduly schovávající informace by měly zahrnovat ty co zapouzdřují výpočetní infrastrukturu tedy izolují podstatnou část SW od změn, které vyplynou ze změn platformy.

Strukturní doporučení Architektura by neměla záviset na konkrétní verzi komerčního produktu či nástroje. Hibernate 2.6 a search pro many to many fungoval ale nebyl popsán v dokumentaci Hibernate 3.0 již neimplementoval tuto funkčnost Př. SW postaven na 2.6 využívající search Změna kódu pro tuto funkčnost = implementace nového systému Pokud arch. závisí na komerčním produktu, pak by měl být systém strukturován tak, že změna na jiný produkt je snadná a nenákladná.. (diskuze???) Bridge GOF pattern

Strukturní doporučení Moduly produkující data by měly být odděleny od modulů konzumujících data. toto má za následek snadnou modifikovatelnost změny jsou často buď pro produkci dat nebo pro konzumaci dat pokud jsou přidána nová data, potom bude změna na obou stranách Separace umožní inkrementální upgrade Export XLS vs. Import XLS

Strukturní doporučení Pro paralelní systémy architektura rozvrhne procesy a úkoly, tak že nemusí nutně odrážet strukturu modulů. proces se může rozprostírat přes více modulů. modul může poskytovat služby více procesům. Úkol by měl být napsán tak, že přiřazení specifickému procesoru může být snadno změněno. Možná i v run-time.

Strukturní doporučení Architektura by měla používat malé množství vzorů interakce design patterns Systém by měl dělat stejné věci stejným způsobem. (Jak navenek tak v implementaci). Lepší srozumitelnost Nižší vývojový čas Lepší čitelnost Lepší modifikovatelnost Také umožní konceptuální integritu v architektuře tj. Snadnější vývoj Zamezení duplikace kódu!!!!

Definice softwarové architektury Architektura softwarového systému představuje definici struktury systému. Tuto strukturu tvoří softwarové komponenty, ze kterých se systém skládá, z vnějšku viditelné vlastnosti těchto komponent a vztahy mezi nimi. Bass, Clements, Kazman. Software Architecture in Practice, Addison-Wesley 1997

Definice softwarové architektury Architektura je organizační struktura systému. Architektura může být rekurzivní dekomponována na části, které komunikují prostřednictvím rozhraní, na vztahy propojující jednotlivé části a omezení, která na jsou na jednotlivé části kladena. Komunikující složky zahrnují třídy, komponenty a subsystémy. UML 1.3

Co plyne z definice Mít architekturu se liší od Mít známou architekturu architektura vs. specifikace architektury