Výpočetní modely - /zdroj Peterka/ Infromatika I Výpočetní modely - /zdroj Peterka/ Vývoj IS a jejich architektury dříve centralizovaný výpočetní model centrální počítač = monolitický IS na něm uložena data (soubory, později databáze) Výpočetní model lze definovat jako ucelenou představu o postavení uživatele, dat a aplikací v rámci IS Řeší se následující problémy: kde jsou umístěny aplikace a kde skutečně běží jsou-li aplikace děleny, jak části spolupracují kde se uchovávají a zpracovávají data kde se nachází uživatel, kdy a jak komunikuje s aplikacemi hesova@pefczu.cz Ing. Ivana Hesova, KIT ČZU

Výpočetní modely - /zdroj Peterka/ Historie a vývoj výpočetních modelů 1. dávkové zpracování (batch processing) vstupní dávka dat výstupní sestava časově oddělené není interaktivní , uživatel nemůže reagovat na průběh výpočtu hesova@pefczu.cz

Výpočetní modely - /zdroj Peterka/ 2. model host - terminál host = počítač, který je „hostitelem“ systémových zdrojů /procesoru, paměti, I/O zařízení, programů, dat/ zpracování probíhá na host. počítači vznikla terminálová pracoviště později terminálové sítě /není to skutečná síť, pouze terminálový rozvod/ obslouží více uživatelů současně terminály jsou místní nebo vzdálené hesova@pefczu.cz

Výpočetní modely - /zdroj Peterka/ host - terminál - pokrač. mezi host. poč. a terminálem se přenáší pouze výstupy na obrazovku počítače vstupy z uživatelovy klávesnice velké objemy dat se nepřenášejí uživatel má iluzi, že má host. poč. pro sebe znakový režim nízký uživ. komfort hesova@pefczu.cz

Výpočetní modely - /zdroj Peterka/ 3. izolované osobní počítače (PC) přístupnější a lacinější výp. technika host/terminál (přísná centralizace) a izolované PC = 2 extrémy PC - nezávislost na ostatních ale: problémy se řeší ne 1x, ale n-krát na n místech jak řešit práci se sdílenými daty? každý nemůže ještě vlastnit drahé periferie smysl má kompromis , něco sdílet, něco vlastnit hesova@pefczu.cz

Výpočetní modely - /zdroj Peterka/ co sdílet? drahé periferie, společná data (firemní databáze, sdílené dokumenty), aplikace (vyžadují správné nakonfigurování a údržbu) vznik prvních LAN řeší potřebu sdílení zpočátku si uživatel sdílení neuvědomuje také aplikace nejsou zpočátku uzpůsobeny síťovému prostředí hesova@pefczu.cz

Výpočetní modely 4. model file server / pracovní stanice data jsou zpracovávána jinde než jsou umístěna musí být přenášena nevýhody: zbytečné přenosy, zahlcování sítě 5. model client / server další vývojový stupeň idea: data se budou zpracovávat tam, kde se nacházejí výstupy pro uživ. se budou generovat u něj hesova@pefczu.cz

Výpočetní modely 6. Další vývoj výp. modelu komponentní model distribuovaný model hesova@pefczu.cz

Nové architektury Vstup db technologií + rozvoj sítí = požadavek na nové modely dat a nové architektury systémů a) architektura klient-server (C/S)- 2 a více stupňová znamená dělení aplikací (tj. programů) na části, které spolu komunikují s tím souvisí: b) komponentní model , komponentová metodologie programování metodologie založená na softwarové komponentové infrastruktuře v síťovém prostředí hesova@pefczu.cz

Nové architektury c) OO model komponenty aplikace jsou též objekty distribuované objekty = systémově nezávislé sw entity, z nichž lze sestavit aplikaci jsou kdekoliv na síti, mají rozhraní (=tabulka metod, operací a jejich parametrů) klienti volají metody z jejich rozhraní, tj. zadávají požadavek na provedení metody vlastní aplikační logika (postup) je předem definována a skryta hesova@pefczu.cz

Distribuované objekty Aby komponenty různých výrobců mohly spolupracovat, musí dodržovat standardy 2 konkurenční standardy = obecná architektura pro vytváření aplikací pomocí komponent CORBA (Common Object Request Broker Architecture), specifikace Object Management Group COM (Component Object Model) a DCOM (Distributed …….) od Microsoftu hesova@pefczu.cz

Distribuované objekty Distribuované objekty pokrač. Přenos zpráv mezi objekty (=požadavek) zprávy zakódovány pro přenos, součástí jsou data podpůrný modul na obou stranách zajišťuje navázání spojení s partnerským procesem, odeslání, příjem, kódování a dekód., předání zpráv objektům o to se programátor aplikace nestará Distribuovaný program = kombinace aplikačního pgmu a možných vzdálených komponent, které používá mohou běžet na jednom nebo více počítačích hesova@pefczu.cz

Architektura klient-server C/S - pokrač. - vývoj 2 stupňová arch. - servery postupně v různých rolích (souborový, tiskový, databázový, aplikační, komunikační), omezený výkon zpočátku nebyly nástroje pro správu takového IS 3 stupňová architektura (poprvé u SAP/R3) databázový server aplikační (i více aplikačních s.) server velký počet klientů (PC) s GUI + komunikační kanály hesova@pefczu.cz

Architektura klient-server C/S - pokrač. = „virtuální superpočítač“ kooperace Vícestupňová architektura C/S - 4 vrstvy klientská vrstva dále rozdělená na 2 části, jedna je provozována na klientovi v roli webového serveru ten druhou část distribuuje na klient. počítače prostřednictvím Internetu či intranetu C/S ze strany hw = spolupráce klientů a serv. C/S znamená z pohledu sw dělení aplikací hesova@pefczu.cz

Architektura klient-server C/S - pokrač. aplikace - má 3 části (komponenty) mohou být různě umístěné ( na serveru, na klientovi), spolupracují části aplikace: prezentační logika (tzv. uživatelské rozhraní) aplikační logika (též business logika, obchodní služby) logika přístupu k datům (též datové služby, správa dat) dělení se vede buď na hranici mezi nimi nebo uvnitř jedné ze 3 částí =5 způsobů dělení aplikace) hesova@pefczu.cz

Architektura klient-server C/S - pokrač. - obr. viz soubor clientserv.doc Způsoby dělení, jak je označujeme: distribuovaná prezentace (většina zpracování probíhá na straně serveru, přenos výsledku ke klientovi) vzdálená prezentace ( “ ) distribuované funkce (vzniknou 2 aplikační programy) vzdálená správa dat (aplikace celá na klientovi, správa dat na serveru, použití SQL) distribuovaná správa dat ( “ ) hesova@pefczu.cz