TIS_I_skripta

, kapacita
výroby, vývoj nových výrobků nebo marketing.
Určení úzkého místa je obvykle problém rozhodování s neúplnou informací, je
to tedy úloha vyžadující zkušenost a intuici.
Úzké místo může být jiné pro různé pro různé doby výhledu
V české ekonomice jsou kandidáti na úzké místo pro výhled roků sociální systém, právní systém a
daně, ve výhledu desetiletí demografie, především porodnost a kvalita vzdělávání
IS by měl usnadňovat hledání úzkých míst a pomáhat je řešit
Budeme se málo zabývat
vývojem hromadně
používaných systémů, jako
jsou operační systémy,
editory atd.

Málokdy se k jejich vývoji
dostaneme
6.1.2008 55
Vývoj od začátku versus nákup
(customizace)
•

Vývoj od začátku „na míru“
–

Převažují nově vyvinuté moduly
–

Požadavky nemusí být omezovány tím, jaký SW
máme k dispozici
•

Customizace

-

Nákup softwaru a jeho
přizpůsobení konkrétním podmínkám
(přesnost dat, formáty, účetní schéma) -

U
velkých firem dnes customizace

převažuje,
trend se ale možná obrací
•

SOA může kombinovat obojí
6.1.2008 56
Životní cyklus softwaru, vývoj od
začátku pro monolity
1. Marketing a specifikace cílů (formulace problému), hledání odpovědí na
otázky proč a rámcově co. Výstupem je

vize či specifikace cílů
2. Specifikace požadavků, formulace přesné odpovědi na otázku co, zčásti na
otázku jak. Výstupy
–

Model systému, diagramy a (formalizované) požadavky,
•

závisí na architektuře SW modelovacích prostředcích a použitém paradigmatu (např
objektovém), musí být srozumitelné oběma stranám
–

Termíny řešení, náklady, zdroje
Oponentura: feasibility

study

(studium uskutečnitelnosti)
3. Návrh systému. Řešení technických otázek dekompozice, návrhy rozhraní,
struktury dat a algoritmů a volba softwarových vývojových prostředků a
systémového softwaru. Dostatečně podrobná dokumentace (u agilního
vývoje nemusí být rozsáhlá a obvykle to platí i pro SOA). Návrh celku může
dělat specialista
Oponentura návrhu
6.1.2008 57
4. Kódování (programování) částí.
Čtení kódu
5. Testování: částí –

unit tests

(testy částí, to dělají kódéři),
integrační, funkcí, systému a předávací.
6. Oživení a předání: instalace hardwaru a základního softwaru,
instalace systému, předávací testy, zkušební provoz. Někdy
zkušební provoz.
7. Provoz a údržba.
–

odstraňování chyb zjištěných za provozu,
–

přizpůsobování novému hardwaru (HW) a přizpůsobování změnám v
použitém základním (systémovém) softwaru (ZSW), jako jsou databázové
a operační systémy, a konečně
–

vylepšování funkcí.
8. Stažení z provozu.
6.1.2008 58
Customizace
•

Generace systému z polotovarů
zadáváním parametrů a jiných informací
pro generaci.
•

Předobraz: generace operačních
systémů mainframů
•

Customizace

vyžaduje vysokou
kvalifikaci těch, co ji provádějí
6.1.2008 59
Životní cyklus softwaru,
customizace
1. Marketing a specifikace cílů (formulace problému), hledání
odpovědí na otázky proč a rámcově co. Výběr dodavatele.
2. Specifikace požadavků, formulace přesné odpovědi na otázku co,
zčásti na otázku jak od daného dodavatele.
–

Model systému, diagramy, závisí pravidlech dodavatele modelovacích
prostředcích a použitém softwaru,
–

Výběr modulů a funkcí
–

Termíny řešení, náklady, zdroje
Oponentura feasibility

study
3. Customizace

systému (generace systému). Zadávání funkcí,
jejich vazeb a parametrů (např. přesnost, formáty dat). Tato etapa
je poměrně pracná a náročná na práci expertů
6.1.2008 60
4. Kódování (programování) nezbytných doplňků. Obvykle provádí
dodavatel, kódování není mnohdy nutné
5. Testování: testy systému a předávací.
6. Oživení a předání: instalace hardwaru a základního softwaru,
instalace systému, předávací testy, zkušební provoz.
7. Provoz a údržba. odstraňování chyb zjištěných za provozu,
přizpůsobování novému hardwaru (HW) a změnám v použitém
základním (systémovém) softwaru (ZSW), jako jsou databázové a
operační systémy, a konečně úpravy systému. Většinu provádí
dodavatel. Často spojeno

