Informačné systémy
-
softwérové
inžinierstvo
-
tvorba
veľkých programových systémov so všetkým, čo s tým súvisí ( IS
je len najčastejší príklad veľkého systému na Slovensku )
-
problémy softwéru:
o
komplexnosť:
software je komplexnejší, než čokoľvek iného, čo je konštruované
ľuďmi ( vrátane hardwéru ). Navyše, časti produktu zvyčajne
so sebou interagujú
o
prispôsobenie:
software zvyčajne nie je osamotený, býva časťou iných systémov,
s ktorými musí komunikovať a poskytovať im rozhranie.
Keďže software nie je fyzická časť nasadených produktov, je
naňho vyvíjaný najväčší tlak na prípadné prispôsobenie
o
premenlivosť:
pri zmene podmienok reálneho sveta, ktorý systém modeluje, software sa musí
zmeniť
-
štatistická
ukážka problémov softwéru (GAO štúdia):
o
doručený,
ale nikdy nepoužitý 47
%
o
zaplatený,
ale nedoručený 29
%
o
použitý
po rozsiahlych zmenách, prípadne zanechaný 19
%
o
použitý
po zmenách 3
%
o
použitý
v stave, v akom bol doručený 2
%
-
PC
Week 95, softwéroví profesionáli považovali svoje projekty:
o
16
% úspešné
o
53
% fungujúce ( avšak nepovažované za úspešné )
o
31
% zrušených počas vývoja alebo po vývoji
-
ďalšie
štúdie:
o
každých
1000 riadkov kódu obsahuje 50 až 60 chýb
o
väčšina
chýb v programe je zapríčinená chybným pochopením riešeného problému
o
počas
vývoja priemerných projektov sa dosahuje efektívnosť 10 riadkov na
človekodeň
-
softwérová
kríza:
o
software
doručený po plánovanom termíne
o
odhady
na náklady na software prekročené
o
nespoľahlivý
software
o
software
sa zložito udržiava
o
trojuholník
: rýchlo, lacno, dobre ( vyber ktorékoľvek dva, nie tri )
UML – vytvorenie modelu systému ( nielen informačného )
čitateľného pre analytikov, dizajnérov a programátorov
-
určený
primárne na objektovo orientované systémy, avšak dá sa použiť aj pre
ostatné
-
model
: abstrakcia problému, ktorý sa rieši ( abstrahuje sa od nepodstatných vecí,
zameriava sa na to, čo je možné podporovať počítačom)
-
doména
: svet, v ktorom riešime náš problém ( každá doména má špecifický pojmový
aparát, svoje typické riešenia )
-
G.
Booch, J. Rumbaugh, I. Jacobson – autori
-
OMG –
prevzalo podporu nad jazykom ( www.omg.org )
-
aktuálna
verzia 1.3 (1.4), pripravovaná verzia 2.0 s veľkými zmenami
Diagramy tried
-
vlastnosti
OOP:
o
zapuzdrenie
( encapsulation ): zahrnutie atribútov a metód do jedného celku,
pričom sa skrývajú interné vlastnosti a definuje rozhranie, pomocou
ktorého objekt komunikuje s okolím, synergia atribútov a metód
o
dedičnosť
( inheritance ): triedy možno organizovať do zväzov, pričom
všeobecnejšie triedy budú nadradené špecifickejším ( tie budú dediť
atribúty a metódy od rodičov, môžu pridať svoje vlastné )
o
mnohotvárnosť
( polymorfizmus ): rôzne objekty môžu reagovať na rovnakú správu rôzne (
otvoriť okno, dvere, noviny, darček, účet ) , obvykle sa využíva
pri objektoch v hierarchii dedičnosti
Trieda
-
obsahuje
atribúty a ich typy a metódy ( s parametrami ), viditeľnosť
- vypočítaný
atribút s lomkou ( napr. vek z dátumu narodenia ), chránená metóda
Objekt
- konkrétna inštancia
triedy
Asociácia a linka
-
definovanie
vzťahov medzi triedami a medzi objektami
-
asociácia
medzi triedami
-
asociácia
medzi objektami ( keďže sú tam objekty, je to inštančný diagram )
-
ternárna
asociácia: projekt, osoba, jazyk
-
príklad:
osoba môže na dvoch projektoch používať rôzne jazyky ( a tie nemusia byť
jediné používané na daných projektoch )
-
násobnosť
( kardinalita )
-
reflexívna
asociácia, roly
-
kvalifikátor
( znižuje násobnosť 1: n na 1:1 )
-
nazovSuboru
by mal byť v rámčeku
-
asociačná
trieda, asociácia ako trieda
-
využíva
sa vtedy, ak má asociácia vlastné atribúty, alebo ak chceme nížiť
násobnosť m : n, * : *
-
iné
riešenie:
-
usporiadanie
( obmedzenie )
-
agregácia
( špeciálny druh asociácie – znamená „skladá sa“ )
-
kompozícia
(zloženina), je silnejšia než agregácia, časti nemôžu existovaťsamostatne
-
generalizácia,
potomci dedia všetky atribúty a metódy ( tie môžu prepísať vlastnou
implementáciou )
-
rekurzívna
agregácia s generalizáciou
-
abstraktná
trieda Pracovnik, nemôže mať inštancie ( konkrétna trieda môže ),
inštancie sú závislé od tried ( jeden typ závislosti )
-
viacnásobná
dedičnosť ( Obojzivelne vozidlo má dediť aj po Pozemnom )
-
viacnásobná
dedičnosť definovaná v Jave, interface ( zvykne sa
označovať aj ako gulička )
-
interface
( rozhranie ) je ( najčastejšia definícia ) množina operácií, ktoré trieda
( alebo nejaký subsystém ) ponúka navonok, a môžu ich používať
ostatné triedy. V Jave je to niečo podobné triede, avšak môže
mať iba finálne konštanty a abstraktné metódy a slúži pre
umožnenie viacnásobnej dedičnosti.
-
potomok
realizuje ( implementuje ) rozhranie Runable
-
potomok
realizuje ( implementuje ) rozhranie Runable
Identifikovanie
tried, atribútov a asociácií
-
hľadáme
konceptuálne triedy ( reálne existujúce myšlienky alebo veci ) v doméne
-
identifikovanie
konceptuálnych tried
o
použitie
zoznamu kategórií
§
fyzické
objekty ( lietadlo )
§
špecifikácie,
návrhy alebo popisy vecí ( popis letu )
§
miesta
( letisko )
§
transakcie
( predaj, rezervácia )
§
položky
transakcií ( položka predaja )
§
roly
ľudí ( pilot, pokladník )
§
kontainery
obsahujúce iné veci ( lietadlo )
§
veci
v kontaineri ( položka, pasažier )
§
iné
externé systémy
§
organizácie
( letecká spoločnosť )
§
udalosti
( Let, Platba, Pristávanie )
§
procesy
( predávanie produktu, zaknihovanie sedadla )
§
pravidlá
a smernice ( pravidlá o náhrade peňazí )
§
zoznamy
( zoznam produktov )
§
záznamy
o práci, dohode, peniazoch ( účtenka, zmluva )
o
pomocou
podstatných mien ( samozrejme opatrne )
o
použitie
analytických vzorov ( pre známe domény )
-
pri
identifikácii samozrejme treba správne rozoznať, čo je trieda
a čo je atribút triedy
-
špecifikácia,
popis, typovanie konceptuálnych tried ( Objednávka – Položka objednávky - Tovar
) :
o
ak
je potreba mať popis položky alebo služby nezávisle od existencie týchto
položiek
o
ak
zmazanie týchto tried ( napr. Položka ) spôsobí stratu informácie, ktorú je
treba udržať
o
rieši
problém s redundanciou dát
-
pridávanie
asociácií
o
vzťahy
medzi triedami, možno použiť všeobecný zoznam asociácií:
§
A je
fyzickou ( logickou ) časťou B ( krídlo – lietadlo, predaj-položka)
§
A je
popis B ( Položka - tovar )
§
A je
položka transakcie B ( položka – predaj
)
§
A je
známe/ zachytené/ zaznamenané v B ( pokladničná kniha -predaj)
§
A je
člen B ( Pilot – letecká spoločnosť )
§
A je
organizačná podjednotka B ( Obchod - sklad )
§
A používa
alebo menežuje B ( Pilot - lietadlo )
§
A komunikuje
s B ( zákazník - pokladník )
§
A sa
vzťahuje ku B ( zákazník - platba )
§
A je
transakcia týkajúca sa inej transakcie ( rezervácia - zrušenie )
§
A je
ďalšia po B ( položka - položka )
§
A je
vlastnená B ( lietadlo - spoločnosť )
§
A je
udalosť týkajúca sa B ( prílet - let )
o
treba
len nutné asociácie, nie odvodené
o
smer
asociácie vyjadruje len smer čítania, nič iného
o
dôležitejšie
je odhaliť konceptuálne triedy než asociácie
o
názov
asociácie, rola, násobnosť
o
viacnásobné
asociácie ( let od a do letiska )
-
pridávanie
atribútov
o
je
to logická dátová hodnota v objekte
o
nepoužívať
atribúty ako cudzie kľúče ( na vyjadrenie vzťahu slúži asociácia
)
Balíček
-
triedy
možno podľa logického rozdelenia organizovať do balíčkov (
package ). Ak ich je príliš veľa na jednom diagrame, vedie to k neprehľadnosti
Stereotyp
-
konštrukcia
na bližšie popísanie nejakého elementu jazyka UML, značí sa
« nazovStereotypu »
Poznámka
-
bližší
popis elementu jazyka UML, ktorý je zobrazený priamo na diagrame
Use case diagramy
-
requirements
engineering ( odbor zaoberajúci sa zisťovaním požiadaviek )
-
požiadavka:
stanovenie určitej služby systému alebo obmedzení, podmienka alebo
schopnosť, ktorú vyžaduje užívateľ a rieši jeho problém alebo
dosiahne jeho cieľ
-
príklady:
o
systém
by mal udržovať záznamy o všetkých materiáloch v knižnici (
knihy, pásky, CD ... ) – v hrubých rysoch popísané, čo má systém
robiť
o
systém
by mal umožniť užívateľovi vyhľadať položku podľa
ISBN, autora, názvu – definovaná funkčnosť systému
o
užívateľské
rozhranie by malo byť definované cez www prehliadač – určenie,
ako musí byť systém implementovaný – podmienka architektúry
o
systém
by mal umožniť aspoň 20 transakcií za sekundu – výkonové kritérium
o
spôsob
obsluhy pre verejných používateľov by mal byť vysvetliteľný za
menej než 10 minút – požiadavka týkajúca sa používania
-
klasicky
by mali požiadavky definovať ČO a nie AKO ( what vs. how )
o
to
sa možno vždy nedá ( ako popísať, čo robí auto, alebo web
prehliadač )
o
jasnejší
popis: čo – vlastnosť aplikačnej domény ( externé pre systém ),
ako – vlastnosť systému ( interné pre systém )
-
počítačový
systém: software a hardware
-
aplikačná
doména: prostredie, s ktorým systém interaguje, systém realizuje
požiadavky prostredia
-
systém
vo všeobecnosti: časť reality, ktorú možno pozorovať alebo ktorá
interaguje so svojím okolím
-
uzavretý
systém: neinteraguje s okolím ( napr. vajce ? ) – v reálnom svete
neexistuje
-
systémy:
o
prirodzené
( ekosystém, počasie, ľudské telo )
o
abstraktné
( matematické teórie, počítačový program )
o
človekom
navrhnuté ( auto, lietadlo, internet )
o
spoločenský
systém ( firma, klub )
-
systémy:
o
hard
( systém je presný, dobre definovaný a kvantifikovateľný )
o
soft
-
kategorizácia
požiadaviek podľa FURPS+ modelu:
o
functional:
črty, schopnosti, bezpečnosť
o
usability
( použiteľosť ) : help, dokumentácia, ľudské faktory
o
reliability
(spoľahlivosť) : frekvencia zlyhaní, pokračovanie po zlyhaní
o
performance:
reakčné časy, priechodnosť, presnosť, dostupnosť
o
supportability:
udržovanie, internacionalizácia, prispôsobovanie, konfigurovateľnosť
o
+:
§
implementation
( jazyky, nástroje, hardware )
§
interface
( ohraničenia dané použitím externých systémov )
§
packaging
§
legal
( licencie )
-
F sú
požiadavky na funkčnosť, ostatné sú tzv. kvantitatívne požiadavky
UML Use case diagramy
-
obsahujú
elementy:
o
aktor:
je to vlastne trieda so stereotypom «actor», je to niečo s schopnosťou
vyvíjať nejakú aktivitu ( osoba, iný počítačový systém,
organizácia ), používa a lebo komunikuje so systémom
o
use
case: prípad použitia – spôsob používania systému, je to množina úspešných a neúspešných
scenárov ( špecifická sekvencia akcií a interakcií medzi aktorom a systémom
)
o
ohraničenie
systému od jeho prostredia ( s ktorým interaguje ) : je závislá na
pohľade, zo systému by sme mali:
§
vylúčiť
veci, ktoré nemajú vplyv na systém
§
vylúčiť
veci, ktoré majú vplyv na systém, ale systém ich môže len minimálne riadiť
alebo ovplyvňovať
§
zaradiť
veci, ktoré môžu byť systémom silne ovplyvňované alebo riadené
§
snaha
o vyváženosť medzi úplne otvoreným a úplne uzavretým systémom (totálna
alebo žiadna komunikácia)
-
definuje
sa v nich, KTO robí ČO, KEDY
Aktor
-
trieda
so stereotypom «actor», tento stereotyp má vlastný grafický symbol
-
rola
užívateľa ( ten ich môže mať viac )
Use case
-
vzor
správania sa aktora voči systému
-
väčší
príklad: use case pre Bankomat
-
ohraničenie:
-
use
case diagramy sú len znázornenie use casov, podstatný je text use caseov
-
zachycujú
sa tu najmä funkčné požiadavky (F z FURPS+ kategorizácie)
Typy use case (
www.usecases.org ):
-
stručný
Proces Predaj:
Zákazník príde s nákupom ku pokladni. Pokladník použije svoj
pokladničný systém na zanamenanie každej položky. Systém priebežne
zobrazuje sumu za položky. Potom
zákazník povie, ako chce platiť, systém tento spôsob skontroluje a zaznamená
údaje o platbe. Zákazník dostane účtenku a odíde aj s nákupom
-
štandardný
Hlavný úspešný
scenár: Zákazník príde s nákupom ku pokladni. Pokladník použije svoj
pokladničný systém na zanamenanie každej položky. ...
Alternatívne
scenáre:
Ak nie je možné
autorizovať kreditnú kartu, informovať zákazníka a požiadať
ho o iný spôsob úhrady.
Ak sa v systéme
nenachádza položka vybraná zákazníkom, systém upozorní pokladníka a umožní
ručné vloženie položky
Ak zlyhá
komunikácia s externý systémom na výpočet dane, tak ...
-
úplný
Proces Predaj
Primárny aktor:
pokladník
Účastníci a záujmy
( vymedzenie toho, čo systém musí podporovať ) :
-
pokladník
chce rýchlo a presne zadať položku tovaru
-
obchodník
chce mať záznamy o kúpe
-
zákazník
chce mať rýchlu obsluhu pri platení, chce mať dôkaz o platení v prípade
reklamácie
-
obch.
spoločnosť chce mať zaznamenanú transakciu a chce
splniť nároky zákazníka
-
daňový
úrad chce zdaniť každú obchodnú transakciu, obch. spoločnosť mu
musí vyhovieť
-
služba
na autorizovanie kred. Kariet chce mať požiadavky na autorizovanie v správnom
protokole
Vstupné
podmienky: pokladník je identifikovaný v systéme
Výstupné
podmienky: Predaj je zaznamenaný. Daň je správne vypočítaná. Údaje o stave
zásob doplnené. Vygenerovaná účtenka. Zaznamenané údaje o autorizovaní
platby.
Hlavný úspešný
scenár ( interakcia medzi aktormi a systémom, kontrola systému, zmena
stavu systému ):
1. Zákazník príde ku pokladni s nákupom
2. Pokladník inicializuje predaj
3. Pokladník vloží identifikátor tovaru
4. Systém zaznamená tovar a zobrazí
popis tovaru, cenu a celkovú sumu (
bod 3. a 4. sa opakuje, kým nie sú zaznamenané všetky položky )
5. Systém vypočíta celkovú sumu aj s daňou
6. Pokladník povie zákazníkovi sumu
7. Zákazník zaplatí a systém zaznamená
platbu
8. Systém ukončí predaj, doplní stav
zásob
9. Vygeneruje sa účtenka
10. Zákazník odchádza
Alternatívne
scenáre ( podmienka a jej obslúženie ) :
a) kedykoľvek, ak systém zlyhal,
pokladník reštartuje systém a môže pokračovať v kroku,
ktorý robil tesne pred zlyhaním ( systém teda musí zaistiť evidovanie
všetkých dôležitých krokov ).
3a) Chybný identifikátor:
1. Systém signalizuje chybu a odmietne
vstup
3b) Zákazník má viac kusov rovnakého tovaru a nie je nutné
zaznamenať identifikátory všetkých položiek:
- Pokladník
vloží identifikátor jedného tovaru a ich počet
3c) Zákazník požiada pokladník zrušiť položku zo zoznamu
1. Pokladník zruší položku
2. Systém zobrazí prepočítanú celkovú
sumu
3d) Zákazník požiada pokladníka zrušiť celý predaj
1. Pokladník zruší predaj
5a) Zákazník chce uplatniť nárok na zľavu ( zamestnanec,
častý zákazník )
1. Pokladník systému signalizuje požiadavku
na zľavu
2. Pokladník zadá identifikátor zákazníka
3. Systém zobrazí celkovú cenu s uplatnenou
zľavou vypočítanou na základe stanovených pravidiel
5b) Systém zistil problém v komunikácii s externým systémom na
výpočet dane:
1. Systém vykoná reštart a pokračuje
1a) systém zistil, že služba stále nefunguje:
1. Systém signalizuje chybu pokladníkovi
2. Pokladník môže vypočítať
daň ručne alebo rušiť predaj
7a) platba v hotovosti:
1. Pokladník vloží do systému sumu
2. Systém zobrazí rozdiel
3. Pokladník uloží bankovky a vráti
rozdiel
4. Systém zaznamená predaj
7b) platba kreditnou kartou
...
Špeciálne
požiadavky ( nefunkcionálne požiadavky a obmedzenia ) :
-
Systém
musí používať dotykovú obrazovku s veľkým panelom. Text musí
byť viditeľný z jedného metra.
-
Reakčné
časy na autorizáciu musia byť do 30 s
-
Jazyková
internacionalizácia
-
Zapojiteľné
zariadenia na výpočet daní
Technologické
záležitosti:
3a) Tovar bude
zadávaný pomocou bar codu pomocou laserového skeneru alebo klávesnicou
...
Rozsah use-case:
-
mali
by sa zamerať na elementárny proces ( úloha vykonávaná užívateľom na
jednom mieste a čase, ako odpoveď na udalosť, ktorá mu dá nejaký úžitok a ponechá dáta
systému v konzistentnom stave)
-
-
častá chyba je definovanie use – case na na nízkej úrovni ( jednoduchý
krok, alebo podúloha v rámci EP )
Vyhľadanie
primárnych aktorov, cieľov a use-cases:
1. Treba určiť hranice systému ( je
to len softwérová aplikácia, je to software + hardware ?)
2. Určiť primárnych aktorov (
ktorých ciele budú splnené použitím služieb systému )
( nezabudnúť na toho, kto štartuje a ukončuje systém,
manažment užívateľov a bezpečnosť, kto a ako
zabezpečuje softw. Update, kto administruje systém, kto vyhodnocuje aktivitu
systému a výkonnosť...)
3. Pre každého určiť jeho ciele
4. Definovať use-cases, ktoré
spĺňajú ciele
Aktori –
primárni, sekundárni ( poskytujú služby systému – typicky informácie – napr.
služba na autorizovanie platieb ), aktori stojaci mimo ( majú záujem o správanie
sa systému, ale nie sú primárni alebo sekundárni – daňový úrad)
Požiadavky vo
forme zoznamu vlastností:
-
nevýhody:
zvyčajne ide o dlhé zoznamy málo súvisiacich vlastností
-
v prípade
použitia use-case a zoznamu vlastností sa zbytočne duplikujú údaje
Use case nie sú
objektovo orientované, dajú sa teda využívať aj v systémoch, ktoré
nie sú objektovo orientované
Ďalšie prvky
use – case diagramov
Generalizácia:
-
jeden
use case je zovšeobecnením iných use casov
-
generalizácia
užívateľov ( hierarchia )
Vloženie (
include )
-
často
opakované činnosti, ktoré sú súčasťami iných use – casov, môžeme
osamostatniť:
-
iné
príklady:
Rozšírenie ( extend
)
-
obohatenie
use – casu o alternatívne scenáre
-
iné:
Príklad
knižničného systému:
Zhrnutie:
-
pri
modelovaní use casov je dôležitý text, nie diagramy
-
vyskytujú
sa tam:
o
aktori:
rola, ktorú má užívateľ systému
o
use
– case: popis funkcionality systému, ktorú má k dispozícii užívateľ
o
scenáre:
inštancie use-casov ( hlavný a aleternatívne scenáre )
-
use
case a aktorov možno generalizovať
-
vzťah
«include» umožňuje často používanému use – casu, aby bol vložený celý
do iného
-
vzťah
«extends» umožňuje rozšíriť use –case o ďalšiu
funkcionalitu
Stavové diagramy
-
popis
zmeny systému v čase
-
objekty
v systéme menia v čase svoj stav
-
stavový
diagram popisuje stavy jedného (!) objektu, príp. triedy alebo systému
(podsystému) ako celku
-
ukážka
obyčajného stavu, počiatočného a koncového stavu
-
v stave
sa uvádza názov, stavové premenné (v niektorých metodikách) a činnosti,
ktoré sa v stave vykonávajú
-
stav
teda popisuje aktuálny postavenie objektu v nejakom časovom intervale
medzi nejakými udalosťami
-
udalosť
je významný alebo pozoruhodný výskyt nejakej príhody v systéme
-
príklad:
-
ak
dôjde ku nejakej udalosti, vykoná sa prechod (transition) medzi stavmi
-
stavový
diagram môže byť aplikovaný na (kvôli lepšiemu pochopeniu):
·
triedy
( konceptuálne i softwérové, prípadne celý systém )
·
use
case
-
popísanie
externých udalostí, ktoré sú obsluhované systémom v kontexte príslušného
use-case (ext. udalosti sú Vytvoriť predaj, Platba a Koniec
vkladania):
-
iný
príklad (use case Spracovanie dokumentu):
-
stavové
diagramy sa vytvárajú pre stavovo závislé objekty ( podľa stavu reagujú
rôzne na udalosti ) s komplexným správaním
-
typické
stavovo závislé objekty (triedy):
o
use
case
o
stateful
session (EJB stavové objekty, Servlety, ktoré si pamätajú stav relácie a vedia
generovať nové stránky a lebo ich meniť v závislosti od
stavu)
o
systém
ako celok (trieda reprezentujúca celý systém)
o
kontrolér
(špeciálna trieda, ktorá sprostredkúva prenos externých udalostí zvonka do
vnútra systému a naopak – prenos reakcií vnútra systému navonok)
o
transakcia
o
zariadenia
(televizor, mikrovlnka reagujú rôzne na udalosti v závislosti na ich
aktuálnom stave)
o
role
mutator (triedy, ktoré menia svoje roly, napr. osoba môže meniť rolu z civila
na veterána)
-
typy
udalostí:
o
externé
(systémové) udalosti: sú spôsobené niečím mimo hraníc systému; tieto
udalosti spôsobia vyvolanie systémových operácií, ktoré ich budú
obsluhovať
o
interné
udalosti: spôsobené niečím vnútri systému; v podstate ide o vyvolanie
nejakej metódy pomocou správy alebo signálu
o
časové
udalosti: vyskytuje sa v nich špecifický čas alebo dátum (napr.
nejaká operácia musí byť vyvolaná do 5 minút a pod.)
-
akcia
vyvolaná udalosťou: objekt na udalosť reaguje nejakou stanovenou
metódou
-
parametre
udalosti: udalosť môže mať parametre, ktoré sprostredkuje pri
prechode
-
strážna
podmienka: prechod sa uskutoční, iba ak platí podmienka
-
zahniezdený
(vnútorný) podstav: dedí všetky prechody z nadradeného stavu ( napr.
kedykoľvek počas telefonovania je možné položiť )
-
stavové
činnosti (vstupné, výstupné a v stave) faxu
-
sekvenčné
a súbežné podstavy (počítač)
-
história
stavu:
-
stav
Práca si pamätá, kde bol, keď sa spustí Šetrenie obrazovky a keď
sa beh systému opäť vráti do tohto stavu, bude v rovnakom „stave“
(napr. ostane otvorený editor a podobne)
-
história
stavu (ukladaný stav) je pseudostav ( rovnako aj počiatočný a koncový
stav, prípadne rozdelenie a spojenie )
-
hlboký
ukladaný stav (pamätá si aj stav podstavov, ktoré sa nachádzajú v aktuálnom
stave) :
- rozdelenie a spojenie (niekedy modelované aj pomocou guličiek)
-
stavový
diagram popisujúci prihlásenie sa do online bankového systému
Diagramy aktivít
-
rozšírenie
stavového diagramu
-
v podstate
je to vývojový diagram
-
stavové
diagramy sa zaoberali stavmi objektov a tried a prechodmi medzi nimi,
diagramy činností sa zaoberajú najmä týmito prechodmi
(činnosťami)
-
príklad:
-
vetvenie
a spojenie:
-
súbežné
činnosti (nezáleží na poradí):
-
signály
(medzi rôznymi objektami, napr. medzi ovládačom a televíziou):
-
využitie
diagramov aktivít:
o
popis
algoritmov
o
popis
use-casov a tried (v podstate to isté, čo pri stavových diagramoch,
avšak zameriame sa na činnosti vykonávané pri prechodoch medzi stavmi)
-
algoritmus:
-
diagram
aktivít pre use-case s rolami zúčastnených aktorov a objektov
(výber peňazí z bankomatu)
Interakčné diagramy
-
sekvenčné
diagramy a diagramy spolupráce
-
popis
toho, ako objekty komunikujú v čase
-
sekvenčné
diagramy obsahujú objekty (inštancie tried), životočiary objektov a spráy,
ktoré naznačujú komunikáciu; čas na životočiare beží zdola zhora
nadol
-
typické
je použitie sekvenčných diagramov pre grafický popis komunikácie
softwérových objektov (čiže klasický program)
-
sekvenčné
diagramy:
-
typy
správ:
o
návrat
o
synchrónna
(vysielajúci objekt čaká, kým je dokončené spracovanie na strane
prijímajúceho objektu a až potom pokračuje ďalej)
o
asynchrónna
(vysielajúci objekt nečaká)
o
typu
Wait (prijímajúci objekt čaká na správu)
o
typu
NoWait (prijímajúci objekt nečaká, koná niečo vlastné a len
občas skontroluje, či mu niekto niečo neposiela)
o
doručená
správa (doručenie trvá nejaký čas)
o
správa
samotnému objektu („self“ alebo „this“)
-
aktívny
objekt: má hrubú čiaru života (alebo je kreslený s hrubým štvorcovým
rámčekom)
-
napr.
je to vždy aktor
-
rozdiel
medzi triedou a objektom (inštancia triedy): objekt:Trieda, :Trieda,
objekt
-
generické
a inštančné diagramy sekvencií
- vytvorenie a zrušenie
objektu:
-
podmienka
-
cyklus
–
diagramy
spolupráce
–
významovo
zhodné so sekvenčnými diagramami (dá sa naň previesť a opačne)
–
zameriava
sa na komunikáciu v priestore, na usporiadanie spolupracujúcich objektov
–
diagram
spolupáce obsahuje objekty, linky medzi spolupracujúcimi objektami, správy
–
viac
správ a ich číslovanie, linky:
–
správa
sebe samému:
–
vytvorenie
inštancií (použiť názov create alebo stereotyp <<create>>):
–
viac
správ a ich číslovanie:
–
podmienka:
–
vzájomne
sa vylučujúce podmienky:
–
cyklus
(a aktívny objekt) :
–
iterácia
cez množinu (postupnosť) objektov (Predaj si od každej Položky pýta jej
sumu a tie v cykle sčítava; Položka má byť kreslená ako
viac prekrývajúcich sa obdĺžnikov)
Využitie
interakčných diagramov:
–
vo
fáze analýzy (systémové sekvenčné diagramy, prípadne systémové diagramy
spolupráce)
–
vo
fáze návrhu (interakčné diagramy budú popisovať komunikáciu a spoluprácu
tried tvoriacich celý systém)
ukážky:
Systémový
sekvenčný diagram:
Porovnanie
sekvenčných adiagramov a diagramov spolupráce:
|
Typ |
Výhody |
Nevýhody |
|
Sekvenčné
diagramy |
Jasne
zobrazujú časový priebeh správ, jednoduchá syntax |
Objekty sa
pridávajú na koniec, čím sa diagram predlžuje |
|
Diagramy
spolupráce |
Priestorovo
výhodné – ľahšie pridávanie ďalších objektov, lepšie ilustrujú
komplexnejšie vetvenie, iteráciu a konkurentné objekty |
Zložitejší
prehľad priebehu správ, zložitejšia nnotácia |
Objektovo orientovaná analýza a dizajn a UP
Analýza – objavenie problému a požiadaviek ( ako bude systém používaný )
Dizajn –
zameranie sa na konceptuálne riešenie, ktoré spĺňa požiadavky (ako
bude systém navrhnutý). Ide skôr o návrh riešenia, než jeho implementácia
Objektovo
orientovaná analýza – nachádzanie a popis objektov ( konceptov ) v uvažovanej
doméne
Objektovo
orientovaný dizajn – definovanie softwérových objektov a ich spolupráce
tak, aby spĺňali požiadavky kladené na systém
Existujúce modely
vývoja systému:
Vodopádový model
(waterfall)
-
využívaný
pri hardware engineering
-
odlišnosti
od vývoja software:
o
nevyrába
sa niečo nemenné (software možno vždy zmeniť)
o
ignorovanie
meniacich sa potrieb a vplyvu užívateľa na celý proces
o
nerealistické
oddelenie špeciikácie od dizajnu
Prototypový model
-
používaný
pre pochopenie požadovaného užívateľského rozhrania
-
testovanie
uskutočniteľnosti navrhovaného riešenia
-
včasné
objavenie výkonnostných problémov
Upravený
vodopádový model
3 Etapové modely
Iteratívny model
-
predpokladá
znalosť všetkých požiadaviek na začiatku
Evolučný
model
-
umožňuje
učiť sa z vytvorených verzií
-
avšak
neumožnuje plánovanie a poučenie niekedy môže byť už neskoré
alebo zbytočné
Špirálový model
-
zahrňuje
prototypovanie a analýzu rizika
Unified process –
iteratívna metodika pre tvorbu objektovo orientovaných systémov
RUP – detailne
spracovaná metodika spoločnosti Rational, ktorá sa stala široko používanou
Iteratívny vývoj
– najdôležitejšia myšlienka
-
vývoj
je rozdelený do krátkodobých miniprojektov – iterácií. Každá iterácia obsahuje
analýzu, návrh, implementáciu, testovanie a integráciu systému. Dĺžka
iterácie sa pohybuje od 2 do 6 týždňov. ( Parkinsonov zákon – práca sa
rozťahuje tak, aby vyplnila čas pre ňu určený, vytvorenie
prioritných požiadaviek, uspokojenie pracujúceho tímu a zvýšenie dôvery zákazníkov
)
-
výsledokom
každej iterácie je spustiteľný ( nedokončený ) systém. Nie je to
prototyp alebo experiment – je to systém, ktorý sa inkrementálne zlepšuje
Výhody:
-
včasné
a časté zachytenie užívateľských reakcií na systém, čo
vedie ku rýchlej adaptácii ( tá je vždy lacnejšia v rannej fáze budovania
systému )
-
zvládnutie
komplexnosti pomocou krátkych etáp
-
rýchlo
viditeľný vývoj
Ďalšie
myšlienky UP:
-
zachytiť
vysoko rizikové oblasti v ranných fázach vývoja ( lepšie je zlyhať na
začiatku než omnoho neskôr ). Taktiež zvládnutím najväčších problémov
na začiatku sa ukáže schopnosť splniť požiadavky
-
neustále
zachytávanie užívateľských požiadaviek a reakcií užívateľov na
systém
-
čo
najskôr vybudovať súdržné kompaktné jadro ( kostru ) architektúry, ktoré
zvyčajne je kritické ( rizikové )
-
neustále
testovať kvalitu, včas a často
-
používať
use-case ako primárnu formu na zistenie požiadaviek
-
vizuálne
modelovať systém pomocou jazykov ako UML
-
správa
požiadaviek – riadenie priorít pre požiadavky
-
riadenie
zmien a konfigurácie – v prípade zmeny sa vyhodnotí jej význam a následky
a v prípade pozitívneho výsledku sa naplánuje jej zapracovanie.
Využíva sa tiež časté integrovanie ( aspoň raz denne ) a testovanie.
Ďalej sa používa versionovanie – a nielen kódu, ale aj ostatných výstupov
-
plánovanie
iterácií nie je detailné ( existuje vysoko úrovňový plán projektu, ale
plánovanie iterácií je postupné, vždy len jednu iteráciu vopred )
UP fázy:
Inception ( založenie, počiatok ) – približné vízie,
vágne odhady ceny a času
Elaboration ( rozpracovanie ) – spresnenie vízií, iteratívne
implementovanie jadra architektúry, rozpoznanie rizikových oblastí,
identifikácia väčšiny požiadaviek,
realistické odhady nákladov
Construction ( budovanie ) – iteratívne implementovanie
ostatných menej rizikových oblastí a príprava na nasadenie
Transition ( prechod ) – beta testy, nasadenie
Nie je tým
myslený sekvenčný vodopádový model ( najprv zachytiť všetky
požiadavky, potom navrhnúť úplný systém, potom ho celý implementovať,
potom otestovať a nakoniec nasadiť ), skôr ide o verziu
špirálového modelu.
Inc elaboration construction transition
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
UP disciplíny:
-
business
modeling: od doménového modelu po modelovanie business procesov (diagramy
aktivít, sekvenčné diagramy, stavové diagramy)
-
requirements:
analýza požiadaviek ( písanie use-case, ich vizualizácia a iné)
-
design:
všetky aspekty dizajnu, vrátane architektúry, databázy, siete atď
-
implementation
: vývoj
-
deployment:
nasadenie
-
test:
testovanie
-
configuration
and change management: riadenie zmien, integrovanie, versionovanie
-
projekt
management: správa a vedenie projektu
-
environment:
výber a konfigurácia vývojových nástrojov a prostredia
Inception
-
vízie
produktu, jeho rozsah, use case
-
zákazníci
projektu sa rozhodnú, či vízia spĺňa ich nároky a či
sú ochotní ďalej investovať do projektu (analógia s ropnou
spoločnosťou, tá sa tiež musí rozhonúť, či má význam
vŕtať a na to musí investovať do )
-
netrvá
dlho ( dni až najviac niekoľko týždňov )
-
počas
inception vznikajú dokumenty ( ktoré sa ďalej spresňujú ):
o
vízia
( predstava ) systému: vysokoúrovňové ciele a obmedzenia
o
use
case model: popisuje funkcionálne požiadavky
o
ďalšia
špecifikácia
o
slovník:
terminológia v doméne
o
iteration
plan : čo sa bude robiť v prvej iterácii elaborácie
o
plán
projektu: zhruba
Use case model
-
obsahuje
use – case (texty! A diagramy)
Dokument
Doplňujúce požiadavky:
Doplňujúca
špecifikácia – požiadavky, ktoré sa nedajú jednoducho zachytiť v use
– cases ( sú to ostatné požiadavky vo FURPS+, čiže spoľahlivosť,
výkonnosť, podpora atď. )
-
zaujímavé
sú doménové pravidlá :
o
systém
zliav: zamestananci 20 %, častí zákazníci 15% ( často sa mení )
o
množstevné
zľavy
o
časovo
obmedzené zľavy na vybrané produkty
Dokument Vízia
-
počas
inception a elaboration sa vypracuje dokument, kde:
o
sa
stanoví problém
o
čoho
sa týka
o
aké
má následky
o
riešenie
je: ...
-
určia
sa vysokoúrovňové ciele a problémy
-
určia
sa vysokoúrovňové vlastnosti systému ( aj s popisom )
-
určia
sa existujúce alternatívy a dôvod, prečo sa nepoužijú ( nemajú
požadované vlastnosti, sú drahé, chceme mať vlastné riešenie, ktoré si
budeme sami udržiavať)
-
kontextový
diagram ( zoznam aktorov – aj externých – ktorí pristupujú ku systému a vysokoúrovňové
use cases)
Slovník:
-
zoznam
podstatných termínov a ich definícia, neskôr môže expandovať a obsahovať
aj formáty, rozsahy hodnôt, pravidlá pre konntrolu údajov
Všetky štyri
dokumenty ( use-case model, vízia, doplňujúce špecifikácie a slovník
) sa začínajú vytvárať počas inception, všetky sa ďalej
spresňujú počas elaboration, kde by mali byť dokončené
Odporúčané
poradie vytvárania:
- Krátky koncept vízie
- Zistiť užívateľov a ich
ciele a use-case, ktoré ich spĺňajú
- Napísať niektoré use-case a začať
Doplňujúce požiadavky
- Spresniť víziu, zosumarizovať
tam informácie z use-cases
Elaboration
-
odhalenie
väčšiny požiadaviek
-
zistenie
najrizikovejších oblastí
-
implementované
a overené jadro architektúry
Aké dokumenty
štartujú v elaboration:
-
domain
model: vizualizácia doménových konceptov
-
design
model: množina diagramov popisujúca logický dizajn ( diagram tried, diagramy
interakcií )
-
software
architecture document: zhrnutie kľúčových architektonických problémov
a ich riešenia
-
data
model: napr. databázové schémy alebo zobrazenie medzi objektami a neobjektovými
reprezentantmi
-
test
model: popis, čo bude testované a ako
-
implementation
model: zdrojový kód, spustiteľné súbory, databáza
-
use
case model – pokračuje jeho ďalšie písanie
Use case model: System sequence diagrams
-
ukazujú
vstupné a výstupné udalosti týkajúce sa systému
-
sú
vytvárané z use – cases, sú vytvárané z hlavného úspešného scenára a často
aj pre alternatívne scenáre
-
slúžia
na lepšie vizuálne znázornenie use-caseov
-
často
sa pri nich vyskytujú aspoň fragmenty use-casov
-
zväčša
sú vytvorené vo fáze elaboration
Doménový model
-
súčasť
Bussiness modelling
-
široko
používaný ako zdroj inšpirácie pre návrh softwerových objektov
-
zobrazuje
významné konceptuálne triedy ( reálne existujúce myšlienky alebo veci ) v doméne, je to najdôležitejší objektovo
orientovaný dokument vo fáze analýzy, ide v podstate o vizuálny
slovník
-
je to
reprezentácia existujúcich konceptuálnych tried, nie softwérových komponent.
Nie je to množina softwérových tried alebo objektov s nejakou
zodpovednosťou
-
v UML
je zobrazený pomocou diagramu tried:
o
doménové
objekty alebo konceptuálne triedy
o
asociácie
medzi triedami
o
atribúty
konceptuálnych tried
-
generalizácie
tried:
o
ak
podtriedy reprezentujú podobné koncepty
o
ak
podtriedy majú všetky atribúty a asociácie, ktoré sú v nadtriede
-
používanie
asociačných tried:
o
asociácia
má atribúty
o
inštancie
asociácie majú životnosť
o
m-n
kardinality
-
kompozícia,
agregácia
-
odvodené
elementy ( Predaj má /celkovúSumu )
-
používanie
package ( nielen pre triedy ) :
o
ak
sa triedy týkajú podobnej oblasti ( blízke koncepty alebo ciele )
o
sú
v hierarchii
o
podieľajú
sa na rovnakých use cases
o
sú
silne asociované
-
medzi
balíčkami sa uvádzajú ich závislosti
Design
Class Diagrams
- zobrazenie softwerových tried
- triedy, asociácie, atribúty
- interface s operáciami a konštantami
- metódy
- typy atribútov
- navigovateľnosť ( možnosť prechádzať z jedného konca role na druhý – pokladňa zaznamenáva Predaj )
- závislosti ( jeden element má informácie o inom elemente – Predaj má info o Špecifikácii tovaru )
- telá metód : pseudokód alebo ľubovoľný jazyk
Software Architecture
-
organizácia
systému, jeho elementov do logických subsystémov
o
logical
architecture: organizácia systému do vrstiev, balíčkov, subsystémov
o
deployment
architecture: popisuje systém ako množinu komunikujúcich samostatných jednotiek
+ sieťová konfigurácia
-
organizovanie
systému do N – vrstiev je vlastne architektonický vzor, ktorý rieši mnohé
problémy:
o
systém
je organizovaný do vrstiev, ktoré komunikujú len medzi sebou ( a horné
vrstvy používajú dolné )
o
nie
je tak miešaná aplikačná logika s UI alebo databázovými službami
o
je
zjednodušené škálovanie systému, vývoj
-
klasická
3 vrstvová architektúra: užívateľské rozhranie ( okná, zostavy ... ) , aplikačná logika ( zabezpečenie
doménových procesov ) a databáza ( perzistencia ) – vrstvy sa samozrejme
môžu členiť dalej
-
2
vrstvová architektúra ( interface a aplikačná logika je zmiešaná ) –
rýchly vývoj, vhodné pre jednoduché aplikácie
Software Architecture
Document
-
súčasť
Design model
-
obsahuje
analýzu týkajúcu sa architektúry
-
architektonické
faktory a rozhodnutia ( použijeme takú databázu, lebo .. , taký komponent,
lebo, potrebujeme takú priechodnosť, výkon stabilitu ...)
-
logický
pohľad : balíčky a diagramy tried pre podstatné elementy (
rozdelenie systému na subsystémy )
-
pohľad
procesov ( ilustrácia podstatných procesov a vláken v systéme pomocou
diagramov tried a spolupráce )
-
pohľad
pre use – case: architektonicky významné use – case ( ktoré podminujú zvolenú
architektúru )
-
pohľad
nasadenia: diagram nasadenia pre pre uzly a ich procesy a komunikáciu
medzi nimi, sieťové rozvrhnutie systému
Data model
-
modelovanie
perzistentných tried ( ktoré zodpovedajú triedam z design class diagramu
alebo doménového diagramu, ktoré je nutné uchovávať aj po skončení
procesu)
-
použitý
UML Data Modeling Profile ( Profile for Database Design )
Ukážka vývoja:
Inception – sa
počas 1 týždňa pomenujú všetky use – case, 10 % sa napíše detailne,
veľmi vágne sa dá odhadnúť rozsah projektu
Elaboration 1 –
počas 4 týždňov sa popíše detailne 30 % use – case, navrhne sa dizajn
pre malú množinu najdôležitejších požiadaviek, tieto sa implementujú, zlepší sa
odhad rozsahu projektu
Elaboration 2 –
počas 4 týždňov sa popíše detailne 50 % use case ( využije sa aj
spätná väzba od užívateľov ) , pokračuje sa dizajnom pre ďalšiu
množinu najdôležitejších požiadaviek, tieto sa implementujú ( je hotových asi 5
% systému ) , zlepší sa odhad rozsahu projektu
Elaboration 3 –
počas 3 týždňov sa popíše detailne 70 % use case ( využije sa aj
spätná väzba od užívateľov ) , pokračuje sa dizajnom pre ďalšiu
množinu najdôležitejších požiadaviek, tieto sa implementujú ( je hotových asi
10 % systému ) , zlepší sa odhad rozsahu projektu
Elaboration 4 –
počas 3 týždňov sa popíše detailne 80-90 % use case ( využije sa aj
spätná väzba od užívateľov ) , jadro systému by už malo byť
stabilizované ( je hotových asi 15 % systému ) , je možno racionálne
odhadnúť rozsah projektu
Porovnanie tried v doménovom modeli, dizajn class diagrame a data
model
-
ide
tu o diagramy tried
-
v doménovom
modeli sa kreslia koncepty (konceptuálne triedy), ktoré sa vyskytujú v doméne
a vzťahy medzi nimi. Cieľ je pochopiť doménu
-
v dizajn
class diagrame sa kreslia softwarové triedy, ktoré sa potom využijú v diagramoch
interakcií (softwarové triedy samozrejme vychádzajú z doménového diagramu)
-
v data
modeli sa kreslia len perzistentné triedy, určia sa kľúče a cudzie
kľúče (v iných diagramoch sa to nerobí!)
Databázové diagramy
-
používané
v data modeli
-
tabuľka,
stĺpec, primárny a cudzí kľúč
-
určujúci
vzťah ( vzťah medzi tabuľkami rodič a dieťa,
dieťa musí existovať, kľúč dieťaťa sa dostane do
primárneho kľúča rodiča – je to potom primárny cudzí
kľúč )
-
neurčujúci
vzťah ( vzťah medzi tabuľkami, ktoré môžu existovať
nezávisle na sebe, kľúč dieťaťa sa dostane medzi
nekľúčové atribúty rodiča )
-
pohľad
( virtuálna tabuľka, z pohľadu užívateľa ako tabuľka,
ale nemá samostatnú nezávislú existenciu )
-
uložená
procedúra ( procedúra týkajúca sa databázy, zvyčajne vykonávaná na
serveri)
-
doména
– množina platných hodnôt pre atribút alebo stĺpec
-
ukážka
tabuľky, kľúčov, určujúceho a neurčujúceho
vzťahu
- ukážka DDL
skriptu pre dané tri tabuľky (%SCHEMA_NAME% je treba nahradiť
konkrétnym názvom databázovej schémy) :
CREATE TABLE
%SCHEMA_NAME%.“Objednavka“
(
„popis“
VARCHAR(30),
„objednavkaID“
INTeger NOT NULL,
„datum“ DATE
NOT NULL,
„ZakaznikID“
INTeger NOT NULL,
CONSTRAINT „objednavkaID“ PRIMARY KEY („objednavkaID“,
„ZakaznikID“)
)
CREATE TABLE
%SCHEMA_NAME%.“Zakaznik“
(
„ZakaznikID“
INTeger NOT NULL,
„meno“
VARCHAR(20),
„priezvisko“
VARCHAR(30),
„ZamestnanecID“
INTeger NOT NULL,
CONSTRAINT „ZakaznikID“ PRIMARY KEY („ZakaznikID“)
)
CREATE TABLE
%SCHEMA_NAME%.“Zamestnanec“
(
„ZamestnanecID“
INTeger NOT NULL,
„meno“
VARCHAR(20),
„priezvisko“
VARCHAR(30),
„datumNastupu“
DATE,
CONSTRAINT „ZamestnanecID“ PRIMARY KEY („ZamestnanecID“)
)
ALTER TABLE
%SCHEMA_NAME%.“Objednavka“ ADD CONSTRAINT „je_objednana“ FOREIGN KEY (
„ZakaznikID“
)
REFERENCES
%SCHEMA_NAME%.“Zakaznik“ (
„ZakaznikID“
)
ALTER TABLE
%SCHEMA_NAME%.“Zakaznik“ ADD CONSTRAINT „je_obsluhovany“ FOREIGN KEY (
„ZamestnanecID“
)
REFERENCES
%SCHEMA_NAME%.“Zamestnanec“ (
„ZamestnanecID“
)
-
stored
procedure a trigger modelujeme pomocou metód so stereotypom SP,TRIGGER
Diagramy komponentov
-
softwerový
komponent je konkrétna súčasť implementovaného systému
-
je to
v podstate softwerová implementácia triedy, komponent ich môže
obsahovať viac
-
vhodné
použiť pri:
o
modelovaní
hotového systému (kvôli predvádzaniu, ako dokumentácia)
o
definovanie
komponentov pre programátorov
o
uľahčenie
znovupoužiteľnosti (reuse)
-
rozhranie
(interface): množina operácií, ktorými sa komponent reprezentuje navonok a pomocou
ktorých ho je možné využívať (používajú ho iné komponenty)
-
vzťah
medzi komponentom a jeho rozhraním je realizácia (komponent realizuje rozhranie)
-
komponent
môže mať viac rozhraní (keď sa podstatne odlišujú svojím zameraním)
-
typy
komponentov:
o
rozmiestňované
– základ spustiteľných systémov (spustiteľné programy, knižnice, ...)
o
podporné
– z ktorých sa vytvárajú rozmiestňované komponenty ( dátové súbory,
zdrojové súbory, ... )
o
vykonávacie
– vznikajú za behu systému
Diagramy nasadenia
-
popis
hardware použitého v systéme
-
uzly
: procesor a zariadenie
Podporné disciplíny UP
Základné
inžinierske (tvorivé) disciplíny:
-
business
modeling : štruktúra a dynamika domény z pohľadu
používateľa ( business model a doménový model)
-
requirements
: využitie use – cases na zistenie a zaregistrovanie požiadaviek (use case
model)
-
design
: viaceré architektonické pohľady systému ( design class diagrams,
interaktívne diagramy – realizácie use –case, diagramy komponentov, databázové
diagramy –– tieto diagramy sú v design modeli)
-
implementation
: vývoj softwéru, testy, integrácia (implementation model)
-
test
: popis spôsobov testovania a testovacích procedúr (test model)
-
deployment:
konfigurácia systému ako celku (aj s hardware) (deployment model)
Podporné disciplíny:
-
project
management : ako splniť podmienky kladené na software, analyzovať a evidovať
riziká, prekonať obmedzenia, dokončiť úspešne projekt, splniť
potreby zákazníkov a používateľov
-
configuration
and change management: ako udržiavať množstvo dokumentov, na ktorých
pracuje viac ľudí ( verzionovanie, simultánne update ), ako
zapracovávať zmeny v systéme
-
environment
: správne určiť vývojové
nástroje a prostredie, ktoré sú nutné na podporu vývojového tímu
Project management
-
práca
manažéra projektu:
o
úspech
zvyčajne nestojí za reč (vyzerá to tak, akoby manažér nerobil
nič; zvonku projekt vždy vyzerá jednoduchšie)
o
neúspech
je veľmi viditeľný ( a manažér je zaň zodpovedný )
o
zložitá
práca
§
je
dosť zdrojov (peňazí, ľudí, času) na projekt ?
§
je
projekt dobre pochopený ?
§
ako
použiť obmedzené zdroje najefektívnejšie ?
§
ako
aktuálny vývoj ovplyvní plán ?
§
ako
by sme sa mali poučiť pre ďašie projekty ?
-
manažér
môže riadiť:
o
zdroje
( získať peniaze, ľudí ... )
o
čas
( zmena plánu, posun termínov )
o
produkt
( redukcia funkcionality )
o
riziko
( rozhodnúť, ktoré riziká sú akceptovateľné )
-
má :
o
pochopiť
ciele a úlohy projektu
o
zaregistrovať
obmedzenia
o
naplánovať
kompromis medzi cieľmi a obmedzeniami
o
sledovať
a aktualizovať plán
o
vytvoriť
pokojné, produktívne a pozitívne pracovné prostredie
-
nástroje
na plánovanie:
PERT grafy
-
program
evaluation and review technique
-
nástroj
na určenie problémových častí
projektu
-
uzly
sú činnosti
-
prechody
označujú, po ktorej činnosti sa môže / má vykonať aká ďalšia
činnosť
-
červenou
je zvýraznená najdlhšia ( kritická ) cesta, ktorá ovplyvňuje splnenie
celého projektu (CPM – critical path method)
-
na
nekritických častiach možno ubrať zdroje a pridať ich na
kritických častiach cesty, čím znížime trvanie celého projektu
-
výhodná
je tiež dekompozícia projektu na menšie sekvenčné alebo paralelné
podprojekty
-
graf
začína vždy z jedného uzlu
GANTT grafy
-
grafy
umožňujú plánovať a sledovať využitie zdrojov alebo vývoj
projektu v prehľadných tabuľkách
-
ukážka
projektu pozostávajúceho zo štyroch úloh
-
sledovanie
aktálneho a plánovaného stavu, zobrazenie míľnikov (kontrolné body)
-
využitie
zdrojov
Stretnutia
-
ďalší
nástroj na plánovanie
-
stretnutia
sú drahé (každý účastník by mohol čas stráviť produktívne)
-
stretnutia
sú nutné (šetria peniaze predchádzaním nedorozumení a koordinačných
chýb)
-
stretnutia
sú zbytočné, ak:
o
účel
stretnutia je nejasný
o
účastníci
nepripravení
o
chýbajú
podstatní ľudia
o
diskusia
ide mimo témy
o
sú
dominantní jeden alebo dvaja ľudia
o
nenasledujú
rozhodnutia
-
rady
pre manažérov stretnutí:
o
dopredu
dať vedieť, kto má prísť, začiatok a koniec stretnutia
a ciele stretnutia
o
dopredu
poslať účastníkom podkladové materiály
o
určiť
manažéra stretnutia, ktorý bude udržovať diskusiu v rámci témy a vyhodnocovať
argumenty
o
určiť
sekretára, ktorý bude zapisovať priebeh, zaznamenávať úlohy vzniknuté
na stretnutí a tiež bude kontrolovať ich vykonanie
o
jednoznačne
určiť osoby zodpovedné za vykonanie úloh
Configuration and change
management
-
zákony
vývoja software
o
stála
zmena (každý software, ktorý zachytáva nejaké externé prostredie, sa musí
podrobovať zmenám, ináč zaniká jeho dôležitosť; tieto zmeny v software
pokračuú, kým nenastane čas, že kompletné prepísanie systému bude
lacnejšie, než pridávanie zmien do starého systému)
o
zväčšujúca
sa komplexnosť (vývojom software sa zvyšuje jeho komplexnosť; dá sa
to sčasti ovplyvniť)
-
zapracovanie
zmien do systému
o
počas
vývoja (fáza construction a transition UP)
o
po
vývoji (fáza údržby)
-
pre
väčšie projekty zvyčajne býva určený protokol, ktorý slúži na
zavádzanie zmien do systému
-
SCI –
software configuration item
o
špecifikácie požiadaviek
o
prototyp
o
diagramy
o
design
dokument
o
zdrojové
kódy
o
užívateľský
manuál
o
plán
testov
o
zaznamenané
výsledky testov
-
check
out je výber položky z repository (úložište CVS servera obsahujúce položky
súvisiace s projektom)
-
check
in je úprava položky v repository podľa lokálnej verzie položky
-
nástroje
pre správu verzií : CVS, VCS, SCC ... ( control version system )
-
zabezpečujú
bezpečnú prácu nad jedným projektom, kde viac ľudí pristupuje ku
rovnakým SCI
-
popis
štandardizovaných operácií (podporuje ich väčšina CVS) :
o
add
– zahrnie položku pod správu verzií (čiže skopíruje polokálnu položku do
repository, kde predtým neexistovala)
o
get
– skopíruje položku z repository do lokálneho projektu
o
update
– synchronizuje položku v repository s lokálnou verziou
o
check
in – ukončenie práce s lokálnou položkou ( a synchronizácia );
lokálna položka je odvtedy read only, v repository je položka odomknutá
o
check
out – začiatok práce s lokálnou položkou ( v repository by sa mala
táto položka uzamknúť, niekto iný si ju bude môcť skopírovať len
na čítanie )
-
typy
údržby (maintenance)
o
corrective
(oprava chýb)
o
adaptive
(reakcia na zmeny prostredia, zmena software i hardware)
o
perfective
– zlepšujúci (pridávanie nových vlastností, zlepšovanie efektívnosti) –
zvyčajne najväčšia časť
o
preventive
(dokumentácia, komentáre) – zvyčajne najmenšia časť
-
problémy
týkajúce sa údržby
o
slabá
kvalita dokumentácie
o
úžívateľ
požaduje zlepšenia a nové funkcie vs. čas údržby
o
zmeny
v užívateľskej organizácii
o
obmedzené
pochopenie domény (zvyčajne až polovica času údržby je nutná na
štúdium software )
o
slabá
morálka (údržba nie je až taká zaujímavá ako vývoj)
Requirements engineering
-
odbor
zaoberajúci sa požiadavkami
-
požiadavka
: podmienka alebo schopnosť, ktorú
musí systém spĺňať
-
requirements
engineering je odbor systémového inžinierstva, ktorý sa zaoberá skutočnými
cieľmi, službami a obmedzeniami softwerových systémov
o
skúma
tiež vzťahy medzi nimi a definuje presnú špecifikáciu systému a ich
vývoj v čase
o
určuje
cieľ softwarového systému a kontext, v ktorom môže byť
použitý
o
funguje
ako most medzi skutočnými reálnymi potrebami užívateľov, zákazníkov a pod.
a schopnosťami a možnosťami softwarových technológií
-
proces
spracovania požiadaviek:
o
pochopenie
problému : elicitation (získanie požiadaviek)
o
formálne
popísanie problému : špecifikácia, modelovanie ...
o
dosiahnutie
dohody pre popísaný problém : kontrola požiadaviek, vyriešenie konfliktov,
správa požiadaviek
-
verification
& validation:
o
test
správnosti požiadaviek
o
sú
stanovené požiadavky správne ? (validation – potvrdenie)
o
sú
požiadavky správne stanovené ? (verification – skontrolovanie )
-
vlastnosti
skúmané v rámci RE
o
vlastnosti
počítačového hardware (R)
o
vlastnosti
programu (P)
o
vlastnosti
systému v aplikačnej doméne (S)
o
vlastnosti
domény (D), je nezávislá na systéme
o
požiadavky
pre systém (R)
-
chceme
ukázať, že program (P) spĺňa požiadavky (R)
o
treba
ukázať, že C a P implikujú S (verification)
o
treba
ukázať, že D a S implikujú R (validation)
-
príklad
validation :
o
požiadavka
R : motor lietadla môže byť nastavený na spätný chod iba počas
rolovania na letisku
o
vlastnosti
domény D :
–
kolesá
lietadla sa chvejú práve vtedy, keď sa otáčajú
–
kolesá
lietadla sa otáčajú práve vtedy, keď sa lietadlo roluje na letisku
o
špecifikácia
S : spätný chod lietadla možno povoliť iba ak sa chvejú kolesá
o
platí
D a S implikuje R
-
typ požadovaného software:
o
statický
(vstupné dáta sú známe pred začiatkom spracovania)
o
dynamický
(počas spracovania sa dodávajú ďalšie dáta)
o
sekvenčný
o
paralelný
o
zameraný
na dáta (prenášané cez hranice systému )
o
zameraný
na riadenie (zložitý systém pravidiel, ktorými sa systém riadi)
o
zameraný
na algoritmy (zložité výpočty vykonávané systémom)
-
typ
projektu:
o
pre
konkrétneho zákazníka, ktorý potrebuje software pre vyriešenie svojho
konkrétneho problému
o
pre
trh ( software je určený pre užšiu alebo širšiu skupinu zatiaľ
neznámych zákazníkov )
o
hybridný
(kombinácia predošlých)
-
typ
software:
o
informačné
systémy – podpora práce s údajmi, zahŕňa aplikácie a databázy,
viac než 70 % software na svete spadá sem
o
embedded (vložené, zapustené) systémy – software,
ktorý riadi nejaký hardwarový process (výťahový systém, bankomat,
kardiosimulátor, mobilný telefón)
o
všeobecné
služby – systém poskytuje nejakú službu ( internetové aplikácie )
-
RE sa
zaoberá POPISOVANÍM:
o
označenie
(designation) – pomenovanie nejakého fenoménu (často sa používa
označenie známe z logiky)
rodič(x,
p) znamená, že p je rodičom x ( biologický ?, vychovávateľ ? )
žena(x)
znamená, že x je biologická žena (a nie
manželka)
zvoní(p,t)
znamená, že telefón p zvoní v čase t
zdvihnutie(p,t)
znamená, že telefón p je zdvihnutý v čase t
odkazovač(p,t)
znamená, že odkazovač telefónu p sa aktivuje v čase t
o
definícia
(definition) – formálna definícia, ktorá môže byť využitá pri ďalších
popisoch
matka(x,m) @ rodič(x,m) and žena(m)
sestra(x,y) @ žena(x) and matka(x,m) and matka(y,m) and
otec(x,f) and otec(y,f)
odpoveď(p,t) @ zvoní(p,t) and ((zdvihnutie (p, q) and (t<q<t+15))
or odkazovač(p,t+15))
"p "s ( navštevuje(p,s) Ţ študent(p) and prednáška(p) ) .... študent je ten, čo sa
zúčastňuje prednášok alebo ten, čo je zapísaný na danú školu
a ešte neskončil štúdium ?
o
hrubý
náčrt – koncept, ktorý je ďalej vyvíjaný
„každý patrí
práve do jednej rodiny“
-
slovesný
tvar požiadaviek:
o
pre
vlastnosti aplikačnej domény (prostredie) je to oznamovací tvar
(výťah premáva vo vertikálnom smere medzi jednotlivými poschodiami)
o
pre
vlastnosti systému je to podmieňovací tvar (pri prekročení povolenej
nosnosti BY systém mal signalizovať preťaženie a nemal BY
pokračovať v činnosti)
Requirements
Elicitation (získavanie požiadaviek)
-
zamerané
na objavenie vedomostí vlastnených nejakým doménovým expertom
-
podporované
expertnými systémami
-
existuje
nejaký problém, ktorý treba riešiť (nespokojnosť so súčasným
stavom, možnosť ušetriť nejaké zdroje, nové obchodné možnosti)
-
je
treba identifikovať 6 novinárskych otázok
o
ČO
je treba riešiť, v čom je problém
o
KDE
je problém (pochopenie kontextu, domény)
o
KTO
je účastníkom celého procesu, ktorý požaduje zmenu (zákazníci, užívatelia,
aktori)
o
PREČO
potrebujeme riešiť problém (ciele účastníkov)
o
KEDY
to potrebujeme riešiť (obmedzenia)
o
AKO
nám software pomôže riešiť problém (use – case, scenáre)
-
problémy
získavania požiadaviek
o
informácie
o doméne sú často distribuované na mnohých miestach a nie sú
explicitne napísané
o
konflikty
medzi informáciami z viacerých zdrojov (ľudia majú rôzne ciele
a rôzne chápu daný problém)
o
problém
s popísaním znalostí (ľudia často nevedia popísať to,
čo samozrejme používajú, experti nie sú zvyknutí na to, aby popisovali to,
čo robia)
o
zaujatosť,
ovplyvnenie (používatelia cítia, že nemôžu povedať svoje požiadavky –
úlohu tu zohrávajú vzťahy na pracoviskách, alebo nechcú povedať požiadavky,
keďže by ich to mohlo nepriaznivo ovplyvniť )
-
techniky
získavania požiadaviek
o
tradičné
–
pozorovanie
(introspection)
–
analýza
dát (ktoré sú produkované a ktoré sú vstupom)
–
rozhovory
–
prieskumy,
dotazníky
–
skupinové
techniky
-
focus
(zameraná) group
-
brainstorming
-
delphi
o
techniky
zamerané na reprezentáciu
–
zameranie
na cieľ
–
zameranie
na scenáre, use – case
o
kontextové
(sociálne) techniky
–
etnografické
techniky
–
analýza
reči a správania sa počas rozhovorov
o
poznávacie
(kognitívne) techniky
–
protocol
analysis
–
získavanie
znalostí
-
card
sorting
-
laddering
-
dotazníky
o
môžu
rýchlo získať informácie od veľkého množstva ľudí
o
spracovávané
na diaľku
o
získajú
sa postoje, názory a charakteristiky ľudí
o
nevýhodou
sú obmedzené kategórie odpovedí
o
treba
dať pozor na:
–
ovplyvnenie
možnosťami odpovedí
–
malá
množina respondentov (malá štatistická platnosť)
–
navádzajúce
otázky
–
nejasné
otázky (každý potom odpovedá na inú otázku)
–
dotazníky
MUSIA byť otestované
-
rozhovory
o
otvorené
o
štukturované
(množina bodov, ktoré sa majú prebrať)
o
v oboch
prípadoch účastník rozhovoru má možnosť na položené otázky
odpovedať vlastným spôsobom
o
zozbiera
sa veľké množstvo dát
o
ťažšie
sa spracováva, je problematické porovnávať viac účastníkov, vyžaduje
si to skúsenosť s vedením rozhovoru
o
pozor
na:
–
nezodpovedateľné
otázky
–
vytrhnutie
z kontextu
–
problém
popísania znalosti (tacit knowledge)
–
ovplyvnenie
účastníka
-
skupinové
techniky
o
focus
group – rozhovor so skupinou, ktorá sa podieľa na procese, ktorý sa má
analyzovať (pochádza z marketingu)
o
brainstorming
– akýkoľvek nápad je vítaný a neskôr sa preskúma
o
delphi
technika – (ak je kontakt medzi expertmi zložitý) každý expert napíše svoj
názor, názory kolujú, každý expert dopíše svoje vyjadrenie a tak to
funguje, kým sa nedokonverguje ku nejakému riešeniu
o
pozor
na:
–
ovplyvnenie
a dominanciu niektorých členov skupiny
-
techniky
zamerané na reprezentáciu
o
viď
use – case diagramy
-
analýza
protokolu
o
založené
na vykonávaní činnosti a súčasnom slovnom popisovaní tejto
činnosti
-
card
sorting
o
doménové
koncepty napíšeme na listy papiera
o
experti
utriedia koncepty do skupín a udajú, podľa čoho ich utriedili
o
získajú
sa vzťahy medzi jednotlivými konceptami
-
laddering
o
použitie
série otázok pre získanie konceptuálnej hierarchie pojmov alebo stromov úloh
(úloha alebo koncept sa zvyčajne skladá z podúloh a podpojmov)
-
etnometodologické
techniky
o
získavanie
požiadaviek je sociálna, psychologická aktivita (vyžaduje kontakt
a komunikáciu medzi ľuďmi, vyjednávanie a nachádzanie
kompromisov v prípade rozporov)
o
základy:
–
sociálny
svet je usporiadaný (alfa, beta, gama, delta, omega)
–
usporiadanie
nemusí byť vždy jasné a ani sa nedá vždy jednoducho popísať,
nemusí vždy platiť hierarchia platná navonok, často je viditeľná
len pre zainteresovaného pozorovateľa
o
technika:
pozorovateľ je zainteresovaný účastník
–
pozorovateľ
sa pripojí ku skupine a podieľa sa na činnosti a neskôr vie
kvalifikovane podať informácie o procese v správnom kontexte
a často získa informácie, ktoré sa nedajú získať inými metódami
–
nevýhody:
trvá to dlho, ťažko sa analyzuje bohatá skúsenosť, ktorú
účastník získa
Requirement
modeling
-
modelovanie
požiadaviek
-
prehľad
modelovacích techník:
o
enterprise
modeling
–
modelovanie
informácií (ERD)
–
modelovanie
organizácií (i*,SSM, ISAC)
–
modelovanie
zamerané na cieľ (KAOS, CREWS)
o
modelovanie
funkčných požiadaviek
–
štrukturovaná
analýza (SADT, SSADM, JSD)
–
objektovo
orientovaná analýza (OOA, OOSE, OMT, UML)
–
formálne
metódy (SCR, RSML, Z, Larch, VDM)
o
modelovanie
nefunkcionálnych požiadaviek
–
atribúty
kvality (QFD)
–
výkonnosť
(Petriho siete)
–
použiteľnosť
(task model)
–
spoľahlivosť
(MTTF)
-
ERD
(entitno relačné diagramy)
o
široko
využívané vo viacerých kontextoch
–
doménové
koncepty
–
databázové
diagramy pre informačné systémy
–
metamodely
-
ISAC
o
information
system work and change analysis (1970)
o
zameriava
sa na spoluprácu medzi užívateľmi, vývojármi a zákazníkmi
o
vhodné
len pre informačné systémy
o
ISAC
proces:
–
analýza
zmien (čo chce organizácia zmeniť ?)
–
štúdium
aktivít (aké aktivity pribudnú v IS, aké sú ich priority)
–
analýza
informácií (aké sú vstupy a výstupy IS, aké sú kvantitatívne požiadavky)
–
implementácia
(akou technológiou, aké sw/hw prvky, čo bude manuálne a čo bude
podporované IS)
o
analýza
zmien:
–
zoznam
problémov
–
zoznam
záujmových skupín, ktorých sa problémy týkajú (matica skupín a problémov)
–
analýza
problémov (doménoví experti kvantifikujú problémy)
–
vytvorenie
modelu aktivít (podobne ako DFD diagramy)
–
analýza
cieľov (získame strom cieľov)
–
definujeme,
čo sa má zmeniť (problémy, ktoré treba riešiť a ciele,
ktoré treba dosiahnuť)
–
určíme
alternatívy, ktorými sa majú dosiahnuť zmeny
–
tieto
namodelujeme, vyhodnotíme a vyberieme optimálne alternatívy
-
i*
o
vyvinuté
v 90-tych rokoch
o
modeluje
kontext organizácie pre informačný systém
o
poskytuje
štruktúru na odpoveď PREČO
o
dve
časti modelu:
–
strategic
dependency model (závislosti medzi aktormi)
-
aktor
môže byž závislý na inom aktorovi, ak chce splniť cieľ alebo úlohu
-
aktor
môže závisieť na nejakom zdroji
–
strategic
rational model (modelovanie záujmov aktorov)
-
uplatnenie
dekompozícií
-
KAOS
o
90-te roky
o
dve
časti modelu:
–
štruktúra
cieľov
–
formálna
entita každej entity v temporálnej (časovej) logike
o
postup:
–
definovať
vysokoúrovňové ciele a objekty, ktorých sa týkajú
–
definovať
počiatočnú množinu agentov a akcií, ktoré budú vykonávať
–
spresniť
ciele pomocou dekompozícií
–
indentifikovať
prekážky brániace cieľom a konflikty cieľov
–
určiť
obmedzenia pre ciele a prideliť ich konkrétnym agentom
–
spresniť
a formalizovať definície objektov a akcií
-
štruktúrovaná
analýza
o
často
využívané na analýzu a návrh inf. systémov
o
základné
používané pojmy:
–
proces
(transformácia dát) : činnosť, v ktorej sa transformujú
a prenášajú dáta
–
dátový
tok (data flow) : prenos dát z výstupu jednej entity na vstup druhej
–
dátový
sklad (data store) : miesto, kde sú dáta umiestnené (sklad je pasívny,
neuskutočňujú sa tam transformácie)
–
externá
entita : nachádza sa mimo systému, zvyčajne je to zdroj alebo cieľ
dátových tokov, ktoré pretínajú hranice systému
o
na
modelovanie sa používajú
–
Data Flow Diagrams (DFD); najprv sa nakreslí
tzv. kontextový diagram a ten sa ďalej dekomponuje
o
varianty
DFD:
–
Structured
Analysis and Design Technique
-
Doug
Ross
-
využíva
viac diagramy aktivít než DFD
-
rozlišuje
medzi riadením dát a ich spracovávaním
–
Structured
Analysis and System Specification
-
Yourdon
a DeMarco
-
klasická
štrukturovaná metóda
–
Structured
System Analysis
-
Gane
a Sarson
-
pridané
Data Access Diagrams pre Data Stores
–
Structured
Requirements Diagrams
-
Ken
Orr
-
vytváranie
oddelených modulov a ich spájanie
-
objektovo
orientovaná analýza
o
modelovanie
požiadaviek pomocou objektov a ich služieb
o
modelovacie
techniky:
–
Coad –
Yourdan (1. generácia)
·
Používanie
tried, objektov, atribútov, relácií
–
Fusion
(2.generácia)
·
použitie
asociačných tried, diagramov pre sekvenčné posielanie správ, životný
cyklus
–
UML
(3. generácia)
-
formálne
metódy
Špecifikácia
požiadaviek (IEEE standard 830-1998)
–
ako
dať požiadavky k dispozícii ostatným
–
software
requirements specification
o
správne
–
požiadavka
musí byť práve tá, ktorá bude požadovaná
o
jasne špecifikované
–
požiadavka
musí mať iba jednu interpretáciu
–
musí
byť teda popísaná jednoznačnými slovami (ak nie, tak použité termíny
by mali byť vysvetlené v slovníku)
–
v prípade
popisovania prirodzeným jazykom je vhodné nechať požiadavky
skontrolovať nezávislým expertom
–
existujú
jazyky na popis, pomocou ktorých sa dá predchádzať syntaktickým,
sémantickým chybám
o
úplné
–
sú
definované všetky významné požiadavky týkajúce sa funkčnosti, výkonu,
výzoru, externých rozhraní
–
definované
odpovede software na všetky možné triedy vstupných dát (aj neplatné pre dáta)
o
konzistentné
–
interná
konzistencia, žiadne požiadavky nie sú navzájom sporné, napr.
§
popis
vlastností skutočných objektov
§
logické
alebo časové konflikty
§
pomenovanie
rovnakých vecí rôznymi termínmi
o
ohodnotené
podľa dôležitosti
–
ohodnotenie
prispieva ku
§
zodpovednejšiemu
prístupu zákazníka
§
správnym
rozhodnutiam dizajnérov systému
o
verifikovateľné
–
existuje
konečný použiteľný algoritmus, ktorým sa dá overiť požiadavka
–
požiadavka
teda nesmie byť zadaná napr. „dobre pracovať“, „vhodné
používateľské rozhranie“, „malo by sa zvyčajne stať“, „program
sa nikdy nedostane do nekonečného cyklu“
o
modifikovateľné
–
je
možné spravovať požiadavky (meniť, pridávať)
§
logická
štruktúra, krížové odkazy, obsah
§
neredundantnosť
§
každá
požiadavka má byť vyjadrená samostatne, nie spolu s inými
o
sledovateľné
–
je možné
vystopovať pôvod požiadavky a jej využitie
§
spätne
(na základe čoho bola požiadavka definovaná)
§
dopredu
(kde všade sa na požiadavku odvoláva)
- problémy s SRS:
Kontrola
požiadaviek
–
používanie
inšpekcií (odvodené od inšpekcií programovania)
Riešenie
konfliktov
–
konflikt:
o
podľa
sociálnej psychológie: „interakcia vzájomne závislých ľudí sledujúcich
spoločný cieľ a záujmy so zvyškom skupiny s protichodnými
realizáciami týchto cieľov alebo záujmov“
o
podľa
RE: „konflikt je rozdielnosť alebo nezhoda cieľov“
o
môže
sa vyskytnúť medzi ľuďmi, skupinami, organizáciami alebo rôznymi
rolami tej istej osoby
–
riešenia
konfliktov:
o
vyjednávanie
§
spoločné
vyjasnenie rozsahu možností
§
nájdenie
riešenia vhodného pre všetkých v maximálnom možnom rozsahu
o
súťaž
§
maximálna
výhoda pre účastníka
§
nezaujímať
sa o stupeň uspokojenia ostatných
§
extrémna
forma - víťaz vyhrá na úkor ostatných
o
vyriešenie
treťou stranou
§
kniha
pravidiel, náhoda (hod mincou), autorita
–
teória
hier
o
ako
dosiahnuť čo najlepšiu svoju stratégiu
o
ako
čo najlepšie odhadnúť stratégiu ostatných hráčov
o
bod
Nasha (individuálny maximalizmus) , bod Mohrea (kolektívny maximalizmus)
o
príklad
s väzňami, Svätoplukove prúty
–
typy
konfliktných cieľov dvoch subjektov:
o
vzájomne
sa vylučujú (minimálne vzájomné uspokojenie)
o
ovplyvňujú
sa (čiastočné vzájomné uspokojenie)
o
neovplyvňujú
sa (úplné vzájomné uspokojenie)
o
jeden
je obsiahnutý v druhom (úplné vzájomné uspokojenie)
–
stav
knihy z knižnice z pohľadu fyzického uloženia
–
stav
knihy z knižnice pohľadu perspektívnej dostupnosti
–
štrukturovaná
argumentácia
–
metóda
gIBIS
o
Conklin
o
proces
argumentácie ako hypertextový graf
o
základy:
§
identifikovať
problémy
§
identifikovať
stanoviská, ktoré niekto k nim môže zaujať
§
spojiť
argumenty týkajúce sa nejakého stanoviska s ním
–
model
riešenia nekonzistencií
–
ukážka
nekonzistencií (telefonovanie z pohľadu volajúceho a volaného)
–
pravidlá
riešiace nekonzistencie
o
ak
v jednom pohľade sú dva stavy spojené prechodom (aj nepriamym)
a vyskytujú sa v druhom pohľade, mali by byť spojené
prechodom aj v druhom pohľade (modré stavy)
o
ak
v jednom pohľade patrí nejaký stav do superstavu (nadstavu)
a existuje aj v druhom pohľade, mal by aj v druhom
pohľade patriť do toho istého superstavu
Vývoj a správa
požiadaviek
–
software
sa vyvíja, pretože požiadavky sa vyvíjajú
–
typy
programov:
o
typ
S : špecifikovateľný úplne formálne
(zvyčajne sa nevyvíja)
o
typ
P : riešenie problémov (ide tu o nepresnú špecifikáciu reálneho problému;
akceptovateľné riešenie nie je perfektné a teda sa môže
zlepšovať)
o
typ
E : vložené programy (systém je časťou sveta, ktorý modeluje)
–
pre
správu požiadaviek platí to, čo pre správu SCI (software configuration
item) všeobecne
o
každý
návrh na doplnenie požiadaviek prechádza procesom schvaľovania, kde sa
určí, či sa akceptuje alebo zamietne
Softwerové metriky
–
problém:
o
aký
dobrý je program, ak dva programy robia to isté, ktorý je lepší
o
aká
bude miera spoľahlivosti programu
o
koľko
testovania ešte treba
o
koľko
môžeme očakávať chýb
o
aká
bude zložitosť údržby
o
ak
môžeme niečo merať v číslach, vtedy o tom niečo
vieme, ak to merať nevieme, vieme o tom omnoho menej
–
proces
merania pozostáva z priradzovania číselných hodnôt alebo symbolov atribútom nejakých entít
–
entita
: objekt v reálnom svete, môže byť prirodzený alebo umelý alebo to
môže byť udalosť
–
atribút
: charakteristika (vlastnosť, črta) entity
–
príklady:
o
entita
– program, atribúty – počet riadkov kódu, trvanie testovania, počet
chýb
o
entita
– fáza programovania, atribúty – počet chýb v návrhu, čas
vymedzený na testovanie, počet kontrol
o
číselné
hodnoty alebo symboly:
§
malý,
stredý, veľký (lingvistické kvantifikátory – hedge – pre fuzzy množiny)
§
slabo,
v poriadku, dobre (tiež lingv. kvantifikátory)
§
0, 1,
2, 3
§
1.5,
3.2, 6.7
–
čo
meriame v SE:
o
atribúty
procesov (aktivít, činností), aby sme tieto procesy zlepšili, zefektívnili
o
atribúty
produktov, aby sme zlepšili ich kvalitu
–
teória
miery:
o
miera
je jednoznačné zobrazenie z množiny A do množiny B, kde množina
A obsahuje reálne, pozorovateľné objekty (atribúty entít)
a množina B obsahuje formálne symboly (napr. čísla alebo lingvistické
symboly)
o
nech
A je množina popísaná vyššie, R je množina reálnych čísel. Zobrazenie
m: A´A ® R je metrika ak a len ak platí
§
pre
všetky x Î A platí m(x,x) = 0 (reflexívnosť)
§
pre
všetky x,y Î A platí m(x,y) = m(y,x) (symetrickosť)
§
pre
všetky x,y,z Î A platí m(x,z) Ł m(x,y)+m(y,z) (trojuholníková nerovnosť)
–
miery
v SE:
o
statické
(odvodené od software samotného, napr. zdrojový kód)
o
dynamické
(odvodené z pozorovania vykonávaného software)
o
priame
(založené na veľkosti, námahe, trvaní, kvalite)
o
nepriame
(napr. produktivita)
–
miery
veľkosti programu:
o
SLOC
– source lines of code (počet riadkov kódu)
o
function
points
–
miery
námahy:
o
–
miery
kvality (základom kvality je bezchybnosť a vhodnosť pre dané
použitie):
o
typické
atribúty
§
stav
problému – aktuälny stav v analýze alebo riešení problému (uzavretý,
otvorený, rozpoznaný, vyhodnotený, vyriešený)
§
typ
problému – chyba software alebo hardware, nová požiadavka, rozšírenie
§
jedinečnosť
– nová chyba lebo opakujúci sa výskyt starej ?
§
kritický
(rozhodujúci) element – ohodnotenie procesu, elementu podľa toho,
s aký by mal dopad na užívateľa v prípade zlyhania
§
urgentnosť
– stupeň dôležitosti pridelený vyhodnoteniu, riešeniu a uzavretiu
problému
–
miery
výkonnosti:
o
čas
získania odpovede (response time)
o
výkon
(troughtput) – počet úloh, ktoré sú splnené za jednotku času
–
miery
spoľahlivosti:
o
MTBF
(mean time between failures) – priemerná doba medzi jednotlivými chybami,
prípadne do prvej chyby
o
mean
time to repair – priemerná doba na opravu
o
availability
(dostupnosť), napr. od operačného systému je požadované, aby fungoval
99,99999 % v roku (zvyšný čas je na výmenu hardware, zotavenie
z chýb, reštarty, update a záplaty)
Požiadavky na zápočtový projekt v prvom semestri:
–
odovzdať
dva týždne pred zápočtovým týždňom (aby ste mali možnosť
opraviť projekt, ak sa v ňom nájdu chyby alebo bude neúplný),
priebežne možno na cvičeniach konzultovať prípadné nejasnosti
–
vízia
(jedna strana), slovník, kontextový model
–
use
case model (aspoň 5 netriviálnych use – case popísať stručne,
aspoň 2 netriviálne use – case úplne, ostatné use – case popísať len
názvom)
–
doménový
model (diagram tried, aspoň 15 tried s atribútmi a ich typmi a metódami,
ktoré sa potom budú využívať v interakčných diagramoch; každá
trieda bude stručne popísaná niekoľkými vetami)
–
aspoň
5 diagramov popisujúcich use – case alebo doménové koncepty (triedy) –
použiť aspoň jeden sekvenčný diagram, aspoň jeden diagram
spolupráce, aspoň jeden stavový diagram, aspoň jeden diagram aktivít
(čiže jeden ďaší diagram si môžete vybrať)
–
data
model (databázové diagramy, aspoň 10 tried s atribútmi a ich
databázovými typmi, kľúčmi a asociáciami )
Časté
chyby:
–
krátka
(žiadna) vízia, krátky (žiaden) slovník
–
kontextový
model (alebo jeho dekompozícia) obsahuje málo use case diagramov
–
nie
sú napísané use case
–
doménový
model obsahuje málo tried, chýbajú podstatné triedy z danej domény, triedy
nie sú popísané
–
doménový
diagram obsahuje umelé kľúče a cudzie kľúče
–
chýba
diagram spolupráce a diagram aktivít
–
diagramy
spolupráce a aktivít a stavové a sekvenčné diagramy sú
triviálne (využite svoje úplné use – case, v ktorých máte alternatívne
scenáre a tie popíšte dynamickými diagramami – treba použiť cykly,
podmienky a vetvenia, pre stavové diagramy a diagramy aktivít
aspoň 7 – 10 stavov / aktivít, pre sekv. Diagramy a diagramy
spolupráce aspoň 5 – 7 tried)
–
chýba
databázový model, prípadne obsahuje málo entít
–
databázový
model má atribúty popísané tak, že v názve je jeho typ, napr priezvisko
varchar(20) – typ atribútu treba nastaviť v logických vlastnostiach
a jeho veľkosť vo fyzických vlastnostiach atribútu (to sa dá až
po prvom generovaní DDL)
Poznámka:
–
za
každú neospravedlnenú neúčasť na cvičení (dvakrát nemusíte na
ňom byť) treba napísať ďalšie netriviálne dva diagramy (
sekv, spolupráce, stavový, aktivity, prípadne úplný use –case )
–
ak
budete meškať s odovzdaním bez akceptovaného ospravedlnenia, tak za
každý začatý týždeň po zápočtovom týždni treba napísať
ďalších 5 netriviálnych diagramov
Literatúra:
1.
Craig
Larman: Applying UML and patterns, Prentice Hall, 2002
2.
Bruce
Powell Douglas: Real-Time UML for embedded systems, Addison Wesley, 2000
3.
Eric
Naiburg, Robert Maksimchuk: UML for Database Design, Addison Wesley, 2001
4.
Joseph
Schmuller: Myslíme v jazyku UML, Grada, 2001
5.
Drbal
a kol: Objektovo orientované metodiky a technológie, Praha, 1997
6.
Rumbugh
a kol: Object oriented modeling and design, Prentice Hall, 1991
7.
Manuály
a tutoriály Together Controll Center, Rational Rose
8.
Internet
(keywords: software engineering, UML, object oriented design)
Ďalšie zdroje:
1.
Humphrey, W.
Managing the Software Process, Addison-Wesley/SEI series in Software
Engineering,
2.
Gamma, E., Helm,R., Johnson,R., Vlissides,J. Design
Patterns, Elements of Reusable Object-Oriented Software, Addison-Wesley, 1994
3.
Icon Computing, Inc. Object-Oriented Design, Idioms and
Architectures,
4.
Rational Unified Process Whitepaper: Best Practices for
Software Development Teams - Rational Software, 1998
5.
Jacobson,
6.
Booch, G., Jacobson,