razvoj informacijskih sistemov
DESCRIPTION
Razvoj informacijskih sistemov. Visokošolski strokovni študij. UNIVERZA V LJUBLJANI Fakulteta za računalništvo in informatiko Doc. dr. Marko Bajec. Študijsko gradivo, verzija 2.3. Splošne informacije. Predavatelj Doc. dr. Marko Bajec, univ. dipl. ing. - PowerPoint PPT PresentationTRANSCRIPT
Razvoj informacijskih sistemovVisokošolski strokovni študij
UNIVERZA V LJUBLJANIFakulteta za računalništvo in informatiko
Doc. dr. Marko Bajec
Študijsko gradivo, verzija 2.3
Splošne informacije... Predavatelj
Doc. dr. Marko Bajec, univ. dipl. ing. Elektronska pošta: [email protected] Informacije: http://infolab.fri.uni-lj.si/marko/
Asistent As. dr. Damjan Vavpotič, univ. dipl. ing. Elektronska pošta: [email protected] Informacije: http://aris.fri.uni-lj.si/~damjan/
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 2 -
http
http
Splošne informacije Predavanja
Vsak ponedeljek od 10:15 do 13:00 (3 šolske ure); Predavanja so obvezna!
Izpit Seminarska naloga (predpogoj) Pisni izpit Ustni izpit
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 3 -
Priporočena literatura… Objektni razvoj (UML in RUP)
[1] Martin Fowler (2003). UML Distilled: A Brief Guide to the Standard Object Modeling Language, Third Edition. Addison-Wesley.
[2] Thomas A. Pender (2002). UML Weekend Crash Course. Wiley Publishing.
[3] Booch, G., J. Rumbaugh in I. Jacobson (1999). The Unified Software Development Process. Addison Wesley.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 4 -
Citiranje: glej [1,15-20] = glej v knjigi M. Fowler, strani od 15 do 20.
Priporočena literatura… Agilne in lahke metodlogije
[4] Kent Beck (1999). Extreme Programming Explained: Embrace Change, Addison-Wesley.
[5] Martin, C. Robert (2003). Agile Software Development: Principles, Patterns and Practices. Prentice Hall.
[6] Cockburn, A (2002). Agile Software Development. Pearson Education.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 5 -
Priporočena literatura Splošno o razvoju IS
[7] Silič Marin et al (2000). EMRIS - Enotna metodologija razvoja informacijskih sistemov. Ljubljana: Vlada RS, CVI.
[8] Stephen J. Mellor, Kendall Scott, Axel Uhl, Dirk Weise (2004). MDA Distilled: Principles of Model-Driven Architecture. Addison-Wesley.
[9] Hoffer, J. A., George, J. F. in Valacich, J. S. (1999). Modern Systems Analysis and Design, Second edition, Addison-Wesley
Avison, D. E. in Fitzgerald, G. (2003). Information systems development: methodologies, techniques and tools, McGraw-Hill, London.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 6 -
Vsebina predmeta… I. Splošno o razvoju IS
Osnovni pojmi Življenjski modeli razvoja IS
Metodologije razvoja IS Definicija metodologije Zgradba metodologije Zgodovina nastajanja metodologij Formalizacija metodologij Komercialne metodologije Vrste metodologij Izbira metodologije
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 7 -
II
Vsebina predmeta II. Strukturni razvoj
Osnovne značilnosti strukturnega pristopa Primer strukturne metodologije Strateško načrtovanje Analiza Načrtovanje Testiranje Namestitev in uvedba
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 8 -
Vsebina predmeta III. Objektni razvoj
Osnovni principi objektne usmerjenosti Osnove modelirnega jezika UML in procesa RUP Objektna analiza in načrtovanje
IV. Modelno usmerjen razvoj MDA – Model Driven Architecture in MDD – Model-
Driven Development. Razlike med MDA/MDD in klasičnim pristopom k
razvoju IS
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 9 -
Poglavje ISplošno o razvoju IS
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 10 -
Osnovni pojmi Življenjski modeli razvoja IS Metodologije razvoja IS
Informacijski sistem… Definicija:
Informacijski sistem lahko opredelimo kot množico medsebojno odvisnih komponent (strojna oprema, programska oprema, ljudje), ki zbirajo, procesirajo, hranijo in porazdeljujejo podatke in s tem podpirajo delavne procese v organizaciji.
Ločimo formalne in neformalne IS.
IS je lahko računalniško podprt.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 11 -
Ponovitev
P1.1 – Osnovni pojmi
IS - opredelitev
Informacijski sistem… Vrste IS:
Transakcijski IS (TPS-Transaction Processing System) Upravljalski (poslovodni) IS (MIS-Management Information
System) Direktorski IS (ESS-Executive Support System) Odločitveni IS (DSS-Decision Support System) Ekspertni IS (EIS-Expert Information System) Sistemi za avtomatizacijo pisarniškega poslovanja
(OAS-Office Automation System) Sistemi za podporo delovnim procesom (WfS-Workflow
Management System)
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 12 -
PonovitevVrste IS
Kaj nas zanima pri razvoju IS?... V okviru razvoja IS nas zanima, kako razviti
računalniške rešitve, ki bodo čim bolje podprle delovanje IS.
V okviru razvoja IS se ukvarjamo z: Razvojem računalniške rešitve Nabavo ustrezne strojne opreme Namestitvijo sistemske programske opreme Uvedbo rešitve Vzdrževanjem rešitve
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 13 -
Kaj nas zanima pri razvoju IS? Razvoj IS ni zgolj programiranje! Ni zgolj inženirsko delo…
Pri razvoju IS imajo velik pomen tudi sociološki dejavniki: Kako dojemamo problematiko? Kako razumemo potrebe uporabnikov? Kako uvedemo rešitve v prakso? …
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 14 -
Information System is about an implementation of IT into a human enterprise!
Razvoj IS in vrste IS Pristop k razvoju IS je odvisen tudi od vrste
IS. Nekatere vrste IS zahtevajo specifične
pristope: Ekspertni sistemi Odločitveni sistemi Sistemi za podporo delovnim procesom
Največ napora gre še vedno za razvoj IS za podporo operativnem delovanjuPS.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 15 -
Strateška raven
Taktična raven
Operativna raven
Sinonimi za računalniške programe V okviru razvoja IS med drugim nastanejo
računalniški programi.
Izraz “Računalniški program” ima številne sinonime: Program Aplikacija Aplikativni sistem Informacijska rešitev Računalniška rešitev …
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 16 -
Terminologija
Življenjski modeli razvoja IS… Razvoj IS zajema številna opravila,
navadno razdeljena v faze: Analiza Načrtovanje Implementacija Testiranje Uvedba Vzdrževanje
Življenjski model razvoja IS (SDLC*) pove, v kakšnem sosledju in na kakšen način si v okviru razvoja IS sledijo posamezne faze.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 17 -
P1.2 – Življenjski modeli razvoja IS
* SDLC - System Development Life Cycle
Kot večina razvojnih procesov sledi tudi razvoj IS določenemu življenjskemu ciklu oziroma razvojnemu modelu, ki določa zaporedje faz razvoja.
Življenjski modeli razvoja IS… Poznamo različne življenjske modele:
Zaporedni ali slapovni model Interativni model Prototipni model Inkrementalni model
V praksi se večinoma uporablja kombinacija različnih modelov.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 18 -
Zaporedni ali slapovni model… Zaporedni ali slapovni model temelji na
zaporednem izvajanju faz. Ko se ena faza v celoti konča, se začne
naslednja.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 19 -
Analiza
Načrtovanje
Izvedba
Uvedba
Spec. zahtev
Načrt
Koda
testiranje
čas
Zaporedni ali slapovni model… Značilnosti:
Najstarejši razvojni model, značilen za prve oblike strukturnega pristopa.
Faze si sledijo zaporedno. Vračanje nazaj ni mogoče. Primeren za relativno kompleksne projekte, če
zahteve dobro razumemo in se med projektom ne bodo bistveno spreminjale.
Omogoča dobro in natančno projektno vodenje.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 20 -
Zaporedni ali slapovni model… Prednosti:
Pomaga zmanjševati količino režijskega dela, ki ni v neposredni povezavi z izdelavo programske opreme (npr. vodenje projekta), saj je mogoče načrtovanje v celoti izvesti vnaprej.
Slabosti: Ni fleksibilen. Vsaka naknadna sprememba zahteva
veliko dodatnega napora. Nenaraven: v praksi težko pričakovati, da se lahko
nek postopek v celoti zaključiti, preden se začne z naslednjim.
Ne omogoča paralelnega izvajanja delov postopkov.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 21 -
Zaporedni ali slapovni model Zaradi kritik pojav modificiranih različic
slapovnega razvoja. Odprava nekaterih pomanjkljivost:
uvedba bolj enostavnega prehajanja med postopki, paralelno izvajanje delov različnih postopkov, ...
Slapovni model kljub vsemu nudi zelo čvrsto oporo sistematičnemu razvoju.
Možno uporabiti v kombinaciji z drugimi modeli.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 22 -
Iterativni model… Razvit kot odziv na pomanjkljivosti
slapovnega pristopa. Faze razvoja izvajamo v več iteracijah.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 23 -
Iteracija je specifično zaporedje aktivnosti, izvedenih na osnovi načrta in z določenim kriterijem vrednotenja, ki se konča z izdajo izdelka.
Iteracija
Iterativni model… V vsaki iteraciji razvijemo določen del
funkcionalnosti celotnega sistema. Iteracija gre navadno čez vse faze razvoja:
analizo, načrt, izvedbo… V začetnih iteracijah razvijemo najbolj
tvegane dele sistema.
Gre za evolucijski razvoj.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 24 -
Iterativni model…
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 25 -
Analiza
izdelki
testiranje
čas
Načrtovanje Izvedba Uvedba
Učenje in izkušnje
Iteracija #1
Analiza
izdelki
Načrtovanje Izvedba Uvedba
Učenje in izkušnje
Iteracija #2testiranje
AnalizaIteracija #3
Tipično trajanje ene iteracije: 7 do 14 dni
Iterativni model… Lastnosti iteracij:
Trajanje: od 7 do 14 dni (tipično) Vsaka iteracija gre čez vse faze (ne z enako
intenzivnostjo) Naslednja iteracija se lahko začne šele takrat, ko je
prejšnja končana. Vsebina naslednje iteracija je določena na osnovi
rezultatov prejšnje. Med izvajanjem iteracije ne sprejemamo sprememb.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 26 -
Planiranje na makro in mikro ravni
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 27 -
R1 R2 R3
Projectstart
S
Projectend
E
1. Release Planning
cca 2-4 months
2. Iteration Planning
R1 R2I1 I2 I3 I4
cca 2 weeks
3. Task Planning
I1 I2?
SALSD Requirements Miniature milestones – task list
Iterativni model… Prednosti:
Prednosti iterativnega razvoja (proti zaporednemu): Najbolj tvegani deli so razrešeni še preden postane
investicija velika Začetne iteracije omogočijo zgodnje povratne
informacije s strani uporabnikov Preizkušanje in povezovanje v sistem sta
nepretrgana Ciljni mejniki omogočajo kratkoročno osredotočenje Napredek merimo z ocenjevanjem izvedenega dela Možna je predaja izvedenega dela projekta še preden
je dokončan celoten projekt
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 28 -
Iterativni model Slabosti:
ne omogoča dobrega načrtovanja poteka projekta. ni mogoče točno predvideti, koliko iteracij bo
potrebnih za razvoj dokončnega (dovolj dobrega) izdelka.
vodenje projekta je zahtevno.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 29 -
Prototipni model… Gre za različico iterativnega modela. Temelji na izdelavi prototipov in njihovi
postopni izboljšavi, dokler ne dosežemo zadovoljive kakovosti.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 30 -
Prototip označuje predhodno izdelane in navadno še nepopolne različice sistema ali dela sistema.
Prototip
Prototipni model
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 31 -
Analizaproblema
Razvoj prototipa
Uporaba in testiranje prototipa
Revizija inIzboljšavaprototipa
Začetnezahteve
Delovniprototip
Problemi,Napaka,pomanjkljivosti
Novprototip Nove zahteve
Iteracije(evoluativni razvoj)
Inkrementalni model… Temelji na postopni gradnji celotne IR in
sprotni predaji posameznih inkrementov uporabniku.
Ne razvijamo celotne IR hkrati. Omejimo se na posamezen sklop, ki ga razvijemo v celoti in predamo uporabniku.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 32 -
Inkrement predstavlja zaokroženo funkcionalnost sistema (sklop, podsistem, modul).
Inkrement
Inkrementalni model… Ne razvijamo celotne IR hkrati. Omejimo se
na posamezen inkrement, ki ga razvijemo v celoti, predamo uporabniku ter nadaljujemo z naslednjim sklopom.
Ob predaji novi sklop povežemo z ostalimi sklopi.
Inkremente je moč razvijati tudi vzporedno.
Rezultat razvoja po inkrementalnem modelu je IR, sestavljena iz integriranih sklopov.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 33 -
Inkrementalni model…
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 34 -
Razvoj in predajaprvega sklopa IR
čas
Razvoj celotne IR
Razvoj in predajadrugega sklopa IR
Razvoj in predajatretjega sklopa IR
Klasičen razvoj
Inkrementalni razvoj
Inkrement #1 Inkrement #2 Inkrement #3
Uvedba intestiranje
sklopa
Uvedba intestiranje
sklopa
Uvedba intestiranje
sklopa
Uvedba intestiranjecelotnega
sistema
Inkrementalni model… Priporočeno določiti ustrezen razpored
razvoja sklopov. Zaporedje lahko določimo na različne
načine: na podlagi pomembnosti sklopov, na podlagi upoštevanja tveganja,…
Pri razporejanju sklopov na osnovi pomembnosti najprej razporedimo sklope z najpomembnejšo funkcionalnostjo. Na tak način funkcionalnost postopno nadgrajujemo do končnega sistema.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 35 -
Inkrementalni model… Pri razporejanju sklopov glede na
pomembnost lahko uporabimo analizo MOSCOW, kjer funkcionalnosti IR razdelimo na:
funkcije, ki jih je nujno potrebno implementirati, funkcije, ki bi jih bilo dobro implementirati, funkcije, ki bi jih lahko implementirali – niso obvezne
in funkcije, ki jih ne bomo implementirali.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 36 -
Inkrementalni model… Na podlagi analize MOSCOW lahko funkcije
sistema ustrezno časovno razporedimo. Pri razporejanju sklopov upoštevajoč tveganost (v
smislu tveganja, da razvit sklop ne bo ustrezal naročniku) najprej razvijemo najbolj tvegane in zahtevne sklope, kar omogoča hitrejše znižanje stopnje tveganja pri celotnem projektu
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 37 -
Skl
op 1
Skl
op 2
Skl
op 3
Tveg
anje
Čas
Skl
op 4
tveganost projekta
tveg
anos
t skl
opa
Skl
op 1
Skl
op 2
Skl
op 3
Tveg
anje
Čas
Skl
op 4
tveganost projekta
tveg
anos
t skl
opa
Inkrementalni model… Prednosti:
Uporabnik prej dobi del zahtevane IR, saj se IR razvija po delih.
Rešitev, ki jo uporablja, se postopoma nadgrajuje, sam pa lahko sodeluje pri testiranju razvitih sklopov.
Naročnik laže sledi napredovanju projekta. Slabosti:
Ni mogoče uporabiti pri vseh projektih. Nekaterih rešitev ni moč predati v uporabo po delih.
IR moramo razdeliti na sklope in predvideti odvisnosti med njimi. Pri neustreznem načrtovanju se lahko zgodi, da sklope neustrezno razporedimo.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 38 -
Inkrementalni model Poseben primer inkrementalnega modela
je razdelitev vsebine na samostojne projekte.
Inkrementalni model možno učinkovito uporabiti v kombinaciji z iterativnim modelom: razdelitev na inkremente, vsak inkrement se izvaja iterativno.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 39 -
Kaj je metodologija razvoja IS? Nekaj definicij:
Metodologija je priporočena zbirka filozofij, faz, postopkov, pravil, tehnik, orodij, dokumentacije, upravljanja in izobraževanja za razvijalce IS (Maddison).
Metodologija razvoja IS je priporočen način razvoja IS, ki temelji na filozofiji in množici principov (Avison, 2003).
Metodologija je množica dogovorov (konvencij), s katerimi se (projektna) skupina/organizacija strinja (Cockburn, 2002).
Metodologija je vse kar redno delamo, da bi dosegli končni rezultat – delujoča PO pri končnem uporabniku (Cockburn, 2002).
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 40 -
MetodologijaProces
Tehnika
Orodje Standard
Filozofija
Izkušnja
Skrito znanje
P1.3 – Metodologije razvoja IS
Kaj je metodologija razvoja IS? Iz terminološkega slovarja:
METODOLOGIJA: skupek metod, postopkov in standardov, ki sestavljajo zaključeno celoto pri izvajanju inženirskih pristopov k razvoju produkta.
METODA: seznam postopkov in pravil za izvedbo določene naloge.
METODOLOGIJA RAZVOJA IS: postopen način razvoja informacijskega sistema, ki vključuje uporabo različnih tehnik in orodij, celovit v smislu korakov življenjskega cikla razvoja
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 41 -
2. Osnovna zgradba metodologij
Proces
Postopek
Aktivnost PodizdelekVloga
OrodjeStandard
vhod
izhod
Izkušnje inznanje
Metodologija
Življenjskicikel
Faza
Tehnika
Filozofija
Podatkovnatehnika
Procesnatehnika
OO tehnika
Tehnika proj.vodenja
Organizacijskatehnika
Tehnika dela zljudmi
Celostnatehnika
Osrednjipostopek
Podpornipostopek
Iteracija
Paradigmametodologije
Ciljmetodologije
Domenametodologije
Sociološkakomponenta
Izdelek
Različica
Predloga
Primer
Slapovni
Iterativni
Inkrementalni
Inkrement
Del izdelka
Uporabnost inizkušnje
Izobraževanje
Metdologijakot izdelek
Bazauporabnikov
Zahtevnostmetodologje
Namenmetodologije
[inkrementalno-iterativni razvoj]
Ozadjemetodologije
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 42 -
Proces
Postopek
Aktivnost PodizdelekVloga
OrodjeStandard
vhodizhod
Izkušnje inznanje
Metodologija
Življenjskicikel
Tehnika
Filozofija
Izdelek
Uporabnostin izkušnje
Proces
Postopek
Aktivnost PodizdelekVlogavhod
izhod
Izkušnje inznanje
Življenjskicikel
Faza
Osrednjipostopek
Podpornipostopek
Iteracija
Izdelek
Različica
Predloga
Primer
Slapovni
Iterativni
Inkrementalni
Inkrement
Del izdelka
[inkrementalno-iterativni razvoj]
Uporabnost inizkušnje
Izobraževanje
Metdologijakot izdelek
Bazauporabnikov
Zahtevnostmetodologje
FilozofijaParadigmametodologije
Ciljmetodologije
Domenametodologije
Sociološkakomponenta
Namenmetodologije
Ozadjemetodologije
Tehnika
Podatkovnatehnika
Procesnatehnika
OO tehnika
Tehnika proj.vodenja
Organizacijskatehnika
Tehnika dela zljudmi
Celostnatehnika
Zgodovina metodologij… Obdobje pred pojavom metodologij (do
zgodnjih 1970) Ni formalnih metodologij, poudarek na reševanju
tehničnih problemov, ključna vloga je programer
Zgodnje obdobje metodologij (do zgodnjih 1980) SDLC, tehnike podatkovnega in procesnega
modeliranja, večji poudarek na zajemu zahtev, analizi in načrtovanju
Royce, Boehm, Codd
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 43 -
Analiza
Načrtovanje
Kodiranje
Testiranje
Zajemzahtev
Razvoj ad hoc
Zgodovina metodologij Obdobje metodologij (do sredine/konca
1990) iterativni in inkrementalni razvoj, RAD, objektna
usmerjenost, večanje teže metodologij, strateško načrtovanje
Booch, Rumbaugh, Jacobson, Martin, Yourdon, Gamma
Obdobje ponovne ocenitve metodologij (danes) kritika težkih metodologij, lahke metodologije,
spletne aplikacije, nove tehnologije, hitro spreminjanje zahtev, trend agilnosti
Beck, Ambler, Cockburn, Highsmith
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 44 -
Začetek
Skupni stroški
Podrobnonačrtovanje
Analizatveganj
Analizatveganj
Analizatveganj
Analizatveganj
Identifikacija inodpravljanje
tveganj
Prototip 1Prototip 2
Prototip 3
Operativniprototip
Ocenialternative
SimulacijeModeli
Kod
iranj
e
Test
iranj
epr
og, e
not
Inte
grac
ija in
test
iranj
e
Pot
rditv
eni
test
Pre
daja
Konceptdelovanja
Načrt zahtev,načrt življen.
cikla
Načrtrazvoja
Načrtintegracije in
testiranja
Načrtovanjenaslednjeiteracije
Določitev ciljev,alternativ in
omejitev
Razvoj izdelkovza iteracijo inpreverjanje
njihove pravilnosti
Prični zizvedbo
naslednjeiteracije
Agilnost
Metodologija kot sociološka komponenta Metodologija razvoja IS ima pomembno
sociološko komponento: Poleg tehnik in orodij zajema skupek dogovorov, ki v
organizaciji oziroma skupini veljajo pri razvoju informacijskih rešitev;
Je prežeta s filozofijo in miselnostjo organizacije in njenih zaposlenih;
Je dinamična in odvisna od posameznikov, ki sestavljajo organizacijo.
Zajema vse kar počnemo, da izdelamo izdelek oziroma opravimo storitev, ki je cilj našega dela.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 45 -
Formalizacija metodologij Metodologije razvoja IS v mnogih podjetjih
niso formalizirane! Postopki, tehnike, orodja itd. niso dokumentirani; Razvoj poteka stihijsko (na vsakem projektu je
drugače; ni definirano, kako nek postopek izvedemo; kakšna orodja se uporabljajo je prepuščeno posameznikom,...
Posledice Slabša kakovost izdelka Razvoj je nesledljiv in netransparenten Tveganje, da izdelek ne bo pravi, Težje vzdrževanje,...
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 46 -
Dojemanje metodologij
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 47 -
Formalizirana metodologija
Postopki, tehnike, smernice,...
Neformalna metodologija
Dojemanje metodologije,
znanje, izkušnje, principi,
ideali
UporabaMetodologije
Izkušnje, nove ideje,
znanje
Je osnova zaformalizacijometodologije
Je osnova zarazumevanjemetodologije
Je osnova zauporabometodologije
Je osnova zaspremembo
dojemanjametodologije
Ponudba komercialnih metodologij Obstaja tudi precej ponudnikov
“komercialnih” metodologij. Nekaj primerov:
IE (Information Engineering) (Oracle CDM) SSADM Rational Unified Process STRADIS Agilne metodologije (XP, SCRUM, FDD,…)
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 48 -
Vrste metodologij Obstaja več načinov za delitev metodologij. Delitev metodologij nam pomaga pri izbiri
ustrezne metodologije.
Nekatere možne delitve: glede na tip metodologije, glede na težo metodologije, glede na utežitev metodologije.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 49 -
Delitev glede na tip metodologije
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 50 -
Pro
cesn
e in
stru
ktur
nete
hnik
e
Pod
atko
vne
tehn
ike
Obj
ektn
ete
hnik
e
Pos
ebne
tehn
ike
dela
z lju
dmi
Zaporedni(slapovni) razvoj
Iterativni ininkrementalni razvoj Prototipiranje
Objektno usmerjenemetodologije
Podatkovno-procesnemetodologije
Procesno usmerjenemetodologije
Metodologije za hiter razvoj(RAD)
Življenjski cikel
Tehn
ike
Metodologijeusmerjene v človeka
Organizacijskousmerjene
metodologije
Tehničnemetodologije
Socio-tehničnemetodologije
Filozofija
Cilj: organizacijska rešitev(lahko tudi programska)
Cilj: izgradnjaprogramske rešitve
Delitev glede na težo metodologije Teža je določena z obsegom in gostoto
Obseg metodologije je določen s številom različnih elementov, ki jih metodologija opisuje.
Gostoto lahko definiramo kot zahtevan nivo podrobnosti oziroma formalnosti.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 51 -Optimiziranost
Pril
agod
ljivo
st
Nizka
Visoka
Nizka Visoka
Proces, formalnost, dokumentacija
Izku
šnje
, dis
cipl
inira
nost
, raz
umev
anje
Lahkametodologija
Težkametodologija
Delitev glede na utežitev metodologije Tipi metodologij glede na utežitev
Spredaj utežene: dajejo poudarek analizi in načrtovanju
Zadaj utežene: dajejo poudarek kodiranju in testiranju
Uravnotežene: kombinacija obeh pristopov
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 52 -
čas
cena
spr
emem
be(n
apak
e)
čas
cena
spr
emem
be(n
apak
e)
Klasičen model Model RAD
Pojem agilnosti Začetki: leto 2001, srečanje strokovnjakov
s področja lahkih metodologij. Skupna izjava
Manifesto for Agile SW Development.
Na osnovi izjave je bilo izpeljanih več konkretnih priporočil za razvoj PO: Načela in priporočila za agilno modeliranje (Ambler). Principi agilnih metodologij (Cockburn, Highsmith).
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 53 -
Agilnost
Osnovna načela agilnosti
Posamezniki in njihova komunikacija so pomembnejši kot sam proces in orodja.
Delujoča programska oprema je pomembnejša kot popolna dokumentacija.
Vključevanje (sodelovanje) uporabnika je pomembnejše kot pogajanje na osnovi pogodb.
Upoštevanje sprememb je pomembnejše od sledenja planu.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 54 -
Principi agilnih metodologij… Neposredna komunikacija – najboljši način
za izmenjavo informacij.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 55 -
dvosmerna komunikacija
enosmerna komunikacija
dva človekaob tabli
telefon
e-poštavideo
audio
papir
pogovor»iz oči v oči«
Uči
nkov
itost
kom
unik
acije
Posrednost komunikacije
visoka
nizka
posredna neposredna
videokonferenca
Principi agilnih metodologij…
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 56 -
Teža (=obseg × gostota) metodologije
Velik
ost p
robl
ema
Majhna razvojna skupina
Optimalna težametodologije
Maksimalna velikostproblema
Teža (=obseg × gostota) metodologije
Vel
ikos
t pro
blem
a
Velika razvojna skupina
Optimalna težametodologije
Maksimalna velikostproblema
Nepotrebna
dodatna teža
metodologije je draga.
Večje razvojne skupine potrebujejo težje metodolo
gije.
Principi agilnih metodologij… Višja stopnja formalnosti metodologije je
primerna za projekte z višjo stopnjo kritičnosti.
Boljša komunikacija in več povratnih informacij zmanjšuje potrebo po vmesnih izdelkih.
Čim večji so discipliniranost, izkušnje in znanje razvojne skupine, tem manjša je potreba po podrobno definiranem procesu, formalnosti in dokumentaciji.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 57 -
Principi agilnih metodologij…
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 58 -
- 58 -
Optimiziranost
Prila
godl
jivos
t
Nizka
Visoka
Nizka Visoka
Proces, formalnost, dokumentacija
Izku
šnje
, disc
iplin
irano
st, r
azum
evan
je Lahkametodologija
Težkametodologija
Izbirametodologije
Principi agilnih metodologij Odkloni od načrtovane rešitve nas vodijo k
pravi rešitvi.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 59 -
Začetek Rešitev načrtovana na začetku
Prava rešitev
Izbira metodologije Pri izbiri si pomagamo z:
Modeli za klasifikacijo metodologij Modeli za klasifikacijo projektov Izbira metodologije glede na podprte postopke in
življenjski cikel Izbira metodologije na podlagi agilnih principov
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 60 -
Modeli za klasifikacijo metodologij… Lahke metodologije uporabimo v primeru,
ko: je glavni (in dokončno opredeljen) cilj razvoj
programske rešitve, imamo odgovorne, disciplinirane, izkušene in
motivirane razvijalce, ki so seznanjeni s posebnimi tehnikami dela,
stranko, ki razume bistvo lahkih metodologij in je pripravljena sodelovati,
imamo nepredvidljive in spreminjajoče se zahteve za programsko rešitev,
je cilj razvoja relativno majhen sistem z nižjo stopnjo kritičnosti, ki ga je mogoče razviti z majhno razvojno ekipo,
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 61 -
Izbira glede na težo metodologije
Modeli za klasifikacijo metodologij… Težke metodologije uporabimo kadar:
cilj ni le razvoj programskega sistema ampak tudi prenova organizacijskega sistema,
imamo manj izkušene razvijalce, pri katerih točno opredeljena formalna pravila nadomeščajo izkušnje in znanje,
naročnik zahteva visoko stopnjo formalizma (izdelovanje dokumentacije),
imamo relativno dobro definirane in stabilne zahteve, je cilj razvoja obsežnejši sistem z višjo stopnjo
kritičnosti, ki zahteva izdelavo ustreznih načrtov in dokumentacije.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 62 -
Izbira metodologije… Primer modela za klasifikacijo projektov
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 63 -
L6
E6
D6
C6 C20
D20
E20
L20 L40
E40
D40
C40 C100
D100
E100
L100 L200 L500 L1000
E1000E500E200
D200
C200 C500
D500 D1000
C1000
L6
E6
D6
C6 C20
D20
E20
L20 L40
E40
D40
C40 C100
D100
E100
L100 L200 L500 L1000
E1000E500E200
D200
C200 C500
D500 D1000
C1000
L6
E6
D6
C6 C20
D20
E20
L20 L40
E40
D40
C40 C100
D100
E100
L100 L200 L500 L1000
E1000E500E200
D200
C200 C500
D500 D1000
C1000
L6
E6
D6
C6 C20
D20
E20
L20 L40
E40
D40
C40 C100
D100
E100
L100 L200 L500 L1000
E1000E500E200
D200
C200 C500
D500 D1000
C1000
Število ljudi, ki sodelujejo na projektu ± 20%
1-6 7-20 21-40 41-100 101-200 201-500 501-1000
udobje
Krit
ično
st (o
dpov
ed s
iste
ma
lahk
o po
vzro
či iz
gubo
…)
nadomestljivdenar
nenadomestljivdenar
življenje
produktivnost
sledljivostponovljivost
Izbira glede na lastnosti projekta
Izbira metodologije… Obseg nekaterih komercialnih metodologij
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 64 -
IE S
SA
DM
RU
P
DS
DM
XP
Strategija
Izvedljivost
Analiza
Logično načrtovanje
Fizično načrtovanje
Programiranje
Testiranje
Uvedba
Evaluacija
Vzdrževanje
Metodologija
Faza
MN
ova
Samo omenjeno
Osnovna navodila, več jeprepuščeno lastni interpretaciji
Manj podroben opis
Podroben opis skupaj stehnikami
Legenda:
EM
RIS
YS
M
STR
AD
IS
ETH
ICS
SS
M
Obseg metodologije
Izbira metodologije…
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 65 -
Življenjski cikel
Kriteriji
Slapovni razvoj
Modificiran slapovni razvoj
Iterativni razvoj
Inkrementalni razvoj
Evolucijsko prototipiranj
e
Kodiraj in popravi
Deluje s slabo razumljenimi zahtevami
Slabo Srednje do odlično Odlično Slabo do
srednje Srednje do
odlično Slabo
Deluje s slabo razumljeno arhitekturo
Slabo Srednje do odlično Odlično Slabo Slabo Slabo
Rezultat je zanesljiv sistem Odlično Odlično Odlično Srednje do
odlično Srednje do
odlično Slabo
Rezultat je nadgradljiv sistem Odlično Odlično Odlično Odlično Odlično Slabo do
srednje Upravlja s tveganji Slabo Srednje Odlično Srednje do
odlično Srednje Slabo
Omogoča predvidljiv razvoj Srednje Srednje Srednje Odlično Srednje Slabo
Potrebuje malo režije Srednje Odlično Srednje Srednje Srednje Odlično
Dovoljuje spremembe med projektom
Slabo Srednje Srednje Slabo do srednje
Srednje do odlično
Slabo do odlično
Stranki omogoča nadzor napredovanja Slabo Srednje Odlično Srednje Odlično Srednje
Vodstvu omogoča nadzor napredovanja Srednje Srednje do
odlično Odlično Odlično Odlično Slabo
Ne zahteva veliko izkušenj Srednje Slabo do
srednje Slabo Slabo do srednje Srednje Odlično
Izbira glede na podprte življenjske cikle
Izbira metodologije Discipliniranost, izkušnje in znanje proti
procesu, formalnosti in dokumentaciji Višja stopnja formalnosti metodologije za
projekte z višjo stopnjo kritičnosti Večje razvojne skupine potrebujejo težje
metodologije
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 66 - Optimiziranost
Pril
agod
ljivo
st
Nizka
Visoka
Nizka Visoka
Proces, formalnost, dokumentacija
Izku
šnje
, dis
cipl
inira
nost
, raz
umev
anje
Lahkametodologija
Težkametodologija
Izbira glede natip projekta
Uporaba metodologij v praksi Empirične raziskave kažejo na nizko
uporabo metodologij. Ključni razlogi:
Nizka strukturiranost procesa razvoja (vsak projekt ima svoje lastnosti in specifičnosti; različne zahteve in pogledi uporabnikov,...)
Neprilagodljivost metodologij, Zastarelost metodologij, Sociološka neprimernost, Neosveščenost uporabnikov.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 67 -
Uporaba metodologij... Povzetek raziskave v slovenskih podjetjih
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 68 -
Poglavje IIStrukturni razvoj
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 69 -
Osnovne značilnosti strukturnega pristopa Primer strukturne metodologije Strateško načrtovanje Analiza Načrtovanje Testiranje Namestitev in uvedba
Strukturni razvoj
Eden prvih sistematičnih pristopov k razvoju IS
Zgleduje se po standardnih postopkih razvoja tehničnih izdelkov: aktivnosti si sledijo zaporedno.
Izoblikoval se je konec 60 in v začetku 70 let. Razlog: uvedba discipliniranega izvajanja analize in
načrtovanja. Cilj: zmanjšanje stroškov izgradnje in uvajanja IS.
Pristop “iz vrha navzdol”.RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 70 -
Osnovne značilnosti strukturnega pristopa
Primer strukturne metodologije
Informacijski inženiring je primer metodologije, ki opisuje razvoj IS po strukturnem pristopu.
Nastane leta 1981, glavni avtor je James Martin.
Uveljavitev v sredini 80-tih let, uporablja se še danes.
IE je zasnovan na teoretičnih in praktičnih dosežkih 80-tih let iz metodološkega in tehnološkega vidika.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 71 -
Informacijski inženiring - IE
Informacijski inženiring – IE
Osnovne značilnosti IE so: sloni na povezani množici tehnik za planiranje,
analizo, načrtovanje, razvoj in vzdrževanje IS celotne združbe ali vsaj njenih glavnih delov;
uporablja pristop od vrha navzdol; je podatkovno usmerjen; podpira avtomatizacijo razvoja; uveljavlja strateško planiranje; povečuje produktivnost.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 72 -
Osnovne značilnosti IE
Informacijski inženiring – IE
IE predpostavlja, da so poslovni sistemi večinoma podatkovno usmerjeni, tehnični sistemi pa procesno ali dogodkovno.
Podatki so stabilnejši od procesov in dogodkov.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 73 -
Osnovne značilnosti IE
Podatkovna usmerjenost
Dogodkovna
usmerjenost
Procesna
usmerjenost
Informacijski inženiring – IE
IE v grobem zajema štiri faze: Strateško planiranje Analiza Načrtovanje Izvedba
IE posebej obravnava podatke, posebej aktivnosti
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 74 -
Glavne faze IE
Planiranje
Analiza
Načrtovanje
Izvedba
Strateško planiranje informatike – SP
Razvoj IS združbe se po IE začne s fazo strateškega planiranja informatike.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 75 -
Opredelitev SP
Fidler in Rogerson, 1996
Strateško planiranje informatike je proces izoblikovanja informacijskega sistema, ki organizaciji omogoča uresničitev njenih ciljev in ji s tem posredno zagotavlja konkurenčno prednost.
Strateško planiranje informatike
Strateško planiranje informatike – SP
Cilji strateškega planiranja so: Povezati razvoj IS s poslovno strategijo organizacije. Izboljšati komunikacijo med vodstvom in informatiki. Načrtovati pretok informacij in procesov. Zmanjšati stroške in čas, potreben za razvoj aplikacij. Predlagati optimalno zaporedje nadaljnjih korakov pri
planiranju in razvoju IS. Pripraviti izhodišča za nadaljnje korake
informatizacije. Zagotoviti uporabo standardov za enotne tehnološke
rešitve. Pokazati na organizacijske probleme pri uvajanju
informacijske podpore in predlagati organizacijske rešitve za dosego racionalnejše uporabo informacijske podpore. RAZVOJ INFORMACIJSKIH SISTEMOV
Visokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 76 -
Cilji SP
Strateško planiranje informatike – SP
Problemi, če gre za investicije v informatiko na osnovi sprotnih potreb: Investiranje v sisteme, ki ne podpirajo poslovnih
usmeritev. Sistemi niso integrirani (podvojitev naporov in
podatkov). Ni sredstva za določitev prioritet projektom, plani se
pogosto spreminjajo. Problemi z obvladovanjem podatkov: niso dostopni,
so neskladni, netočni ali nepravočasni. Nezadostne infrastrukturne investicije.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 77 -
Problemi brez SP
Strateško planiranje informatike – SP
Problemi (nadaljevanje): Vsi projekti so ovrednoteni le na finančni bazi. Problemi glede IT investicij povzročajo konflikte med
različnimi oddelki znotraj organizacije. Nerazumevanje med uporabniki in informatiki vodi v
konflikte in nezadovoljstvo. Sistemi imajo večinoma krajšo življenjsko dobo,
pogosteje je potreben ponoven razvoj, kar povzroča večje stroške.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 78 -
Problemi brez SP
Strateško planiranje informatike – SP
IE priporoča postopek za izdelavo. V LINF razvitih več različic. Osnovna različica temelji na metodologiji
IE. Prilagojene različice za potrebe
posameznih podjetij.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 79 -
Metodologija IS
Osnovna različicaBody of Knowledge
Prilagojene različicePriročnik
1992
2006
Strateško planiranje informatike – SP
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 80 -
Shema procesa izdelave SP
80
Proces SP zajema 6 postopkov: Pregled in analiza obstoječega stanja; Opredelitev poslovno-informacijske
arhitekture; Opredelitev informacijske vizije; Opredelitev projektov; Izdelava akcijskega načrta; Spremljanje izvajanja in vzdrževanje
strateškega plana.
Pregled in analiza
obstoječega stanja
Opredelitev poslovno-
informacijske arhitekture
Opredelitev informacijske
vizije
Opredelitev projektov
Izdelava letneganačrta
Vprašalniki
Izpolnjeni vprašalniki
Poslovno-informacijska arhitektura
Razna dokumentacija
Razna dokumentacija
Informacijska vizija
Analiza
Prioriteteprojektov
Spremljanje izvajanja in vzdrževanje
strateškega plana
Terminska opredelitev
letnega planaPoročilo o izvajanju
letnega plana
Seznam Projektov
Podrobna opredelitev
izbranih projektov
Izdelava kratkoročnega plana
Izdelava dolgoročnega plana
Legenda
Postopek
Izdelek
Izhod postopka
Vhod postopka
3-4 mesece
Strateško planiranje informatike – SP
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 81 -
Postopki pri strateškem planiranju
Pregled in analiza
obstoječega stanja
Opredelitev poslovno-
informacijske arhitekture
Opredelitev informacijske
vizije
Opredelitev projektov
Izdelava letneganačrta
Spremljanje izvajanja in vzdrževanje
strateškega plana
Pregled in analiza
obstoječega stanja
Opredelitev poslovno-
informacijske arhitekture
Opredelitev informacijske
vizije
Opredelitev projektov
Izdelava letneganačrta
Vprašalniki
Izpolnjeni vprašalniki
Poslovno-informacijska arhitektura
Razna dokumentacija
Razna dokumentacija
Informacijska vizija
Analiza
Prioriteteprojektov
Spremljanje izvajanja in vzdrževanje
strateškega plana
Terminska opredelitev
letnega planaPoročilo o izvajanju
letnega plana
Seznam Projektov
Podrobna opredelitev
izbranih projektov
Izdelava kratkoročnega plana
Izdelava dolgoročnega plana
Legenda
Postopek
Izdelek
Izhod postopka
Vhod postopka
Strateški plan razvoja informatike
Izdelava strateškega plana traja približno od 3 do 6 mesecev.
Pri izdelavi sodelujejo: Zunanji svetovalci Metodologi (informatike izven organizacije) Ključni uporabniki Člani vodstvene skupine organizacije
Strateški plan je potrebno osveževati!
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 82 -
Trajanje izdelave SP in sodelujoči
Razvoj po strukturnem pristopu
Strukturni pristop k razvoju temelji na strukturni izvedbi analize in načrtovanja. podatki se obravnavajo ločeno od aktivnosti
postopkov. ključen element pri strukturnem modelu je
podatkovna baza, ki predstavlja strukturo, okrog katere se razvije programske module.
Strukturni razvoj se z uveljavitvijo objektnih programskih jezikov ukinja.
Danes se uporablja hibriden pristop: temelji na objektni filozofiji, vendar podatkovna baza še vedno ohranja ključen pomen.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 83 -
Osnovne značilnosti strukturnega pristopa k razvoju
Razvoj po strukturnem pristopu
Strukturni pristop k razvoju zajema več postopkov: Zajem in specifikacija zahtev; Analiza; Načrtovanje; Izvedba; Testiranje; Namestitev in uvedba Vzdrževanje.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 84 -
Ključni postopki strukturnega razvoja
Razvoj po strukturnem pristopu
Postopki strukturnega pristopa: Zajem in specifikacija zahtev; Analiza; Načrtovanje; Izvedba; Testiranje; Namestitev in uvedba Vzdrževanje.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 85 -
Kje smo?
Zajem in specifikacija zahtev
Zajem in specifikacija zahtev je ena pomembnejših aktivnosti razvoja oziroma nakupa IR.
Osnovni namen zajema in specifikacije zahtev je opredeliti želeno IR na način, ki bo omogočal: Pri nakupu IR izbirati med obstoječimi rešitvami, Pri razvoju IR opredeliti osnovno funkcionalnost ter
tehnološke in druge nefunkcionalne zahteve in omejitve za izgradnjo želene IR.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 86 -
Opredelitev in namen
Zajem in specifikacija zahtev
Rezultat zajema in specifikacije zahtev je dokument, kjer so zabeležene vse funkcionalne in nefunkcionalne zahteve v zvezi z želeno IR.
V nadaljnjih korakih se dokument lahko uporablja: kot vhod v postopek analize, pri pripravi razpisne dokumentacije za nakup IR
oziroma izbiro zunanjega razvijalca, kot priloga k pogodbi med naročnikom in izvajalcem
sistema.RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 87 -
Končni izdelek e
Zajem in specifikacija zahtev
Zajem zahtev izvede sistemski analitik ob tesnem sodelovanju s poznavalci problemske domene oziroma ključnimi uporabniki.
Osnovni koraki zajema: Zajem zahtev, Ureditev zahtev in Potrditev zahtev.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 88 -
Vloge in koraki
Zajem in specifikacija zahtev
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 89 -
Postopek zajema in specifikacije zahtev
Razvoj po strukturnem pristopu
Postopki strukturnega pristopa: Zajem in specifikacija zahtev;
• Zajem zahtev,• Ureditev zahtev in• Potrditev zahtev
Analiza; Načrtovanje; Izvedba; Testiranje; Namestitev in uvedba.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 90 -
Kje smo?
Zajem in specifikacija zahtev
Obstajajo različne tehnike zajema zahtev: Razgovori Vprašalniki Opazovanje pri delu Analiza obstoječega sistema Skupinsko načrtovanje aplikacij
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 91 -
Zajem zahtev
Zajem in specifikacija zahtev
Splošni napotki za uspešno izvedbo zajema zahtev: Analitik mora biti objektiven, Analitik mora upoštevati vse možnosti v okviru
nekega problema, Analitik posveča pozornost podrobnostim, Analitik mora strmeti k novim in boljšim rešitvam, Analitik ne daje obljub uporabnikom, Analitik nima zadržkov pri zajemanju zahtev.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 92 -
Zajem zahtev
Razvoj po strukturnem pristopu
Postopki strukturnega pristopa: Zajem in specifikacija zahtev;
• Zajem zahtev,• Ureditev zahtev in• Potrditev zahtev
Analiza; Načrtovanje; Izvedba; Testiranje; Namestitev in uvedba.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 93 -
Kje smo?
Zajem in specifikacija zahtev
V aktivnosti ureditev zahtev skušamo naše razumevanje želene IR opredeliti še v okviru dokumenta, s katerim bodo zahteve IR podane bolj formalno in jedrnato.
Izdelek, ki nastane, imenujemo specifikacija zahtev.
Specifikacija zahtev lahko služi kot temeljna podlaga pri dogovarjanju med naročnikom in izvajalcem.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 94 -
Ureditev zahtev
Zajem in specifikacija zahtev
Specifikacija zahtev ima navadno naslednjo strukturo:
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 95 -
Specifikacija zahtev
1. Kratek opis namena IR ali njenega podsistema2. Opis funkcionalnih zahtev3. Opis nefunkcionalnih zahtev4. Opis vmesnikov5. Slovar izrazov
Zajem in specifikacija zahtev
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 96 -
Specifikacija zahtev
Funkcionalne zahteve so zahteve, ki se nanašajo na želeno funkcionalnost sistema.
Funkcionalne zahteve
Odjava iz izpitnega rokaSistem naj študentom omogoča odjavo iz izpitnega roka. Poslovna pravila:• Študent se ne more odjaviti iz izpitnega roka, če je do
roka še manj kot tri dni.• …
Zajem in specifikacija zahtev
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 97 -
Specifikacija zahtev
Nefunkcionalne zahteve so zahteve, ki se nanašajo na tehnične in druge nevsebinske zahteve sistema.
Nefunkcionalne zahteve
• Sistem naj bo narejen v tri-nivojski arhitekturi z lahkim odjemalcem.
• Podatki naj se hranijo v podatkovni bazi Oracle.• Za avtentikacijo nej se uporabi digitalno potrdilo.• Izdajatelj digitalnega potrdila je lahko CVI RS, NLB, PS.• …
Razvoj po strukturnem pristopu
Postopki strukturnega pristopa: Zajem in specifikacija zahtev;
• Zajem zahtev,• Ureditev zahtev in• Potrditev zahtev
Analiza; Načrtovanje; Izvedba; Testiranje; Namestitev in uvedba.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 98 -
Kje smo?
Zajem in specifikacija zahtev
Namen aktivnosti potrditev zahtev je predstavitev specifikacije zahtev naročniku in pridobitev soglasja o tem, da so zajete zahteve res to, kar si naročnik želi.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 99 -
Potrditev zahtev
Razvoj po strukturnem pristopu
Postopki strukturnega pristopa: Zajem in specifikacija zahtev; Analiza; Načrtovanje; Izvedba; Testiranje; Namestitev in uvedba Vzdrževanje.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 100 -
Kje smo?
Analiza
Glavni namen analize je izdelati razumljiv opis realnega sveta oziroma poslovnega okolja,na katerega se nanaša razvoj IS.
Izdelamo model sistema, ki na formalen način opredeli potrebne podatkovne strukture in funkcije, ki te podatke uporabljajo.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 101 -
Opredelitev in namen
Analiza
Analiza daje odgovor na vprašanje, KAJ naj IS podpira. Kaj se izvaja v poslovnih funkcijah in kakšne podatke te rabijo?
Analiza služi kot: sredstvo za definicijo zahtev, osnova za dogovor med naročnikom in izvajalcem osnova za kasnejše faze razvoja.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 102 -
Opredelitev in namen
Analiza
Rezultat analize je model sistema. Na osnovi modelov se v nadaljnjih korakih
izdela podatkovna baza ter potrebni programski moduli.
Poleg modela sistema v fazi analize izdelamo tudi predlog tehnične arhitekture sistema ter opcijsko prototipe komponent uporabniškega vmesnika.
Med izdelke analize sodi tudi strategija testiranja.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 103 -
Končni izdelek e
Analiza
Postopek analize izvajajo sistemski analitik, sistemski arhitekt in ključni uporabniki.
Postopek analize tipično zajema naslednje aktivnosti: Izdelava modela sistema; Izdelava prototipov; Izdelava predloga tehnične arhitekture sistema; Opredelitev strategije testiranja; Predstavitev rezultatov analize naročniku.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 104 -
Vloge in koraki
Analiza
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 105 -
Shema postopka
Razvoj po strukturnem pristopu
Postopki strukturnega pristopa: Zajem in specifikacija zahtev; Analiza
• Izdelava modela sistema;• Izdelava prototipov;• Izdelava predloga arhitekture sistema;• Opredelitev strategije testiranja;• Predstavitev rezultatov analize naročniku.;
Načrtovanje; Izvedba; Testiranje; Namestitev in uvedba.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 106 -
Kje smo?
Analiza
Modeliranje je uveljavljena inženirska tehnika na mnogih področjih: Gradbeništvo, Strojništvo, Kemija, Ekonomija, Sociologija, Računalništvo…
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 107 -
Splošno o modeliranju
Analiza
Modele razvijamo zato, da bi sisteme bolje razumeli.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 108 -
Splošno o modeliranju
Analiza
Model je poenostavitev realnosti, pri čemer je abstrakcija realnosti poljubno natančna.
Pomembno je, da model prikazuje pomembne elemente in izpušča tiste, ki nas ne zanimajo.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 109 -
Splošno o modeliranju
Analiza
Modeliranje prinaša naslednje bistvene prednosti: Omogoča vizualizacijo sistema, Prikazuje tako statične kot dinamične lastnosti
sistema, Predstavlja šablono za nadaljnjo gradnjo sistema, Dokumentira sprejete odločitve.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 110 -
Splošno o modeliranju
Analiza
Izbira modelov Za modeliranje sistema lahko izberemo različne
modele. Izbira modelov določa, kako bomo pristopili k
reševanju problema ter kako oblikovali rešitev. Modeli morajo podpirati izražanje na različnih ravneh
natančnosti. Najboljši modeli so tesno povezani z realnostjo. En sam model nikoli ni dovolj. Sistem je potrebno
modelirati iz različnih vidikov. Najboljši pristop je izbira nekaj modelov, ki kar najbolje pokrijejo najpomembnejše vidike sistema.
Metodologije razvoja IS predlagajo različne modele.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 111 -
Splošno o modeliranju
Analiza
Model, ki ga izdelamo v fazi analize po strukturnem pristopu, se v grobem deli na: Podatkovni model, Procesni model in Model procesne logike.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 112 -
Analiza po strukturnem pristopu
Model sistemaPodatkovni model
Procesni model
Model procesne logike
Analiza – Izdelava modela sistema
Podatkovni model: prikazuje sistem s podatkovnega vidika tako, da
opisuje podatkovne strukture, ki so potrebne za delovanje sistema. Poleg podatkovnih struktur zajema tudi vse povezave med njimi.
Procesni model: prikazuje sistem z vidika aktivnosti ali procesov, ki se
v sistemu izvajajo. Definirani so tokovi podatkov med procesi.
Model procesne logike: natančneje definira procese, definirane v procesnem
modelu.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 113 -
Izdelava modela sistema po strukturnem pristopu
Analiza – Izdelava modela sistema
Za predstavitev posameznih modelov sistema uporabljamo formalne, semi-formalne in tudi neformalne tehnike. Podatkovni model: diagram entiteta-razmerje Procesni model: procesni diagram, diagram
podatkovnih tokov, funkcionalna razgradnja Model procesne logike: naravni jezik, strukturiran
jezik, odločitvene tabele, odločitveni grafi, diagrami prehajanja stanj
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 114 -
Strukturne diagramske tehnike
Analiza – Izdelava modela sistema
Podatkovni model: Je eden izmed najpomembnejših
izdelkov faze analize in predstavlja vse podatkovne kategorije, za katere na nekem delovnem področju obstaja potreba, da se o njih podatki spremljajo, obdelujejo in hranijo.
V analizi izdelamo konceptualni podatkovni model.
Za izdelavo uporabljamo diagramsko tehniko entiteta-razmerje.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 115 -
Podatkovni model
Model sistemaPodatkovni model
Procesni model
Model procesne logike
Analiza – Izdelava modela sistema
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 116 -
Podatkovni model
svet mentalni model konceptualni model logični model PB
Analiza – Izdelava modela sist.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 117 -
Podatkovni model – primer
Konceptualni podatkovni modelPredmet
PredmetNazivDodatne obveznostiSemesterKreditne točke…
IzpitZap. št. polaganjaOcena pisnoOcena ustnoDatum ocene
ŠtudentVpisna številkaPriimekImeNaslovTelefonE-mailStatus…
DelavecDelavecPriimekImeE-mailGeslo…
PrijavaDatum prijaveDatum odjaveZap. št. polaganjaKolokvijLetnikPlača izpit…
RokRokDatum izpitaPrijavljenihMaks. prijavljenihMeja pozitivno…
V konceptualnem modelu lahko nastopajo tudi sestavljeni in večvrednostni atributi!
?
Analiza – Izdelava modela sistema
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 118 -
Podatkovni model – primer
Primer nerazumljivega podatkovnega modela
NAC_DEL
PRE_DEL
POTRDILO
ZAHTEVA
NACINPOSTA
STAT_IZPITA
IZPRASEVALEC
OBVESTILASTAT_POSSTAT_PR
NAC_IZV
PRIJAVA_U ROK_U
VRSTA_POT
ZAVOD
VSI
VRSTA_OC
VIP SMER
NAC_OC
VSI_F
VPIS
VIP_F
VAJE
STUDENT
SPP
SKUPINA
SKLEPI
ROK
PRIJAVA
PRE_PRE
PRED_PRPRED_OBC
PRED_IZB
PRED_DIFPRED_AT
PREDPOGPREDMET
PP
IZPIT
IZJEME
IZBIRNIEKVIVAL
DELNA_OC
DELAVEC
APP
a
a
a
a
a
a
aa
aa
a
a
a
a
a
a
a
a
a
a
a a
a
a
a
a
a
a
a
b
aa
aaaa
a
a
a
a
a
a
a
a
a
b
a
a
a
a
a
a
ab
a
a
a
a
a
b
a
b
ab
a
ab
b
a
a
bb
c
c
b
b
a
a
r r
a
a
a
a
a
a
aa
a
a
a
a
a
a
a
a
a
a
aa
a
aaa
a
a
a
a
a
a
a
a
a
a
a
a
a
a
aa
a
a
a
a
a
a
a
aa
a
a
a
a
a
a
a
a
a
aa
a a
a
aa
a
a
a a
aa
a
a
a
a
a
a
a
a
a
a
a
a
a
aa
a
a
a
a
a
a
a
a
Analiza – Izdelava modela sistema
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 119 -
Podatkovni model – primer
Entitetne tipe je potrebno dokumentirati Primer dokumentacije:
Naziv entitetnega tipa
Opis Sinonim Število entitet
Delavec Predstavlja pedagoškega delavca, ki je nosilec enega ali več predmetov
Pedagoški delavec
Vsaka katedra ima enega ali več pedagoških delavcev. Niso vsi delavci nosilci predmetov.
Rok Predstavlja datum, na katerega je za nek predmet in določeno ciljno skupino (letnik, smer,...) razpisan izpitni rok.
Rok, pisni izpit, kolokvij
Na leto se razpiše okrog 300 pisnih izpitov. Vsak predmet mora imeti vsaj tri roke letno
...
Analiza – Izdelava modela sistema
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 120 -
Podatkovni model – metoda načrtovanja
Možni koraki konceptualnega načrtovanja: K 1.1: Identificiraj entitetne tipe K 1.2: Identificiraj povezave K 1.3: Identificiraj in z entitetnimi tipi poveži atribute K 1.4: Atributom določi domene K 1.5: Določi kandidate za ključe; izmed kandidatov
izberi primarni ključ
K 1.6: Po potrebi uporabi elemente razširjenega diagrama
entiteta – razmerje K 1.7: Preveri, če v modelu obstajajo odvečni
elementi K 1.8: Preveri, če model “zdrži” transkacije K 1.9: Preveri model z uporabnikom
Analiza – Izdelava modela sistema V postopku identifikacije povezav smo
pazljivi na dvoumne in nepopolne povezave.
- 121 -
Primer dvoumne povezave
1..* 1..1 1..1 1..*Profesor Katedra Laboratorij
je član vključuje
Pr1
Pr2
Pr3
K1
K2
L1
L2
L3
Podatkovni model – metoda načrtovanja – identifikacija povezav
K 1.2
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
Analiza – Izdelava modela sistema Dvoumno povezavo odpravimo z
restrukturiranjem modela
- 122 -
Profesor Laboratorij Katedraje član vključuje
Pr1
Pr2
Pr3
L1
L2
K1
K2
K3
1..* 1..1 1..* 1.1
Podatkovni model – metoda načrtovanja – identifikacija povezav
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
Analiza – Izdelava modela sistema
- 123 -
Podatkovni model – metoda načrtovanja – Identifikacija povezav
Primer nepopolne povezave
1..1 1..* 0..1 0..*Katedra Član Oprema
ima je skrbnik
K1
K2
K3
Čl1
Čl2
O1
O2
O3Čl3
Kateri katedri pripada oprema O2?
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
Analiza – Izdelava modela sistema Odpravimo z prestrukturiranjem modela.
- 124 -
Podatkovni model – metoda načrtovanja – identifikacija povezav
1..1 1..* 0..1 0..*Katedra Član Oprema
ima je skrbnik
K1
K3
Čl1
Čl2
O1
O2
Čl3
1..1 1..*pripada
K2
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
Analiza – Izdelava modela sistema Identifikacija odvečnih povezav
Povezava je odvečna, če je možno priti do iste informacije prek drugih povezav!
Izdelati želimo minimalen podatkovni model odvečne povezave zato odstranimo.
Zgolj pregledovanje poti med entitetnimi tipi ne zadošča (povezave imajo lahko različen pomen)
- 125 -
Podatkovni model – metoda načrtovanja – odvečne povezave
K 1.7
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
Analiza – Izdelava modela sistema Ali je kakšna povezava odveč?
- 126 -
Podatkovni model – metoda načrtovanja – odvečne povezave
Profesor Katedraje predstojnik
1..1 0..1
Laboratorij
pripada
1..1
1..*je član
1..1
1..*
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
Analiza – Izdelava modela sistema Ali je kakšna povezava odveč?
- 127 -
Podatkovni model – metoda načrtovanja – odvečne povezave
Profesor Katedrapripada
1..* 1..1
Laboratorij
pripada
1..1
1..*je član
1..1
1..*
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
Analiza – Izdelava modela sistema Preveriti moramo, če model podpira vse
zahtevane transakcije. Transakcije izvajamo ročno Če neke transakcije ne uspemo izvesti, je model
pomanjkljiv (manjka bodisi entitetni tip, povezava ali atribut)
Možna dva pristopa: Preverjanje prek opisa transakcij Preverjanje prek transakcijskih poti
- 128 -
Podatkovni model – metoda načrtovanja – preverjanje transakcij
K 1.8
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
Analiza – Izdelava modela sistema Preverjanje prek opisa transakcij
Vsako transakcijo opišemo; Preverimo, če model zajema vse entitetne tipe,
povezave in atribute, ki jih transakcija potrebuje.
- 129 -
Podatkovni model – metoda načrtovanja – preverjanje prek opisa transakcij
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
Analiza – Izdelava modela sistema
Primer opisa transakcijskih zahtev Vnos podatkov:
• Vnesi podatke o študentih (npr. 24010637, Monika Jemec,...)
• Vnesi podatke o predmetih (npr. 70029, Razvoj IS, Letni,...)
• ... Urejanje in brisanje podatkov:
• Uredi/briši podatke o študentu• Uredi/briši podatke o predmetih• ...
Poizvedbe• Izpiši vse študente, ki so se vpisali v določen letnik,
določene smeri, določenega programa• Izpiši vse predmete, ki jih je opravil določen študent• ...
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 130 -
Podatkovni model – metoda načrtovanja – preverjanje prek opisa transakcij
Analiza – Izdelava modela sistema Preverjanje prek transakcijskih poti
Transakcije preverimo na modelu – pot transakcije narišemo
Pristop načrtovalcu omogoča: Da identificira pomanjkljivosti modela (če pot za neko
transakcijo ni možna) Da identificira dele modela, ki so transakcijsko kritični Da odkrije odvečne dele modela (deli, ki jih ne potrebuje
nobena transakcija)
- 131 -
Podatkovni model – metoda načrtovanja – preverjanje prek transakcijskih poti
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
Analiza – Izdelava modela sistema
- 132 -
Podatkovni model – metoda načrtovanja – preverjanje prek transakcijskih poti
Prijava PredmetpredID
SmersmerID
ProgramprogID
RokrokID
ŠtudentvpisSt
IzpitstPol
ima
0..11..1
se predava na1..*
1..*
za1..10..*
iz
1..1
0..*
se nanaša na1..10..*
pripada
1..1
0..*
je opravljal1..1 0..*
a) Izpiši vse predmete, ki jih je opravil določen študent b) Izpiši vse študente, ki so se vpisali v določen letnik, določene smeri,
določenega programa
a
?b
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
Analiza – Izdelava modela sistema
Procesni model: prikazuje sistem z vidika aktivnosti ali
procesov, ki se v sistemu izvajajo. V procesnem modelu lahko nastopajo tudi podatkovne strukture, ki jih procesi potrebujejo pri svojem delovanju.
Za izdelavo procesnega modela uporabimo dve diagramski tehniki: diagram razgradnje ter diagram podatkovnih tokov. Uporabimo lahko tudi procesni diagram.
- 133 -
Izdelava modela sistema – procesni model
Model sistemaPodatkovni model
Procesni model
Model procesne logike
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
Analiza – Izdelava modela sistema
Z diagramom funkcionalne razgradnje prikažemo hierarhijo funkcij, ki jih želimo s sistemom podpreti.
Hierarhijo funkcij lahko prikažemo na različne načine, najbolj običajno kot navpično hierarhijo.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 134 -
Procesni model – diagram funkcionalne razgradnje – opredelitev
Analiza – Izdelava modela sistema
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 135 -
Funkcija 1
Funkcija 1.1 Funkcija 1.2Funkcija
1.2.1
Funkcija 1.2.2
Funkcija 1.3
Procesni model – diagram funkcionalne razgradnje
Funkcija 1Funkcija 1.1
Funkcija 1.2
Funkcija 1.3
Funkcija 1
Funkcija 1.1
Funkcija 1.2
Funkcija 1.3
Funkcija 1Funkcija
1.1Funkcija
1.2Funkcija
1.3
Analiza – Izdelava modela sistema
Smernice za izdelavo diagramov funkcionalne razgradnje: Število nivojev in število enot na enem nivoju
običajno ni omejeno, čeprav velja priporočilo, naj ima vsak element največ devet podrejenih elementov.
Za vsako enoto velja, da ima nič, eno ali več podrejenih enot (vej) in da vedno pripada natanko eni nadrejeni enoti na prvem višjem nivoju.
Enote na istem nivoju razporedimo od leve proti desni po neki sekvenčni karakteristiki, ki jo natančno definiramo in k diagramu dokumentiramo.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 136 -
Procesni model – diagram funkcionalne razgradnje – smernice
Analiza – Izdelava modela sistema
Študijska Informatika (izpitna evidenca)
Vzdrževanje in
pregled izpitnih rokov
Elektronski indeks/
kartotečni list
Naročanje potrdil
Opravljanje pisnih izpitov
Prijava na izpit
Odjava iz izpita
Pregled števila prijavljenih kandidatov
Vnos rezultatov
Objava rezultatov
Opravljanje ustnih izpitov
Vpis končne ocene
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 137 -
Procesni model – diagram funkcionalne razgradnje - primer
Analiza – Izdelava modela sistema
Diagrame podatkovnih tokov (DFD) uporabimo za prikaz okolja, v katerem bo sistem deloval, ter za prikaz odvisnosti med procesi, ki jih bo sistem podprl.
DFD združuje podatkovni in procesni pogled na obravnavano področje.
DFD je uvedel Tom DeMarco leta 1978. Od takrat nastalo več različic DFD tehnike. Razlikujejo se predvsem v notaciji.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 138 -
Procesni model – diagram podatkovnih tokov – opredelitev
DFD – Data Flow Diagram
Analiza – Izdelava modela sistema
DFD sodi med enostavnejše diagramske tehnike.
Osnovni gradniki DFD so: Proces Tok podatkov Podatkovno skladišče Zunanja entiteta
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 139 -
Procesni model – diagram podatkovnih tokov – osnovni gradniki
Analiza – Izdelava modela sistema
Proces predstavlja množico aktivnosti, ki vhodne podatke pretvorijo v izhodne.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 140 -
Procesni model – diagram podatkovnih tokov – proces
Proces sistema
Notranja shramba podatkov
Zunanji prejemnik
Izhodnipodatki
Vhodnipodatki
Analiza – Izdelava modela sistema
Proces je generičen pojem in lahko predstavlja dogajanje na različnih ravneh (funkcija, proces, pod-proces, naloga, aktivnost ipd.)
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 141 -
Procesni model – diagram podatkovnih tokov – proces
Rave
n po
drob
nosti
Funkcionalna razgradnja
Proces
Analiza – Izdelava modela sistema
Vsakemu procesu je dodeljen naziv in številčna oznaka, ki se v diagramu vpišeta v grafični simbol procesa.
Za naziv procesa običajno uporabimo glagol, glagolski samostalnik ali zaporedje besed, ki opisujejo vrsto dejavnosti.
Številčna oznaka enolično določa proces.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 142 -
Procesni model – diagram podatkovnih tokov – proces
Prijava na izpit
1Vnos
končne ocene
2
Analiza – Izdelava modela sistema
Tok podatkov predstavlja množico vhodnih ali izhodnih podatkov, ki imajo enolično definirano vsebino in strukturo.
Podatki lahko predstavljajo: elementarne podatke (npr. ime, priimek, vpisna
številka,...) dokumente (vpisni list, kartotečni list,…) elektronske dokumente (elektronski indeks,…)
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 143 -
Procesni model – diagram podatkovnih tokov – tok podatkov
Analiza – Izdelava modela sistema
Vsakemu toku podatkov določimo naziv, ki pove kaj tok prenaša.
Nazivi so samostalniki, običajno v ednini, ali pa kombinacija samostalnika in pridevnika
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 144 -
Procesni model – diagram podatkovnih tokov – tok podatkov
Vnos končne ocene
2Izpitni rok
Prijava
Izpit
Podatki o izpitnem roku
ID prijave
Ocena pisno,Ocena ustno
Podatki o preteklih
polaganjih
Analiza – Izdelava modela sistema
Podatkovni tok se lahko giblje: iz zunanje entitete v proces ali iz procesa k zunanji
entiteti, iz procesa v drug proces in iz procesa v skladišče podatkov ali obratno.
Podatkovni tok ne more povezovati zunanje entitete s skladiščem podatkov!
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 145 -
Procesni model – diagram podatkovnih tokov – tok podatkov
Analiza – Izdelava modela sistema
Podatkovna shramba predstavlja prostor, kamor procesi shranjujejo podatke za druge procese ali kasnejšo uporabo.
Podatkovna shramba je lahko enostavna (npr. zajema le elementarne podatke) ali kompleksna (npr. predstavlja celo zbirko podatkov).
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 146 -
Procesni model – diagram podatkovnih tokov – podatkovna shramba
Podatkovna baza
Izpit
Analiza – Izdelava modela sistema
V fazi analize s podatkovno shrambo opišemo logične sklope podatkov neodvisno od bodoče fizične organizacija podatkov.
Naziv podatkovne shrambe je največkrat enak nazivu vhodnih podatkovnih tokov (skladišče je pravzaprav podatkovni tok v mirovanju)
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 147 -
Procesni model – diagram podatkovnih tokov – podatkovna shramba
Vnos izpitnega
roka
2Izpitni rok
Podatki o izpitnem roku
Analiza – Izdelava modela sistema
V vsako shrambo mora pisati vsaj en proces, sicer je shramba odveč!
Velja logično pravilo, da iz shrambe ni mogoče brati podatkov, ki niso bili vanj zapisani.
Shramba je interna podatkovna struktura, zato dostop do nje ni omogočen zunanjim entitetam!
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 148 -
Procesni model – diagram podatkovnih tokov – podatkovna shramba
Analiza – Izdelava modela sistema
Povezava med podatkovnim in procesnim modelom: Eden od načinov uporabe DFD je, da najprej
izdelamo podatkovni model, potem pa z DFD pokažemo, kako se podatki med procesi prenašajo.
Podatkovna shramba tedaj ustreza enemu ali več entitetnim tipom iz podatkovnega modela.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 149 -
Procesni model – diagram podatkovnih tokov – podatkovna shramba
Analiza – Izdelava modela sistema
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 150 -
Procesni model – diagram podatkovnih tokov – podatkovna shrambaProcesni m
odelPodatkovni m
odel
Analiza – Izdelava modela sistema
Zunanje entitete predstavljajo zunanje procese ali zunanje sisteme.
Nahajajo se izven interesnega področja analize.
Ne zanima nas njihova struktura ali obnašanje, pač pa le podatkovni tokovi, ki se prenašajo med obravnavanim področjem in njimi.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 151 -
Procesni model – diagram podatkovnih tokov – zunanja entiteta
Analiza – Izdelava modela sistema
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 152 -
Procesni model – diagram podatkovnih tokov – zunanja entiteta
Vnos končne ocene
2Izpitni rok
Prijava
Izpit
Podatki o izpitnem roku
ID prijave
Ocena pisno,Ocena ustno
Podatki o preteklih
polaganjih
Študent
indeks
Analiza uspešnosti generacije
3Univerza v Ljubljani
Poročila o uspešnosti generacije
Podatki o izpitih
Analiza – Izdelava modela sistema
V analizi pogosto identificiramo večje število procesov.
Predstavitev vseh procesov enem diagramu je nepregledna, sama vsebina pa nerazumljiva.
Zato uporabljamo razčlenjevanje. Diagrame rišemo od “vrha navzdol”: Začnemo z najvišjo ravnjo, kjer nastopajo obsežnejši
procesi, nadaljujemo do najnižje ravni, kjer nastopajo zelo
podrobni procesi.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 153 -
Procesni model – diagram podatkovnih tokov – način risanja DFD
Analiza – Izdelava modela sistema
Razčlenjevanje: Za vsak proces, ki je predstavljen v DFD na višji
ravni, izdelamo poseben DFD, kjer proces razbijemo na pod-procese.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 154 -
Procesni model – diagram podatkovnih tokov – način risanja DFD
Analiza – Izdelava modela sistema
Kontekstni diagram: razčlenjevanje DFD začnemo na najvišji ravni, kjer
nastopa en sam proces – korenski proces.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 155 -
Procesni model – diagram podatkovnih tokov – način risanja DFD
kontekst sistema
KOTEKSTNI DIAGRAM
korenski proces
Analiza – Izdelava modela sistema
Značilnosti kontekstnega diagrama: Kontekstni diagram prikazuje kontekst sistema –
sistem v sodelovanju z okoljem. Kontekstni diagram ima en sam proces – korenski
proces. Kontekstni diagram nima podatkovnih shramb.
Shrambe so namenjene odlagališču podatkov pri prenosu le-teh med procesi. Podatkovna shramba je del sistema!
Podatkovni tokovi med korenskim procesom in zunanjimi entitetami opredeljujejo vmesnike med sistemom in okoljem.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 156 -
Procesni model – diagram podatkovnih tokov – način risanja DFD
Analiza – Izdelava modela sistema
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 157 -
Procesni model – diagram podatkovnih tokov – primer kontekstnega diagrama
e-študent
0
Študent
Univerza v Ljubljani
MŠŠ
Vpisna prijavno-
informacijska služba
Računovodstvo FRI
Podatkovni tokovi brez nazivov ne povedo skoraj nič!!
Analiza – Izdelava modela sistema
Prvi nivo diagrama podatkovnih tokov Prvi nivo razčlenitve kontekstnega diagrama
predstavlja DFD na hierarhičnem nivoju 1. DFD na prvem hierarhičnem nivoju prikažemo z eno
sliko, kjer korenski proces razčlenimo na potrebno število pod-procesov (priporočljivo do 9).
Pri razčlenjevanju procesa je potrebno ohraniti vso funkcionalnost: vsota funkcionalnosti vseh podrejenih procesov je enaka funkcionalnosti nadrejenega procesa.
Potrebno je zagotoviti, da so evidentirani procesi približno enakovredni oziroma uravnoteženi.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 158 -
Procesni model – diagram podatkovnih tokov – način risanja DFD
Analiza – Izdelava modela sistema
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 159 -
Procesni model – diagram podatkovnih tokov – kontekstni diagram
Izpitna evidenca
0.1
Diplome
0.2
Vpis
0.3
Podatki o polaganjih
Roki, prijave,Izpiti, ocene
Podatki o diplomah
Teme, ocene
diplom,
kandidati za
diplome,
mentorji
Povprečne ocene
Študent
Univerza v Ljubljani
MŠŠ
Vpisna prijavno-
informacijska služba
Računovodstvo FRI
Osebni podatki,indeks
Podatki za vpis
Poda
tki o
pla
čilih
izp
itov
Podatki o plačilih vpisnine
Sumarni podatki za
podatkovno skladišče
Sumarni podatki za podatkovno skladišče
Sumarni podatki za
podatkovno skladišče Kandidati
za vpis
Omejitev vpisa
Vpisna evidencaVpisni
podatkiVpisni podatki
Napačna raba shrambe
Analiza – Izdelava modela sistema
Kako podrobno razčlenjujemo DFD? Razčlenjevanje je smiselno do nivoja procesov, pri
katerih ugotovimo, da je težko definirati shrambe podatkov, ki povezujejo njihove pod-procese. Na tem nivoju se procesi povezujejo neposredno s podatkovnimi tokovi.
Ta pogoj je vedno izpolnjen na nivoju elementarnih procesov, ki jih lahko opišemo z zaporedjem korakov.
Za opis procesov na najnižji ravni DFD tehnika ni primerna, ker ne prikazuje zaporedja. Uporablja se druge tehnike, ki so del modeliranja procesne logike.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 160 -
Procesni model – diagram podatkovnih tokov – način risanja DFD
Analiza – Izdelava modela sistema
Procesni diagram uporabimo, ko želimo prikazati tok dogodkov ali potek določenega procesa.
Za modeliranje procesov obstajajo številne tehnike, ki se razlikujejo predvsem po številu gradnikov ter notaciji.
Diagrami eEPC spadajo med eno popularnejših tehnik modeliranja poslovnih procesov.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 161 -
Procesni model – procesni diagram
eEPC – Extended Event-Driven Process Chain
Analiza – Izdelava modela sistema
Tipični gradniki procesnih diagramov: Dogodek Aktivnost Krmilni tok Operator Vloga Aplikacija Informacijski objekt
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 162 -
Procesni model – procesni diagram
Analiza – Izdelava modela sistema
Dogodek: vsaka aktivnost procesa ima praviloma vhodni in
izhodni dogodek. Vhodni dogodek se zgodi ob določenem trenutku, ko
je izpolnjen nek pogoj in ima za posledico začetek izvajanja neke aktivnosti.
Ko se aktivnost izvede, lahko rezultat vpliva na izhodni dogodek.
Primeri dogodkov so: prijava zaključena, izpitni rok vnesen, ocena vpisana, prijava zavrnjena ipd.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 163 -
Procesni model – procesni diagram
Prijava zaključena
Ocena vpisana
Analiza – Izdelava modela sistema
Aktivnost: aktivnost je najmanjša enota poslovnega procesa. Pomeni zaokroženo celoto procesiranja. Primeri aktivnosti: razpis ustnega roka, prijava na
izpit, vnos končne ocene, odjava iz izpita ipd. Aktivnost lahko poteka v sodelovanju z uporabnikom
ali popolnoma avtomatsko.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 164 -
Procesni model – procesni diagram
Razpis ustnega
roka
Vnos končne ocene
Analiza – Izdelava modela sistema
Krmilni tok krmilni oziroma kontrolni tok v obliki puščice
nakazuje zaporedje dogodkov in aktivnosti v modeliranemu procesu.
Kontrolni tok lahko razumemo kot nosilec kontrolnih podatkov in drugih pomembnih podatkov za izvajanje procesa.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 165 -
Procesni model – procesni diagram
Analiza – Izdelava modela sistema
Operator Operator predstavlja mesto razdruževanja
kontrolnega toka ali združitve iz več kontrolnih tokov v enega.
Na nekem mestu v modeliranem procesu se lahko kontrolni tok, ki izhaja iz aktivnosti ali dogodka, razdruži v več tokov, ki vodijo naprej do dogodkov ali aktivnosti.
Obratno se lahko kontrolni tokovi, ki izhajajo iz več aktivnosti ali dogodkov, združijo v en kontrolni tok, ki vodi do dogodka ali aktivnosti. Operatorji so AND, OR, XOR.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 166 -
Procesni model – procesni diagram
AND
Analiza – Izdelava modela sistema
Vloga Vloga predstavlja subjekt, ki aktivnost izvaja oz. je
zanjo odgovoren (posameznik, skupina ljudi, organizacijska enota, ipd.)
Aplikacija Predstavlja informacijsko rešitev, ki podpira izvajanje
neke aktivnosti. Informacijski objekt
Predstavlja nosilec podatkov, ki bodisi vstopa kot vhod v aktivnost ali v obliki izhoda iz nje izstopa.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 167 -
Procesni model – procesni diagram
Analiza – Izdelava modela sistema
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 168 -
Procesni model – procesni diagram – primer
Priprava razpisa
Obvestilo ULJ o
razpisu
Razpis pripravljen
Objavarazpisa
Razpis objavljen
Zbiranje prijav
Razpis zaključen
Izbira kandidatov
Kandidati določeni
AND
Priprava podatkov
za ULJ
Priprava podatkov
za KŠZ
Podatki pripravljeni
SejaKŠZ
Podatki pripravljeni
Kandidati zavrnjeni
Kandidati potrjeni
XOR
AND
Obvestilo ULJ o izboru
Obvestilo kandidatov
o izboru
Izbira kandidatov za mednarodne izmenjave
Analiza – Izdelava modela sistema
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 169 -
Procesni model – procesni diagram – primer – dodatni gradniki
Izbira kandidatov za mednarodne izmenjave
Kandidati določeni
AND
Priprava podatkov
za ULJ
Priprava podatkov
za KŠZ
Podatki pripravljeni
SejaKŠZ
Podatki pripravljeni
Izbira kandidatov
Seznam za KŠZ
IR za izbiro kandidatov
S/Ekoordinator
Seznam za ULJ
S/Ekoordinator
KŠZ
MS Excel
Analiza – Izdelava modela sistema
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 170 -
Procesni model – procesni diagram – primer – steze
Izbira kandidatov za mednarodne izmenjave
ULJ S/Ekoordinator
KŠZ
Izdaja obvestila o razpisu
Priprava razpisa
Objava razpisa
Obvestilo ULJ o
razpisu
Razpis pripravljen
Razpis objavljen
Zbiranje prijav
Podatki pripravljeni
SejaKŠZ
Analiza – Izdelava modela sistema
Model procesne logike: Dopolnjuje procesni model. Osredotoči se na tiste procese, ki v
procesnem modelu niso dovolj jasno opisani: zaporedje korakov, kompleksne odločitvene situacije.
Model procesne logike izdelamo s pomočjo diagramskih tehnik, kot so: strukturiran jezik, odločitvene tabele, odločitvena drevesa, diagrami prehajanja stanj idr.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 171 -
Izdelava modela sistema – model procesne logike
Model sistemaPodatkovni model
Procesni model
Model procesne logike
Analiza – Izdelava modela sistema
Najpreprostejši način opisa procesne logike je z naravnim jezikom.
Strukturiran jezik je oblika naravnega jezika: kjer so opisi kratki in jedrnati stavki, sestavljeni iz
glagolskih in samostalniških oblik naravnega jezika. kjer ne uporabljamo drugih besednih oblik, npr.
pridevnikov, prislovov itd. kjer pišemo z zamiki, da poudarimo strukturo
posameznih delov opisa.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 172 -
Model procesne logike – strukturiran jezik
Analiza – Izdelava modela sistema
Primer opisa: Vnos diplomske teme
Izberi študijski program //izpišejo se vsi študijski programiIzberi študenta //izpišejo se vsi kandidati, ki so pri mentorju dvignili temoVnesi naslov temeVnesi opis temePotrdi ali prekliči temo //če uporabnik vnosa ne potrdi, se podatki ne zabeležijo//prikaži opcije za vnos/spreminjanje/izpis tem diplomskih
nalog
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 173 -
Model procesne logike – strukturiran jezik – primer
Analiza – Izdelava modela sistema
Odločitvene tabele in odločitvena drevesa uporabimo pri modeliranju zapletenejše procesne logike.
Tehniki sta primerni predvsem, ko v procesni logiki nastopa veliko pogojev, ki v različnih kombinacijah sprožajo različne akcije.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 174 -
Model procesne logike – odločitvene tabele in drevesa
Analiza – Izdelava modela sistema
Zgradba odločitvene tabele: v zgornjem delu prikazuje pogoje, ki nastopajo v
procesu ter vrednosti, ki jih ti pogoji lahko zavzamejo. Posameznim kombinacijam vrednosti pogojev pravimo pravilo.
v spodnjem delu tabele so navedene akcije, ki se morajo izvesti ob določenem pravilu.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 175 -
Model procesne logike – odločitvene tabele
Analiza – Izdelava modela sistema
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 176 -
Model procesne logike – odločitvene tabele
Pravilo 1 Pravilo 2 … Pravilo pPogoj 1 V(p1) V(p1) … V(p1)Pogoj 2 V(p2) V(p2) … V(p2)… … … … …Pogoj n V(pn) V(pn) V(pn)Akcija 1 D/N D/N … D/NAkcija 2 D/N D/N … D/N… … … … …Akcija m D/N D/N … D/N
Pravilo – kombinacija vrednosti pogojev.
Akcije, ki jih izvedemo, če velja pravilo p.
Vrednost pogoja 2v pravilu p
Analiza – Izdelava modela sistema
Pravila v odločitveni tabeli predstavljajo kombinacije vrednosti, ki jih posamezni pogoji lahko zavzamejo.
Število pravil:
zv: zaloga vrednosti n: število pogojev
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 177 -
Model procesne logike – odločitvene tabele
Primer:p1 = Pogoj 1: status vpisap2 = Pogoj 2: letnik
p1 = {redno, izredno, ponavlja, pavzira}zv(p1) = 4
p2 = {1, 2, 3, 4, 5, ABS}zv(p2) = 6
Število pravil = 4 * 6 = 24
Prijava na izpitni rok
Analiza – Izdelava modela sistema
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 178 -
Model procesne logike – odločitvene tabele – primer
Pravila
Pogoji
Izpitni rok razpisan D D D D D D D N
Dovoljen pristop k izpitu D D D D D D D N
Pravočasna prijava D D D D D D N N
Izpolnjeni vsi predpogoji D D D D D N D D
Število zaporednih polaganj presega 3 N N N D D N N N
Prvo polaganje v izpitnem obdobju D N N D N D D D
Drugo polaganje v jesenskem obdobju N D N N D N N N
Četrto polaganje v šolskem letu N N N N D N N N
Akcije
Sprejmi prijavo × × ×
Zavrni prijavo × × × × ×
Sestavi komisijo ×
Izdaj plačilni nalog ×
Analiza – Izdelava modela sistema
Zgradba odločitvenega drevesa: Odločitveno drevo je sestavljeno iz vozlišč ter
povezav med njimi. Vozlišča predstavljajo pogoje, povezave med njimi pa
možne vrednosti posameznih pogojev. Posamezna pot v drevesu, od korena do
predzadnjega vozlišča, predstavlja kombinacijo pogojev ali pravilo.
List drevesa, ki je na koncu poti, prikazuje seznam akcij pravila.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 179 -
Model procesne logike – odločitvena drevesa
Analiza – Izdelava modela sistema
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 180 -
Model procesne logike – odločitvena drevesa
Pogoj p1
Pogoj p2
A {a1, a2, …, an} A {a1, a2, …, an}
V(p 1) p 1
V(p1) p1
V(p1 ) p
1
A {a1, a2, …, an} A {a1, a2, …, an}
V(p 2)
p 2 V(p2 ) p
2
Pot od korena do lista: pravilo
List: seznam akcij pravila
Analiza – Izdelava modela sistema
Sestavljanje odločitvenega drevesa: Odločitveno drevo rišemo iz leve v desno. Začnemo s prvim vozliščem, v katerega vpišemo prvi
pogoj. Glede na zalogo vrednosti, ki jo pogoj ima, narišemo
iz vozlišča ustrezno število puščic. Na konec vsake puščice narišemo novo vozlišče, ki
predstavlja naslednji pogoj. Če gre za list, vpišemo seznam akcij, ki se izvedejo ob pravilu.
Če ugotovimo, da na koncu določenih poti ni nobenih akcij, lahko te poti brišemo iz drevesa.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 181 -
Model procesne logike – odločitvena drevesa
Analiza – Izdelava modela sistema
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 182 -
Model procesne logike – odločitvena drevesa – primer
Izpitni rok razpisan?
NZavrni prijavo:
Rok ne obstaja!
Dovoljen pristop k izpitu?Zavrni prijavo:
Nima dovoljenja za opravljanje izpita!
Pravočasna prijava?Zavrni prijavo:
Prijava ni bila oddana pravočasno!
Predpogoji izpolnjeni?Zavrni prijavo:
Predpogoji niso izpolnjeni!
Prvo polaganje v izpitnem obdobju?
Analiza – Izdelava modela sistema
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 183 -
Model procesne logike – odločitvena drevesa – primer
Prvo polaganje v izpitnem obdobju?
D Je skupno število polaganj > 3?Komisijski izpit:* sestavi komisijo
* izdaj plačilni nalog* sprejmi prijavoSprejmi prijavo
Je to jesensko obdobje?Je skupno število polaganj > 3Komisijski izpit:
* sestavi komisijo* izdaj plačilni nalog
* sprejmi prijavoSprejmi prijavo
Zavrni prijavo:Že opravljal v zimskem/letnem obdobju!
Diagramske tehnike
Z diagramom prehajanja stanj prikažemo stanja, v katerih se lahko nahaja opazovan proces ter odzive oziroma prehajanja med stanji kot odziv na različne dogodke.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 184 -
Model procesne logike – diagram prehajanja stanj
Stanje S1
Stanje S2
d0 /a
0
Začetno stanje
Končno stanje
d1/a1
dk /a
k
di/ai
{d0, d1, di, dk}: dogodki{a0, a1, ai, ak}: akcije
Diagramske tehnike
Glavni gradniki diagrama prehajanja stanj: Stanje Dogodek Akcija
Stanje: Z vidika dogajanja v sistemu se lahko proces nahaja
v različnih stanjih. Stanja so določena z vrednostjo lastnosti, ki nas v
okviru dogajanja procesa zanimajo. Proces se nahaja v določenem stanju vse dokler se
katera izmed opazovanih vrednosti ne spremeni. Tedaj nastopi novo stanje.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 185 -
Model procesne logike – diagram prehajanja stanj
Diagramske tehnike
Dogodek: Prehajanja med stanji povzročajo dogodki. Dogodek vpliva na spremembo ene ali več
opazovanih lastnosti procesa. Z vidika prehajanja med stanji je dogodek nekaj, kar
se pripeti v določenem trenutku in nima časovne razsežnosti.
Akcija: Ob dogodku se lahko zgodijo različne akcije. Kot dogodki tudi akcije niso časovno trajajoče;
zgodijo se v trenutku.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 186 -
Model procesne logike – diagram prehajanja stanj
Diagramske tehnike
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 187 -
Model procesne logike – diagram prehajanja stanj – primer – prikaz z grafom
Ponavljalec
Pavzer
Pogoji za napredovanje niso izpolnjeni /[Ponoven vpis v letnik]
Pogoji za napredovanje so
izpolnjeni /[Vpis v višji letnik
omogočen]
Pogoji za napredovanje niso izpolnjeni /[Odvzem statusa
študenta]
Redno vpisan
Pogoji za napredovanje so
izpolnjeni /[Vpis v višji letnik
omogočen]
Pogoji za napredovanje niso izpolnjeni, število ponovnih vpisov > 1 /
[Odvzem statusa študenta]
Pogoji za napredovanje so
izpolnjeni /[Vpis v višji letnik
omogočen]
Status študenta
Diagramske tehnike
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 188 -
Model procesne logike – diagram prehajanja stanj – primer – prikaz s tabelo
Status študenta
Dogodek Stanje
Redno vpisanS1
Ponovno vpisanS2
PavzerS3
Pogoji za napredovanje so
izpolnjeni
S1 /[Vpis v višji letnik
omogočen]
S1 /[Vpis v višji letnik
omogočen]
S1 /[Vpis v višji letnik
omogočen]
Pogoji za napredovanje niso
izpolnjeni S2 /
[Ponoven vpis s letnik]S3 /
[Odvzem statusa študenta]
Pogoji za napredovanje niso izpolnjeni, število
ponovnih vpisov > 1
S3 /[Odvzem statusa
študenta]
Vaja
Za opisan problem želimo izdelati informacijsko rešitev. Izdelaj model sistema, ki bo problemsko domeno kar najbolje opisal.
Izbiraš lahko med poljubnimi diagramskimi tehnikami.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 189 -
Vaja – rešitev
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 190 -
Podatkovni model
Strankasifra strankeimepriimekstevilka OD
Hotelski Gostdatum nastanitvedatum odjave
Sobasifra sobestevilo lezisczasedenododatne lastnosti
Tip Sobesifra tipa sobeopis
Hotelska Uslugakolicinacena
Tip Hotelske Uslugesifra tipa hotelske uslugeopisenotacena
Racunletosifra racunadatum
Hotelski Usluzbenecsifra hotelskega usluzbencaimepriimeknaslovtel
Tip Nastanitvesifra tipa nastanitveopis nastanitve
Poraba minibaradatum porabekolicina porabe
Statussifra statusaopis statusa
PritozbaStevilka pritozbeOpis pritozbe
Hotelska stranka
Navadnastranka
Hotelskigost
Vaja – rešitev
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 191 -
Status stranke – frekvenca bivanja v hoteluPrvič v hotelu?
Da
NOV GOST
Je bil v hotelu že več kot dva krat?
Gre vedno za isto sezono?
SEZONSKI GOST
REDNI GOST
?
Manjka status!Predlog: Navaden gost.
Slabo poimenovanje: sezonski gost je tudi redni gost!Predlog: redni gost letni gost.
Vaja – rešitev
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 192 -
Status stranke – posebni statusi
Status <> NOV GOST
AND
Ne
Da
AND
Ali se je kdaj
pritožil?
Ali spadamed 10%najdono-snejših?
Ima posebne potrebe?
Je znana oseba?
OBČUTLJIV GOST
SUPER GOST
POSEBEN GOST
POMEMBEN GOST
Posebni statusi
Razvoj po strukturnem pristopu
Postopki strukturnega pristopa: Zajem in specifikacija zahtev; Analiza
• Izdelava modela sistema;• Izdelava prototipov;• Izdelava predloga arhitekture sistema;• Opredelitev strategije testiranja;• Predstavitev rezultatov analize naročniku.;
Načrtovanje; Izvedba; Testiranje; Namestitev in uvedba.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 193 -
Kje smo?
Analiza – Izdelava prototipov
Izdelava prototipov je neobvezna v okviru analize učinkovito sredstvo za prikaz izgleda
ter osnovne funkcionalnosti uporabniškega vmesnika.
Razvita posebna razvojna okolja, ki omogočajo vizualno sestavljanje zaslonskih mask, izpisov in poizvedb ter vsebujejo mehanizme za avtomatsko generiranje kode.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 194 -
Izdelava prototipov v okviru analize
Analiza – Izdelava prototipov
Prototipi se navadno uporabljajo le kot del specifikacije sistema, za pridobitev jasnejše podobe bodočega sistema in se v nadaljevanju zavržejo.
Obstajajo tudi metode, ki tako izdelane prototipe izkoristijo kot osnovo za izdelavo produkcijskega sistema (Rapid Application Development – RAD).
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 195 -
Izdelava prototipov v okviru analize
Analiza – Izdelava prototipov
Nekaj primerov orodij za izdelavo prototipov: Vizualna razvojna okolja: npr. Delphi; Risarska orodja: npr. MS Visio; CASE orodja: npr. Oracle Designer.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 196 -
Izdelava prototipov v okviru analize
Analiza – Izdelava prototipov
Primer
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 197 -
Izdelava prototipov v okviru analize – Primer MS Visio
Analiza – Izdelava prototipov
Primer
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 198 -
Izdelava prototipov v okviru analize – Primer Delphi
Razvoj po strukturnem pristopu
Postopki strukturnega pristopa: Zajem in specifikacija zahtev; Analiza
• Izdelava modela sistema;• Izdelava prototipov;• Izdelava predloga arhitekture sistema;• Opredelitev strategije testiranja;• Predstavitev rezultatov analize naročniku.;
Načrtovanje; Izvedba; Testiranje; Namestitev in uvedba.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 199 -
Kje smo?
Analiza – Predlog tehnične arhitekture V okviru analize ne analiziramo zgolj
funkcionalnih zahtev, temveč tudi tehnične in druge nefunkcionalne zahteve.
Na osnovi tega podamo predlog tehnične arhitekture sistema.
Upoštevamo tudi strategijo podjetja oziroma standarde, ki so v podjetju določeni za celoten informacijski sistem.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 200 -
Izdelava predloga tehnične arhitekture
Analiza – Predlog tehnične arhitekture V okviru predloga tehnične arhitekture
sistema opredelimo strojno, komunikacijsko in programsko opremo, ki je potrebna za vzpostavitev ustreznega razvojnega, testnega in produkcijskega okolja.
V fazi analize navadno izdelamo le predlog, ki služi kot eden pomembnih virov za oceno stroškov razvoja oziroma nakupa IR.
Upoštevati moramo standarde in predpise, ki so določeni za posamezna področja.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 201 -
Izdelava predloga tehnične arhitekture
Analiza – Predlog tehnične arhitekture
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 202 -
Izdelava predloga tehnične arhitekture – vsebina
1. Arhitektura sistema1.1 Strojna oprema1.2 Sistemska programska oprema1.3 Komunikacijska oprema 1.4 Druga oprema1.5 Postavitveni diagram (opcijsko)
2. Postopki, predpisi in standardi2.1 Zagotavljanje varnosti2.2 Varnostne kopije (Backup)2.3 Vzpostavitev sistema (Recovery)2.4 Obravnava napak
Razvoj po strukturnem pristopu
Postopki strukturnega pristopa: Zajem in specifikacija zahtev; Analiza
• Izdelava modela sistema;• Izdelava prototipov;• Izdelava predloga arhitekture sistema;• Opredelitev strategije testiranja;• Predstavitev rezultatov analize naročniku.;
Načrtovanje; Izvedba; Testiranje; Namestitev in uvedba.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 203 -
Kje smo?
Analiza – Opredelitev strategije testiranja Način testiranja je s standardi kakovosti
podrobno določen. Njegova izvedba vseeno odvisna od vrste projekta.
V okviru opredelitve strategije testiranja se odločimo: Kaj je predmet testiranja? Npr. programske enote,
programski sklopi, integracija, tehnične zahteve… Kdo bo izvajal testiranje, kje in kako bo testiranje
potekalo? Npr. teste programskih enot izvajajo programerji sami v okviru razvojnega okolja.
Kje bo nameščeno testno okolje (pri izvajalcu ali pri uporabniku)?
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 204 -
Strategija testiranja
Analiza – Opredelitev strategije testiranja Opredelitev strategije testiranja
(nadaljevanje): Na kakšni strojni opremi bo nameščeno testno
okolje? V kateri točki projekta se bo namestilo testno okolje? Bo testiranje v testnem okolju potekalo v več
iteracijah ali v celoti? Kakšna orodja se bo uporabljalo za pripravo testov? Kakšna orodja se bo uporabljalo za izvajanje testov? …
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 205 -
Strategija testiranja
Analiza – Opredelitev strategije testiranja
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 206 -
Strategija testiranja – prva aktivnost v okviru postopka testiranja
Razvoj po strukturnem pristopu
Postopki strukturnega pristopa: Zajem in specifikacija zahtev; Analiza
• Izdelava modela sistema;• Izdelava prototipov;• Izdelava predloga arhitekture sistema;• Opredelitev strategije testiranja;• Predstavitev rezultatov analize naročniku;
Načrtovanje; Izvedba; Testiranje; Namestitev in uvedba.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 207 -
Kje smo?
Analiza – Predstavitev rezultatov
Ko izdelamo vse izdelke, ki jih predvideva faza analize, pripravimo predstavitev za naročnika.
Osnovni namen predstavitve je pridobitev potrdila s strani naročnika o pravilnosti razumevanja problema, ki ga rešujemo z IR.
Potrebno upoštevati, da naročnik morda nima strokovnih znanj za poglobljeno razumevanje rezultatov analize; predstavitev mora biti temu primerna. RAZVOJ INFORMACIJSKIH SISTEMOV
Visokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 208 -
Predstavitev rezultatov analize uporabniku
Analiza – Predstavitev rezultatov
Predstavitev se zaključi s potrditvijo naročnika, da rezultati analize ustrezajo zahtevam.
Potrditev se izvede s podpisom dokumenta, ki pogosto predstavlja eno izmed kontrolnih točk v okviru projektnega vodenja.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 209 -
Predstavitev rezultatov analize uporabniku
Razvoj po strukturnem pristopu
Postopki strukturnega pristopa: Zajem in specifikacija zahtev; Analiza Načrtovanje; Izvedba; Testiranje; Namestitev in uvedba.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 210 -
Kje smo?
Načrtovanje
Glavni namen načrtovanja je izdelati načrt zgradbe sistema glede na specifikacije, ki so bile zbrane v fazi analize.
Načrt daje odgovor na vprašanje, KAKO izdelatisistem, da bo ustrezal zahtevam, ki smo jihevidentirali v fazi analize.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 211 -
Opredelitev in namen
Načrtovanje
Cilji načrtovanja so: Izdelati načrt IR, ki ustreza ugotovitvam iz analize in
upošteva tehnološke omejitve sistema; Dokumentirati specifikacije načrta na način, ki bo
omogočal vzdrževanje sistema; Zasnovati strategijo prehoda iz obstoječe na novo
aplikacijo.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 212 -
Cilji načrtovanja
Načrtovanje
Osnovna rezultata načrtovanja sta načrt podatkovne baze in načrt programskih modulov, s katerima pripravimo vse potrebno za izdelavo podatkovnih in programskih komponent IR.
V fazi načrtovanja izdelamo tudi: načrt dokumentacije, načrt testiranja in načrt namestitve in uvedbe.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 213 -
Končni izdelek e
Načrtovanje
Pri načrtovanju sodelujejo načrtovalec podatkovne baze, načrtovalec aplikacije, skrbnik podatkovne baze, izdelovalec dokumentacije, uvajalec, poslovni lastnik in končni uporabnik.
Tipične aktivnosti načrtovanja so: Izdelava načrta podatkovne baze, Izdelava načrta programskih modulov, Izdelava načrta dokumentacije, Izdelava načrta testiranja, Izdelava načrta namestitve in uvedbe in Predstavitev načrta naročniku.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 214 -
Vloge in koraki
Načrtovanje
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 215 -
Shema postopka
Načrtovanje
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 216 -
Shema postopka
Načrtovanje – Izdelava načrta PB
Namen aktivnosti je na podlagi konceptualnega modela iz analize izdelati logični podatkovni model in izvesti ostale korake, potrebne za vzpostavitev učinkovite fizične podatkovne baze.
V sklopu faze načrtovanja izdelamo logični podatkovni model in določimo sistem pravic za uporabo podatkov in programskih modulov.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 217 -
Namen aktivnosti
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 218 -
Načrtovanje – Izdelava načrta PB Logično modeliranje podatkovne baze
nastopi za konceptualnim modeliranjem. Osnova logičnega modela je jezik, ki je
razumljiv ciljnemu SUPB. Če izberemo relacijski SUPB, potem
govorimo o relacijskem modelu.
svet mentalni model konceptualni model logični model PB
Izdelava logičnega podatkovnega modela
Načrtovanje – Izdelava načrta PB
- 219 -
SUPB
Konceptualni PM
Logični PM
Fizični PM(skripta)
Podatkovna baza
i-CASE
ODBC
Reverse Engineering
Odločitev o PB:- Relacijska- Hierarhična- Objektna
Logično načrtovanje
Podpora CASE orodij
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
Načrtovanje – Izdelava načrta PB Prehod iz konceptualnega v logični model
je navadno avtomatiziran s strani CASE orodij.
- 220 -
Primer: vrsta baze: relacijskaSUPB: Oracle
NAČRTOVANJEANALIZA
Konceptualni model
Entitetni tip
Atribut
Enolični identifikator
Povezava 1:n
Povezava m:n
Atribut / Stolpec
Relacija / Tabela
Vmesna tabelaTuji ključ
Ključ
Relacijski model
Prehod iz konceptualnega v logični model
Načrtovanje – Izdelava načrta PB Tipični koraki:
Za entitetne tipe kreiraj relacije Preveri relacije z normalizacijo Preveri relacije s pregledom uporabniških transakcij Preveri omejitve integritete Preveri model z uporabnikom Združi lokalne modele v globalni model (opcijsko) Preveri zmožnosti modela za razširitve
V nadaljevanju si bomo pogledali nekaj osnov o relacijskem modelu.
- 221 -RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
Tipični koraki pri izdelavi relacijskega modela
Načrtovanje – Izdelava načrta PB Pri relacijskem modeliranju se srečamo z
naslednjimi koncepti: Relacija Atribut Domena n-terica Funkcionalna odvisnost Ključ Pogled Normalizacija …
- 222 -RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
Osnovni koncepti relacijskega modela
Načrtovanje – Izdelava načrta PB Relacijo si lahko predstavljamo kot
dvodimenzionalno tabelo s stolpci in vrsticami. Velja za logično strukturo podatkovne baze in ne za
fizično.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 223 -
Ime Starost (v letih)
Teža (v kg)
Tine 15 50
Meta 20 45
Jure 40 80
Ana 5 10
Relacija
Predstava relacije
Načrtovanje – Izdelava načrta PB Atribut je poimenovani stolpec relacije.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 224 -
Ime Starost (v letih)
Teža (v kg)
Tine 15 50
Meta 20 45
Jure 40 80
Ana 5 10
Atribut relacije
Atribut relacije
Načrtovanje – Izdelava načrta PB Domena je množica dovoljenih vrednosti
enega ali več atributov, ki so vključeni v to domeno.
Primeri domen:
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 225 -
Domena relacije
Načrtovanje – Izdelava načrta PB N-terica je ena vrstica v relaciji. Števnost relacije je število n-teric relacije. Stopnja relacije je število atributov v
relaciji.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 226 -
Ime Starost (v letih)
Teža (v kg)
Tine 15 50
Meta 20 45
Jure 40 80
Ana 5 10
n-terica relacijeŠtevnost relacije
Stopnja relacije
Osnovne karakteristike relacije
Načrtovanje – Izdelava načrta PB Relacijska podatkovna baza je množica
normaliziranih relacij z enoličnimi imeni.
Normalizirane relacije so relacije, ki ustrezajo normalnim oblikam. Te določajo pravila, ki jim morajo relacije zadoščati, da pri vnašanju, spreminjanju in brisanju podatkov ne prihaja do anomalij.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 227 -
Relacijska podatkovna baza in normalizacija
Načrtovanje – Izdelava načrta PB Relacijo matematično definiramo kot
podmnožico kartezičnega produkta množic, ki predstavljajo domeno vrednosti atributov relacije.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 228 -
Matematična definicija relacije
nDDDr ...21
D1 je domena atributa A1: množica vrednosti, ki jih A1 lahko zavzame!
Načrtovanje – Izdelava načrta PB Vsaki relaciji pripada relacijska shema. Relacijsko shemo sestavlja oznaka sheme
R ter lista oznak atributov Ai s pripadajočimi oznakami domen Di:
R (A1: D1, A2: D2, ..., An: Dn)
Relacijska shema predstavlja semantiko ali pomen relacije.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 229 -
Relacijska shema
Načrtovanje – Izdelava načrta PB
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 230 -
Ime Starost (v letih)
Teža (v kg)
Tine 15 50
Meta 20 45
Jure 40 80
Ana 5 10
Sh(r) = Oseba(Ime: I, Starost: C, Teža: C)
Domena, ki obsega imena: I {Tine, Meta, Jure, Ana}Domena, ki obsega interval celih števil: C 1, 2,... 200
Relacija, predstavljena kot tabela
Shema relacije
Domene atributov relacije
Shema relacije
Relacijska shema
Načrtovanje – Izdelava načrta PB Enoličnost:
Ime relacije je enolično. V relacijski shemi podatkovne baze ni dveh relacij z enakim imenom;
Vsak atribut relacije ima enolično ime. V isti relaciji ni dveh atributov, ki bi imela isto ime;
Vsaka n-terica relacije je enolična v relaciji ni dveh enakih n-teric.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 231 -
Lastnosti relacij
Načrtovanje – Izdelava načrta PB Atomarnost:
Vsaka celica tabele, ki predstavlja relacijo, vsebuje natančno eno atomarno vrednost.
Zaloga vrednosti: Vrednosti nekega atributa so vse iz iste domene.
Nepomembnost vrstnega reda: Vrstni red atributov v relaciji je nepomemben. Vrstni red n-teric v relaciji je nepomemben.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 232 -
Lastnosti relacij
Načrtovanje – Izdelava načrta PB
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 233 -
Lastnosti relacij – primer
Ime Starost (v letih), teža (v kg)
Tine S15_T50
Meta S20_T45
Jure S40_T80Ana S5_T10
Zakonca Leto poroke (celo število)
Tine,Meta
1995
Ana,Jure
1980
Celice ne vsebujejo atomarnih vrednosti
Celice vsebujejo več vrednosti
Načrtovanje – Izdelava načrta PB Predpostavimo, da obstaja relacijska
shema R z množico atributov, katere podmnožici sta X in Y.
V relacijski shemi R velja X Y (X funkcionalno določa Y oziroma Y je funkcionalno odvisen od X), če v nobeni relaciji, ki pripada shemi R, ne obstajata dve n-terici, ki bi se ujemali v vrednostih atributov X in se ne bi ujemali v vrednostih atributov Y.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 234 -
Funkcionalne odvisnosti
Načrtovanje – Izdelava načrta PB Imamo relacijo s shemo
Izpit( VpŠt, Priimek, Ime, ŠifraPredmeta, DatumIzpita, OcenaPisno, OcenaUstno)
z naslednjim pomenom: Študent z vpisno številko VpŠt ter priimkom Priimek
in imenom Ime je na DatumIzpita opravljal izpit iz predmeta s šifro ŠifraPredmeta. Dobil je oceno OcenaPisno in OcenaUstno.
Funkcionalne odvisnosti sheme Izpit so: F { VpŠt (Priimek, Ime), (VpŠt, ŠifraPredmeta,
DatumIzpita) (OcenaPisno, OcenaUstno) }
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 235 -
Funkcionalne odvisnosti - primer
Načrtovanje – Izdelava načrta PB Ker je relacija množica n-teric, so v njej vse
n-terice ločene med seboj. Za sklicevanje na posamezno n-terico ni
potrebno poznati vseh vrednosti atributov n-terice, če v shemi nastopajo funkcionalne odvisnosti.
Množici atributov, ki določajo vsako n-terico, pravimo ključ relacije oziroma ključ relacijske sheme.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 236 -
Ključi relacije
Načrtovanje – Izdelava načrta PB Predpostavimo, da obstaja relacijska
shema z atributi A1 A2, ... An, katere podmnožica je množica atributov X.
Atributi X so ključ relacijske sheme oziroma pripadajočih relacij, če sta izpolnjena naslednja dva pogoja: X A1 A2 ... An ne obstaja X’, ki bi bila prava podmnožica od X in ki
bi tudi funkcionalno določala A1 A2 ... An
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 237 -
Ključi relacije
Načrtovanje – Izdelava načrta PB Poznamo več vrst ključev:
Kandidat za ključ (a key candidate) Primarni ključ (primary key) Superključ (superkey) Tuji ključ (foreign key)
Kandidat za ključ je vsaka podmnožica atributov relacije, ki relacijo enolično določa.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 238 -
Ključi relacije
Načrtovanje – Izdelava načrta PB Primarni ključ je tisti kandidat za ključ, ki
ga izberemo za shranjevanje relacij v fizični podatkovni bazi.
Superključ je vsaka množica atributov, v kateri je vsebovan ključ ključ je podmnožica superključa.
Tuji ključ je množica atributov, v okviru ene relacije, ki je enaka kandidatu za ključ neke druge ali iste relacije.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 239 -
Ključi relacije
Načrtovanje – Izdelava načrta PB
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 240 -
Ključi relacije primer
Šifra Naziv Zaloga
A10 Telovadni copati Nike 10
A12 Trenerka Bali 4
BC80 Moška jakna QuickSilver 1
X12 Ženska jakna QuickSilver 0
Račun Šifra artikla Količina
15/05 A10 1
15/05 X12 1
Primarni ključ v tabeli Artikel
Primarni ključ v tabeli Račun
Tuji ključ v tabeli Račun kaže na primarni ključ v tabeli Artikel
ARTIKEL
RAČUN
Načrtovanje – Izdelava načrta PB Za celovitost ter skladnost podatkov v
podatkovni bazi skrbimo s pomočjo omejitev.
Poznamo več vrst omejitev: Omejitve domene (Domain constraints) Pravila za celovitost podatkov (Integrity constraints)
Celovitost entitet (Entity Integrity) Celovitost povezav (Referential Integrity)
Števnost (Multyplicity) Splošne omejitve (General constraints)
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 241 -
Omejitve nad podatki
Načrtovanje – Izdelava načrta PB Omejitev entitete
V osnovni relaciji ne sme biti noben atribut, ki je del ključa, enak Null.
Omejitve povezav Če v relaciji obstajajo tuji ključi, potem morajo:
(a) njihove vrednosti ustrezati tistim, ki so v obliki ključa zapisane v eni izmed n-teric neke druge ali iste relacije
(b) ali pa mora biti tuji ključ v celoti enak Null.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 242 -
Omejitve nad podatki
Načrtovanje – Izdelava načrta PB Splošne omejitve
Dodatna pravila, ki jih določi uporabnik ali skrbnik podatkovne baze, ki definirajo ali omejujejo nek vidik področja, za katerega je narejena podatkovna baza.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 243 -
Omejitve nad podatki
Načrtovanje – Izdelava načrta PB
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 244 -
PedagogEMŠO N13 <pk>DavcnaSt C9 not nullIme C20 Priimek C20DtmRoj DKatedra N3 <fk>
Primarni ključ ne sme biti NULL
Zahtevamo obveznost podatka
KatedraKatedra N3 <pk>Naziv C20 not nullStLab N2 Vodja N3 <fk>
Omejitev povezave
Omejitve nad podatki – primeri omejitev
Načrtovanje – Izdelava načrta PB Pogled je navidezna relacija, ki ne obstaja v
relacijski bazi, temveč se dinamično kreira takrat, ko nekdo po njej povprašuje.
Vsebina pogleda je definirana kot poizvedba nad eno ali več osnovnimi relacijami.
Pogledi so dinamični spremembe nad osnovnimi relacijami, katerih atributi so zajeti tudi v pogledu, so v pogledu takoj vidne.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 245 -
Pogledi
Načrtovanje – Izdelava načrta PB Zakaj uporabljamo poglede:
Varnost: predstavljajo odličen mehanizem za zagotavljanje varnosti skrivajo posamezne dele podatkovne baze pred določenimi uporabniki.
Prilagojenost uporabnikom: uporabnikom dajejo možnost, da do podatkov dostopajo na prilagojen način isti podatki so lahko s strani različnih uporabnikov v istem času vidni na različne načine.
Poenostavitev: poenostavljajo kompleksne operacije nad osnovnimi relacijami.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 246 -
Namen uporabe pogledov
Načrtovanje – Izdelava načrta PB Vse spremembe nad osnovnimi relacijami
morajo biti takoj vidne tudi v pogledih nad temi relacijami.
Če spremenimo podatke v pogledu, se morajo spremembe poznati tudi v osnovnih relacijah, na katere se te spremembe nanašajo.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 247 -
Spreminjanje pogledov
Načrtovanje – Izdelava načrta PB V pogledih niso možne vse spremembe.
Veljajo naslednje omejitve: Nad pogledom so možne spremembe, če pogled
zajema eno samo osnovno relacijo ter vključuje atribute, ki so kandidat za ključ relacije.
Če pogled zajema več relacij, spremembe niso možne.
Če je pogled pridobljen z agregacijo ali grupiranjem n-teric, spremembe niso možne.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 248 -
Spreminjanje pogledov
Načrtovanje – Izdelava načrta PB
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 249 -
Šifra Naziv Zaloga
A10 Telovadni copati Nike 10
A12 Trenerka Bali 4
BC80 Moška jakna QuickSilver 1
X12 Ženska jakna QuickSilver 0
Račun Šifra artikla Količina
15/05 A10 1
15/05 X12 1
16/05 A10 3
17/05 A10 1
RAČUNARTIKEL
SELECT A.sifra, A.naziv, sum(R.kolicina) AS ProdanihFROM artikel A, racun RWHERE A.sifra = R.sifraGROUP BY A.sifra, A.naziv
Šifra Naziv Prodanih
A10 Telovadni copati Nike 5
X12 Ženska jakna QuickSilver 1
...
Primer pogleda
Načrtovanje – Izdelava načrta PB Normalizacija je postopek, s katerem
pridemo do množice primernih relacij, ki ustrezajo potrebam poslovne domene.
Nekaj lastnosti primernih relacij: Relacije imajo minimalen nabor atributov zgolj
tiste, ki so potrebni za pokritje potreb poslovnega sistema;
Atributi, ki so logično povezani, so zajeti v isti relaciji; Med atributi relacij je minimalna redundanca vsak
atribut (razen tujih ključev) je predstavljen samo enkrat.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 250 -
Normalizacija
Načrtovanje – Izdelava načrta PB Prednosti uporabe podatkovnih baz, ki jih
sestavljajo množice primernih relacij, so: Enostavnejša dostop do podatkov ter vzdrževanje
podatkov; Večja učinkovitost; Boljša izraba diskovnih kapacitet.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 251 -
Normalizacija
Načrtovanje – Izdelava načrta PB Relacije, ki vsebujejo odvečne podatke
lahko povzročajo anomalije pri spreminjanju podatkov govorimo o ažurnih anomalijah.
Poznamo več vrst anomalij: Anomalije pri dodajanju n-teric v relacijo Anomalije pri brisanju n-teric iz relacije Anomalije pri spreminjanju n-teric
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 252 -
Normalizacija – ažurne anomalije
Načrtovanje – Izdelava načrta PB Primeri anomalij:
Če želimo dodati podatke o novih članih (staff) za neko organizacijsko enoto (branch) moramo vpisati tudi vse podrobnosti o organizacijski enoti.
Če želimo dodati podatke o novi organizacijski enoti, ki še nima nobenega člana, moramo v vsa polja , ki člane opisujejo, vpisati Null.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 253 -
Normalizacija – ažurne anomalije pri dodajanju
Načrtovanje – Izdelava načrta PB Primeri anomalij:
Če iz relacije zbrišemo n-terico, ki predstavlja zadnjega člana v neki organizacijski enoti, zgubimo tudi podatke o tej organizacijski enoti.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 254 -
Normalizacija – ažurne anomalije pri brisanju
Načrtovanje – Izdelava načrta PB Primeri anomalij:
Če želimo spremeniti vrednost nekega atributa določene organizacijske enote (npr. naslov), moramo popraviti vse n-terice, v katerih takšna vrednost atributa nastopa.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 255 -
Normalizacija – ažurne anomalije pri spreminjanju
Načrtovanje – Izdelava načrta PB Postopku preoblikovanja relacij v obliko, pri
kateri do ažurnih anomalij ne more priti, pravimo normalizacija.
Obstaja več stopenj normalnih oblik: 1NO – Prva normalna oblika 2NO – Druga normalna oblika 3NO – Tretja normalna oblika in 4PNO – Četrta poslovna normalna oblika BCNO – Boyce Codova normalna oblika 4NO – Četrta normalna oblika 5NO – Peta normalna oblika
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 256 -
Normalne oblike
Načrtovanje – Izdelava načrta PB Relacija je v prvi normalni obliki, če:
Nima ponavljajočih atributov ne obstajajo atributi ali skupine atributov, ki bi imele več vrednosti pri isti vrednosti ostalih atributov (na presečišču ene vrstice in enega stolpca je več vrednosti)
Ima definiran primarni ključ in določene funkcionalne odvisnosti
Koraki: Odstranimo ponavljajoče atribute Določimo funkcionalne odvisnosti Določimo primarni ključ
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 257 -
Normalizacija – prva normalna oblika
Načrtovanje – Izdelava načrta PB
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 258 -
VŠ priimek ime pošta kraj šifra predmeta naziv ocena64010632 Bratina Simon 4100 Kranj 20020
2002120033
ISTPOIPI
1088
64016209 Bizjak Tadeja 2250 Ptuj 2006020033
E1IPI
96
Indeks( VŠ, priimek, ime, pošta, kraj, ( šifra predmeta, naziv, ocena ) )
Skupina ponavljajočih se atributov.
Načrtovanje – Izdelava načrta PB
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 259 -
Indeks( VŠ, priimek, ime, pošta, kraj, ( šifra predmeta, naziv, ocena ) )
Indeks( VŠ, priimek, ime, pošta, kraj, šifra predmeta, naziv, ocena )
Odpravimo ponavljajoče atribute
Identificiramo funkcionalne odvisnosti
F { VŠ (priimek, ime, pošta, kraj), šifra predmeta naziv, pošta kraj, (VŠ, šifra predmeta) ocena }
Določimo primarni ključ
Indeks( VŠ, priimek, ime, pošta, kraj, šifra predmeta, naziv, ocena )
Načrtovanje – Izdelava načrta PB
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 260 -
VŠ priimek ime pošta kraj šifra predmeta naziv ocena64010632 Bratina Simon 4100 Kranj 20020 IS 1064010632 Bratina Simon 4100 Kranj 20021 TPO 864010632 Bratina Simon 4100 Kranj 20033 IPI 864016209 Bizjak Tadeja 2250 Ptuj 20060 E1 964016209 Bizjak Tadeja 2250 Ptuj 20033 IPI 6
VŠ priimek ime pošta kraj šifra predmeta naziv ocena64010632 Bratina Simon 4100 Kranj 20020
2002120033
ISTPOIPI
1088
64016209 Bizjak Tadeja 2250 Ptuj 2006020033
E1IPI
96
Načrtovanje – Izdelava načrta PB Relacija je v drugi normalni obliki:
Če je v prvi normalni obliki in Ne vsebuje parcialnih odvisnosti noben atribut, ki
ni del ključa, ni funkcionalno odvisen le od dela primarnega ključa, temveč od celotnega ključa
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 261 -
Normalizacija – druga normalna oblika
Načrtovanje – Izdelava načrta PB
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 262 -
Indeks( VŠ, šifra predmeta, priimek, ime, pošta, kraj, naziv, ocena )
!
Relacijo razbijemo
Študent( VŠ, priimek, ime, pošta, kraj)Predmet( šifra predmeta, naziv)Indeks( #VŠ, #šifra predmeta, ocena)
!
Načrtovanje – Izdelava načrta PBVŠ priimek ime pošta kraj šifra predmeta naziv ocena64010632 Bratina Simon 4100 Kranj 20020 IS 1064010632 Bratina Simon 4100 Kranj 20021 TPO 864010632 Bratina Simon 4100 Kranj 20033 IPI 864016209 Bizjak Tadeja 2250 Ptuj 20060 E1 964016209 Bizjak Tadeja 2250 Ptuj 20033 IPI 6
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 263 -
VŠ priimek ime pošta kraj64010632 Bratina Simon 4100 Kranj64016209 Bizjak Tadeja 2250 Ptuj
šifra predmeta
naziv
20020 IS20021 TPO20033 IPI20060 E120033 IPI
VŠ šifra predmeta
ocena
64010632 20020 1064010632 20021 864010632 20033 864016209 20060 964016209 20033 6
Načrtovanje – Izdelava načrta PB Relacija je v tretji normalni obliki:
Če je v drugi normalni obliki in Če ne vsebuje tranzitivnih funkcionalnih odvisnosti
med atributi, ki niso del primarnega ključa, ni odvisnosti.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 264 -
Normalizacija – tretja normalna oblika
Načrtovanje – Izdelava načrta PB
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 265 -
Študent( VŠ, priimek, ime, pošta, kraj)Predmet( šifra predmeta, naziv)Indeks( #VŠ, #šifra predmeta, ocena)
!
Študent( VŠ, priimek, ime, #pošta)Pošta(pošta, kraj)Predmet( šifra predmeta, naziv)Indeks( #VŠ, #šifra predmeta, ocena)
Relacijo razbijemo
Načrtovanje – Izdelava načrta PB
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 266 -
VŠ priimek ime pošta kraj64010632 Bratina Simon 4100 Kranj64016209 Bizjak Tadeja 2250 Ptuj
VŠ priimek ime pošta64010632 Bratina Simon 410064016209 Bizjak Tadeja 2250
pošta kraj4100 Kranj2250 Ptuj
Načrtovanje – Izdelava načrta PB Relacija je v četrti poslovni normalni obliki,
če: je v tretji normalni obliki in v relaciji ne obstajajo atributi, ki bi bili odvisni od
vrednosti primarnega ključa.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 267 -
Normalizacija – četrta poslovna normalna oblika
Načrtovanje – Izdelava načrta PB
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 268 -
Študent( VŠ, priimek, ime, #pošta, datum plačila šolnine, rok diplome)
Za izredne študenta Za redne študenta
Študent( VŠ, priimek, ime, #pošta)Redni študent( #VŠ, rok diplome)Izredni študent( #VŠ, datum plačila šolnine)
Načrtovanje – Izdelava načrta PB
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 269 -
VŠ Priimek Ime Datum plačila šolnine Rok diplome64010632 Bratina Simon 15.3.200564016209 Bizjak Tadeja 19.4.200264010670 Berce Marjan 12.4.200464620010 Mele Silvana 1.4.200565120987 Leban Tibor 15.7.2005
VŠ Priimek Ime64010632 Bratina Simon64016209 Bizjak Tadeja64010670 Berce Marjan64620010 Mele Silvana65120987 Leban Tibor
VŠ Datum plačila šolnine64016209 19.4.200264010670 12.4.2004
VŠ Rok diplome64010632 15.3.200564620010 1.4.200565120987 15.7.2005
Načrtovanje – Izdelava načrta PB Tipični koraki:
Za entitetne tipe kreiraj relacije Preveri relacije z normalizacijo Preveri relacije s pregledom uporabniških transakcij Preveri omejitve integritete Preveri model z uporabnikom Združi lokalne modele v globalni model (opcijsko) Preveri zmožnosti modela za razširitve
- 270 -RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
Tipični koraki pri izdelavi relacijskega modela Ponovitev
Načrtovanje – Izdelava načrta PB
- 271 -RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
Primer pretvorbe konceptualnega v relacijski model
IzpitZap. št. polaganjaOcena pisnoOcena ustnoDatum ocene
ŠtudentVpisna številkaPriimekImeNaslovTelefonE-mailStatus…
StudentVpisSt N8 <pk>Priimek C20Ime C20Ulica C25Posta N4Drzava C20GSM N15Tel N15Email C25 nullStatus N1…
IzpitZapStPol N2 <pk>VpisSt N8 <pk, fk>OcPisno N2,2OcUstno N2,2DatumOc D
VpisSt = VpisSt
Načrtovanje – Izdelava načrta PB
- 272 -RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
Primer pretvorbe konceptualnega v relacijski model
StudentVpisSt N8 <pk>Priimek C20Ime C20Ulica C25Posta N4Drzava C20GSM N15Tel N15Email C25 nullStatus N1…
IzpitZapStPol N2 <pk>VpisSt N8 <pk, fk>OcPisno N2,2OcUstno N2,2DatumOc D
VpisSt = VpisSt
Dodatno poskrbimo za: Indekse Integriteto povezav Druge omejitve Poglede …
Razvoj po strukturnem pristopu Postopki strukturnega pristopa:
Zajem in specifikacija zahtev; Analiza Načrtovanje
• Izdelava načrta podatkovne baze,• Izdelava načrta programskih modulov,• Izdelava načrta dokumentacije,• Izdelava načrta testiranja,• Izdelava načrta namestitve in uvedbe in• Predstavitev načrta naročniku.
Izvedba; Testiranje; Namestitev in uvedba.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 273 -
Kje smo?
Načrtovanje – izdelava načrta modulov Namen aktivnosti je prikazati, kako bodo
posamezne funkcije in procesi, identificirani v sklopu analize, realizirani v okviru rešitve.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 274 -
Namen aktivnosti
Analiza
Proces FunkcijaProces
ProcesFunkcija
FunkcijaFunkcija
Funkcija
Načrt
Programski modulProgramski modulProgramski modul
Programski modul
Programski modul
Programski modulProgramski modul
Načrtovanje – izdelava načrta modulov Funkcije in procesi iz analize predstavljajo
logične sklope sistema. V fazi načrtovanja jih pretvorimo v fizične oziroma programske sklope ali module.
Pretvorba ni nujno 1:1 Implementacija enega logičnega sklopa je lahko
izvedena z več programskimi sklopi. En programski sklop lahko implementira več logičnih
enot.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 275 -
Namen aktivnosti
Fizična enota1..n 1..n
Logična enota
Načrtovanje – izdelava načrta modulov Tipi programskih modulov:
Zaslonska maska Obdelava Poročilo ali izpis
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 276 -
Programski modul
Zaslonska maska
Izpis/ poročilo
Paketna obdelava
Programski moduli
Načrtovanje – izdelava načrta modulov Strukturo programskih modulov prikažemo
s pomočjo strukturnega diagrama.
Lastnosti strukturnih diagramov: Prikazuje programske module, s katerih bo
sestavljena informacijska rešitev; Prikazuje odvisnost med programskimi moduli ter
podatke, ki se med moduli prenašajo; Omogoča prikaz zaporedja, izbire in ponavljanja.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 277 -
Strukturni diagram
Načrtovanje – izdelava načrta modulov Lastnosti strukturnih diagramov:
Moduli so organizirani v hierarhijo, podobno kot funkcije v funkcionalni razgradnji.
Na najvišjem mestu je vseobsegajoč modul ali koren. Na naslednjem nivoju so moduli, ki jih koren lahko kliče (analogno kot izbire v meniju).
Moduli komunicirajo med seboj s pomočjo parametrov:
• nosilci podatkov• kontrolne zastavice
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 278 -
Strukturni diagram
Načrtovanje – izdelava načrta modulov
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 279 -
Strukturni diagram – primer
Dodajizpitni rok
Izračunajdan roka
Preveriposlovna
praviladan roka pravilaOK
številkakršenegapravila
kontrolna zastavicapodatek
Razvoj po strukturnem pristopu Postopki strukturnega pristopa:
Zajem in specifikacija zahtev; Analiza Načrtovanje
• Izdelava načrta podatkovne baze,• Izdelava načrta programskih modulov,• Izdelava načrta dokumentacije,• Izdelava načrta testiranja,• Izdelava načrta namestitve in uvedbe in• Predstavitev načrta naročniku.
Izvedba; Testiranje; Namestitev in uvedba.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 280 -
Kje smo?
Načrtovanje – načrt dokumentacije Namen aktivnosti je določiti obseg in
strukturo dokumentacije ter izbrati ustrezne standarde in vzorce za dokumentacijo.
Upoštevamo zahteve naročnika iz zajema in specifikacije zahtev.
Določimo tudi vire za dokumentacijo.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 281 -
Izdelava načrta dokumentacije
Načrtovanje – načrt dokumentacije Potrebno upoštevati, da lahko nekatere
dele dokumentacije izdelamo šele, ko je del sistema, ki ga dokumentiramo, izdelan: Npr. posnetke zaslonov za uporabniško
dokumentacijo lahko izdelamo šele, ko je uporabniški vmesnik izdelan in smo prepričani, da se ne bo več spreminjal.
V grobem lahko dokumentacijo razdelimo na: uporabniško dokumentacijo, sistemsko-tehnično dokumentacijo ter navodila za operativno skrbništvo.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 282 -
Izdelava načrta dokumentacije
Načrtovanje – načrt dokumentacije Uporabniška dokumentacija je osnovna
pomoč za uporabnike oziroma uporabo rešitve.
Možne različne oblike…
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 283 -
Izdelava načrta dokumentacije
Vir: ERP sistem Pantheon
Načrtovanje – načrt dokumentacije Sistemsko-tehnična dokumentacija
dokumentira informacijsko rešitev s sistemsko-tehničnega vidika. Npr.: Podatkovni model; Arhitektura sistema; Komponente sistema; Opis testnega, produkcijska in razvojnega okolja; Opis sistemske programske opreme in druge
infrastrukture, ki je potrebna za delovanje sistema; …
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 284 -
Izdelava načrta dokumentacije
Načrtovanje – načrt dokumentacije Navodila za operativno skrbništvo zajemajo
opis ključnih postopkov, ki so potrebni za operativno delovanje sistema. Npr: Postopek izdelave varnostnih kopij; Postopek ustavitve sistema; Postopek ponovnega zagona sistema; Postopek namestitve nadgradenj in popravkov; Postopek vzpostavitve nadomestnega sistema; …
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 285 -
Izdelava načrta dokumentacije
Načrtovanje – načrt dokumentacije V okviru načrta dokumentacije izdelamo
vzorce dokumentacije in jih predstaviti naročniku ter uporabniku.
Cilj je uskladitev o obliki dokumentacije.
Nivo podrobnosti in obseg dokumentacije je odvisen od dogovora med izvajalcem in naročnikom. Praviloma se podrobneje dokumentirajo samo pomembnejši podsistemi in kritični postopki.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 286 -
Izdelava načrta dokumentacije
Razvoj po strukturnem pristopu Postopki strukturnega pristopa:
Zajem in specifikacija zahtev; Analiza Načrtovanje
• Izdelava načrta podatkovne baze,• Izdelava načrta programskih modulov,• Izdelava načrta dokumentacije,• Izdelava načrta testiranja,• Izdelava načrta namestitve in uvedbe in• Predstavitev načrta naročniku.
Izvedba; Testiranje; Namestitev in uvedba.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 287 -
Kje smo?
Načrtovanje – načrt testiranja Testiranje, ki intenzivno poteka v fazi
izvedbe ter v okviru namestitve in uvedbe sistema, je nujno predhodno načrtovati.
Načrt testiranja zajema: Načrt poteka testiranja Načrte za izvedbo posameznih testov
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 288 -
Izdelava načrta testiranja
Načrtovanje – načrt testiranja Osnovni potek testiranja, vrste testov in
vsebino testiranja določa postopek testiranja.
Z načrtom poteka testiranja, ki ga izdelamo v sklopu načrtovanja, podrobneje določimo zaporedje izvajanja posameznih testov po sklopih informacijske rešitve in po okoljih.
Načrt poteka testiranja je odvisen od načrta programskih modulov.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 289 -
Načrt poteka testiranja
Načrtovanje – načrt testiranja Z načrti za izvedbo posameznih testov
podrobneje določimo, kaj bomo v okviru posameznega testa, ki je predviden v načrtu poteka testiranja, testirali.
V odvisnosti od namena testiranja, faze testiranja in okolja testiranja podrobneje določimo vsebino testiranja npr. testiranje funkcionalnosti, testiranje GUI,
testiranje vmesnikov, testiranje prevedbe podatkov, testiranje drugih nefunkcionalnih zahtev IR ipd.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 290 -
Načrt za izvedbo testa
Načrtovanje – načrt testiranja Načrt za izvedbo testa mora opredeliti vsaj:
Namen testiranja: čemu je namenjena izvedba testa? (npr. testiranje programske enote »Prijava na izpit«)
Faza testiranja: v kateri fazi izvajamo testiranje? (npr. testiranje v fazi razvoja ali testiranje v fazi namestitve in uvedbe)
Okolje testiranja: v katerem okolju je potrebno test izvesti? (npr. v testnem okolju)
Področje testiranja: kaj se s testom testira? (npr. funkcionalnost sklopa, integracija sklopa, GUI,...)
Način izvedbe testiranja: podroben opis, ki pove, kako se izvede test. Opis je odvisen od področja testiranja.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 291 -
Načrt za izvedbo testa
Načrtovanje – načrt testiranja Pri izdelavi načrtov za izvedbo posameznih
testov si pomagamo s testnimi scenariji. Testni scenariji opisujejo postopke uporabe
sistema in so zato dobro vodilo za testiranje funkcionalnosti IR.
V okviru testiranja po izbranem scenariju spremljamo uporabo in spreminjanje izbranih podatkov, na osnovi česar lahko ob zaključku testa bodisi potrdimo ali ovržemo pravilnost delovanja modulov/ sklopov, ki so bili v testu vključeni.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 292 -
Uporaba scenarijev
Načrtovanje – načrt testiranja
Za izvedbo testa po nekem scenariju je potrebno določiti vhodne podatke ter pričakovane rezultate.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 293 -
Uporaba scenarijev
Načrtovanje – načrt testiranja
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 294 -
Opredelitev scenarija
Testno oklolje
Razvojno okolje
T1 T2 T3 T4 T5 T6
T7
T8
Produkcijsko okolje
Tn-1
Tn
Načrt poteka testiranja
Test T3
Scenarij: Vhodni podatki Pričakovani rezultati Načrt za izvedbo testa
Načrtovanje – načrt testiranja
Izdelek načrt testiranja je sestavljen iz več dokumentov: Dokument, ki podaja potek testiranja. Dokument, ki podaja scenarije za testiranje
funkcionalnih in nefunkcionalnih zahtev sistema. Dokumenti, ki podrobneje opredeljujejo izvedbo
posameznih testov, ki jih načrt poteka testiranja predvideva.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 295 -
Načrt testiranja – izdelek
Načrtovanje – načrt testiranja
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 296 -
Načrt testiranja – primer načrta poteka testiranja
Načrt poteka testiranjaT1: sklop: prijava na izpit
okolje: razvojT2: sklop: odjava iz izpita
okolje: razvojT3: sklop: pregled števila prijavljenih kandidatov
okolje: razvoj T4: sklop: Izpis seznama prijavljenih kandidatov
okolje: razvoj T5: sklop: Vnos rezultatov
okolje: razvoj T6: sklop: Objava rezultatov
okolje: razvoj T7: sklop: Opravljanje pisnih izpitov (integracijski test)
okolje: testnoT8: sklop: Vnos obvestil
okolje: razvoj ....Tn-1: sklop: celoten sistem (potrditveni test)
okolje: testnoTn: sklop: celoten sistem (končni test)
okolje: produkcijsko
Testno oklolje
Razvojno okolje
T1 T2 T3 T4 T5 T6
T7
T8
Produkcijsko okolje
Tn-1
Tn
Načrtovanje – načrt testiranja
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 297 -
Načrt testiranja – primer načrta za izvedbo testa
NAČRT TESTIRANJA ZA TEST T2
Namen testiranja: testiranje sklopa odjava iz izpitaFaza testiranja: testiranje v fazi razvojaOkolje testiranja: razvojno okoljePodročje testiranja: funkcionalnost sklopa, GUI
Način izvedbe testiranja:
1. Testiranje funkcionalnosti: testirati po scenarijih S1, S3, S4, S82. Testiranje GUI: preveriti skladnost elementov GUI z načrtom
programskega modula/podsistema PM3
Načrtovanje – načrt testiranja
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 298 -
Načrt testiranja – primer scenarija
OZNAKA SCENARIJA: S3
Kratek opis: odjava iz izpitnega roka, če je rok za odjavo že potekel
Koraki scenarija: 1. v sistem se prijaviti kot študent [Š]2. prijaviti se na razpisan rok za izbran datum in predmet [I]3. na strežniku spremeniti sistemski datum na trenutni datum [D]4. poskusiti se odjaviti iz izpita [I]
Vhodni podatki: Š, I, D
Pričakovani rezultati: sistem ne dovoli odjave iz izpita [I]. Če študent izbere opcijo Odjava iz izpita, dobi sporočilo »Iz izpita se ne morete odjaviti. Rok za odjavo je že potekel!«.
Razvoj po strukturnem pristopu Postopki strukturnega pristopa:
Zajem in specifikacija zahtev; Analiza Načrtovanje
• Izdelava načrta podatkovne baze,• Izdelava načrta programskih modulov,• Izdelava načrta dokumentacije,• Izdelava načrta testiranja,• Izdelava načrta namestitve in uvedbe in• Predstavitev načrta naročniku.
Izvedba; Testiranje; Namestitev in uvedba.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 299 -
Kje smo?
Načrtovanje – načrt namestitve in uvedbe Naloga aktivnosti je izdelati načrt
namestitve in uvedbe IR v razvojno, testno in produkcijsko okolje ter uvedbo uporabnikov in skrbnikov za delo z IR.
Načrt namestitve in uvedbe v razvojnem okolju pripravijo člani projektne skupine razvijalca, pri izdelavi načrta namestitve in uvedbe v testnem oz. produkcijskem okolju pa sodelujejo tudi predstavniki končnih uporabnikov.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 300 -
Načrt namestitve in uvedbe
Načrtovanje – načrt namestitve in uvedbe V načrtu potrebno opredeliti:
namen in cilj namestitve in uvedbe, zahteve okolja za namestitev in uvedbo (pogoji za
izvedbo namestitve in uvedbe, potrebna strojna oprema, potrebna sistemska programska oprema, povezovanje z ostalo aplikativno opremo, potrebna dokumentacija),
naloge namestitve in uvedbe (funkcionalne naloge, administrativne naloge),
udeležence namestitve in uvedbe, njihove odgovornosti ter vključitev uporabnikov in skrbnikov,
opis sestave paketa za namestitev IR (določitev in označitev distribucijskih medijev - CD-ROM, diskete, spletne strežniške datoteke, priložena dokumentacija),RAZVOJ INFORMACIJSKIH SISTEMOV
Visokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 301 -
Načrt namestitve in uvedbe
Načrtovanje – načrt namestitve in uvedbe V načrtu potrebno opredeliti
(nadaljevanje): opis procesa namestitve in uvedbe (način izvedbe
faz namestitve, dodelitev pravic za delo, opis prevedbe podatkov, opis načina uvajanja uporabnikov in skrbnikov, opis izvedbe potrditvenega testa IR, opis prehoda na nov sistem),
merila za uspešno namestitev in uvedbo (ključne točke za uspešno opravljeno namestitev, seznam ali opis pričakovanih rezultatov namestitve in uvedbe in dovoljenih odstopanj),
vrednotenje ugotovljenih napak ali pomanjkljivosti pri postopku namestitve in uvedbe,
potrditev oz. odobritev rezultatov namestitve in uvedbe.RAZVOJ INFORMACIJSKIH SISTEMOV
Visokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 302 -
Načrt namestitve in uvedbe
Načrtovanje – načrt namestitve in uvedbe Načrt namestitve in uvedbe se sestoji iz:
načrta namestitve IR; načrta dodelitve pravic; načrta prevedbe podatkov; načrta uvajanja načrta za izvedbo potrditvenega ter končnega testa
IR načrta prehoda na nov sistem
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 303 -
Načrt namestitve in uvedbe
Razvoj po strukturnem pristopu Postopki strukturnega pristopa:
Zajem in specifikacija zahtev; Analiza Načrtovanje
• Izdelava načrta podatkovne baze,• Izdelava načrta programskih modulov,• Izdelava načrta dokumentacije,• Izdelava načrta testiranja,• Izdelava načrta namestitve in uvedbe in• Predstavitev načrta naročniku.
Izvedba; Testiranje; Namestitev in uvedba
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 304 -
Kje smo?
Načrtovanje – predstavitev načrta
Osnovni namen predstavitve je pridobitev potrditve s strani naročnika o ustreznosti načrta.
Pri predstavitvi je potrebno upoštevati, da naročnik navadno nima strokovnih znanj, ki bi mu omogočala poglobljeno razumevanje načrta, hkrati pa to tudi ni njegova naloga.
Naročniku predstavimo le osnovne elemente načrta.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 305 -
Predstavitev načrta naročniku
Načrtovanje – predstavitev načrta
Primeren za podrobno predstavitev je načrt uporabniškega vmesnika posredno razkriva tudi druge elemente načrta.
Na osnovi predstavitve lahko naročnik opozori na pomanjkljivosti oz. izrazi dodatne želje.
Aktivnost se zaključi s potrditvijo naročnika (navadno podpis dokumenta), da načrt ustreza zahtevam.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 306 -
Predstavitev načrta naročniku
Razvoj po strukturnem pristopu Postopki strukturnega pristopa:
Zajem in specifikacija zahtev; Analiza; Načrtovanje; Izvedba; Testiranje; Namestitev in uvedba.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 307 -
Kje smo?
Testiranje
Glavni namen testiranja jezagotoviti, da IR deluje tako, kot smo načrtovali.
Postopek testiranja se prepleta skozi ves življenjski cikel razvoja IR: analiza, načrtovanje, izvedba inuvedba.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 308 -
Opredelitev in namen
Podroben opis aktivnosti testiranja je podan po posameznih postopkih.
Testiranje
Končen izdelek testiranja je preverjena in delujoča IR.
Skozi potek testiranja nastane tudi več drugih izdelkov. Opisani so pri aktivnostih, kjer nastanejo (glej
postopke analiza, načrtovanje in uvedba).
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 309 -
Končni izdelek e
Testiranje
Testiranje se izvaja na različnih ravneh. Prvo testiranje izvaja že sam razvijalec
neposredno ob razvoju. Sledi sistematično testiranje s strani preizkuševalca, zatem pa še testiranje s strani končnega uporabnika.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 310 -
Vloge
Testiranje
Za zagotovitev ustrezne ravni varnosti potrebno za testiranje in produkcijo zagotoviti ločena okolja.
Ločena okolja pogosto težko (drago) zagotoviti.
Najboljši pristop je uporaba ločene strojne opreme.
Produkcijsko okolje vedno namestimo na ločeno strojno opremo.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 311 -
Okolje za testiranje
Testiranje
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 312 -
Primer okolja za testiranje
Razvojni AS Razvojni PS
Testni AS in PS
Produkcijski AS
Produkcijski PS
Razvoj in vmesnotestiranje
Končno testiranje in produkcija
Testiranje
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 313 -
Shema postopka
Testiranje
Testiranje poteka na različnih ravneh, v različnih okoljih in s strani različnih vlog.
Vrste testov: Test programskih enot Test integracije Sistemski test Test sprejemljivosti - Potrditveni test Test sprejemljivosti - Končni test
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 314 -
Vrste in potek testiranja
Testiranje
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 315 -
Vrste in potek testiranja
Vrsta testa Vsebina testiranja Okolje testiranja
Vloge
Test programskih enot
Uporabniški vmesnik, funkcionalnost programske enote, skladnost z zahtevami in standardi
Razvojno okolje,Testno okolje
Razvijalec, Preizkuševalec
Test integracije Test integracije programskih enot, test integracije v okolje (vmesniki)
Testno okolje
Integrator, Preizkuševalec,Ključni uporabnik
Sistemski test Obnašanje v okolju, zmogljivosti, dostopnost, nefunkcionalne zahteve
Testno okolje
Skrbnik podatkovne baze,Sistemski administrator, Skrbnik aplikacije, Preizkuševalec, Ključni uporabnik
Test sprejemljivosti - Potrditveni test
Preverjanje delovanja celotne funkcionalnosti, preverjanje nefunkcionalnih zahtev
Testno okolje
Ključni uporabnik
Test sprejemljivosti - Končni test
Test funkcionalnosti v omejenem obsegu v produkcijskem okolju
Produkcijsko okolje
Ključni uporabnik
Testiranje
Testiranje programski enot Testiranje programskih enot je osnovno testiranje,
osredotočeno na ustreznost uporabniškega vmesnika in funkcionalnosti programske enote glede na podane zahteve in standarde.
Izvaja v razvojnem okolju. Najprej se s testiranjem ukvarjajo razvijalci, ko sami testirajo module oziroma programske enote, ki so jih razvili.
Testiranje s strani razvijalcev je navadno nesistematično in se ne izvaja po načrtu.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 316 -
Vrste in potek testiranja
Testiranje
Testiranje programski enot (nadaljevanje) Ko razvitih več programskih enot (funkcionalni
sklop), testiranje prevzame preizkuševalec. Skladno z načrtom testiranja preveri pravilnost funkcionalnega sklopa, preden se le-ta namesti v testno okolje.
Testiranje programskih enot se izvaja tudi v testnem okolju. Sodelujeta preizkuševalec in ključni uporabnik. Ustreznost sklopa potrdi ključni uporabnik.
Če je moč testiranje v testnem in razvojnem okolju izvajamo vzporedno.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 317 -
Vrste in potek testiranja
Testiranje
Testiranje integracije Testiranje integracije namenjeno testiranju povezav
med programskimi enotami ter testiranju vmesnikov - povezav IR z okoljem.
Testiranje integracije poteka v več korakih, vzporedno z razvojem. Testiranje vmesnikov z okoljem navadno izvedemo na koncu za celoten sistem.
Testiranje integracije poteka v testnem okolju. Pri tem sodelujejo integrator, preizkuševalec in ključni uporabniki.
Testiranje se izvaja po pripravljenem načrtu in se zaključi z ustrezno potrditvijo.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 318 -
Vrste in potek testiranja
Testiranje
Testiranje sistema Testiranje sistema namenjeno testiranju obnašanja
sistema kot celote ter njegovega delovanja v okolju. Poudarek na testiranju nefunkcionalnih zahtev kot na primer: zmogljivost, dostopnost, test pod obremenitvijo ipd.
Test se izvaja v testnem okolju. Izvede se enkrat, in sicer takrat, ko je v testnem okolju nameščen celoten sistem in povezan z okoljem. Pri izvedbi testa sodelujejo: skrbnik podatkovne baze, sistemski administrator, skrbnik aplikacije, preizkuševalec in ključni uporabniki.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 319 -
Vrste in potek testiranja
Testiranje
Testiranje sprejemljivosti Test sprejemljivosti se deli na potrditveni test in
končni test.
Potrditveni test namenjen testiranju celotne IR, tako z vidika funkcionalnih kot nefunkcionalnih zahtev, z namenom pridobitve potrdila o njegovi ustreznosti. Test se izvaja v testnem okolju v sklopu postopka namestitve in uvedbe IR. Test izvaja ključni uporabnik po pripravljenem načrtu.
Končni test je zadnji test IR. Izvedemo ga v produkcijskem okolju z namenom, da se prepričamo, da pri postopku namestitve ni prišlo do kakršnihkoli napak. Končni test izvedemo s pomočjo produkcijskih oziroma pravih primerov. Izvaja ga ključni uporabnik.RAZVOJ INFORMACIJSKIH SISTEMOV
Visokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 320 -
Vrste in potek testiranja
Razvoj po strukturnem pristopu Postopki strukturnega pristopa:
Zajem in specifikacija zahtev; Analiza; Načrtovanje; Izvedba; Testiranje; Namestitev in uvedba.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 321 -
Kje smo?
Namestitev in uvedba
Glavni namen namestitve in uvedbe je namestitev izbrane IR ali njenih delov v testno ali
produkcijsko okolje ter; izvedba potrditvenega in končnega testa IR; uvedba uporabnikov, skrbnikov in drugih, ki
bodo z IR delali, za delo z novo IR.
Z izvedbo postopka zagotovimo, da lahko uporabniki nemoteno uporabljajo novo IR.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 322 -
Opredelitev in namen
Namestitev in uvedba
Končen izdelek namestitve in uvedbe sta nameščena IR v produkcijsko okolje in uvedeni uporabniki.
Ko je nova IR nameščena v produkcijskem okolju in so uporabniki usposobljeni za uporabo nove IR, se uporaba nove IR lahko prične.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 323 -
Končni izdelek e
Namestitev in uvedba
Aktivnosti v okviru postopka namestitve in uvedbe IR izvajajo načrtovalec podatkovne baze, uvajalec, skrbnik podatkovne baze, končni uporabnik, sistemski administrator, skrbnik aplikacije, postavitveni inženir, informacijski varnostni inženir in poslovni lastnik.
Po potrebi sodelujejo tudi ostale vloge.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 324 -
Vloge in koraki
Namestitev in uvedba
Postopek namestitve in uvedbe lahko razdelimo na sedem aktivnosti: Namestitev IR, Dodelitev pravic za delo z IR, Prevedba podatkov, Izvedba potrditvenega testa IR, Izvedba končnega testa IR, Uvajanje uporabnikov in skrbnikov za delo z IR, Prehod na novi sistem.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 325 -
Vloge in koraki
Namestitev in uvedba
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 326 -
Shema postopka
Namestitev in uvedba
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 327 -
Shema postopka
Razvoj po strukturnem pristopu Postopki strukturnega pristopa:
Zajem in specifikacija zahtev; Analiza; Načrtovanje; Izvedba; Testiranje; Namestitev in uvedba:
• Namestitev IR,• Dodelitev pravic za delo z IR,• Prevedba podatkov,• Izvedba potrditvenega testa IR,• Izvedba končnega testa IR,• Uvajanje uporabnikov in skrbnikov za delo z IR,• Prehod na novi sistem.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 328 -
Kje smo?
Namestitev in uvedba – Namestitev IR Naloga namestitve je vključitev nove IR v
testno ali produkcijsko okolje. V okviru tega je potrebno namestiti: strojno opremo, sistemsko programsko opremo in aplikativno programsko opremo - programske
module.
Namestitev poteka na podlagi načrta namestitve IR, postopki nameščanja opreme pa morajo biti v čim večji meri avtomatizirani.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 329 -
Namestitev IR
Namestitev in uvedba – Namestitev IR Namestitev IR v testno okolje poteka v več
fazah (med razvojem) ali v celoti (ob zaključku).
Namestitev IR v produkcijsko okolje se izvede, ko je aplikacija razvita in potrjena s potrditvenim testom v testnem okolju.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 330 -
Namestitev IR
Razvoj po strukturnem pristopu Postopki strukturnega pristopa:
Zajem in specifikacija zahtev; Analiza; Načrtovanje; Izvedba; Testiranje; Namestitev in uvedba:
• Namestitev IR,• Dodelitev pravic za delo z IR,• Prevedba podatkov,• Izvedba potrditvenega testa IR,• Izvedba končnega testa IR,• Uvajanje uporabnikov in skrbnikov za delo z IR,• Prehod na novi sistem.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 331 -
Kje smo?
Namestitev in uvedba – Dodelitev pravic V skladu z načrtom namestitve in uvedbe –
načrt dodelitve pravic definiramo vloge, izvedemo vključitev oseb – uporabnikov v ustrezne vloge in jim dodelimo gesla.
Upoštevamo tudi varnostno politiko. Pravice za dostop do podatkov in uporabo programskih modulov dodelimo naenkrat celotni posamezni skupini uporabnikov, ki izvajajo določeno vlogo.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 332 -
Dodelitev pravic za delo z IR
Razvoj po strukturnem pristopu Postopki strukturnega pristopa:
Zajem in specifikacija zahtev; Analiza; Načrtovanje; Izvedba; Testiranje; Namestitev in uvedba:
• Namestitev IR,• Dodelitev pravic za delo z IR,• Prevedba podatkov,• Izvedba potrditvenega testa IR,• Izvedba končnega testa IR,• Uvajanje uporabnikov in skrbnikov za delo z IR,• Prehod na novi sistem.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 333 -
Kje smo?
Namestitev in uvedba – Prevedba
Prevedba podatkov pomeni vzpostavitev začetnega stanja podatkov.
Prevedba podatkov je lahko zelo kompleksen proces, saj se poleg prenosa podatkov pogosto izvaja tudi čiščenje, agregacija, reorganizacija podatkovnih struktur itd.
Podatki v obstoječih sistemih so pogosto pomanjkljivi ali nepopolni, zapisani v obliki, ki je razumljiva zgolj programerjem itd.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 334 -
Prevedba podatkov
Namestitev in uvedba – Prevedba
Načrt za prevedbo podatkov je narejen v sklopu načrta namestitve in uvedbe. Programski moduli, ki so potrebni za prevedbo podatkov, so narejeni v sklopu izvedbe.
Prevedba podatkov v sklopu namestitve in uvedbe poteka v testno in produkcijsko okolje.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 335 -
Prevedba podatkov
Namestitev in uvedba – Prevedba
Prevedba podatkov v testno okolje se izvede v sklopu namestitve testnega okolja. Po potrebi se lahko izvede večkrat. Zagotavljanje testnih podatkov ter ponovljivosti
testov je lahko zelo kompleksna naloga…
Prevedba podatkov v produkcijsko okolje se izvede v sklopu namestitve IR v produkcijsko okolje. Navadno gre za ponovitev že preverjenih in utečenih
postopkov prevedbe, ki zagotovijo pravilen prenos podatkov.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 336 -
Prevedba podatkov
Razvoj po strukturnem pristopu Postopki strukturnega pristopa:
Zajem in specifikacija zahtev; Analiza; Načrtovanje; Izvedba; Testiranje; Namestitev in uvedba:
• Namestitev IR,• Dodelitev pravic za delo z IR,• Prevedba podatkov,• Izvedba potrditvenega testa IR,• Izvedba končnega testa IR,• Uvajanje uporabnikov in skrbnikov za delo z IR,• Prehod na novi sistem.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 337 -
Kje smo?
Namestitev in uvedba – Potrditveni test Potrditveni test izvedemo v testnem okolju. Predstavlja zaključni test pravilnega
delovanja celotne IR v testnem okolju in zajema vse funkcionalnosti sistema, potrebne za delovanje v testnem okolju.
Poteka na osnovi načrta testiranja in se zaključi s potrdilom o ustreznosti IR za namestitev v produkcijsko okolje.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 338 -
Izvedba potrditvenega testa
Razvoj po strukturnem pristopu Postopki strukturnega pristopa:
Zajem in specifikacija zahtev; Analiza; Načrtovanje; Izvedba; Testiranje; Namestitev in uvedba:
• Namestitev IR,• Dodelitev pravic za delo z IR,• Prevedba podatkov,• Izvedba potrditvenega testa IR,• Izvedba končnega testa IR,• Uvajanje uporabnikov in skrbnikov za delo z IR,• Prehod na novi sistem.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 339 -
Kje smo?
Namestitev in uvedba – Končni test
Končni test izvedemo v produkcijskem okolju.
Predstavlja končni test pravilnega delovanja IR v produkcijskem okolju in poteka na produkcijskih primerih - na "živih" oz. produkcijskih podatkih v produkcijskem okolju.
V končni test običajno ne moremo zajeti vse funkcionalnosti sistema. Poteka na osnovi načrta testiranja in se zaključi s potrdilom o ustreznosti IR za uporabo v produkcijskem okolju.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 340 -
Izvedba končnega testa
Razvoj po strukturnem pristopu Postopki strukturnega pristopa:
Zajem in specifikacija zahtev; Analiza; Načrtovanje; Izvedba; Testiranje; Namestitev in uvedba:
• Namestitev IR,• Dodelitev pravic za delo z IR,• Prevedba podatkov,• Izvedba potrditvenega testa IR,• Izvedba končnega testa IR,• Uvajanje uporabnikov in skrbnikov za delo z IR,• Prehod na novi sistem.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 341 -
Kje smo?
Namestitev in uvedba – Uvajanje
Naloga uvajanja je naučiti uporabnike uporabljati in skrbeti za IR.
Uvajanje izvaja uvajalec, ki je v primeru razvoja IR običajno član razvojne ekipe, v primeru nakupa IR pa predstavnik proizvajalca.
Osnovni cilj uvajanja je vsako skupino uporabnikov naučiti uporabljati tiste sklope IR, ki jih uporabniki pri svojem delu potrebujejo.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 342 -
Uvajanje uporabnikov in skrbnikov za delo z IR
Namestitev in uvedba – Uvajanje
V okviru obravnavane aktivnosti je potrebno poleg običajnih uporabnikov uvesti tudi skrbnike IR.
Poleg uvajanja samega je potrebno poskrbeti tudi za pripravo uvajalnih gradiv in testnih podatkov v podatkovni bazi, ki bodo služili za potrebe uvajanja.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 343 -
Uvajanje uporabnikov in skrbnikov za delo z IR
Namestitev in uvedba – Uvajanje
Smernice in priporočila za uvajanje: uvajanje uporabnikov za uporabo novega sistema naj
poteka ločeno za običajne uporabnike in za skrbnike novega sistema;
najprej naj predstavniki izvajalca ali prodajalca IR izvedejo uvajanje skrbnikov, nato pa naj se izvede uvajanje uporabnikov – možen pristop: train the trainer;
pri uvajanju je potrebno upoštevati velikost organizacije in uporabnike razdeliti v skupine glede na njihovo področje dela in podobnost načina uporabe novega sistema;
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 344 -
Uvajanje uporabnikov in skrbnikov za delo z IR – Smernice
Namestitev in uvedba – Uvajanje
Smernice in priporočila za uvajanje (nadaljevanje): uvajanje naj poteka v testnem okolju; če se uvajanje
izvaja na produkcijski podatkovni bazi, je potrebno paziti, da ne izvajamo aktivnosti, kjer bi nastali podatki, ki jih ne bi mogli povrniti v prejšnje stanje oz. v stanje, ki odraža dejansko stanje v organizaciji,
uporabniki morajo imeti dostop do sistema pomoči uporabnikom (raznovrstnih navodil), hkrati pa tudi vedeti, na koga se lahko obrnejo, če naletijo na težave, ki jih kljub navodilom ne znajo sami rešiti.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 345 -
Uvajanje uporabnikov in skrbnikov za delo z IR – Smernice
Razvoj po strukturnem pristopu Postopki strukturnega pristopa:
Zajem in specifikacija zahtev; Analiza; Načrtovanje; Izvedba; Testiranje; Namestitev in uvedba:
• Namestitev IR,• Dodelitev pravic za delo z IR,• Prevedba podatkov,• Izvedba potrditvenega testa IR,• Izvedba končnega testa IR,• Uvajanje uporabnikov in skrbnikov za delo z IR,• Prehod na novi sistem.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 346 -
Kje smo?
Namestitev in uvedba – Prehod
Prehod na nov sistem predstavlja trenutek, ko je IR primerna za uporabo v produkcijskem okolju.
O trenutku začetka uporabe nove IR mora biti vnaprej obveščena vsa organizacija.
Najprimernejši termini za začetek uporabe nove IR so delovno neintenzivna obdobja. Pogoj, ki mora biti izpolnjen za možnost začetka uporabe, so uspešno opravljene aktivnosti namestitve, testiranja, prevedbe podatkov in uvajanja. RAZVOJ INFORMACIJSKIH SISTEMOV
Visokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 347 -
Prehod na nov sistem
Namestitev in uvedba – Prehod
V praksi se za uvedbo IR uporabljajo različne strategije. V grobem jih delimo v tri skupine: Fazni pristop (Phased strategy); Zamenjava ali vse naenkrat (Replacement strategy,
BigBang); Vzporedno delovanje (Parallel strategy).
Poleg omenjenih strategij uvedbe se lahko uporabljajo tudi različne kombinacije.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 348 -
Strategije uvedbe
Namestitev in uvedba – Prehod
Fazni pristop: Star/obstoječ sistem nadomestimo z novim v več
korakih oziroma postopoma. Vsebina posameznega koraka ali faze je lahko
različna; npr. najprej eno poslovno področje, potem drugo itd., ali najprej en funkcionalni sklop, zatem drugi itd.
Prednosti postopne uvedbe oziroma postopne zamenjave starega z novim sistemom so številne, vendar takšen pristop ni vedno izvedljiv, saj pogosto zahteva začasne vmesnike za komunikacijo med deli novega in starega sistema.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 349 -
Strategije uvedbe – Fazni pristop
Namestitev in uvedba – Prehod
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 350 -
Strategije uvedbe – Fazni pristop – problem začasnih vmesnikov
Zunanji sistemi
Star sistem
Uvedba celotnega sistema naenkrat
Zunanji sistemiZunanji sistemi
Star sistem
Uvedba po delihI faza.
Namestitev in uvedba – Prehod
Zamenjava ali vse naenkrat: pri tej strategiji gre za enkratno zamenjavo
obstoječega sistema z novim. Na izbran (in ustrezno načrtovan) trenutek se stare aplikacije ugasne in nadomesti z novimi.
Takšen pristop zmanjša potrebo po virih, vendar je bolj tvegan, saj pomeni, da nimamo več dostopa do starega sistema v primeru, da gre kaj narobe.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 351 -
Strategije uvedbe – Zamenjava ali vse naenkrat
Namestitev in uvedba – Prehod
Vzporedno delovanje: strategija vzporednega delovanja temelji na
vzporedni uporabi starega in novega sistema. Med uvajanjem novega sistema v produkcijo starega
ne ugašamo, temveč uporabljamo oba vzporedno. Prednost takšne strategije je v zmanjšanju tveganja
(če gre kaj narobe, imamo še vedno na voljo star sistem), ključna slabost pa v zahtevnosti po virih ter potencialni neskladnosti podatkov zaradi dvojnega zajema.
V praksi se strategija vzporednega delovanja pogosto uporablja v okrnjeni obliki, kjer star sistem ohranimo za vpoglede, medtem ko so vi vnosi izvedeni v novem sistemu.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 352 -
Strategije uvedbe – Vzporedno delovanje
Namestitev in uvedba – Prehod
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 353 -
Strategije uvedbe
Možni pristopi
Vse naenkrat
Postopoma
Zamenjava
Vzporedno
Po področjih
Po lokacijah
Po modulih
Po starih aplikacijah
V celoti vzporedno
Delno vzporedno
V celoti zamenjava
Poglavje IIIObjektni razvoj
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 354 -
Osnovni principi objektne usmerjenosti Osnove modelirnega jezika UML in procesa RUP Objektna analiza in načrtovanje
Objektni pristop
Objektni pristop k razvoju IR se pojavi kot posledica uveljavitve objektnih programskih jezikov in objektnih tehnologij…
V 90-ih letih nastane več deset metod objektne analize in načrtovanja IR.
Objektna analiza in načrtovanje se od strukturnega ločuje predvsem v predstavitvi realnega sveta: ne ločuje med podatki in aktivnostmi temveč vse modelira z objekti.RAZVOJ INFORMACIJSKIH SISTEMOV
Visokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 355 -
Osnovne značilnosti objektnega pristopa
Objektni pristop
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 356 -
Osnovne značilnosti objektnega pristopa
Profesor
Študent
Učilnica Strukturni pristop1. Podatki
Študent Profesor Učilnica Predmet …
2. Procesi Vzdrževanje izpitnih rokov Opravljanje izpita Vodenje izpitne evidence …
Podatkovna baza
Programski modul
Programski modul
Programski modul
Programski modul
Programski modul
Programski modul
Programski modulProgramski modul:
Pregled zasedenosti učilnice
Podatkovna baza
Objektni pristop
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 357 -
Osnovne značilnosti objektnega pristopa
Profesor
Študent
UčilnicaObjektni pristop
Objekt tipa ŠTUDENTLastnosti:
– Priimek, – Ime, – Vpisna številka,– …
Funkcije:– Prijava na izpit – Odjava iz izpita– Pregled elektronskega indeksa– …
Objekt tipa UČILNICALastnosti:
– Velikost, – Število sedežev, – …
Funkcije:– Pregled predavanj v učilnici po dnevih– Izpis naziva profesorja P, ki na določen dan D
predava v učilnici– …
Objekt Marko: PROFESOR
Objekt NP15: UČILNICA
Ali je učilnica NP15 15.5.07 prosta?
Objektni pristop
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 358 -
Primerjava postopkov strukturnega in objektnega razvoja IR
Zajem zahtev
Analiza
Načrtovanje
Izvedba
Uvajanje
Vzdrževanje
Testiranje
Življenjski cikel razvoja IR
Objektni pristop
Sledi: Osnovni principi objektne usmerjenosti Osnove modelirnega jezika UML in procesa RUP Objektna analiza in načrtovanje
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 359 -
Vsebina
Razvoj po objektnem pristopu Objektni pristop:
Osnovni principi objektne usmerjenosti;• Objekt in razred• Enkapsulacija ali skrivanje podatkov• Dedovanje in hierarhija
Jezik UML in proces RUP; Objekta analiza in načrtovanje;
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 360 -
Kje smo?
Osnovni principi objektne usmerjenosti Objekt lahko predstavlja fizično entiteto ali
konceptualni pojem. Učitelj, učenec,… Predmet, test,…
S stališča razvoja IR je objekt koncept, abstrakcija ali stvar z natančno določenimi mejami in pomenom za IR.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 361 -
Definicija objekta
Osnovni principi objektne usmerjenosti Objekti lahko predstavljajo tudi konkretne
koncepte s področja računalniških jezikov in rešitev: Seznam Indeks …
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 362 -
Definicija objekta
Osnovni principi objektne usmerjenosti Objekt je abstrakcija neke entitete, ki je
pomembna za IR…
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 363 -
Abstrakcija
Vesna: ProfesorIme: Vesna JugTelefon: 01/4768 814
Prijavi (int pid): boolean
Osnovni principi objektne usmerjenosti Objekt ima svoje stanje, obnašanje in
identiteto.
Stanje objekta določajo njegove lastnosti: Flomaster ima barvo, proizvajalca, debelino,… Knjiga ima vsebino, število strani,
založnika,…
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 364 -
Stanje, obnašanje in identiteta objekta
Osnovni principi objektne usmerjenosti Objekt se zaveda svojega stanja! Ve
kakšne vrednost imajo lastnosti, ki ga opisujejo. Flomaster je rumene barve, debeline 3mm,
proizvajalca Pilot,… Knjiga opisuje razvoj IS, ima 432
strani, izdaja jo založba Pasadena,…
Vsakokrat ko se spremeni vrednost neke lastnosti, ki nas o objektu zanima, rečemo se je spremenilo stanje objekta.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 365 -
Stanje, obnašanje in identiteta objekta
Osnovni principi objektne usmerjenosti Objekti imajo svoje obnašanje.
Študent študira, se prijavi na izpit, opravlja izpit, posluša predavanja,…
Pisalo piše??? Kdo v resnici piše?
Objekt se zaveda, kajlahko počne in kaj selahko z njim počne!
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 366 -
Stanje, obnašanje in identiteta objekta
Osnovni principi objektne usmerjenosti Objekte istega tipa združujemo v razrede. Razred je
opis skupine objektov z enakimi lastnostmi, enakim obnašanjem, povezavami in semantiko.
abstrakcija, ki poudarja pomembne karakteristike in izpusti ostale nepomembne karakteristike.
Objekt je primerek razreda.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 367 -
Razred
Osnovni principi objektne usmerjenosti Odnos med objektom in razredom je
podoben odnosu med entiteto in entitetnim tipom.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 368 -
Razred
Objekti Razred
Ime razreda: ProfesorLastnosti:• Ime• Priimek• …Obnašanje• …
Osnovni principi objektne usmerjenosti Koliko razredov je na sliki?
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 369 -
Razred
Razvoj po objektnem pristopu Objektni pristop:
Osnovni principi objektne usmerjenosti;• Objekt in razred• Enkapsulacija ali skrivanje podatkov• Dedovanje in hierarhija
Jezik UML in proces RUP; Objekta analiza in načrtovanje;
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 370 -
Kje smo?
Osnovni principi objektne usmerjenosti Enkapsulacija govori o organizaciji
podatkov, ki jih vemo o objektih, na način, da jih bo moč učinkovito uporabljati in vzdrževati?
Kar vemo o objektu, razdelimo v dve skupini: Kar moramo vedeti, da objekt lahko uporabimo, Kar moramo vedeti, da bo objekt pravilno deloval.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 371 -
Enkapsulacija ali skrivanje podatkov
Osnovni principi objektne usmerjenosti Želimo se naučiti voziti avtomobil. Kaj
moramo o avtomobilu vedeti? Kako se upravlja z volanom, kako se
zavira in p pospešuje,… Potrebno vedeti, kako deluje
motor? Kako pride do vžiga?Kaj natančno se zgodi, kopritisnemo na plin?
Za delo z objektom ne potrebujemo vseh podatkov o objektu, temveč samo določene – vmesnik (interface).
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 372 -
Enkapsulacija ali skrivanje podatkov
Osnovni principi objektne usmerjenosti Kaj mora veljati, da objekt deluje pravilno?
Vmesnik nam omogoča uporabo objekta. Za njegovo pravilno delovanje pa morajo biti vse funkcije, ki jih vmesnik daje na voljo, tudi dejansko implementirane!
Za delovanje objekta moramo priskrbeti mehanizem, ki sezna odzivati na vmesnik…
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 373 -
Enkapsulacija ali skrivanje podatkov
Osnovni principi objektne usmerjenosti Enkapsulacija objekta zahteva, da
skrijemo: Implementacijo obnašanja, ki je na voljo prek
vmesnika; Podatke znotraj objekta, ki so potrebni za
implementacijo obnašanja in beležijo stanje objekta v vsakem trenutku njegovega obstoja.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 374 -
Enkapsulacija ali skrivanje podatkov
Razvoj po objektnem pristopu Objektni pristop:
Osnovni principi objektne usmerjenosti;• Objekt in razred• Enkapsulacija ali skrivanje podatkov• Dedovanje in hierarhija
Jezik UML in proces RUP; Objekta analiza in načrtovanje;
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 375 -
Kje smo?
Osnovni principi objektne usmerjenosti Dedovanje je ključen koncept objektnega
razvoja. Pove, da ima objekt v času svojega kreiranja dostop
tudi do lastnosti drugih razredov poleg dostopa do razreda, kateremu pripada.
Podedovan razred združi vse lastnosti (lastne in podedovane) v svojo definicijo.
Primer: Profesor je poseben primer pedagoškega delavca. Objekt tipa profesor ima lastnosti pedagoškega
delavca ter svoje lastne lastnosti.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 376 -
Hierarhija in dedovanje
Osnovni principi objektne usmerjenosti Primer razreda Profesor in Pedagoški delavec
Opis: P ima enake lastnosti
kot PD. Za P nas zanima tudi
akademski naziv teršt. predmetov, ki jihpoučuje.
P lahko razpisuje tuditeme za diplome.
P ima pri vnašanju ocen več pravic kot PD. Lahko vpisuje tudi ocene ustno…
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 377 -
Hierarhija in dedovanje
Pedagoški delavecImePriimekEMŠOTelefonDelovno mestoDatum rojstvaNaslov…Razpiši izpitni rokVnesi oceno
ProfesorAkademski nazivŠtevilo predmetov…
Vnesi ocenoRazpiši temo diplome
Osnovni principi objektne usmerjenosti Razrede lahko zapišemo v hierarhijo.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 378 -
Hierarhija in dedovanje
Pedagoški delavec
Delavec
Oseba
Profesor
Redni profesor
Asistent
Strokovni sodelavecRaziskovalec
Osnovni principi objektne usmerjenosti Hierarhija razredov v Delphi razvojnem
okolju…
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 379 -
Hierarhija in dedovanje
Osnovni principi objektne usmerjenosti Delček
razredne hierarhije java.awt…
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 380 -
Hierarhija in dedovanje
Razvoj po objektnem pristopu Objektni pristop:
Osnovni principi objektne usmerjenosti; Jezik UML in proces RUP:
• O jeziku UML• Osnove procesa objektnega razvoja RUP;
Objekta analiza in načrtovanje;
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 381 -
Kje smo?
Jezik UML in proces RUP
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 382 -
Zakaj UML?
Jezik za modeliranje
Poenotenproces
Skupinski razvoj
Jezik UML in proces RUP
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 383 -
UML – univerzalni modelirni jezik
Univerzalni modelirni jezik (UML) je jezik za specifikacijo, vizualizacijo, konstrukcijo in dokumentacijo izdelkov v okviru objektnega razvoja informacijskih rešitev.
Univerzalni modelirni jezik
Jezik UML in proces RUP
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 384 -
Razlogi za nastanek UML
V začetku 90-ih več kot 50 OO metod! Fusion, Shlaer-Mellor, ROOM, Wirfs-Brock, Coad-
Yourdon, MOSES, BOOM, OOSD, OSA, BON, Catalysis, HOOD, Ooram, DOORS …
Problem: Presek in konflikti v meta-modelih… Različne grafične notacije… Procesi različni ali manjkajo Gospodarstvo potrebuje standard!!!
Jezik UML in proces RUP
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 385 -
UML – Zgodovina do 1997
Jezik UML in proces RUP
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 386 -
Drugi viri in prispevki
Fusion
opisi operacij,oštevilčenje sporočil
Meyer
predpogoji inpopogoji
Harel
diagrami stanj
Wirfs-Brock
odgovornostiOdell
klasifikacija
Shlaer - Mellor
življenjski cikli objekta
Gamma, et.al
ogrodja, vzorci,opombe
BoochJacobsonRumbaugh
Jezik UML in proces RUP
UML 1.1 specifikacija predstavlja integracijo različnih metod/pristopov problem slaba semantična integracija. Številne revizije: UML 1.3, 1.4, 1.5 UML 2.0 največja revizija – odpravlja semantične
neskladnosti… sprejet v dveh delih: oktobra 2004 prvi del, novembra 2005 drugi del.
V postopku sprejemanja UML 2.1
Na voljo številna orodja, ki podpirajo UML 2.0 specifikacijo…
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 387 -
UML danes
Jezik UML in proces RUP
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 388 -
UML diagrami
Diagrami primerov uporabe
Razredni diagrami
Diagrami zapore-dja
Diagrami sodelova-njaKompo-
nentni diagrami
Diagrami stanj
Diagrami impleme-
ntacije
Diagrami aktivnosti
Objektni diagramiUML diagramske tehnike
Jezik UML in proces RUP
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 389 -
UML diagramske tehnike – enostavnost
profesorizbira predmetov
za poučevanje
študent
seznam predavanj
prijava na izbirni predmet
vnos podatkov o študentih
vnos podatkov o profesorjih
Referent
sistem za pripravo urnikazaključitev prijave
?
Jezik UML in proces RUP
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 390 -
UML diagramske tehnike – kompleksnost
Jezik UML in proces RUP
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 391 -
UML diagramske tehnike – hrbtenica razvoja
Actor A
Use-Case 1
Use-Case 2
Actor B
user : »ç¿ëÀÚ
mainWnd : MainWnd
fileMgr : FileMgr
repository : Repositorydocument : Document
gFile : GrpFile
9: sortByName ( )
L1: Doc vi ew request ( )
2: fetchDoc( )
5: readDoc ( )
7: readFile ( )
3: create ( )
6: fi llDocument ( )
4: create ( )
8: fil lFile ( )
GrpFile
read( )open( )create( )fillFile( )
rep
Repository
name : char * = 0
readDoc( )readFile( )
(from Persistence)
FileMgr
fetchDoc( )sortByName( )
Docum entList
add( )delete( )
Document
name : intdocid : intnumField : int
get( )open( )close( )read( )sortFileList( )create( )fillDocument( )
fList
1
FileList
add( )delete( )
1
File
read( )
read( ) fill the code..
UI
MFC
RogueWave
global
DocumentApp
Persistence W indow95
¹®¼ °ü¸ ® Ŭ ¶óÀ̾ ðÆ® .EXE
W indowsNT
¹®¼ °ü¸ ® ¿£Áø.EXE
W indowsNT
W indows95
Solaris
ÀÀ¿ë¼ ¹ö.EXE
AlphaUNIX
IBM Mainframe
µ¥ÀÌŸº£À̽ º¼ ¹ö
W indows95
¹®¼ °ü¸® ¾ ÖÇø´
ºÐ»ê ȯ°æÀÇ Çϵå¿þ¾ î¹× ³×Æ®¿÷À¸·ÎÀÇ Á¤º¸ ½ ýºÅÛ ¿¬°á ¸ðµ¨ - À© µµ¿ì 95 : Ŭ¶óÀ̾ ðÆ ® - À© µµ¿ì NT: ÀÀ¿ë¼ ¹ö - À¯´Ð½ º ¸Ó½ Å: ÀÀ¿ë ¼ ¹ö ¹× µ¥ÀÌŸ ¼ ¹ ö, Åë½ Å ¼ ¹ö - IBM ̧ ÞÀÎÇÁ·¹ ÀÓ: µ¥À ÌŸ ¼ ¹ö, Åë½ Å ¼ ¹ö
Document
FileManager
GraphicFileFile
Repository DocumentList
FileList
usermainWnd fileMgr :
FileMgrrepositorydocument :
DocumentgFile
1 : Doc v iew re ques t ( )
2: fetch Doc( )
3: cr eate ( )
4: creat e ( )
5 : readD oc ( )
6: f il lDocum ent ( )
7: readFi l e ( )
8: f ill Fi l e ( )
9: sortByNam e ( )
Ư Á¤¹®¼ ¿ ¡ ´ëÇÑ º ±̧â ¦̧ »ç¿ëÀÚ°¡ ¿ äûÇÑ ´Ù.
È À Ï°ü¸®À Ú´Â ÀÐ ¾î¿Â ¹®¼ ÀÇ Á¤º ¸̧ ¦ ÇØ´ç ¹®¼ °´Ã¼ ¿¡ ¼³Á ¤À» ¿ äûÇÑ ´Ù.
È ̧é °´Ã ¼ ´Â ÀÐ ¾îµéÀ Î ° ´Ã¼µé¿¡ ´ëÇØ À̸§º°·Î Á ¤·ÄÀ» ½ÃÄÑ È ̧é ¿¡ º ¸¿©ÁØ´Ù.
Customernameaddr
withdraw()fetch()send()
receive()
<<entity>>
Forward Engineering (specifikacija -> koda)Reverse Engineering (koda -> specifikacija)
Razvijalec
Poznavalecobravnavanega
področja
Openning
Writing
ReadingClosing
add file [ numberOffile==M AX ] / flag OFF
add file
close file
close file
Use-Case 3
urejanje izvorne kode, prevajanje, razhroščevanje, povezovanje
diagram primera uporabe razredni diagram
diagram sodelovanja
diagram zaporedja
diagramkomponent
diagram stanj
diagrampaketov
diagram implementacijerazred
Razvoj po objektnem pristopu Objektni pristop:
Osnovni principi objektne usmerjenosti; Jezik UML in proces RUP:
• O jeziku UML• Osnove procesa objektnega razvoja RUP;
Objekta analiza in načrtovanje;
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 392 -
Kje smo?
Jezik UML in proces RUP
Proces določa kdo dela kaj, kdaj in kako za doseganje določenega cilja.
Cilj razvoja IR je njena izgradnja ali izboljšava.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 393 -
Proces razvoja
Nove ali spremenjenezahteve
Nov ali spremenjensistem
Proces razvoja IR
Jezik UML in proces RUP
RUP – Rational Unified Process primer procesa objektnega razvoja avtor: podjetje Rational
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 394 -
Proces razvoja – RUP
Jezik UML in proces RUP
Glavne lastnosti RUP: Daje smernice za učinkovit razvoj kakovostne
programske opreme Zmanjšuje tveganje in povečuje predvidljivost Zajema in vpeljuje najboljše izkušnje
• učenje iz izkušenj drugih• mentorstvo v elektronski obliki• razširitev izobraževalnega gradiva
Pospešuje skupno vizijo in kulturo Vpeljuje načrt za uvedbo orodij Omogoča enostaven in hiter dostop do informacij v
elektronski obliki (spletna stran,...)
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 395 -
RUP – glavne lastnosti
Jezik UML in proces RUP
RUP opisuje, kako učinkovito uporabiti šest najboljših izkušenj s področja razvoja IR.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 396 -
RUP – šest poglavitnih dobrih praks
Iterativni razvoj
Nadzorovanje sprememb
Uporaba komponentne
arhitekture
Obvladovanje zahtev
Vizualno modeliranje
Preverjanjekakovosti
Jezik UML in proces RUP
Primeri uporabe so osnova mnogim aktivnostim procesa: Izdelava in potrditev razvojnega modela Določitev preizkusnih primerov in postopkov za
model preizkušanja Načrtovanje iteracij Izdelava uporabniške dokumentacije vpeljava sistema Primeri uporabe pripomorejo k uskladitvi vsebine
različnih modelov
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 397 -
RUP – primeri uporabe kot osnova drugim aktivnostim
Jezik UML in proces RUP
Primeri uporabe so hrbtenica procesa RUP.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 398 -
RUP – primeri uporabe so hrbtenica procesa RUP
Zajem zahtev
Analiza
Načrtovanje
Implementacija
Testiranje
Jezik UML in proces RUP
Na arhitekturo se osredotočimo v začetnih iteracijah Zasnova in potrditev arhitekture je eden primarnih
ciljev razvoja IR. Dokument o arhitekturi IR pomeni primarni
izdelek, ki opisuje izbrano arhitekturo. Drugi izdelki, ki izhajajo iz arhitekture
Smernice razvoja Zgradba izdelka Sestava skupine
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 399 -
RUP – arhitekturna usmerjenost
Jezik UML in proces RUP
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 400 -
RUP – arhitekturna usmerjenost – 4+1 pogledi na arhitekturo
Procesnipogled
Postavitveni pogled
Logičnipogled
Izvedbenipogled
ProgramerUpravljanje s prog. op.
ZmogljivostPrilagodljivostThroughput
System IntegratorsSystem topology
Delivery, installationcommunication
***System Engineering
Primer uporabe
Zgradba
Analitik/Razvijalec Končni upor.
Funkcionalnost
Procesnipogled
Postavitveni pogled
Logičnipogled
Izvedbenipogled
ProgramerUpravljanje z IR
ZmogljivostRazširljivostPrepustnost
Sistemski povezovalecTopologija sistema
Predaja v uporabo, namestitevkomunikacije
Sistemski inženir
Primer uporabe
ZgradbaAnalitik/Razvijalec
Končniuporabnik
Funkcionalnost
Jezik UML in proces RUP
Omogoča vzpostavitev in ohranitev nadzora nad projektom, obvladovanje kompleksnosti in vzdrževanje celovitosti sistema.
Razširja možnosti ponovne uporabe izdelkov.
Pospešuje komponentno usmerjen razvoj.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 401 -
RUP – prednosti arhitekturno usmerjenega pristopa
Jezik UML in proces RUP
RUP zajema štiri faze: Začetna faza – vzpostavitev projekta, opredelitev
okvirjev obravnavanega področja, načrtovanje virov,...;
Zbiranje informacij – zbiranje informacij o obravnavanem področju, specifikacija značilnosti, načrtovanje arhitekture;
Konstrukcija – konstrukcija izdelka; Prevzem – predaja izdelka v uporabo končnemu
uporabniku.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 402 -
RUP – faze življenjskega cikla razvoja po RUP
Jezik UML in proces RUP
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 403 -
RUP – makro mejniki
MejnikDoločeni cilji
projekta/naloge
MejnikStabilna
arhitektura
MejnikUporabnik zadovoljen
MejnikIzdelek
delujoč/ ustrezen
Jezik UML in proces RUP
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 404 -
RUP – mikro mejniki
Začetna fazaZbiranje
informacij Konstrukcija Prevzem
čas
I1 I2 I3 I4 I5 I6 I7 I8
Iteracija je specifično zaporedje aktivnosti izvedenih na osnovi načrta in z določenim kriterijem vrednotenja, ki se konča z izdajo izdelka.
Iteracija
Jezik UML in proces RUP
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 405 -
RUP – gradnja modela sistema prek postopkov RUP
Poslovno modeliranje Primeri uporabe
poslovnega okoljaKonceptualni
model poslovnega okolja
Modelira poslovno okolje
Zajem zahtev
Model primerov uporabe
Prikazuje tiste primere uporabe iz poslovnega okolja,
za katere se bo razvijala IR
Analiza in načrtovanje Model
načrta
Prikazuje načrt za implementacijo rešitve
Modelizvedbe
Izvedba Prikazuje dejansko Izvedbo rešitve
Modeltestiranja
Prikazuje načrt testiranjaTestiranje
Objektni razvoj – RUP
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 406 -
RUP – prednosti arhitekturno usmerjenega pristopa
Osnovni postopki
Podporni postopki
V vsaki iteraciji gremo čez vse postopke
Razvoj IR konvergira od vzpostavitve projekta in zbiranja zahtev/podatkov proti konstrukciji in uvedbi
Jezik UML in proces RUP
RUP definira več postopkov: Osnovni postopki:
• Poslovno modeliranje• Zajem zahtev• Analiza in načrtovanje• Izvedba • Testiranje• Uvedba
Podporni postopki: • upravljanje s konfiguracijami • projektno vodenje• obvladovanje okolja
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 407 -
RUP – osnovni in podporni postopki
Razvoj po objektnem pristopu Objektni pristop:
Osnovni principi objektne usmerjenosti; Jezik UML in proces RUP; Zajem zahtev; Objekta analiza in načrtovanje
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 408 -
Kje smo?
RUP – Zajem zahtev
Namen zajema zahtev je: Doseči soglasje s stranko oz. uporabniki, kaj naj sistem
dela. Omogočiti razvijalcem boljše razumevanje zahtev sistema. Določiti meje sistema. Zagotoviti osnovo za načrtovanje tehnične vsebine. Definirati uporabniški vmesnik sistema.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 409 -
RUP – zajem zahtev
RUP – Zajem zahtev
Namen zajema zahtev je podoben kot pri strukturnem pristopu
V določeni meri uporabljamo podobne tehnike kot pri strukturnem pristopu
RUP za zapis zahtev uvaja višjo stopnjo formalnosti: Primeri uporabe (UML) Opisi s tokovi dogodkov Uporaba drugih tehnik UML v posebnih primerih
(diagrami stanj, diagrami aktivnosti, diagrami interakcije)
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 410 -
RUP – zajem zahtev
RUP – Zajem zahtev
Diagrami primerov uporabe Ključna elementa diagramov primerov uporabe sta
akter in primer uporabe Med seboj jih povezujemo
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 411 -
RUP – zajem zahtev – primeri uporabe
Akter
RUP – Zajem zahtev
Akter Akter je oseba ali stvar (sistem,
naprava), ki je:• izven sistema,• v neposredni interakciji s
sistemom.
Akter je na mejah sistema Poseben primer akterja je ura oz.
časovni prožilec, ki omogoča periodično proženje posameznih primerov uporabe
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 412 -
RUP – zajem zahtev – primeri uporabe
Stranka
Primer uporabe
RUP – Zajem zahtev
Primer uporabe Primer uporabe je zaporedje
akcij, ki jih izvede sistem in dajo določenemu akterju nek rezultat
Primer uporabe lahko obravnavamo tudi kot zaključen tok dogodkov z določenim namenom
Primer uporabe prikazuje pomembnejši način uporabe sistema za enega ali več akterijev, ki vplivajo na ta primer uporabe
Primer uporabe poimenujem z vidika uporabnika
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 413 -
RUP – zajem zahtev – primeri uporabe
Kupi vstopnico
Tok dogodkov
RUP – Zajem zahtev
Primer uporabe - tok dogodkov Opis dogajanja znotraj primera
uporabe Primer uporabe ima en osnovni
tok dogodkov. Primer uporabe ima več
alternativnih tokov:• Običajni primeri• Neobičajni primeri• Izjemni primeri in napake
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 414 -
RUP – zajem zahtev – primeri uporabe
RUP – Zajem zahtev Primer osnovnega toka dogodkov – Kupi vstopnico preko
interneta:1. Sistem prikaže seznam prireditev2. Kupec izbere prireditev3. Sistem vrne kupcu seznam terminov, kjer so še prosti sedeži za izbrano
prireditev in podrobne podatke o prireditvi.4. Kupec izbere termin5. Sistem prikaže kupcu matriko sedežev z označenimi zasedenimi in
rezerviranimi sedeži.6. Kupec izbere enega ali več prostih sedežev7. Sistem označi izbrane sedeže kot rezervirane8. Sistem zahteva vnos imena in št. kreditne kartice9. Kupec vnese ime in št. kreditne kartice10.Sistem komunicira z zunanjim sistemom ponudnika kreditnih kartic11.Zunanji sistem vrne sporočilo o uspešni transakciji12.Sistem označi sedeže kot prodane13.Sistem prikaže zaslon z vstopnico/cami, ki vsebuje tudi referenčne št.
vstopnic14.Sistem pošlje e-pošto stranki z enakimi podatki kot v točki 12RAZVOJ INFORMACIJSKIH SISTEMOV
Visokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 415 -
RUP – zajem zahtev – primeri uporabe
RUP – Zajem zahtev Primer alternativnega toka dogodkov – Kupi vstopnico preko
interneta:1. Sistem prikaže seznam prireditev2. Kupec izbere prireditev3. Sistem vrne kupcu sporočilo, da so vse vstopnice na vseh terminih
prodane.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 416 -
RUP – zajem zahtev – primeri uporabe
RUP – Zajem zahtev Podtokovi
Pri obsežnejših oz. ponavljajočih tokovih dogodkov si pogosto pomagamo s podtokovi
Podtokovi omogočajo ponovno uporabo dela toka dogodkov Primer podtokov:
1. Sistem prikaže uporabniku seznam oseb2. Uporabnik iz seznama izbere določeno osebo3. Sistem prikaže podrobnosti osebe4. Uporabnik lahko izbere brisanje osebe (glej Podtok A) ali
ažuriranje podatkov o osebi (glej Podtok B).5. Sistem osveži prikaz
4A.1 Sistem izbriše podatke o osebi4A.2 Sistem izpiše sporočilo o uspešnem brisanju podatkov o osebi
4B.1 Uporabnik ažurira podatke o osebi in spremembe potrdi4B.2 Sistem izpiše sporočilo o uspešnem ažuriranju podatkov o osebi
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 417 -
RUP – zajem zahtev – primeri uporabe
Podtok A
Podtok B
RUP – Zajem zahtev Komunikacija
Komunikacija je povezava, ki prikazuje, da akter uporablja sistem na nek način (primer uporabe) oz. da je v okviru primera uporabe uporabljen nek zunanji sistem.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 418 -
RUP – zajem zahtev – primeri uporabe
Komunikacija
Stranka Kupi vstopnico Bančni sistem
RUP – Zajem zahtev UML ne predpisuje usmerjanja
komunikacij, usmerjanje je razširitev, ki je opredeljena v RUP
Komunikacija in usmerjenost kadar gre puščica iz akterja proti primeru uporabe
to pomeni, da je akter začetnik primera uporabe (uporablja določeno funkcionalnost sistema)
kadar gre puščica iz primera uporabe proti akterju (ali pa puščic ni) to pomeni, da ti akterji sodelujejo pri določenem primeru uporabe
vsak primer uporabe mora imeti povezavo, ki je usmerjena od akterja proti primeru uporabe
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 419 -
RUP – zajem zahtev – primeri uporabe
RUP – Zajem zahtev Odvisnost “vključuje” - <<include>>:
Vedno poteka le med dvema primeroma uporabe in sicer od “izhodiščnega” primera uporabe, ki vključuje tudi drug primer uporabe
Omogoča ponovno uporabo primera uporabe
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 420 -
RUP – zajem zahtev – primeri uporabe
Odvisnost “vključuje”
Stranka
Kupi vstopnico
<<include>>
Rezervirajvstopnico
Plačaj s kartico<<include>>
RUP – Zajem zahtev Odvisnost “razširja” - <<extend>>:
Vedno poteka le med dvema primeroma uporabe in sicer od primera uporabe, ki razširja “izhodiščni” primer uporabe
Omogoča, da se primer uporabe izvede pod določenim pogojem (razširitvena točka - “extension point”).
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 421 -
RUP – zajem zahtev – primeri uporabe
Odvisnost “razširja”
StrankaKupi vstopnico
<<extend>>
Pridobi dodatenračun
RUP – Zajem zahtev Generalizacija med
akterji Prikazuje, da določen
akter lahko sistem uporablja tudi na tak način kot določen drugi akter.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 422 -
RUP – zajem zahtev – primeri uporabe
Generalizacija med akterji
Stranka
Kupi vstopnico
Rezervirajvstopnico
Stranka “VIP”
Prijavi bonus
Preglej bonus
RUP – Zajem zahtev Generalizacija med
primeri uporabe Omogoča, da določen
primer uporabe “razbijemo” na bolj podrobne primere uporabe
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 423 -
RUP – zajem zahtev – primeri uporabe
Generalizacija med primeri uporabe
Plačaj s kartico
Plačaj z bančno kartico
Plačaj s kreditno kartico
Meja sistema
RUP – Zajem zahtev Meja sistema
Mejo sistema lahko eksplicitno prikažemo s pomočjo pravokotnika
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 424 -
RUP – zajem zahtev – primeri uporabe
Stranka
Kupi vstopnico
Rezervirajvstopnico
Stranka “VIP”
Prijavi bonus
Preglej bonus
RUP – Zajem zahtev
Možen pristop pri načrtovanju diagrama primerov uporabe:1. Identificiraj akterje2. Identificiraj primere uporabe sistema3. Poveži akterje in primere uporabe (ugotovi na
kakšne načine različni akterji uporabljajo sistem)4. Odstrani odvečne primere uporabe (npr.
neuporabljeni primeri uporabe)5. Odstrani odvečne akterje (npr. podvojeni akterji;
akterji, ki to niso ipd.)6. Preveri in popravi morebitne napake
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 425 -
RUP – zajem zahtev – primeri uporabe
RUP – Zajem zahtev
Pogoste napake pri načrtovanju primerov uporabe:1. Nejasno/nepravilno opredeljene meje sistema2. Veliko število primerov uporabe na enem diagramu3. Križanje povezav, nepreglednost diagrama4. Primeri uporabe niso napisani s stališča akterja oz.
uporabnika (npr. “Kupi vstopnico” vs. “Prodaj vstopnico”)
5. Model primerov uporabe je podoben diagramu podatkovnih tokov
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 426 -
RUP – zajem zahtev – primeri uporabe
Primer
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 427 -
RUP – zajem zahtev – primeri uporabe
Stranka
Kupi vstopnico preko spleta
Rezervirajvstopnico
Stranka “VIP”
Prijavi bonus
Preglej bonus
Referent
Uredi prireditve
Dodeli stranki status“VIP”
Plačaj preko spleta
<<include>>
<<include>>
Unovči bonus
<<extend>>
Spletniplačilnisistem
RUP – Zajem zahtev
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 428 -
RUP – zajem zahtev – pomembni izdelki
Dodatnespecifikacije
Slovar
Opisi primerov uporabe
...
Model primerov uporabe
AkterjiPrimeri uporabe
RUP – Zajem zahtev
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 429 -
RUP – zajem zahtev – Model primerov uporabe
Opisi primerov uporabe
...
Model primerov uporabe
AkterjiPrimeri uporabe
Ime Kratek opis Tokovi dogodkov Diagrami aktivnosti
in diagrami stanj Diagrami primerov
uporabe Posebne zahteve Pred-pogoji Po-pogoji Razširitvene točke
RUP – Zajem zahtev
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 430 -
RUP – zajem zahtev – Model primerov uporabe – primer opisa primera uporabe
Register for Courses Use Case 1. Brief Description
This use case allows a Student to register for course offerings in the current semester. The Student can also modify or delete course selections if changes are made within the add/drop period at the beginning of the semester. The Course Catalog System provides a list of all the course offerings for the current semester.
The main actor of this use case is the Student. The Course Catalog System is an actor within the use case.
2. Flow of Events
The use case begins when the Student selects the "maintain schedule" activity from the Main Form.
2.1 Basic Flow - Create a Schedule
1. The Student selects "create schedule." 2. The system displays a blank schedule form. 3. The system retrieves a list of available course offerings from the Course Catalog System. 4. The Student selects 4 primary course offerings and 2 alternate course offerings from the list of
available offerings. Once the selections are complete the Student selects "submit." 5. The "Add Course Offering" sub-flow is performed at this step for each selected course
offering. 6. The system saves the schedule.
2.2 Alternative Flows
2.2.1 Modify a Schedule
1. The Student selects "modify schedule." 2. The system retrieves and displays the Student's current schedule (e.g., the schedule
for the current semester). 3. The system retrieves a list of all the course offerings available for the current
semester from the Course Catalog System. The system displays the list to the Student.
4. The Student can then modify the course selections by deleting and adding new courses. The Student selects the courses to add from the list of available courses. The Student also selects any course offerings to delete from the existing schedule. Once the edits are complete the Student selects "submit".
5. The "Add Course Offering" sub-flow is performed at this step for each selected course offering.
6. The system saves the schedule.
2.2.2 Delete a Schedule
1. The Student selects the "delete schedule" activity. 2. The system retrieves and displays the Student current schedule. 3. The Student selects "delete." 4. The system prompts the Student to verify the deletion. 5. The Student verifies the deletion. 6. The system deletes the schedule.
2.2.3 Save a Schedule
Namesto alternativnega toka bi lahko za nekatere tokove uporabili tudi podtokove.
RUP – Zajem zahtev
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 431 -
RUP – zajem zahtev – Model primerov uporabe – primer opisa primera uporabe
2.2.3 Save a Schedule
At any point, the Student may choose to save a schedule without submitting it by selecting "save". The current schedule is saved, but the student is not added to any of the selected course offerings. The course offerings are marked as "selected" in the schedule.
2.2.4 Add Course Offering
The system verifies that the Student has the necessary prerequisites and that the course offering is open. The system then adds the Student to the selected course offering. The course offering is marked as "enrolled in" in the schedule.
2.2.5 Unfulfilled Prerequisites or Course Full
If in the "Add Course" sub-flow the system determines that the Student has not satisfied the necessary prerequisites or that the selected course offering is full, an error message is displayed. The Student can either select a different course offering or cancel the operation, at which point the use case is restarted.
2.2.6 No Schedule Found
If in the "Modify a Schedule" or "Delete a Schedule" sub-flows the system is unable to retrieve the Student's schedule, an error message is displayed. The Student acknowledges the error and the use case is restarted.
2.2.7 Course Catalog System Unavailable
If, the system is unable to communicate with the Course Catalog System after a specified number of tries, the system will display an error message to the Student. The Student acknowledges the error message and the use case terminates.
2.2.8 Course Registration Closed
If, when the student selects "maintain schedule", registration for the current semester has been closed, a message is displayed to the Student and the use case terminates. Students cannot register for courses after registration for the current semester has been closed.
3. Special Requirements
There are no special requirements associated with this use case.
4. Preconditions
4.1 Login
Before this use case begins the Student has logged onto the system.
5. Postconditions
There are no postconditions associated with this use case.
6. Extension Points
There are no extension points associated with this use case.
RUP – Zajem zahtev
Funkcionalnost Uporabnost Zanesljivost Učinkovitost Podpora Omejitve pri načrtovanju
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 432 -
RUP – zajem zahtev – dodatne specifikacije
Razvoj po objektnem pristopu Objektni pristop:
Osnovni principi objektne usmerjenosti; Jezik UML in proces RUP; Zajem zahtev; Objekta analiza in načrtovanje
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 433 -
Kje smo?
Objekta analiza in načrtovanje
Namen analize in načrtovanja je: Pretvoriti zahteve v načrt sistema; Razviti robustno arhitekturo sistema; Prilagoditi načrt izvedbenemu okolju.
Povezava z drugimi postopki: Poslovno modeliranje postavi organizacijski kontekst
sistema. Postopek zajema zahtev je primarni vhod v postopek
analize in načrtovanja. Postopek izvedbe realizira sistem na osnovi načrta, …
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 434 -
RUP – namen analize in načrtovanja
Objekta analiza in načrtovanje
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 435 -
RUP – Analiza in načrtovanje – primerjava analize in načrtovanja
Analiza
Se osredotoča na razumevanje problema
Idealizirano načrtovanje Obnašanje Struktura sistema Funkcijske zahteve Majhen model
Načrtovanje
Se osredotoči na razumevanje rešitve
Operacije in atributi Zmogljivost rešitve Blizu programski kodi Življenjski cikel objektov Nefunkcionalne zahteve Velik model
Objekta analiza in načrtovanjeRUP – Analiza in načrtovanje – vhodni in izhodni izdelki
Končen izdelek analize in načrtovanja
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 436 -
Analiza in načrtovanje
Dodatnespecifikacije
Model primerovuporabe
Slovar
Arhitekturasistema
Model načrta
Podatkovni model
e
Objekta analiza in načrtovanje
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 437 -
RUP – Analiza in načrtovanje – vloge
Arhitekt
Arhitekturasistema
Model načrta
Podatkovni modelNačrtovalec PB
Realizacijaprimera uporabe
Paket/Podsistem
Razred
Načrtovalec
Pregledovalecarhitekture
Pregledovalecnačrta
Objekta analiza in načrtovanje
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 438 -
RUP – Analiza in načrtovanje – koraki
Arhitekt Analizaarhitekture
Načrtarhitekture
Analiza sočasnostiin porazdeljenosti
Pregledarhitekture
Načrtovalec Analizaprimerovuporabe Načrtovanje
primerovuporabe
Načrtovanjepodsistemov
Načrtovanjerazredov
Preglednačrta
Pregledovalec arhitekture
Pregledovalec načrta
Razvoj po objektnem pristopu Objektni pristop:
Osnovni principi objektne usmerjenosti; Jezik UML in proces RUP; Objekta analiza in načrtovanje:
• Analiza arhitekture• Analiza primerov uporabe• Načrt arhitekture• Načrt primerov uporabe• Načrt podsistemov• Načrt razredov
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 439 -
Kje smo?
Objekta analiza in načrtovanje
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 440 -
Analiza arhitekture
Analiza arhitekture
Smernice za načrtovanje
Slovar
Dodatnespecifikacije
Arhitekturasistema
Model primerovuporabe
Poslovni model
Model načrta
Izbrani primeri uporabe za realizacijo
Objekta analiza in načrtovanje
Osnovni koraki aktivnosti analiza arhitekture sistema:
Identifikacija ključnih abstrakcij Analiza potreb po sistemskih storitvah Opredelitev arhitekturnih ravni
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 441 -
RUP – Koraki analize arhitekture
Objekta analiza in načrtovanje
V okviru identifikacije ključnih abstrakcij potrebno identificirati začetne razrede analize tipično gre za poslovne entitete ter povezave med
njimi – prikažemo z razrednim diagramom.
Vhodi: Znanje o domeni (vključno s poslovnim
modelom, če obstaja) Zahteve Slovar
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 442 -
RUP – Koraki analize arhitekture – Identifikacija ključnih abstrakcij
Razredi analize ali ključne abstrakcije
Objekta analiza in načrtovanje
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 443 -
RUP – Od razredov analize do izvedbenih elementov – komponent
Analiza Načrt Izvedba
Objekta analiza in načrtovanje
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 444 -
Primer ključnih abstrakcij
Študent
Predmet
Izpitni rokPrijava
Vpis
Nekaj ključnih abstrakcij s področja študijska informatike…
Študijski program
Objekta analiza in načrtovanje
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 445 -
Primer ključnih abstrakcij
Povezave med identificiranimi abstrakcijami…
Predmet
Izpitni rokPrijava
VpisŠtudijski program
Študent
Objekta analiza in načrtovanje
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 446 -
RUP – Koraki analize arhitekture – analiza potreb po sistemskih storitvah
Dodatnespecifikacije
Model primerovuporabe
Želena funkcionalnost Okolje implementacije
Arhitekt
Arhitekt je odgovoren za izbiro ustreznih načrtovalskih vzorcev za realizacijo potrebnih sistemskih storitev (dostop do relacijske podatkovne baze, uporaba digitalnih potrdil, obvladovanje transakcij,…
Objekta analiza in načrtovanje
Primeri sistemskih storitev: Trajnost Procesna komunikacija (IPC in RPC) Usmerjanje sporočil Porazdeljevanje Obvladovanje transakcij Nadzor nad procesi in sinhronizacija Varnost Odkrivanje, obravnavanje in poročanje o napakah …
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 447 -
RUP – Koraki analize arhitekture – analiza potreb po sistemskih storitvah
Objekta analiza in načrtovanje
V analizi arhitekturne potrebno pretehtati tiste arhitekturne vzorce, katerih izbira vpliva na visoko nivojsko organizacijo modela sistema.
Arhitekturne ravni predstavljajo aplikacijo z različnih nivojev abstrakcije. Nivoji potekajo od aplikacijskih ravni na vrhu do
izvedbenih (za določeno tehnologijo specifičnih) nivojev na dnu arhitekture.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 448 -
RUP – Koraki analize arhitekture – opredelitev arhitekturnih ravni
Objekta analiza in načrtovanje
Primeri arhitekturnih vzorcev: Model-view-controller: aplikacija je razdeljena na tri
dele: Model, ki vsebuje poslovna pravila in pripadajoče podatke, View, ki prikazuje, kako je informacija izpisana uporabniku in Controller-je, ki procesirajo uporabniške vhode.
Pipes and Filters: tok podatkov potuje skozi cevi od filtra do filtra. Vsak filter je korak procesiranja.
Blackboard: je vzorec sodelovanja neodvisnih specializiranih aplikacij nad skupno podatkovno strukturo za doseganje skupne rešitve.
… Aplikacija lahko uporablja več arhitekturnih
vzorcev…RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 449 -
RUP – Koraki analize arhitekture – opredelitev arhitekturnih ravni
Objekta analiza in načrtovanje
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 450 -
RUP – Koraki analize arhitekture – opredelitev arhitekturnih ravni
Poslovni podsistemi(Business specific)
Številni ponovno uporabni podsistemi, ki so specifični za aplikativna področja (npr. telekomunikacije, bančništvo itd.)
Aplikacijski podsistemi(Application subsystems)
Ločeni aplikacijski podsistemi, ki skupaj tvorijo aplikacijski sistem. Specifične aplikacije organizacije.
Vmesni nivo(Middleware)
Vmesni nivo sestavljajo razni pomožni podsistemi (utility classes) in sistemi, ki so od platforme neodvisni (npr. Storitve za porazdeljena in heterogena okolja)
Sistemska programska oprema(System software)
Zajema programsko opremo za dejansko infrastrukturo, npr. operacijski sistemi, vmesniki do specifičnih naprav ipd.
Objekta analiza in načrtovanje
Organizacijo arhitekturnih ravni pokažemo s paketi.
Paket je element modela, ki lahko vključuje druge elemente modela.
Uporaba: Organizacija modela v razvoju Enota upravljanja s konfiguracijami
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 451 -
RUP – Koraki analize arhitekture – opredelitev arhitekturnih ravni
Objekta analiza in načrtovanje
Paketi morajo biti organizirani v nivoje tako, da imamo na: zgornjih nivojih arhitekture aplikacijsko specifične
pakete, na spodnjih nivojih arhitekture strojno in operacijsko
odvisne pakete, na srednjih nivojih splošno namenske storitve.
Prednost takšne delitve je čista razdelitev odgovornosti. Aplikacije so bolj prožne in lažje prilagodljive.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 452 -
RUP – Koraki analize arhitekture – opredelitev arhitekturnih ravni
Objekta analiza in načrtovanje
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 453 -
RUP – Koraki analize arhitekture – opredelitev arhitekturnih ravni
Ciklične odvisnosti so nezaželene…
A
B
A
B
C
A
B
C
A’
Objekta analiza in načrtovanje
Arhitekturne plasti lahko modeliramo s pomočjo paketov in stereotipa <<layer>>
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 454 -
RUP – Koraki analize arhitekture – opredelitev arhitekturnih ravni
<<layer>>
Ime ravni
<<layer>>
Business Services
<<layer>>
Application
Razvoj po objektnem pristopu Objektni pristop:
Osnovni principi objektne usmerjenosti; Jezik UML in proces RUP; Objekta analiza in načrtovanje:
• Analiza arhitekture• Analiza primerov uporabe• Načrt arhitekture• Načrt primerov uporabe• Načrt podsistemov• Načrt razredov
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 455 -
Kje smo?
Objektna analiza in načrtovanje
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 456 -
Analiza arhitekture
Analiza primerov uporabe
Smernice za načrtovanje
Slovar
Dodatnespecifikacije
Arhitekturasistema
Model primerovuporabe
Izbrani primeri uporabe za realizacijo
Model načrta(dopolnjen)
Analizirani primeri uporabe
Razredi analize
Objektna analiza in načrtovanje
Osnovni koraki aktivnosti analiza primerov uporabe: Dopolnitev opisov primerov uporabe Identifikacija potrebnih razredov za realizacijo
posameznih primerov uporabe Razdelitev odgovornosti posameznim razredom Identifikacija povezav (in dodatnih atributov) med
razredi Podrobna analiza potrebnih sistemskih storitev Poenotenje razredov pridobljenih z analizo
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 457 -
RUP – Koraki analize primerov uporabe
Objektna analiza in načrtovanje
V okviru analize primerov uporabe opise posameznih primerov uporabe dopolnimo s podatki, potrebnimi za nadaljnji razvoj, ki jih že imamo na razpolago.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 458 -
RUP – Koraki analize primerov uporabe – dopolnitev opisov primerov uporabe
Sistem preveri veljavnost kreditne kartice.
Sistem preveri veljavnost kreditne kartice. Pri tem se poveže s sistemom “SKK” in uporabi njegovo spletno storitev “CardCheck”.
Objektna analiza in načrtovanje
Osnovni koraki aktivnosti analiza primerov uporabe: Dopolnitev opisov primerov uporabe Identifikacija potrebnih razredov za realizacijo
posameznih primerov uporabe Razdelitev odgovornosti posameznim razredom Identifikacija povezav (in dodatnih atributov) med
razredi Podrobna analiza potrebnih sistemskih storitev Poenotenje razredov pridobljenih z analizo
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 459 -
RUP – Koraki analize primerov uporabe
Objektna analiza in načrtovanje
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 460 -
Model Primerov Uporabe Model Načrta
Primer Uporabe Realizacija Primera Uporabe
Diagrami Razredov
Diagrami Zaporedja
Primer Uporabe
Diagrami sodelovanja
RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…
Objektna analiza in načrtovanje
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 461 -
<<entity>>
Dinamika primera uporabe mora biti v celoti dodeljena razredom, ki realizirajo ta primer uporabe
<<entity>>
<<boundary>><<boundary>>
<<control>>
RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…
Objektna analiza in načrtovanje Razredi analize:
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 462 -
RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…
<<entity>>
<<boundary>>
<<control>>
<<entity>>
<<boundary>>
Meja sistem
a
Objektna analiza in načrtovanje
Ikonski prikaz razredov analize:
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 463 -
RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…
Objektna analiza in načrtovanje
Mejni razred - <<boundary>>: Mejni razred je posrednik med okoljem in sistemom Ogradi sistem pred spremembami v okolici Odvisen od sprememb v okolju
Več vrst mejnih razredov: Razredi uporabniškega vmesnika Razredi sistemskega vmesnika Razredi vmesnika do naprav
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 464 -
RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…
Objektna analiza in načrtovanje
Mejni razredi modelirajo interakcijo med okoljem in sistemom
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 465 -
RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…
<<entity>>
<<boundary>>
<<control>>
<<entity>>
<<entity>>
<<boundary>>
<<boundary>>
Objektna analiza in načrtovanje
Identifikacija mejnih razredov: “en mejni razred za vsak par akter – primer uporabe”
Primer:
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 466 -
RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…
Kupi vstopnico Stranka Bančni sistem
<<boundary>>ZMStrankaKupiVstopnico
<<boundary>>SVBančniSistem
Objektna analiza in načrtovanje
Smernice za oblikovanje mejnih razredov: Razredi uporabniškega vmesnika:
• Kateri podatki so posredovani uporabniku?• Katere podatke posreduje uporabnik sistemu?• Prototipi zaslonskih mask so lahko dobra osnova za
načrtovanje razredov uporabniškega vmesnika Razredi sistemskega vmesnika in vmesnika do
naprav:• Kateri protokoli so potrebni za komunikacijo?• Če obstaja dobro definiran vmesnik do obstoječega
sistema oz. do naprave, odgovornosti mejnega razreda določimo na podlagi definicije tega vmesnika.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 467 -
RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…
Objektna analiza in načrtovanje
Poslovni razred - <<entity>>: Ključni koncept sistema, ki ga razvijamo Od okolja je neodvisen Hrani in upravlja podatke Navadno gre za trajen razred Njegovo obnašanje je strogo vezano na entiteto, ki jo
predstavlja Poslovni razred navadno ni vezan le na en primer
uporabe
V nekaterih primerih modeliramo tudi podatke o akterju, ki jih hranimo znotraj sistema, čeprav je akter izven sistema. Tak razred imenujemo tudi “zastopnik akterja” (surrogate).
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 468 -
RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…
Objektna analiza in načrtovanje
Poslovni razredi hranijo in upravljajo ključne podatke sistema
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 469 -
RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…
<<entity>>
<<boundary>>
<<control>>
<<entity>>
<<entity>>
<<boundary>>
<<boundary>>
Objektna analiza in načrtovanje
Identifikacija poslovnih razredov: postopek kot pri podatkovnem modeliranju – ključna abstrakcija sistema v kontekstu primera uporabe
Viri: ključne abstrakcije, tok primerov uporabe, slovar, poslovni model
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 470 -
RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…
Objektna analiza in načrtovanje
Primer:
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 471 -
RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…
Kupi vstopnico
<<entity>>Sedež <<entity>>
Vstopnica
<<entity>>Prireditev <<entity>>
Termin
Ključne abstrakcije
Slovar
<<entity>>Stranka
“Zastopnik”akterja Stranka
ImeRazreda<<stereotip>>
atribut : tip = začVrednostatribut : tip = začVrednostatribut : tip = začVrednost
IzbirniPredmet<<entity>>
predmetID :String=“100”začetek : Timekonec: TimešteviloDni: Enum
atribut
V analizi se na ukvarjaj s podpisi (signaturami) atributov
Objektna analiza in načrtovanjeRUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…
Objektna analiza in načrtovanje
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 473 -
RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…
Pri identifikaciji poslovnih razredov si lahko pomagamo z generalizacijo
Generalizacijo uporabimo, ko en razred predstavlja isto strukturo in obnašanja kot več drugih razredov
V analizi uporabljamo le med poslovnimi razredi
Računstanjeimeštevilka
Dvigni()Položi()
Osebni
Dvigni()
Varčevalni
VrniObresti()Dvigni()
Objektna analiza in načrtovanje
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 474 -
RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…
<<entity>>Prireditev
<<entity>>Dogodek
<<entity>>Trening
<<entity>>Tekma
<<entity>>Koncert
<<entity>>Film
Primer:
<<entity>>Zborovanje
Objektna analiza in načrtovanje
Sledi identifikacija povezav med poslovnimi razredi: V analizi iščemo povezave tipa asociacija Asociacija je strukturna povezava, ki modelira
pomensko povezavo med primerki razredov
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 475 -
RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…
Objektna analiza in načrtovanje Modelira pomensko povezavo med primerki
razredov
Enostavna povezava
<<entity>>Študent
<<entity>>Urnik
<<entity>>IzbirniPredmet
Rekurzivna povezava
je predpogoj za
<<entity>>Predmet
Asociacija je strukturna povezava
RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…
Objektna analiza in načrtovanje Vloga, ki jo igra razred v povezavi
Predpogoj
Nosilec predmeta
<<entity>>IzbirniPredmet
Vodja katedre
<<entity>>Profesor
<<entity>>Katedra
<<entity>>Predmet
Ime vloge
RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…
IzbirniPredmet<<entity>>
Urnik<<entity>>
glavniPredmet
dodatniPredmet
IzbirniPredmet<<entity>>
Urnik<<entity>> dodaj študenta
odstrani študenta
Vsaka povezava igra svojo vlogo
Objektna analiza in načrtovanjeRUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…
Objektna analiza in načrtovanje
2..4
0..1
1..*
0..*
1
*
Nedoločeno Točno ena Nič ali več (več,
neomejeno)
Ena ali več Nič ali ena Določen interval Več nepovezanih
intervalov2, 4..6
Števnost:RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…
Števnost
0..4
0..2glavniPredmet
dodatniPredmet
0..*
0..*0..*1<<entity>>
Študent<<entity>>
Urnik <<entity>>IzbirniPredmet
Objektna analiza in načrtovanjeRUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…
Neusmerjena
Usmerjena
Razred1 Razred2
Razred1 Razred2
Objektna analiza in načrtovanje
Razred1 vidi Razred2 in Razred 2 vidi Razred1. Drug od drugega sta odvisna.
Razred1 vidi Razred2, Razred2 pa Razreda1 ne vidi. Razred1 je odvisen od Razreda2,Razred2 pa od Razreda1 ni odvisen.
Navigacijo podrobneje določimo v fazi načrtovanja in ima pomembno vlogo pri implementaciji
Navigacija – usmerjenost povezave:RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…
Neusmerjena povezava
0..4
0..2glavniPredmet
dodatniPredmet
0..*
0..*
<<entity>>Urnik
<<entity>>IzbirniPredmet
Usmerjena povezava
1 1<<boundary>>ZMVpišiPredmet
<<control>>KVpišiPredmet
Objektna analiza in načrtovanjeRUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…
Objektna analiza in načrtovanje
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 483 -
RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…
<<entity>>Sedež
<<entity>>Vstopnica
<<entity>>Prireditev <<entity>>
TerminŠtevilkaVrstaTribuna
ImeOpis ZačetekTrajanje Status
Identifikacija atributov in povezav, ki modelirajo podatke poteka na enak način kot pri podatkovnem modeliranju
1**11 1..*
Primer:<<entity>>
Stranka
1
*
ImePriimek
Objektna analiza in načrtovanje
Kontrolni razred - <<control>>: Kontrolni razred koordinira dogajanje znotraj primera
uporabe. Sistem lahko izvaja nekatere primere uporabe tudi brez
kontrolnih razredov, vendar le takšne, ki obsegajo le enostavno rokovanje s shranjenimi podatki (npr. zapiši/ preberi atribut).
Bolj kompleksni primeri uporabe navadno zahtevajo enega ali več kontrolnih razredov, ki koordinirajo obnašanje objektov drugih razredov v sistemu.
Kontrolni razredi učinkovito ločijo mejne in poslovne razrede in s tem naredijo sistem še bolj odporen na spremembe v okolju.
Ločijo tudi obnašanje, ki je specifično za primer uporabe od poslovnih razredov, s čimer omogočijo ponovno uporabo poslovnih razredov v več primerih uporabe in celo različnih sistemih.RAZVOJ INFORMACIJSKIH SISTEMOV
Visokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 484 -
RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…
Objektna analiza in načrtovanje
Tipični primeri kontrolnih razredov: Razred za upravljanje transakcij (transaction manager) Razred za usklajevanje virov (resource manager) Razred za obvladovanje napak (error handler)
Kontrolni razredi modelirajo obnašanje, ki: je od okolice neodvisno - se ne spremeni, ko se spremeni
okolica. definira kontrolno logiko (vrstni red dogodkov) in
transakcije znotraj primerov uporabe - se le malo spreminja, če se spremeni struktura ali obnašanje poslovnih razredov.
hkrati deluje nad vsebino več poslovnih razredov, pri čemer kontrolni razred skrbi za koordinacijo.
se ob vsakem aktiviranju ne izvaja na enak način (tokovi dogodkov oblikujejo različna stanja).
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 485 -
RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…
Objektna analiza in načrtovanje
Kontrolni razred koordinira obnašanje primera uporabe
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 486 -
RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…
<<entity>>
<<boundary>>
<<control>>
<<entity>>
<<entity>>
<<boundary>>
<<boundary>>
Objektna analiza in načrtovanje
Identifikacija kontrolnih razredov: na začetku uporabimo pravilo “en kontrolni razred za vsak primer uporabe”
Primer:
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 487 -
RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…
Kupi vstopnico Stranka Bančni sistem
<<control>>KKupiVstopnico
Kupi vstopnico
Objektna analiza in načrtovanje
Navadno začnemo z identifikacijo enega kontrolnega razreda na realizacijo primera uporabe.
V nadaljevanju analize, ko izdelamo več realizacij pa upoštevamo naslednje: Nekateri kontrolni razredi lahko sodelujejo v več primerih
uporabe, če so naloge le-teh tesno povezane. Različni kontrolni razredi lahko sodelujejo v enem primeru
uporabe. Vsi primeri uporabe ne potrebujejo kontrolnega razreda. Na
primer, če je tok dogodkov v primeru uporabe vezan le na en poslovni razred, lahko že mejni razred v sodelovanju s poslovnim razredom realizira primer uporabe (ni potrebe po kompleksni koordinaciji).
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 488 -
RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…
Objektna analiza in načrtovanjeRUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…
Kupi vstopnico Stranka Bančni sistem
<<boundary>>ZMStrankaKupiVstopnico
<<boundary>>SVBančniSistem<<control>>
KKupiVstopnico
<<entity>>Sedež
ŠtevilkaVrstaTribuna
<<entity>>Termin
Začetek
<<entity>>Prireditev
ImeOpisTrajanje
<<entity>>Vstopnica
Status
1
*11
1..*1
* *<<entity>>Stranka
ImePriimek
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 489 -
*
Model primerov uporabe
Model načrta
Objektna analiza in načrtovanje
Vaja: Identificirajte razrede analize, ki nastopajo v okviru
določenega primera uporabe iz podane problemske domene.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 490 -
RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…
Objektna analiza in načrtovanje
Osnovni koraki aktivnosti analiza primerov uporabe: Dopolnitev opisov primerov uporabe Identifikacija potrebnih razredov za realizacijo
posameznih primerov uporabe Razdelitev odgovornosti posameznim razredom Identifikacija povezav (in dodatnih atributov) med
razredi Podrobna analiza potrebnih sistemskih storitev Poenotenje razredov pridobljenih z analizo
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 491 -
RUP – Koraki analize primerov uporabe
Objektna analiza in načrtovanje
Za vsak tok dogodkov v okviru primera uporabe: Ugotovimo kateri od identificiranih razredov v
okviru toka sodelujejo Dodelimo odgovornosti posameznim razredom in
prikažemo sodelovanje med objekti razredov
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 492 -
Diagrami ZaporedjaPrimer Uporabe
Diagrami sodelovanja
Realizacija primerov uporabe
RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav
Objektna analiza in načrtovanje
Dodeljevanje odgovornosti na podlagi stereotipov: Mejni razredi
• Dinamika primera uporabe, ki zajema komunikacijo z akterjem
Poslovni razredi• Dinamika primera uporabe, ki zajema podatke (poslovne)
Kontrolni razredi• Dinamika, ki je specifična za primer uporabe ali
pomembnejši del toka dogodkov
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 493 -
RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav
Objektna analiza in načrtovanje
Dodeljevanje odgovornosti na podlagi lokacije podatkov (tipično vprašanje pri poslovnih razredih): Če so vsi podatki v enem razredu - dodeli
odgovornost temu razredu (načelo OO – podatki in operacije skupaj).
Če so podatki razpršeni po več razredih:• Odgovornost dodeli enemu razredu ter vzpostavi
povezave z razredi, ki posedujejo podatke.• Kreiraj nov (kontrolni) razred in mu dodeli
odgovornost. Dodaj povezave na razrede s podatki.
• Odgovornost dodeli obstoječemu kontrolnemu razredu. Dodaj povezave na razrede s podatki.RAZVOJ INFORMACIJSKIH SISTEMOV
Visokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 494 -
RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav
Za podrobno opredelitev odgovornosti in povezav med razredi si pomagamo z diagrami interakcije: Diagrami zaporedja Diagrami sodelovanja
S pomočjo diagramov interakcije modeliramo tokove dogodkov
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 495 -
Objektna analiza in načrtovanjeRUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav
Alternativni tok 4 Alternativni tok 5 Alternativni tok n
Alternativni tok 1 Alternativni tok 2 Alternativni tok 3
AF1
AF2
AF3
Osnovni tok
Objektna analiza in načrtovanjeRUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav
Potrebnih je več diagramov interakcije
Diagrami sodelovanja– Poleg interakcije
kažejo tudi povezave– Boljši za prikaz
vzorcev sodelovanja– Boljši za prikaz vseh
učinkov na posamezen objekt
– Lažji za uporabo v fazi brainstorminga
Diagrami zaporedja– Eksplicitno kažejo
zaporedje sporočil– Boljši za prikaz
celotnega toka dogodkov
– Boljši za specifikacijo dogodkov, ki potekajo v realnem času ter zapletenih scenarijev
Objektna analiza in načrtovanjeRUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav
Objektna analiza in načrtovanje
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 498 -
1: IzvediOdgovornost
Objekt, ki uporablja storitev(predaja odgovornost)
Objekt, ki zagotavlja storitev(izvaja odgovornost)
Sporočilo
:Odjemalec
Fokus(aktivnost objekta)
Rekurzivno sporočilo
Življenjska črta objekta
1.1: IzvediDrugo Odgornost
Hierarhično številčenje
sporočil
:Ponudnik
DIAGRAMI ZAPOREDJA - UML
ČAS
RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 499 -
Ponavljaj za vse izbrane
sedeže
Ponavljaj za vse izbrane
sedeže
1: PričniNakup( )2: VrniSeznamPredstav( )
3: VrniSeznamPredstav( )4: PrikažiSeznamPredstav( )
5: IzberiPredstavo( )6: VrniPodrobnostiPredstave( )
7: VrniPodrobnePodatekOPredstavi( )
8: VrniSeznamterminovZaPredstavo( )9: PrikažiPodrobnostiInTerminePredstave( )
10: IzberiTermin( )11: VrniSeznamSedeževZaIzbranTermin( )
12: VrniSeznamSedeževInNjihovStatusZaTermin( )
13: VrniStatusZaTermin( )
14: PrikažiMatrikoProstihSedežev( )
15: IzberiSedeže( )16: RezervirajIzbraneSedeže( )
17: PreveriStatus( )
18: VrniStatusZaTermin( )
19: RezervirajSedežZaTermin( )
20: KreirajRezervacijoZaTermin( )21: ZahtevajVnosKKInImena( )
22: VnesiImeInKK( )23: ZaključiNakup( )
25: IzvediTransakcijo( )
24: IzračunajCeno( )
26: IzvediTransakcijo
27: ProdajSedežZaTermin( )
28: OznačiRezervacijoKotProdano( )
29: VrniŠtevilkoKarte( )
32: PrikažiSporočiloOUspešnemNakupuZRefŠt( )
:ZMStrankaKupiVstopnico :KKupiVstopnico :Prireditev
Kupec
:Termin :Vstopnica :Sedež
SKK
:SVBančniSistem
1: PričniNakup( )2: VrniSeznamPredstav( )
3: VrniSeznamPredstav( )4: PrikažiSeznamPredstav( )
5: IzberiPredstavo( )6: VrniPodrobnostiPredstave( )
7: VrniPodrobnePodatekOPredstavi( )
8: VrniSeznamterminovZaPredstavo( )9: PrikažiPodrobnostiInTerminePredstave( )
10: IzberiTermin( )11: VrniSeznamSedeževZaIzbranTermin( )
12: VrniSeznamSedeževInNjihovStatusZaTermin( )
13: VrniStatusZaTermin( )
14: PrikažiMatrikoProstihSedežev( )
15: IzberiSedeže( )16: RezervirajIzbraneSedeže( )
17: PreveriStatus( )
18: VrniStatusZaTermin( )
19: RezervirajSedežZaTermin( )
20: KreirajRezervacijoZaTermin( )21: ZahtevajVnosKKInImena( )
22: VnesiImeInKK( )23: ZaključiNakup( )
25: IzvediTransakcijo( )
24: IzračunajCeno( )
26: IzvediTransakcijo
27: ProdajSedežZaTermin( )
28: OznačiRezervacijoKotProdano( )
29: VrniŠtevilkoKarte( )
32: PrikažiSporočiloOUspešnemNakupuZRefŠt( )
Objektna analiza in načrtovanjeRUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav
Objektna analiza in načrtovanje
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 500 -
Fragmenti za prikazovanje podtokov, alternativnih tokov, zank na skupnem diagramu
RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav
Objektna analiza in načrtovanje
Diagrami zaporedja dobro prikazujejo zaporedje Tok dogodkov opisuje zaporedje akcij Diagrami zaporedja so zato zelo primerni za zapis
toka dogodkov v bolj formalni obliki Diagrami sodelovanja dobro prikazujejo
vzorce sodelovanja med objekti Dobra osnova za iskanje povezav med razredi in
odgovornosti razredov Diagrame zaporedja pretvorimo v
diagrame sodelovanja
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 501 -
RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav
1: IzvediOdgovornost
Sporočilo
Povezava
:Odjemalec
:Ponudnik
Objektna analiza in načrtovanje
Smer
Objekt, ki uporablja storitev(predaja odgovornost)
Objekt, ki zagotavlja storitev(izvaja odgovornost)
RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav
DIAGRAMI SODELOVANJA - UML
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 503 -
Objektna analiza in načrtovanjeRUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav
22: VnesiImeInKK( )15: IzberiSedeže( )
10: IzberiTermin( )5: IzberiPredstavo( )
1: PričniNakup( )
23: ZaključiNakup( )16: RezervirajIzbraneSedeže( )
11: VrniSeznamSedeževZaIzbranTermin( )6: VrniPodrobnostiPredstave( )
2: VrniSeznamPredstav( )
7: VrniPodrobnePodatekOPredstavi( )3: VrniSeznamPredstav( )
32: PrikažiSporočiloOUspešnemNakupuZRefŠt( )21: ZahtevajVnosKKInImena( )
14: PrikažiMatrikoProstihSedežev( )9: PrikažiPodrobnostiInTerminePredstave( )
4: PrikažiSeznamPredstav( )
8: VrniSeznamterminovZaPredstavo( )
27: ProdajSedežZaTermin( )19: RezervirajSedežZaTermin( )
17: PreveriStatus( )12: VrniSeznamSedeževInNjihovStatusZaTermin( )
29: VrniŠtevilkoKarte( )28: OznačiRezervacijoKotProdano( )
20: KreirajRezervacijoZaTermin( )18: VrniStatusZaTermin( )
13: VrniStatusZaTermin( )
24: IzračunajCeno( )25: IzvediTransakcijo( )
26: IzvediTransakcijo
Kupec
:ZMStrankaKupiVstopnico
:KKupiVstopnico
:Prireditev
:Termin
:Sedež
:Vstopnica
:SVBančniSistem
SKK
Objektna analiza in načrtovanje
Na podlagi diagrama sodelovanja razdelimo odgovornosti
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 504 -
RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav
// IzvediOdgovornost
:Odjemalec :Ponudnik
Ponudnik
// IzvediOdgovornost
Diagram sodelovanja
Diagram razredov
Objektna analiza in načrtovanje
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 505 -
RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav
1..1
0..*
1..1
0..*
1..1
0..*
1..1
0..*
<<boundary>>
ZMStrankaKupiVstopnico
PričniNakup ()PrikažiSeznamPredstav ()IzberiPredstavo ()PrikažiPodrobnostiInTerminePredstave ()IzberiTermin ()PrikažiMatrikoProstihSedežev ()IzberiSedeže ()ZahtevajVnosKKInImena ()VnesiImeInKK ()PrikažiSporočiloOUspešnemNakupuZRefŠt ()
<<boundary>>
SVBančniSistem
IzvediTransakcijo ()
<<control>>
KKupiVstopnico
VrniSeznamPredstav ()VrniPodrobnostiPredstave ()VrniSeznamSedeževZaIzbranTermin ()RezervirajIzbraneSedeže ()ZaključiNakup ()IzračunajCeno ()
<<entity>>
PrireditevImeOpisTrajanje
VrniSeznamPredstav ()VrniPodrobnePodatekOPredstavi ()
<<entity>>
TerminZačetek
VrniSeznamterminovZaPredstavo ()
<<entity>>
StrankaImePriimek
<<entity>>
SedežŠtevilkaVrstaTribuna
VrniSeznamSedeževInNjihovStatusZaTermin ()PreveriStatus ()RezervirajSedežZaTermin ()
<<entity>>
VstopnicaStatus
VrniStatusZaTermin ()KreirajRezervacijoZaTermin ()OznačiRezervacijoKotProdano ()VrniŠtevilkoKarte ()
Objektna analiza in načrtovanje
Preverimo skladnost: Odvečne odgovornosti (iz vidika vseh razredov) Nepovezane odgovornosti znotraj enega razreda
(dva razreda?) Razredi z eno samo odgovornostjo (ali so potrebni?) Razredi brez odgovornosti (nihče ne potrebuje?!) Boljše porazdelitve odgovornosti Razredi, ki so v interakciji z mnogimi drugimi razredi
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 506 -
RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav
Objektna analiza in načrtovanje
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 507 -
RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav
1..1
0..*
1..1
0..*
1..1
0..*
1..1
0..*
<<boundary>>
ZMStrankaKupiVstopnico
PričniNakup ()PrikažiSeznamPredstav ()IzberiPredstavo ()PrikažiPodrobnostiInTerminePredstave ()IzberiTermin ()PrikažiMatrikoProstihSedežev ()IzberiSedeže ()ZahtevajVnosKKInImena ()VnesiImeInKK ()PrikažiSporočiloOUspešnemNakupuZRefŠt ()
<<boundary>>
SVBančniSistem
IzvediTransakcijo ()
<<control>>
KKupiVstopnico
VrniSeznamPredstav ()VrniPodrobnostiPredstave ()VrniSeznamSedeževZaIzbranTermin ()RezervirajIzbraneSedeže ()ZaključiNakup ()IzračunajCeno ()
<<entity>>
PrireditevImeOpisTrajanje
VrniSeznamPredstav ()VrniPodrobnePodatekOPredstavi ()
<<entity>>
TerminZačetek
VrniSeznamterminovZaPredstavo ()
<<entity>>
StrankaImePriimek
<<entity>>
SedežŠtevilkaVrstaTribuna
VrniSeznamSedeževInNjihovStatusZaTermin ()PreveriStatus ()RezervirajSedežZaTermin ()
<<entity>>
VstopnicaStatus
VrniStatusZaTermin ()KreirajRezervacijoZaTermin ()OznačiRezervacijoKotProdano ()VrniŠtevilkoKarte ()
? razred brez odgovornosti
Objektna analiza in načrtovanje
Sledi identifikacija preostalih povezav: V analizi iščemo povezave tipa asociacija Nekatere povezave (zlasti med poslovnimi razredi)
smo že identificirali – po potrebi jih le še dopolnimo V načrtovanju lahko nekatere od asociacij pretvorimo
v odvisnosti, saj so enostavnejše za implementacijo – tipično gre za asociacije med mejnimi in kontrolnimi oz. kontrolnimi in poslovnimi razredi
V okviru podrobnejšega opredeljevanja povezav preverimo tudi druge vidike povezav – kot npr. odnos celota/del
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 508 -
RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav
Celota/agregat del
0..4
0..2glavniPredmet
dodatniPredmet
0..*
0..*0..*1<<entity>>
Študent<<entity>>
Urnik <<entity>>IzbirniPredmet
Objektna analiza in načrtovanje
Agregacija: modelira odnos celota - delRUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav
Ko si v dvomih, uporabi asociacijo
asociacija
agragacija
Razred1 Razred2
Razred1 Razred2
Objektna analiza in načrtovanje Premislek
Kontekst, neodvisnost delov od celote?
RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav
Objektna analiza in načrtovanje
Agregacija modelira “šibko lastništvo”: Del je lahko del več celot. Del lahko obstaja dlje kot obstaja celota. Tudi če
celoto uničimo, del ostane.
“Močna oblika” agregacije je kompozicija: Del je lahko del le ene celote. Del lahko obstaja le dokler obstaja celota. Če celoto
uničimo, uničimo tudi vse njene dele.
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 511 -
RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav
Objektna analiza in načrtovanje
Kompozicija:
Diskusija - kompozicija ali agregacija?
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 512 -
RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav
kompozicijaRazred1 Razred2
0..*1<<entity>>Študent
<<entity>>Urnik
?
Objektna analiza in načrtovanjeRUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav
Primera:
Kakšna je števnost?
Objektna analiza in načrtovanje Asociacijski razred:
Razred, povezan s povezavo
Vsebuje lastnosti povezave
En primerek na povezavo
UrnikIzbirniInfostatus
// označi kot izbran()// označi kot neizbran()// ali je izbran?()
<<entity>>
IzbirniPredmet<<entity>>
Urnik<<entity>>
0..*0..4
glavniPredmet
dodatniPredmet0..* 0..2
UrnikGlavniIzbirniInfoocena
// ali je izdelal?()// vnesi oceno()// vrni oceno()
<<entity>>
RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav
Diskusija: Ali bi kje postavili kompozicijo/asociacijo?
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 515 -
Objektna analiza in načrtovanjeRUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav
1..1
0..*
1..1
0..*
1..1
0..*
<<entity>>
PrireditevImeOpisTrajanje
VrniSeznamPredstav ()VrniPodrobnePodatekOPredstavi ()
<<entity>>
TerminZačetek
VrniSeznamterminovZaPredstavo ()
<<entity>>
SedežŠtevilkaVrstaTribuna
VrniSeznamSedeževInNjihovStatusZaTermin ()PreveriStatus ()RezervirajSedežZaTermin ()
<<entity>>
Vstopnica
Status
VrniStatusZaTermin ()KreirajRezervacijoZaTermin ()OznačiRezervacijoKotProdano ()VrniŠtevilkoKarte ()
1: izvediOdgovornost
Povezava
0..*
Osnovni ponudniki0..*
:Odjemalec :Ponudnik
Odejmalec Ponudnik
izvediOdgovornost()
Povezava v diagramu sodelovanja pomeni povezavo v razrednem diagramu !
Objektna analiza in načrtovanje
Navigacija (pogojno!)
Diagram sodelovanja
Razredni diagram
RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav
Objektna analiza in načrtovanje
Podrobna opredelitev asociacije: Navigacija:
• Če vsa sporočila na vseh diagramih, ki prikazujejo interakcijo med objektoma dveh razredov potekajo le v eno smer, lahko povezavo usmerimo.
• Upoštevamo VSE tokove dogodkov. Števnost:
• Števnosti med poslovnimi razredi smo že določili.• Pri ostalih razredih je vprašanje enako: koliko primerkov
enega razreda (objektov) bo hkrati v interakciji s primerkom drugega razreda (objekta) in obratno.
• Pogoste števnosti med mejnimi in kontrolnimi razredi so: 0..1 in 1..1. Vendar se lahko pojavljajo tudi drugačne števnosti!
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 517 -
RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav
Objektna analiza in načrtovanje
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 518 -
RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav
Dia
gram
VO
PC –
Vie
w o
f par
tici
pati
on c
lass
esPo
gled
na
razr
ede,
ki s
odel
ujej
o v
prim
eru
upor
abe
1..1
0..*
1..1
0..*
1..1
0..*
0..1
0..*
0..1
0..*
0..1
0..*
1..1
0..11..1
1..1
<<boundary>>
ZMStrankaKupiVstopnico
PričniNakup ()PrikažiSeznamPredstav ()IzberiPredstavo ()PrikažiPodrobnostiInTerminePredstave ()IzberiTermin ()PrikažiMatrikoProstihSedežev ()IzberiSedeže ()ZahtevajVnosKKInImena ()VnesiImeInKK ()PrikažiSporočiloOUspešnemNakupuZRefŠt ()
<<boundary>>
SVBančniSistem
IzvediTransakcijo ()
<<control>>
KKupiVstopnico
VrniSeznamPredstav ()VrniPodrobnostiPredstave ()VrniSeznamSedeževZaIzbranTermin ()RezervirajIzbraneSedeže ()ZaključiNakup ()IzračunajCeno ()
<<entity>>
Prireditev
ImeOpisTrajanje
VrniSeznamPredstav ()VrniPodrobnePodatekOPredstavi ()
<<entity>>
Termin
Začetek
VrniSeznamterminovZaPredstavo ()
<<entity>>
SedežŠtevilkaVrstaTribuna
VrniSeznamSedeževInNjihovStatusZaTermin ()PreveriStatus ()RezervirajSedežZaTermin ()
<<entity>>
VstopnicaStatus
VrniStatusZaTermin ()KreirajRezervacijoZaTermin ()OznačiRezervacijoKotProdano ()VrniŠtevilkoKarte ()
Objektna analiza in načrtovanje
Osnovni koraki aktivnosti analiza primerov uporabe: Dopolnitev opisov primerov uporabe Identifikacija potrebnih razredov za realizacijo
posameznih primerov uporabe Razdelitev odgovornosti posameznim razredom Identifikacija povezav (in dodatnih atributov) med
razredi Podrobna analiza potrebnih sistemskih storitev Poenotenje razredov pridobljenih z analizo
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 519 -
RUP – Koraki analize primerov uporabe – sistemske storitve
Razred analize Sistemska storitev
Objektna analiza in načrtovanje
Sestavi seznam vseh potrebnih sistemskih storitev
Sestavi seznam razredov, ki potrebujejo sistemske storitve
Opiši lastnosti sistemskih storitev
RUP – Koraki analize primerov uporabe – sistemske storitve
Razred Sistemska storitev
PrireditevTermin
Vstopnica
Sedež
KKupiVstopnico
Trajnost
Trajnost, Varnost?
Trajnost
Porazdelitev
Trajnost
Objektna analiza in načrtovanje
Preslikava med razredi in sistemskimi storitvami
RUP – Koraki analize primerov uporabe – sistemske storitve
Objektna analiza in načrtovanje Lastnosti sistemskih storitev Trajnost za razred Vstopnica:
Granulacija: od 15 do 25 bajtov Kapaciteta: do 10.000.000 vstopnic Pogostost dostopa
Kreiranje: do 10.000 na dan Branje: do 50.000 na uro Spreminjanje: do 500 na dan Brisanje: do 50 na dan
Itd.
RUP – Koraki analize primerov uporabe – sistemske storitve
Objektna analiza in načrtovanje
Kakšne bi bile lahko lastnosti trajnosti za razred Predstava? Granulacija? Kapaciteta? Pogostost dostopa?
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 523 -
RUP – Koraki analize primerov uporabe – sistemske storitve
Objektna analiza in načrtovanje
Osnovni koraki aktivnosti analiza primerov uporabe: Dopolnitev opisov primerov uporabe Identifikacija potrebnih razredov za realizacijo
posameznih primerov uporabe Razdelitev odgovornosti posameznim razredom Identifikacija povezav (in dodatnih atributov) med
razredi Podrobna analiza potrebnih sistemskih storitev Poenotenje razredov pridobljenih z analizo
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 524 -
RUP – Koraki analize primerov uporabe
Pono
vim
o za
vsa
k pr
imer
upo
rabe
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 525 -
Objektna analiza in načrtovanjeRUP – Koraki analize primerov uporabe
Objektna analiza in načrtovanje
Osnovni koraki aktivnosti analiza primerov uporabe: Dopolnitev opisov primerov uporabe Identifikacija potrebnih razredov za realizacijo
posameznih primerov uporabe Razdelitev odgovornosti posameznim razredom Identifikacija povezav (in dodatnih atributov) med
razredi Podrobna analiza potrebnih sistemskih storitev Poenotenje razredov pridobljenih z analizo
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 526 -
RUP – Koraki analize primerov uporabe – poenotenje
<<control>>
<<boundary>>
<<entity>><<entity>>
Objektna analiza in načrtovanjeRUP – Koraki analize primerov uporabe – poenotenje
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 528 -
Objektna analiza in načrtovanjeRUP – Koraki analize primerov uporabe - poenotenje
Rezultat poenotenja razredov je enoten načrt. Pogledi VOPC še
vedno ostanejo, vendar uporabljajo skupne razrede.
Dodatne Specifikacije
Slovar
Model Primerov Uporabe
Model Načrta
Razredi Analize
Objektna analiza in načrtovanjeRUP – Koraki analize primerov uporabe – poenotenje
Objektna analiza in načrtovanje
Razredne diagrame lahko pretvorimo v kodo
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 530 -
Od razreda do kode
1..1
0..*
1..1
0..*
1..1
0..*
0..1
0..*
0..1
0..*
0..1
0..*
1..1
0..11..1
1..1
<<boundary>>
ZMStrankaKupiVstopnico
PričniNakup ()PrikažiSeznamPredstav ()IzberiPredstavo ()PrikažiPodrobnostiInTerminePredstave ()IzberiTermin ()PrikažiMatrikoProstihSedežev ()IzberiSedeže ()ZahtevajVnosKKInImena ()VnesiImeInKK ()PrikažiSporočiloOUspešnemNakupuZRefŠt ()
<<boundary>>
SVBančniSistem
IzvediTransakcijo ()
<<control>>
KKupiVstopnico
VrniSeznamPredstav ()VrniPodrobnostiPredstave ()VrniSeznamSedeževZaIzbranTermin ()RezervirajIzbraneSedeže ()ZaključiNakup ()IzračunajCeno ()
<<entity>>
Prireditev
ImeOpisTrajanje
VrniSeznamPredstav ()VrniPodrobnePodatekOPredstavi ()
<<entity>>
TerminZačetek
VrniSeznamterminovZaPredstavo ()
<<entity>>
SedežŠtevilkaVrstaTribuna
VrniSeznamSedeževInNjihovStatusZaTermin ()PreveriStatus ()RezervirajSedežZaTermin ()
<<entity>>
Vstopnica
Status
VrniStatusZaTermin ()KreirajRezervacijoZaTermin ()OznačiRezervacijoKotProdano ()VrniŠtevi lkoKarte ()
nit main;
interface
uses Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, Grids, ExtCtrls, StdCtrls, Buttons, NxScrollControl, NxCustomGridControl, NxCustomGrid, NxGrid, NxColumns, NxColumnClasses, ComCtrls;
type T1to9 = set of 1..9; TMatrix = array[1..9, 1..9] of T1to9; TRows = array[1..9, 1..9] of byte; TCols = array[1..9, 1..9] of byte;
type Tf_main = class(TForm) Panel1: TPanel; Panel2: TPanel; bb_solve: TBitBtn; sg_Possibilities: TStringGrid; bb_load: TBitBtn; bb_save: TBitBtn; bb_clear: TBitBtn; b_chkrow: TButton; b_chkcol: TButton; ng_TablePlate: TNextGrid; b_SetGrid: TButton; col1: TNxTextColumn; col2: TNxTextColumn; col3: TNxTextColumn; col4: TNxTextColumn; col5: TNxTextColumn; col6: TNxTextColumn; col7: TNxTextColumn; col8: TNxTextColumn; col9: TNxTextColumn; sd_save: TSaveDialog; od_open: TOpenDialog; Button1: TButton; b_solveRest: TButton; sg_steps: TStringGrid; procedure bb_loadClick(Sender: TObject); procedure bb_clearClick(Sender: TObject); procedure b_chkrowClick(Sender: TObject); procedure b_chkcolClick(Sender: TObject); procedure b_SetGridClick(Sender: TObject); procedure bb_saveClick(Sender: TObject); procedure Button1Click(Sender: TObject); procedure b_solveRestClick(Sender: TObject); private { Private declarations } procedure CheckCell( x, y: byte ); procedure CheckRow( x: byte ); procedure CheckCol( y: byte ); …
Razred z atributi in metodami
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 531 -
Student- name: String
+ addSchedule (theSchedule: Schedule, forSemester: Semester)+ hasPrerequisites(forCourseOffering: CourseOffering) : boolean# passed(theCourseOffering: CourseOffering) : boolean
public class Student{
private String name;public void addSchedule (Schedule theSchedule; Semester forSemester) { }public boolean hasPrerequisites(CourseOffering forCourseOffering) { }protected boolean
passed(CourseOffering theCourseOffering) { }}
Podporni in globalni razredi
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 532 -
<<utility>>
MathPack
- randomSeed : long = 0- pi : double = 3.14159265358979
+sin (angle : double) : double+cos (angle : double) : double+random() : double
import java.lang.Math;import java.util.Random;class MathPack { private static randomSeed long = 0; private final static double pi = 3.14159265358979; public static double sin(double angle) { return Math.sin(angle); } public static double cos(double angle) { return Math.cos(angle); } public static double random() {
return new Random(seed).nextDouble(); }}
Asociacija
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 533 -
Schedule
Student
class Schedule{ public Schedule() { } private theStudent;}
class Student{ public Student() { } private Schedule theSchedule;}
Enosmerna asociacija
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 534 -
Student
Schedule
class Student{ public Student() { } private Schedule theSchedule;}
class Schedule{ public Schedule() { }}
Vloge pri asociaciji
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 535 -
class Professor {public Professor() {}private CourseOffering theCourseOffering;}
class CourseOffering{public CourseOffering () {}private Professor instructor;}
Professor
CourseOffering
instructor
Števnost asociacij
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 536 -
class Schedule{public Schedule() {}private CourseOffering[]
primaryCourses =new CourseOffering[4]
}
class CourseOffering{public CourseOffering() {}}
Schedule
CourseOffering
0..4 primaryCourses
Vmesni razred
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 537 -
Schedule CourseOfferingprimaryCourses
alternateCourses0..4
0..20..*0..*
ExaminationInfo- grade: Char = I
Schedule ExaminationInfo CourseOfferingalternateCourses 0..20..*
0..41ExaminationInfo
- grade: Char = I
Realizacija vmesnega razreda je stvar odločitve v načrtovanju
Vmesni razred - realizacija
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 538 -
class ExaminationInfo{ public ExaminationInfo() {}
public CourseOffering get_theCourseOffering(){ return theCourseOffering; } public void set_theCourseOffering(CourseOffering toValue){ theCourseOffering = toValue; } private char get_Grade (){ return grade; } private void set_Grade(char toValue) { grade = toValue; } private char grade = ‘I’; private CourseOffering theCourseOffering;}
Schedule ExaminationInfo CourseOfferingalternateCourses 0..20..*
0..41ExaminationInfo
-grade: Char = I…
…
Rekurzivna asociacija
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 539 -
import java.util.Vector;
class Course { public Course() {} // The unbounded multiple association // is stored in a vector private Vector prerequisites;}
Course
prerequisites
0..*
Agregacija
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 540 -
class Schedule{public Schedule() { }private Student theStudent;}
import java.util.Vector;
class Student{ public Student() { } private Vector theSchedule;}
1
Schedule
Student
0..*
Java nima eksplicitnega konstrukta za agregacijo.
Generalizacija (dedovanje)
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 541 -
class GroundVehicle{ public int licenseNumber; public void register() { }}
class Truck extends GroundVehicle{ public float tonnage; public void getTax() { }}
GroundVehicle
Truck
0..*+ licenceNumber: int+ register()
+ tonnage: float
+ getTax()
1
Abstraktni razredi
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 542 -
abstract class Animal { public abstract void talk();}
Animal{Abstract}
Lion
+ talk () {abstract}
+ talk ()
Tiger+ talk ()
class Tiger extends Animal{ public Tiger() { } public void talk() { }}
Poglavje IVModelno usmerjen razvoj
RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko
- 543 -
MDA – Model Driven Architecture in MDD – Model-Driven Development. Razlike med MDA/MDD in klasičnim pristopom k razvoju IS
Razlogi za pojav pristopa Vedno večje število različnih implementacijskih
tehnologij, hiter razvoj, menjava, … Razvijalci se morajo specializirati za ozka
področja, ki se pogosto spreminjajo Že med izdelavo sistema se pojavljajo nove,
boljše različice tehnologij Prehod na drugo tehnologijo pogosto pomeni,
da je potrebno aplikacijo razviti na novo oz. so potrebne obsežne prilagoditve
Možnost za izboljšanje: Razvoj PO na podlagi modelov?
Model Driven Development Dvig nivoja abstrakcije, na katerem nastaja
programska oprema Razvijalci naj se posvetijo predvsem
funkcijam sistema, ne pa tehnološkim podrobnostim
Opis funkcionalnosti na visokem abstraktnem nivoju, neodvisnem od uporabljene platforme in tehnologije
Opis sistema z uporabo vizualnih modelov Ideja MDD ni nova (npr. podat.
modeliranje)
Model Driven Architecture… Model Driven Architecture:
je standardizirano ogrodje za razvoj programske opreme na podlagi modelov, nastal v okviru OMG
predvideva avtomatizirano transformacijo visoko abstraktnih modelov v modele na nižjem nivoju abstrakcije in nato teh v delujočo kodo
ne predpisuje konkretnih tehnik za opis modelov, predlaga uporabo UML + OCL (nova različica za podporo MDA), obstajajo tudi druge možnosti
Model Driven Architecture MDA predvideva tri osnovne vrste modelov
glede na njihovo stopnjo abstrakcije: PIM (platform independent model) je model na
visokem abstraktnem nivoju PSM (platform specific model) je model na nivoju, ki
upošteva konstrukte implementacije Programska koda je model na najnižjem nivoju, ki jo
je mogoče pretvoriti v izvedljivo kodo oziroma jo interpretirati
Predvideva transformacije med modeli, ki naj bi bile avtomatizirane…
Model Driven Architecture - koncept
Tehnologija/platforma yTehnologija/platforma x
PIM
PSM x PSM y
Delujoča izvorna koda sistema
Koda x Koda y
PIM → PSM x PIM → PSM y
PSM y → K yPSM x → K x
Most med PSM x in PSM y
Most med Kodo x in Kodo y
CIM
Kritike MDA Ni učinkovitega jezika za zapis PIM Ni učinkovitih transformacijskih orodij
(delno generiranje ni dovolj) Standardi MDA so v začetni fazi razvoja Z uporabo sodobnih razvojnih orodij,
ogrodij in procesov je moč produktivnost povečati že v okviru klasičnega razvoja
Primerjava klasičnega razvoja in MDD…
MDD
Klasičen razvoj
Zajem zahtev Analiza Načrtovanje Kodiranje
Večinoma besedilo
Diagrami in besedilo
Diagrami in besedilo
Koda
……
Zajem zahtev Načrtovanje – tran. PIM v PSM
Kodiranje – tran. PSM v Kodo
Večinoma besedilo
PIM PSM Koda
……
generiranje
Analiza – izdelava PIM
V MDD je bistvena izdelava PIM in izbira ustreznih implementacijskih tehnologij, precej pa se zmanjša pomen klasičnega kodiranja.
Poveča se pomen analitičnih vlog in hkrati zmanjša pomen vlog implementacije
Nekaj možnih novih vlog: Analitik in načrtovalec PIM na podlagi izdelkov zajema zahtev ter
izdelkov poslovnega modeliranja izdelata model PIM. Izdelovalec PSM s pomočjo orodja za transformiranje PIM pretvori
v enega ali več modelov PSM. Pred transformacijo mora izbrati ciljne platforme, arhitekture, vzorce, tehnologije itd.
Razvijalec definicij transformacij je vloga, ki skrbi za izdelavo definicij transformacij za transformacijska orodja.
Primerjava klasičnega razvoja in MDD…
Razvijalec def. transformacij
Transformacijsko orodje
Orodje za izdelavo / preverjanje definicije
transformacije
PSM
Analitik in načrtovalec PIM
Izdelovalec PSM
Definicija transformacije
Orodje za modeliranje / izdelavo / preverjanje PIM
PIM
izdela
izdela
Izbira platform, arhitektur, vzorcev,
nastavitve orodja itd. izbere, določi z orodjem
generira
Pregled prednosti in slabosti MDA MDD prinaša vrsto prednosti že v današnji
obliki: višja produktivnost zaradi generiranja (celo
do 40%) boljša arhitektura zaradi razvoja na višjem
nivoju abstrakcije višja stopnja skladnosti nastale kode v prihodnosti naj bi MDD potekal tako, kot
danes delujejo prevajalniki programskih jezikov
Pregled prednosti in slabosti MDA Na drugi strani pa ne smemo zanemariti
kritik: Predpogoj za uspeh MDD (MDA) je ustrezen
jezik za zapis PIM. MDD bo uporaben šele s 100%
generiranjem kode. Pravi MDD s trenutnimi tehnologijami ni
izvedljiv, delni MDD pa ne prinaša nobene bistvene prednosti.
Implikacije morebitne uveljavitve MDA Uveljavitev MDA v praksi bi prinesla
vrsto sprememb: Vloge:
nove vloge, nova znanja manjši pomen vlog implementacije večji pomen vlog analize
Proces: več časa za analizo in zajem zahtev velik del klasičnih aktivnosti implementacije bi
izvedla orodja (generiranje) bližje zaporednemu (slapovnemu) razvoju
Osrednji pomen bi dobili izdelki analize, ki bi med drugim predstavljali tudi “izvorno kodo”.
Velik pomen orodij za generiranje.
MDA in podpora orodij… Orodja za razvoj na podlagi MDA:
orodja za preslikavo iz PIM v PSM orodja za preslikavo PSM v kodo orodja za preslikavo PIM v kodo prilagodljiva transformacijska orodja orodja za definiranje transformacij
Današnja orodja dajo dovolj ugodnosti, ki jih ponuja MDA, da bi bila uporabna.
Poln potencial MDA še ni dosežen!
MDA in podpora orodij… Orodja, ki imajo dostopno evaluacijsko
verzijo: Compuware OptimalJ ObjectFrontier FronierSuite professional InnoQ iQgen Interactive Objects Software ArcStyler Objecteering Objecteering/UML Metanology MDE Aonix Ameos Codagen Technologies Codagen Architect 3.2 Rational Software Architect
Uradni seznam zavezanih družb in skupin na uradni strani o razvoju MDA organizacije OMG
MDA in podpora orodij Primeri orodij:
Teleologic TAU Generation2 Sosy OlivaNova Model Execution System Tata Consultancy Services MasterCraft Consyst REP++Studio Borland Delphi 8