i se zajišťováním provozu
8. Stažení z provozu.
6.1.2008 61
Výhody customizace
•

Ověřený dodavatel, zná obor, ověřené techniky specifikací a
oživování, know-how

z mnoha instalací
•

Dobré reference,
•

Alibi pro management (jinde to přece fungovalo)
•

Menší nebezpečí selhání projektu a toho, že dodavatel
opustí trh
•

Úspory-cena (má to ale háček, viz níže), hlavní úspora je u
údržby
•

Velká nabídka funkcí (ale nebezpečí, že se koupí i
zbytečnosti a že cena proto bude zbytečně vysoká)
•

Rychlejší realizace (ne závratně)
Osvědčuje díky malé pravděpodobnosti totálního selhání
projektu,, plný úspěch také nebývá častý
6.1.2008 62
Nevýhody customizace
•

Kupuje se vlastně něco jako konfekce
–

Může znamenat zbytečné organizační změny a tím značné zvýšení
nákladů,
–

Může blokovat žádoucí organizační změny
–

Nemusí vyhovovat daným podmínkám, což může vyvolat další
ztráty
–

Často se používají zastaralá řešení s dopady na funkce
–

Často se nakupují zbytečnosti –

větší náklady při nákupu a při
provozu, zbytečnosti mohou při provozu i překážet
–

Nedostatečná lokalizace (dnes spíše jiné než jazykové problémy,
např. nedostatečná implementace legislativy a nedostatečné
zohlednění místní kultury)
6.1.2008 63
Nevýhody customizace
•

Ztráta vlastních znalostí a kvalifikace a nezdravá
závislost

na dodavateli, často nemožnost
používat i svoje řešení a řešení třetích stran
(řešení –

servisní orientace)
•

Odstraňuje spíše konkurenční nevýhodu než
přináší výhodu. Vhodné spíše pro operativu.
6.1.2008 64
Pracnost Doba Pracnost Doba
Vize 5 8-10 5 8-10
Specifikace 15-25 25-40 10-15 20
Návrh/generace 15-20 Cca 20 15-20 10-15
Kódování 15-20 10 Cca 5
nutnost

hlubší spolupráce většiny vývojářů s
uživateli z různých stupňů organizační hierarchie,
uplatňování principů agilního vývoje, viz níže
65
Hlavní překážka prosazení
nového
•

Domněnka, že se o nic nového nejedná,
že jde je o převlečené nové věci
•

Lenost se učit
66
Klíčová role architektury

Architektura
systému
Management
IT
Politika výrobců
SW a
systémových
integrátorů
Vývoj
Uskutečnitelné
požadavky
Agilní byznys procesy
67
Architektura aliance a konfederace
A –

aplikační služba, B –

její rozhraní (primární brána)
UR je uživatelské rozhraní, např. portál
Staré aplikační rozhraní je u komplexnějších služeb
nutností (viz IS úřadů), usnadňuje podstatně vývoj.
68
Struktura brány
fronta
Vnitřní
transformace
A

p

l

i

k

a

c

e
Výstupní
transformace
Brána má interní skrytou datovou strukturu, u ESB je
skryta, IBM to nabízí explicitně jako MQ –

Message

queue
M

i

d

d

l

e

w

a

r

e
69
Struktura brány
fronta
Vnitřní
transformace
A

p

l

i

k

a

c

e
Výstupní
transformace
Pokud middleware

nabízí jen point-to-point, MQ to nezmění.
Řešení je možné přes specializované služby typu data store
M

i

d

d

l

e

w

a

r

e
70
Struktura brány
Při implementaci lze použít dotNet,ASP,
primitiva UNIXu, MQ firmy IBM ….
71
Důsledky p2p architektury
•

Stabilita systému zásadním způsobem závisí
na stabilitě (neměnnosti) rozhraní
•

Rozhraní se bude málo měnit, pokud nebude
záviset na implementačních detailech a
změnách úrovně technologie a bude ověřena
používáním (je-li např. deklarativní a
uživatelsky orientované, uživatelé v operativě

používají léty ověřené postupy, viz účetnictví)
72
Důsledky p2p architektury
•

P2p systémy se málo kamarádí s
centralizovanými službami, i jen funkčně
centralizovanými.
–

Takové služby lze sice někdy používat, lze však
očekávat problémy
•

Přidání/ubrání služeb je relativně snadné,
pokud mají vhodné rozhraní
•

XML a www výhodou, ne však podmínkou
73
Obvyklá architektura aliance,
e-komerce
A B
A B
A B
A B
Middleware
Staré rozhraní
pro A
log




74
Podmínky spolupráce v alianci
Partner se musí nejdříve vyhledat
•

Partneři dostupní přes veřejný celosvětový middleware
•

Rozhraní služeb na obecných standardech
–

Jazyk zpráv standardizován, v jistém smyslu univerzální
–

Přístup přes standardní nástroje (prohlížeče)
–

Poskytované služby popsány standardním způsobem,
popis dostupný i pro programy (WSDL)
–

Výhodný je telefonní seznam (UDDI), ale to je centrální
služba a mohou s tím být potíže v p2p prostředí, to se již
potvrzuje (údržba seznamu)
Komunikace formou zpráv
–

žádná data v middlewaru, na internetu se datové úložiště
obtížně implementuje
75
Podmínky spolupráce v alianci
WSDL, SOAP a UDDI mají tendenci být
založeny na nízkoúrovňovém

konceptu
volání metod, čili procedurálním
rozhraní
To ale znamená, že je obtížné
dosáhnout uživatelské orientace
rozhraní
To je podstatné omezení, již se projevuje
jako závažný problém
V poslední době se přechází na SOAP –

message

literal

nebo message

encoded
76
Deklarativnost kontra procedurálnost
Rozsah použitelnosti
Efektivnost
použití
Jazyk nízké
úrovně
Jazyk
deklarativní
77
Podmínka deklarativního rozhraní
•

Je nutné mít dobře vymezené komponenty
–

Mají totiž mít možnost mít uživatelsky
orientované rozhraní pro nějaký ne zcela malý
uživatelský obor
•

Musí být zčásti součástíspecifikací

(pro
integraci legacy

nutností)
78
Formáty zpráv v alianci
•

Univerzální řešení: univerzalita ⇒ nízká

úroveň

⇒ procedurálnost

⇒ SOAP, ve starší

versi (SOAP –

RPS, nebo SOAP RPC literal)
–

Programátorsky orientováno ⇒ omezení

role
uživatelů

při definování

a řízení

business procesů

a
zásazích do jejich chodu, není

výhodné

pro
uživatelsky orientovaná

rozhraní
–

Implikuje tvar specifikace služeb (WSDL) a
telefonního seznamu (UDDI)
–

Vhodnější

pro operativu

a pro rozhraní

bez vlastní

inteligence
79
Nevýhody aliancí
•

Služby nemají uživatelsky orientované rozhraní –

obtíže při použití (např. u podnikových procesů) i při
vývoji (specifikace společně s uživateli)
•

Potíže při řešení sporů, odpovědností a ad hoc

zásazích
do procesů (nečekané události, nové informace), zprávám
koncoví uživatelé a experti nerozumí
•

Změny obchodních procesů je nutné řešit uvnitř služeb
–

Neflexibilní, u služeb s vlastnostmi černých skříněk
(produkty třetích stran) téměř nereálné
80
Nevýhody aliancí
•

Existence centrálních služeb je proti duchu p2p
•

Rozhraní je pracné, není uživatelsky orientované a
má tendenci zviditelňovat implementační detaily
•

Potřebné normy se rychle mění a rychle rostou =>
nestabilita

rozhraní a nadměrný vliv velkých hráčů
81
Výhody aliancí
•

V e-komerci v podstatě jinak nelze
•

Služby lze programovat autonomně, podobně jako kdysi
programy používající hloupé terminály
•

Využívají se webovské

služby a výsledky výzkumu
sémantického webu
•

V lidské společnosti fungují služby podobně, lze použít
analogické postupy
•

Úloha pro další výzkum
82
Proč konfederace (opakování)
•

Chceme-li použít uživatelsky orientované nebo
existující rozhraní a middleware

jiný než
webovský
•

Propojování systémů různých zdrojů
–

Existující aplikace, vývoj, třetí strany
•

a různých vlastníků,
–

Organizační subsystémy decentralizace
–

Spolupráce samostatných podniků
•

a různých technologií a úkolů
•

Příliš velký systém na monolit
•

Chceme inteligentní rozhraní, a někdy i dávkové
techniky
83
Technické důvody pro SOA
•

SW inženýrské přednosti
–

inkrementálnost, stabilita, láce, …
•

Lze se vyhnout tzv. reorg. Cycle

(než
systém stihnu přeprogramovat, je nová
verze již zastaralá)
84
Souhrn hlavních rysů SOA
•

Síť autonomních komponent, které mají rysy nebo
přímo jsou aplikacemi
•

Při navazování komunikace se partner nemusí
zpravidla vyhledávat (je znám předem)
•

Komponenty jsou používány jako černé skříňky
–

Komplexní funkcionalita, komplexní rozhraní deklarativního
typu
–

Různé technologie, různí výrobci
–

Na různých místech
–

Peer

to peer
•

Výkonný middleware

s podporou flexibilního
uživatelského rozhraní a s dalšími funkcemi o které
se může dělit s komponentami (kryptografie,
směrování, optimalizace polohy komponent,…)
85
Vlastnosti konfederací
+ Lze dohodnout pravidla šitá na míru
ƒ formát zpráv může být deklarativní,
uživatelsky orientovaný – klíčová přednost,
snazší specifikace a snazší integrace
uživatelů do procesů
ƒ lze použít i jiný než webovský middleware,
lze kombinovat různé technologie
middlewaru i komunikace
ƒ služby mohou zahrnovat i služby reálného
světa (řízení procesů, uživatele), ?doba
odezvy?, na webu složitější
86
Vlastnosti konfederací
+ Lze dohodnout pravidla šitá na míru,
uživatelsky orientovaná
ƒ lze snadno kombinovat dávkové a interaktivní
zpracování
ƒ lze kombinovat funkcionální a objektové techniky
ƒ snadná integrace produktů třetích stran a
existujících aplikací
ƒ snadné modifikace a výhodné SW inženýrské
vlastnosti
ƒ k dokumentaci často stačí popis rozhraní služeb
•

výhodné pro agilní formy vývoje
87
Vlastnosti konfederací II
++ Služby mohou být i informační systémy
jednotlivých organizací a organizačních
jednotek nebo nakupované/vyvíjené aplikace a
dokonce přímo technologie či jednotliví
pracovníci (za vhodným rozhraním), výhody
+ snazší decentralizace, prodej/akvizice částí podniku
+ nástroje kontroly spolupráce částí
+ snazší spolupráce s obchodními partnery (CRM,
SCM, nákupní koalice..) a se státní správou
+ podpora strategických záměrů managementu
Implementace podnikových systémů ve formě
aliance je riskantní, neefektivní a pracná (proto
raději např. enterprise

service

bus)
88
Vlastnosti SOA III
-

Neví se, je-li vůbec možná model driven
architecture, chybějí příklady řešení a CASE
nástroje pro SOA
-

Problémy s proprietálními

řešeními takže
nelze vždy použít standardy
–

lze zmírnit správnou strategií (volba dialektu XML)
–

může urychlit vznik uživatelských XML jazyků a tím
nevýhodu změnit na výhodu
+-

Nutná úzká spolupráce mezi skoro všemi
vývojáři a mnoha uživateli i z nejvyšších postů
(CEO se musí účastnit specifikací)
++ Velmi dobré zkušenosti s provozem (dvacet
let bez údržby, viz též zkušenosti s Y2K)
89
Neinteraktivní komunikace
Spolupráce plánovacích algoritmů s provozem
vyžaduje inteligenci při přenosu požadavků
Podnik
Plánovač
Rozvrh
Technologický
subsystém
Technologický
subsystém
Technologický
subsystém
Dávková
Interaktivní
komunikace
výměna dat
Dispečer
Plánování v noci,
neboť běží dlouho
90
Důvody
•

Data jsou nevčasná, neboť plán algoritmy jsou
pomalé, změny musí proto udělat rychle člověk
aby výroba nestála když se objeví nečekaná
překážka
•

Data jsou nepřesná ⇒plán je nedokonalý
91
Řízení na buffery
•

Před každým pracovištěm front
Mistr sleduje bufery

a hledá pro práci, když
se bufer

nepříjemně zkracuje (řízení na
průšvih)
Nutné pro výroby s krátkými seriemy

a velkou
variabilitou
92

Prac
1
Prac
P1.z-1 s1
F.j
P1.z+1
s3
P2.y-1 s4
E.k
P1.z+1
s5
P2.y s
D.i
P3.x-1
s6
P3.x+1
s8
P3.x s7
D.i+1
P1.z s2
D.i-1
Prac
Segment
výr. postupu
Segment fronty
prací na Prac1
Segment fronty
prací na Prac2
Segment fronty
prací na Prac3
Data aktuální výrobní operace D.i
93
Pozorování
•

Některé akce musí být dávkové (trvají příliš
dlouho), to platí pro některé algoritmy, pro lidi a
pro procesy reálného světa
•

Jsou třeba zásahy dispečera
–

Nečekané/vzácné události -

nevyplatí se je zahrnovat
do rozvrhování (Vonásek

je lempl, Pepa se včera
ztřískal)
–

Kvalita dat
•

Nedostupnost, neznámá, nepřesná (mají velký rozptyl)
•

Zřídka potřebná (nevyplatí se sbírat)
–

Potřeba využít inteligenci lidí jako součásti procesů
94
Pozorování
•

Neběží jen o poskytování informací, předávají se i
příkazy, služby mohou být služby reálného světa
(raketové základny)
•

Datové rozhraní je typické pro manažerskou úroveň
řízení, ta se stává hlavním tématem současnosti
•

Snadné kombinování ručních a automatizovaných
postupů
•

Vysoká autonomie služeb
•

Částečný návrat DFD a datových úložišť (používání
dříve zavrhované funkční dekompozice)
•

Podle současných znalostí je implementace datového
rozhraní v aliancích obtížná, i když možná
95
Pozorování
•

Datové úložiště může být virtuální (bez replikace
dat), data poskytovaná službami mohou být
čtena z jejich databáze, vypočítávána, měřena,
zadávána uživateli –

klasická DB nemusí být
adekvátní koncepcí (problém indexace), viz
semantic

web
•

Důležité je deklarativní uživatelsky orientované
rozhraní
•

Úložiště může být plněno z více zdrojů současně
(lze použít předřazené brány diskutované níže)
•

Výhodné dávkové plnění dat
–

ušetří to mnoho práce, stabilita řešení
96
Další výhodySOA
•

Typické pro služby v lidské společnosti
srozumitelné uživatelům
•

Jiné paradigma než objektová orientace nebo
vzdálené volání procedur (kombinace s těmito
paradigmaty je možná, pokud se koncepce používají
jako ortogonální nástroje)
•

Lze poměrně snadno vylaďovat spolehlivost
(doručitelnost zpráv), zabezpečení, kontrolu průběhu,
efektivnost, rozhraní a umožnit ruční zásahy do
průběhu procesů
•

Poměrně snadné je využívání aplikací, které se
nakupují, existují nebo jsou téměř nezávisle vyvíjeny
97
Doporučení, uplatnit, pokud lze
•

Použít SOA a XML, možná SOAP
•

Raději komunikace přes datové úložiště
a to raději neinteraktivní (bez trigerů)
není-li na závadu (často nebývá)
•

Používat i dávkové zpracování, šetří to
náklady, vyšší stabilita
–

Jde použít častěji, než se má za to
98
Doporučení, uplatnit, pokud lze
•

Uživatelsky orientované rozhraní, hranice služeb
obdobná hranicím služeb v reálném světě
•

Uživatelé by měli být schopni snadno měnit obchodní
procesy během provádění
•

Umožnit simulaci služeb uživateli
•

Uživatelé by měli být schopni analyzovat žurnál
komunikace pro kontrolu a pro případné soudní řízení
•

Maximálně využívat znalosti obsluhy
OLAP a snad i datové sklady používat jako služby
99
Klíčová role rozhraní
•

Stabilita konfederace závisí především na stabilitě
(neměnnosti) rozhraní
•

Jazyk rozhraní by měl být vysoké úrovně
(deklarativní)
•

Rozhraní by se mělo chovat podobně jako rozhraní
služeb v reálu (být uživatelsky orientované)
–

Být srozumitelné uživatelům, mělo by být podobné tomu, nač
jsou zvyklí; je to nutné pro návrh a kontrolu průběhu
business procesů
–

Takové má šanci nebýt měněno, je vlastně ověřeno
dlouhodobým používáním
100
Potřeba metadefinic
Konfederovaný systém může obsahovat velmi
mnoho komponent komplikované funkcionality.
Komponenty je výhodné propojovat deklarativně
(co je třeba udělat, nikoliv jak to udělat).
Pro růz